[mdlug] Video Input issues (Was: Wall Wart Devices)

[David McMillan]

On 2/12/2011 6:44 PM, David McMillan wrote:

     Top-posting for reasons of brevity:
     I've still got the listed issues with the video input.  /dev/video0 
just can't seem to dependably sync to the Vsync of the incoming 
composite video  signal -- even my best images have bottom 2/3 of the 
image *above* the top 1/3.  And usually a thick green bar taking up the 
bottom 10% or so of each image, probably representing a portion of the 
Vertical Blanking Interval (wow, I still remember some of that stuff 
from ELT 205 in college!).  That's about 75% of all the images, with the 
other 25% being either fuzzed out or vertically "rolling".
     I figure there *has* to be some way to "tune" this in better, 
adjust the timing threshold of how the V4L tools handle the vertical 
sync, or something.  But so far all my googling about has mainly turned 
up references to bugs in video *output* from ATI and Nvidia cards.
     One thing I'm wondering is if mplayer or ffmpeg might have the 
tools I need.  But then I need a way to get motion to take a feed from 
mplayer/ffmpeg, rather than directly from /dev/video0.

> 	Well, I'm kind of ricocheting around.  I had a brainstorm (or
> brainfart, as the case may be), and grabbed one of those little
> micro-cams once I realized I could power it off a 9V battery, then got a
> "VHS-to-DVD" ripping device that would (I thought) convert composite
> (single RCA-jack) video signal from the camera's receiver into a
> USB-webcam-like signal readable by motion.
> 	Well... almost.
> 	My older Ubuntu install wouldn't see the converter, but Lucid Lynx did.
>    Saw it on boot and auto-mounted it as /dev/video0, slick as anything.
>    Unfortunately, something in the chain doesn't work -- the image on
> /dev/video0, while recognizably the view from the camera, has a lot of
> issues: violent constant vertical rolling, like an old 70s TV that's
> lost V-sync, and bursts of noise happening so frequently that motion,
> when I started it, was snapping images less than a second apart.
> 	Now, I know the video image from the camera to its receiver is good; I
> tested that using my TV's video input.  And if I use the Windows
> software that came with the RCA-to-USB converter on my XP box, it works
> fine (however, XP won't recognize the converter as it would a typical
> webcam, so my XP-based webcam intervalometer script is useless).  So
> there's got to be something about how Lynx is treating this chipset. But
> what I've been able to dig out of LinuxTV suggests that this chipset is
> well supported -- it's even in the kernel.
> 	So at the moment I'm a little stuck trying to figure out how to
> proceed.  Dealing with video input devices under Linux is new territory
> for me.  I'd *really* like to just find a way to get the computer to see
> the video stream from the mini-cam as if it were just another ordinary
> webcam, and then treat it accordingly.  I'm wondering if there's some
> way to maybe "tune" /dev/video0, or possibly pipe it through ffmpeg and
> "filter" out some of the problems before piping the feed to motion.