Difference between revisions of "V4L capturing"

From LinuxTVWiki
Jump to: navigation, search
m (Live x264 capture comparison)
(Live x264 capture comparison)
Line 60: Line 60:
 
<th>a/v sync</th>
 
<th>a/v sync</th>
 
<th>efficiency</th>
 
<th>efficiency</th>
  +
<th>file size</th>
 
<th>streaming</th>
 
<th>streaming</th>
 
</tr>
 
</tr>
Line 67: Line 68:
 
<td></td>
 
<td></td>
 
<td></td>
 
<td></td>
  +
<td></td>
 
<td></td>
 
<td></td>
 
<td></td>
 
<td></td>
Line 75: Line 77:
 
<td>middling</td>
 
<td>middling</td>
 
<td>good</td>
 
<td>good</td>
  +
<td>small</td>
 
<td>yes</td>
 
<td>yes</td>
 
</tr>
 
</tr>
Line 82: Line 85:
 
<td>great</td>
 
<td>great</td>
 
<td>poor</td>
 
<td>poor</td>
  +
<td>smaller</td>
 
<td>no</td>
 
<td>no</td>
 
</tr>
 
</tr>
Line 89: Line 93:
 
<td>good</td>
 
<td>good</td>
 
<td>great</td>
 
<td>great</td>
  +
<td>variable</td>
 
<td>yes</td>
 
<td>yes</td>
 
</tr>
 
</tr>
Line 95: Line 100:
 
<td></td>
 
<td></td>
 
<td></td>
 
<td></td>
  +
<td></td>
 
<td></td>
 
<td></td>
 
<td></td>
 
<td></td>
Line 106: Line 112:
   
 
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 64 -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
   
 
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:\
 
audiorate=32000:adevice=/dev/dsp$DEV:input=0:amode=1:normid=4:width=512:height=384 \
 
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 \
+
-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
   
 
transcode -x v4l2=resync_margin=1:resync_interval=250,v4l2 -M 2 \
 
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 \
 
-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 \
+
-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
 
--lame_preset medium -o $DIR/$FIL.avi
   
Line 124: Line 130:
 
** a/v sync drifts a bit -- not reliable
 
** a/v sync drifts a bit -- not reliable
 
** encoding efficiency is high, but frames are dropped silently
 
** encoding efficiency is high, but frames are dropped silently
* <b>transcode</b>
 
** 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
 
 
* <b>mencoder</b>
 
* <b>mencoder</b>
** creates files that don't stream correctly -- we've not got to the bottom of this
+
** 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
 
** 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.
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.
 
   
  +
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).
 

Revision as of 19:29, 31 March 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

  • 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 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 file size streaming
ffmpeg middling good small yes
mencoder great poor smaller no
transcode good great variable 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 96 -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=800: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 96 -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
  • mencoder
    • 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
    • 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.

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.