V4L capturing
TV Recording applications
- DVR -- Digital Video Recorder for Linux
- ffmpeg (see also below)
- fftv
- gstreamer
- XdTV -- XdTV is a software that allows you to watch record & stream TV
- 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
- a. 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%"
- b. dov4l
- Console tool that sets the parameters of a Video4Linux-device
- You can set picture size, brightness, contrast, tuner frequency, and so on.
- You can also retrieve a complete list of all current settings.
3. Capture the stream
- 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
- 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
Capture from composite or S-video
ffmpeg -async 12 -vd /dev/video -ad /dev/dsp -f avi -r 25 -s 720x576 -croptop 8 -cropbottom 8 -cropleft 8 \ -cropright 8 -sameq -aspect 4:3 -acodec mp2 -ac 2 -ab 224k -ar 48000 -y -t 04:30:00 outfile.avi
- -async 12 (helps eliminate problems with audio/video syncronization)
- v4lctl setattr vcr_hack (needed for bttv cards - can also be set in /etc/modprobe.conf)
- crop values result in far better quality/file size
Compression formats
- Multimediawiki
- Fourcc site
- x264 -- GPL H.264 encoder. Offers best quality/bitrate efficiency, but a fast CPU for playback/recording is recommended.
- 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 and a dual-core or dual amd64 CPU.
| application | a/v sync | efficiency | file size | streaming |
|---|---|---|---|---|
| ffmpeg | middling | good | small | yes |
| mencoder | great | poor | smaller | no |
| transcode | good | great | variable | yes |
ffmpeg
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 96 -ar 32000 \ -ad /dev/dsp$DEV -t $TIM -f avi -y $DIR/$FIL.avi
- a/v sync drifts a bit -- not reliable
- encoding efficiency is high, but frames are dropped silently
mencoder
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=800:subq=2:me=2:frameref=4:8x8dct \ -oac mp3lame -lameopts cbr:br=96 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null
- creates files that don't stream correctly in VLC -- 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
- superior to the others in its ability to accept a much fuller set of x264 encoding parameters
transcode
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 96 -Q 5 -e 32000,16,2 \ --lame_preset medium -o $DIR/$FIL.avi
- after adding the resync parameters, the sync problem, previously severe, appears to be solved!
- does a great job keeping up with frames -- full-size capture with no drops -- though I'm still wondering if it might be dropping frames silently
- file sizes are highly variable and are poorly controlled by the -w video bitrate switch
- on a single CPU, the audio track is confused and overlapping; on a dual-core or dual CPU, the result is good
- to run two threads, see Transcode.
A change was made to the x264 repository on 1 August 2006 that allows the switch --threads=auto to detect the number of CPUs.
General
File size is in theory a simple function of audio and video bitrates. In practice, ffmpeg and mencoder produce files according to bitrate settings, while transcode is all over the map -- in a small sample of ten, an hour at "-w 500" ranged from a small 377MB all the way up to 684MB, and "-w 800" from 407MB to 754MB. Quality may also vary; currently not assessed.
See also Discussion.