V4L capturing

From LinuxTVWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

TV Recording applications

Other frame grabbers

Common configuration and control commands

1. v4l2ucp -- universal control panel for v4l2 (available for Debian from Marillat)

2. Command-line control the TV card (v4lctl is a part of the xawtv package)

  • v4lctl -c /dev/video0 list
  • v4lctl -c /dev/video0 bright "60%"
  • v4lctl -c /dev/video0 contrast "55%"

3. Capture the stream

  • streamer (part of the xawtv package):
Usage:
streamer -i 1 -c /dev/video0 -s 320x240 -q -j 80 -f jpeg -n ntsc -b 24 -o /var/www/webcam.jpeg
streamer -i 1 -c /dev/video0 -s 320x240 -q -j 80 -f jpeg -n ntsc -b 24 -o /dev/stdout |uuencode thief.jpeg|sendmail alarm@foo.com
  • videodog:
Usage:
videodog -x 640 -y 480 -w 3 -b 1 -c 65535 -m PAL -q -d /dev/video0 -j -f /var/www/webcam.jpg
This useful tool supports continuously moving (ftp or scp - ssh copy) of jpeg output to remote server. Also allows put in additional text (date time, location), rotating of image.
Usage:
webcam /etc/webcamrc
See webcams for model and driver details

Compression formats

Live x264 capture comparison

The x264 encoder is now of such a high quality that it is possible to compress live tv on the fly with good results. So far I've been unable to find a solution that delivers on all counts: good audio/video synchronization, small file size, efficient encoding (full size and high quality without dropped frames), and a resulting file that streams with VLC. These results, however, may vary locally; the following is a status report from late March 2006 on a Debian amd64 sid with Marillat's multimedia packages.


application a/v sync file size efficiency streaming
ffmpeg middling small good yes
mencoder great small poor no
transcode poor large great yes


Encoding commands used

ffmpeg -threads 2 -vd /dev/video$DEV -r 29.97 -b 800 -s 640x480 -vcodec h264 -qmax 51 \
-me epzs -deinterlace -g 300 -async 1 -ac 2 -acodec mp3 -ab 64 -ar 32000 \
-ad /dev/dsp$DEV -t $TIM -f avi -y $DIR/$FIL.avi
mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:adevice=/dev/dsp$DEV:input=0:amode=1:normid=4:width=512:height=384 \
-ovc x264 -x264encopts threads=2:bitrate=500:subq=2:me=2:frameref=4:8x8dct \
-oac mp3lame -lameopts cbr:br=96 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null
 transcode -x v4l2,v4l2 -M 2 -i /dev/video$DEV -p /dev/dsp$DEV -y ffmpeg -F h264 \
-c 00:$TIM -g 640x480 -f 29.970,4 -u 1024,2 -Q 5 -e 32000,16,2 \
--lame_preset medium -o $DIR/$FIL.avi

Notes

  • ffmpeg
    • a/v sync drifts a bit -- not reliable
    • encoding efficiency is high, but frames are dropped silently
  • transcode
    • audio lags several seconds behind video after an hour
    • there may be ways to enforce better sync -- not fully explored
    • file size can of course be brought down with "-w 800 -b 96" -- effect on sync not tested
    • does a swell job keeping up with frames -- full-size capture with no drops
  • mencoder
    • creates files that don't stream correctly -- we've not got to the bottom of this
    • encoding efficiency is somewhat below ffmpeg and transcode -- cannot capture to full 640x480 size without dropping frames

I tried three different CPUs -- a dual Opteron 240, a dual-core athlon64x2 3800+, and an athlon64-3000+, and (to my surprise) results are comparable on all three.