Video4linux Examples

Capturing NTSC from a V4L2 Device

This shows you how to capture video through the v4l or v4l2 interfaces. This is useful if you have some video on VHS or you are recording live NTSC tv through a video capture card such as a BT848 card [Hauppauge WinTV], or firewire capture device like the Pinnacle. In addition to transcode, you'll also need a recent version of [ffmpeg]. I recommend building ffmpeg from CVS. Once you get all that ready to go, you can run transcode like this:

 transcode -x v4l2,v4l2 \
           -M 2 \
           -i /dev/video0 \
           -p /dev/dsp0 \
           -y ffmpeg \
           -F msmpeg4v2 \
           -c 00:30:00 \
           -g 720x480 \
           -f 0,4 \
           -I 1 \
           -u 100 \
           -Q 3 \
           -Z 360x240,fast \
           -E 48000,16,2 \
           --lame_preset medium \
           -o clip.avi

Options Explaination

• -x v4l2,v4l2 This sets the video and audio (respectively) import modules as video4linux2.
• -M 2 Sets the synchronization method so the audio and video stay synched up for NTSC.
• -i /dev/video0 The name of the v4l2 device from which to grab the video stream.
• -p /dev/dsp0 The name of the audio device from which to grab the sound.
• -y ffmpeg Sets the export module.
• -F msmpeg4v2 Tells ffmpeg to export to Microsoft MPEG4-v2 (DivX3 Compatible) format.
• -c 00:30:00 Capture for 30 minutes.
• -g 720x480 Lets transcode know the incoming frame size for NTSC.
• -f 0,4 Sets the framerate to 29.97 fps (NTSC).
• -I 1 De-Interlace by interpolation.
• -u 100 Use 100 framebuffers for processing.
• -Q 3 Encoding quality (5 is the best, slowest).
• -Z 360x240,fast Rescales image from 720x480 to 360x240
• -E 48000,16,2 Sets the audio handling to 48 kHz, 16 bits, stereo.
• --lame_preset medium audio encoding parameters for about 170 kbs stream that sounds very good.
• -o clip.avi output file name. Should end in .avi

Variations

• change -y ffmpeg -F msmpeg4v2 to -y xvid4 if you have the xvid library for an MPEG4 compatible video stream, though it will be in an avi container and not an mp4.

Capturing PAL from a V4L2 Device

This example shows the command line that I (Francesco) actually use to record tv shows/clips with my v4l2 card. Isn't too different from other transcode v4l examples. My card it's a SAA7134 based one: I use the audio direct access through OSS emulation from ALSA. I know this a bit sick, and I'll write an ALSA import module as soon as is possible (it's also a good reason to learn more about ALSA, too). I'm fairly satisfied from recorded output, but I'm concerned about some small sync problems on my box, even if it should be fast enough (Athlon64 3200+/1 GB ram). So, I'm planning to do more extensive tests and tuning very soon, following Erik's documentation: see Import Modules/Import V4l2. Of course I'll report changes and improvements here.

command is the following:

#!/bin/sh

TODAY=$( date +%Y%m%d )
NOW=$( date +%H:%M )

transcode \
        -x v4l2=resync_margin=1:resync_interval=250,v4l2 \
        -g 640x480 \
        -i /dev/video0 -p /dev/dsp1 \
        -e 32000,16,2 -N 0x1 \
        -J resample,levels,smartyuv,pv \
        -w 4000 -y ffmpeg -F mjpeg \
        -o tvrecord-${TODAY}-${NOW}.avi \
        --avi_limit 1536

option explanations: For a detailed explanation of each option, see the transcode manual page. I'll discuss the choice of parameter, not meaning nor syntax!

synchronization options

    -x v4l2=resync_margin=1:resync_interval=250,v4l2

See docs/import_v4l2.txt for a quick explanation of used options. The resync code in import_v4l2 basically works cloning/dropping frames to enforce tha A/V synchronization. This sounds bad, but in my experience this has very little impact in output file quality. Of course YMMV, so let me/us know if your result is worse turning on those options also has the nice effects that import_v4l2 will produce a message when it clone/drop a frame, so user can have a rough idea of what's going on.

On my system, Athlon64 3200+/1 GB ram/Saa7134 card, forcing resync has very little but still noticeable impact: at the end of encoding I see that there are something like ~120 Cloned + Dropped (Significantly more Cloned than Dropped) frames on average on a ~90k frames length recored clip.

input settings

    -g 640x480

Force the frame size to 640x480, which is an handy resolution to be encoded without resizing, and has correct aspect ratio (1.333).

    -i /dev/video0 -p /dev/dsp1

select the input sources. '/dev/dsp1' is the device provided by SAA7134 device when 'saa7134-oss' module is loaded or (for kernels roughly <= 2.6.13) if 'saa7134' module is loaded with option 'oss=1' or even if module 'saa7134-alsa' is used and OSS emulation is enabled. In all the above cases, the saa7134 chip deliver audio frames directly instead to pass through soundcard. I know it's strange to use the ALSA module through OSS emulation instead to using ALSA directly, but ad time of writing transcode lacks import modules to read from ALSA.

    -e 32000,16,2 -N 0x1

setup audio input stream parameter. Note the first argument of -e option. AFAIK, because some limitations of SAA7134 chipset, it can safely output only audio at 32000 Hz rate. Using default transcode parameter for sampling rate (48000 Hz) causes wrong reads and early desync issues.

filter settings

    -J resample,levels,smartyuv,pv

explictely select the filter chain and, more important, the filter loading order. I use 'pv' filter because I usually watch TV during recording sessions. Of course in the mean case tvtime it's a better choice than transcode with pv filter ;) I also use 'smartyuv' because, for my own taste, it's the best compromise between deinterlacing quality (compared to -I option and compared to the other avalaible filter that I have tested so far) and transcoding speed.

export options

    -w 4000 -y ffmpeg -F mjpeg

-w select the video bitrate used for encoding. 4000 kbit/s is a good compromise for me for efficiency and good output quality. I use libavcodec's (through ffmpeg module) mjpeg encoder since it's fast and it delivers a good quality. I choose MJPEG codec because it's easy to handle, i.e. for cutting commercials and so on, since it encodes using intra-frames only (also knows as key frames). MJPEG has also a good space efficiency (considering it as an intermediate format). Lossless codec like LZO (-y lzo) or HuffYUV (-y ffmpeg -F huffyuv) or LJPEG (-y ffmpeg -F ljpeg) are of course better choice from quality point of view, but they delivers a much lower compression ratio. Moreover, for my own taste, quality loss using MJPEG codec are negligible, so I'm quite happy with it. ffmpeg's lossless codec, FFV1 (-y ffmpeg -F ffv1) can be an interesting choice but it's still a bit too experimental at moment of writing, and it's a bit too heavy to process yet.

    -o tvrecord-${TODAY}-${NOW}.avi --avi_limit 1536

rotate output file when they become bigger than (roughly) 1.5 Gigabytes. This size it's good for me to be handled easily and comfortably, since I don't like HUGE single output files.