V4L capturing

From LinuxTVWiki
Revision as of 17:37, 23 November 2008 by CityK (talk | contribs) (add a description line that David Liontooth had provided in the "Video recording" article that has become pushed to the wayside)
Jump to navigation Jump to search

Some applications useful for recording audio and video off a v4l device:

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

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

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.