V4L capturing
TV Recording applications
- DVR -- Digital Video Recorder for Linux
- ffmpeg
- fftv
- Freevo -- open-source digital video jukebox
- mencoder
- MythTV -- a Personal Video Recorder project
- streamer
- transcode
- videodog
- vlc
Other frame grabbers
- See webcams
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
- mencoder
- webcam:
- 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
- Fourcc site
- H264 -- a highly compressed codec optimized for streaming
- xvid -- free mpeg4 codec
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 transcode is the only 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 | efficiency | streaming |
|---|---|---|---|
| ffmpeg | middling | good | yes |
| mencoder | great | poor | no |
| transcode | good | 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=resync_margin=1:resync_interval=250,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 -w 800 -b 128 -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
- after adding the resync parameters, the sync problem, previously severe, appears to be solved!
- does a swell job keeping up with frames -- full-size capture with no drops -- though I'm still wondering if it might be dropping frames silently
- 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.
File size is of course a function of audio and video bitrates. While there may be minor differences in resulting file sizes for identical bitrates (not tested), the real question at that point is quality (also not tested).