V4L capturing: Difference between revisions
(encoding application comparison) |
|||
Line 107: | Line 107: | ||
<br> |
<br> |
||
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,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 -Q 5 -e 32000,16,2 \ |
|||
--lame_preset medium -o $DIR/$FIL.avi |
|||
Notes |
|||
* <b>ffmpeg</b> |
|||
** a/v sync is not fully tested; it may be a bit off |
|||
** encoding efficiency is high, but frames are dropped silently! |
|||
* <b>transcode</b> |
|||
** audio lags several seconds behind video after an hour |
|||
** there may be ways to enforce better sync -- not fully explored |
|||
** file size can of course be brought down with "-w 800 -b 96" -- effect on sync not tested |
|||
** does a swell job keeping up with frames -- full-size capture with no drops |
|||
* <b>mencoder</b> |
|||
** 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. |
Revision as of 20:26, 27 March 2006
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
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 I've been unable to find a 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 | file size | efficiency | streaming |
---|---|---|---|---|
ffmpeg | ? | small | good | yes |
mencoder | great | small | poor | no |
transcode | poor | large | 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,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 -Q 5 -e 32000,16,2 \ --lame_preset medium -o $DIR/$FIL.avi
Notes
- ffmpeg
- a/v sync is not fully tested; it may be a bit off
- encoding efficiency is high, but frames are dropped silently!
- transcode
- audio lags several seconds behind video after an hour
- there may be ways to enforce better sync -- not fully explored
- file size can of course be brought down with "-w 800 -b 96" -- effect on sync not tested
- does a swell job keeping up with frames -- full-size capture with no drops
- 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.