On Sat, Jan 14, 2017 at 8:01 AM, Michael Ira Krufky <mkrufky@xxxxxxxxxxx> wrote: > > On Fri, Jan 13, 2017 at 11:56 PM, Justin Husted <valentinej@xxxxxxxxx> wrote: > > Hi! > > > > I recently got one of these cards on ebay to do some analog video capturing, > > and I'm having a few problems with it on the 4.4.0 kernel. > > > > I wasn't really sure who the maintainer is for this stuff, but I saw your > > name in the Linux MAINTAINERS file for the tda18271, which seems to be one > > of the relevant drivers. :-) > > > > Are you the person to talk to, or do you know who is? > > Justin, > > Better to email the linux-media mailing list on kernel.org with this > type of question (cc added) Ok, thanks! > What is the problem that you're having in the 4.4.0 kernel? There are two fundamental problems. Note that I'm just attempting to use this card as an analog video capture card, using the RCA plug. == Sleep / Reference Leak == The first problem is less important, but is clearly annoying: the card does not work after sleep/resume, and I can't try the typical approach of adding a special module unload/reload rule because it appears to have a reference leak. I'm seeing that there is (usually) one reference to cx25840 and cx23885 at all times, plus extra references if a capture is actually going on. However, it is also somewhat unreliable, so occasionally there isn't a reference to the driver and I'm able to unload/reload it (but it still doesn't work). == Interlaced Video Capture == The second problem is the more important one: It seems like the interlaced video capture I'm receiving via various tools has something wrong with it. I'm not sure precisely how to characterize this. Basically, what I first noticed was that after deinterlacing, it looked as if each pair of lines in the output was reversed, leading to an extremely vertically pixelated result. I attempted to investigate, and basically what I'm seeing is that the interlaced video frames (720x480 @ 29.97 fps) appear as if they're in an inverted pattern in the output, like 214365.... Ok! I think, maybe they're in bff rather than tff format. I then attempted to change my capture settings (I've been using vlc, ffmpeg, mplayer, and cheese to try to debug), and found that occasionally this seemed to help, but it would invariably not work reliably. I then attempted capturing with a variety of different deinterlacing schemes. I found with a bob deinterlacer that it seemed like the video would switch modes, jumping every few seconds up and down a little. The next thing I tried was to extract the interlaced fields and produce a 59.94 hz stream, so I could frame by frame it. What was most notable about this was that it seemed like in high-motion scenes, the motion would actually jump backwards in time by a few frames, instead of the fields each showing an A-B-C-D-E-F or B-A-D-C-F-E pattern like I expected. So, basically, it seemed to me almost like this driver is mis-managing its video buffers. I don't know how the internal hardware interface works (I mean seriously, I wasn't even sure which driver programs the analog video chip...), so I wasn't sure if it was plausible that perhaps the driver is reading the video stream one field at a time and then composing them in the wrong order or something crazy like that. Regardless, the card doesn't really seem to be usable for NTSC video capture with this driver. > Which is the most recent kernel that works for you correctly? I just picked up this card recently (I need to transfer old video tape), and haven't tried it with any other kernel series. I did check the kernel changelog to see if there had been commits recently to the cx23885 or cx25840 drivers, and didn't see anything relevant. > Do you have logs that illustrate your problem? I've attached the result of lsmod, showing the refcounts. I'm not really sure what the most useful data regarding the actual video capture problem is. Alternatively, do you know a good reliable PCIe or USB analog video capture card that produces good results? It's seemed quite difficult to find something these days given that it's basically a dead technology... (and for the low end USB cards, we seem to be in counterfeit hell). Thanks, Justin
Attachment:
hauppage_lsmod_pre2
Description: Binary data
