Difference between revisions of "V4L capturing"

From LinuxTVWiki
Jump to: navigation, search
(TV Recording applications)
m (Live x264 capture comparison)
Line 48: Line 48:
 
==Live x264 capture comparison==
 
==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.
+
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 CPU.
   
 
<br>
 
<br>
Line 107: Line 107:
 
<br>
 
<br>
   
  +
<b>ffmpeg</b>
<big><b>Encoding commands used</b></big>
 
   
 
ffmpeg -threads 2 -vd /dev/video$DEV -r 29.97 -b 800 -s 640x480 -vcodec h264 -qmax 51 \
 
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 \
 
-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
 
-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
  +
  +
<b>mencoder</b>
   
 
mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
 
mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
Line 117: Line 122:
 
-ovc x264 -x264encopts threads=2:bitrate=800:subq=2:me=2:frameref=4:8x8dct \
 
-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
 
-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
  +
  +
<b>transcode</b>
   
 
transcode -x v4l2=resync_margin=1:resync_interval=250,v4l2 -M 2 \
 
transcode -x v4l2=resync_margin=1:resync_interval=250,v4l2 -M 2 \
Line 123: Line 134:
 
--lame_preset medium -o $DIR/$FIL.avi
 
--lame_preset medium -o $DIR/$FIL.avi
   
  +
* after adding the resync parameters, the sync problem, previously severe, appears to be solved!
<big><b>Notes</b></big>
 
  +
* 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]].
   
* <b>ffmpeg</b>
+
<b>General</b>
** a/v sync drifts a bit -- not reliable
 
** encoding efficiency is high, but frames are dropped silently
 
* <b>mencoder</b>
 
** 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
 
* <b>transcode</b>
 
** 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
 
   
 
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.
 
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.
 
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.
 

Revision as of 00:20, 16 April 2006

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

  • 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

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 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.

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.