# HG changeset patch
# User henry
# Date 1035886150 0
# Node ID 26ddd166422ea663f6cc6574488f0f33c054fb43
# Parent 537af766336917226a56ba7f84847e9e7bbdc9c1
updated v4l section
diff -r 537af7663369 -r 26ddd166422e DOCS/documentation.html
--- a/DOCS/documentation.html Tue Oct 29 10:03:58 2002 +0000
+++ b/DOCS/documentation.html Tue Oct 29 10:09:10 2002 +0000
@@ -198,7 +198,8 @@
2.5 TV input
@@ -942,10 +943,6 @@
TV tuner. See the man page for a description of TV options and keyboard
controls.
-THIS CODE IS CURRENTLY NOT BEING WORKED ON! Do not expect it to work
- without tweaking/experimenting!
-
-
@@ -957,28 +954,127 @@
xawtv.
-
- Hint
- Are the colors messed up? Then your tuner cannot display
- in YV12 colorspace. Try I420 (-vc rawi420) or YUY2, UYVY, RGB32
- (-vo sdl) colorspaces.
- You can specify these with the outfmt=YV12 option, see below.
-
+
+
+The full listing of the options is available on the manual page. Here
+are just a few tips:
+
+
+
+-
+Choose some sane image dimensions. The dimensions of the resulting
+image should be divisible by 16.
+
+
+- If you capture the video with the vertical resolution higher than
+half of the full resolution (i.e. 288 for PAL or 240 for NTSC), make
+sure you turned deinterlacing on. Otherwise you'll get a movie which
+is distorted during fast-motion scenes and the bitrate controller will
+be probably even unable to retain the specified bitrate as the
+interlacing artifacts produce high amount of detail and thus consume
+lot of bandwidth. You can enable deinterlacing with
-vop
+pp=DEINT_TYPE. Usually pp=lb does a good
+job, but it can be matter of personal preference. See other
+deinterlacing algorithms in the manual and give it a try.
+
+-
+Crop out the dead space. When you capture the video, the areas at the
+edges are usually black or contain some noise. These again consume
+lots of unnecessary bandwidth. More precisely it's not the black
+areas themselves but the sharp transitions between the black and the
+brighter video image which do but that's not important for now. Before
+you start capturing, adjust the arguments of the
crop
+option so that all the crap at the margins is cropped out. Again,
+don't forget to keep the resulting dimensions sane.
+
+-
+Watch out for CPU load. It shouldn't cross the 90% boundary for most
+of the time. If you have a large capture buffer, MEncoder can survive
+an overload for few seconds but nothing more. It's better to turn off
+the 3D OpenGL screensavers and similar stuff.
+
-
+-
+Don't mess with the system clock. MEncoder uses the system clock for
+doing A/V sync. If you adjust the system clock (especially backwards
+in time), MEncoder gets confused and you will lose frames. This is an
+important issue if you are hooked to a network and run some time
+synchronization software like NTP. You have to turn NTP off during the
+capture process if you want to capture reliably.
+
+
+-
+Don't change the
outfmt unless you know what you are
+doing or your card/driver really doesn't support the default (YV12
+colorspace) . In the older versions of MPlayer/MEncoder it was necessary
+to specify the output format. This issue should be fixed in the
+current releases and outfmt isn't required anymore, and
+the default suits the most purposes. For example, if you are capturing
+into DivX using libavcodec and specify outfmt=RGB24 in
+order to increase the quality of the captured images, the captured
+image will be actually later converted back into YV12 so the only
+thing you achieve is a massive waste of CPU power.
+
+
+-
+To specify the I420 colorspace (
outfmt=i420), you have to
+add an option -vc rawi420 due to a fourcc conflict with
+an Intel Indeo video codec.
+
+
+-
+If MEncoder cannot open the audio device, make sure that it is really
+available. There can be some trouble with the sound servers like arts
+(KDE) or esd (GNOME). If you have a full duplex soundcard (almost any
+decent card supports it today), and you are using KDE, try to check
+the "full duplex" option in the sound server preference menu.
+
+
+
+
+
Dummy output, to AAlib :)
mplayer -tv on:driver=dummy:width=640:height=480 -vo aa
Input from standard V4L
- mplayer -tv on:driver=v4l:width=640:height=480:outfmt=i420 -vc rawi420 -vo xv
+ mplayer -tv
+on:driver=v4l:width=640:height=480 -vo xv
+
+
+ A more sophisticated example. This makes MEncoder capture the full
+ PAL image, crop the margins, and deinterlace the picture using
+ a linear blend algorithm. Audio is compressed with a constant
+ bitrate of 64kbps, using LAME codec. This setup is suitable for
+ capturing movies.
mencoder -tv
+ on:driver=v4l:width=768:height=576 \
+ -ovc lavc -lavcopts
+ vcodec=mpeg4:vbitrate=900 \
-oac
+ mp3lame -lameopts cbr:br=64 \
-vop
+ pp=lb,crop=720:540:24:18 -o output.avi
-Note:
- If you have a TV card with an external audio device and get only a black
- screen, although input works with xawtv or similar, then try to use the
- -noaudio option. For the example above this would be:
- mplayer -tv on:noaudio:driver=v4l:width=640:height=480:outfmt=i420 -vc rawi420 -vo xv
+
+ This will additionally rescale the image to 384x288 and compresses
+ the video with the bitrate of 350kbps in high quality mode. The
+ vqmax option looses the quantizer and allows the video compressor to
+ actualy reach so low bitrate even at the expense of the
+ quality. This can be used for capturing long TV series, where the
+ video quality isn't so important.
+
+ mencoder -tv on:driver=v4l:width=768:height=576 \
+ -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=350:vhq:vqmax=31:keyint=300 \
+ -oac mp3lame -lameopts cbr:br=48 \
+ -vop scale=384:288,pp=tn/lb,crop=720:540:24:18 -sws 1 -o output.avi
+
+
+ It's also possible to specify smaller image dimensions in the
+ -tv option and omit the software scaling but this
+ approach uses the maximum available information and is a little more
+ resistant to noise. The bt8x8 chips can do the pixel averaging only
+ in the horizontal direction due to a hardware limitation.
+
+