2003-03-23 23:35:12 +00:00
|
|
|
<?xml version="1.0" encoding="iso-8859-1"?>
|
2003-09-21 13:05:42 +00:00
|
|
|
<!-- $Revision$ -->
|
2003-03-23 23:35:12 +00:00
|
|
|
<sect1 id="tv-input" xreflabel="TV input">
|
|
|
|
<title>TV input</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This section is about how to enable <emphasis role="bold">watching/grabbing
|
2003-03-31 22:31:35 +00:00
|
|
|
from V4L compatible TV tuner</emphasis>. See the man page for a description
|
|
|
|
of TV options and keyboard controls.
|
2003-03-23 23:35:12 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<sect2 id="tv-compilation">
|
|
|
|
<title>Compilation</title>
|
|
|
|
|
|
|
|
<procedure>
|
|
|
|
<step><para>
|
|
|
|
First, you have to recompile. <filename>./configure</filename> will
|
|
|
|
autodetect kernel headers of v4l stuff and the existence of
|
|
|
|
<filename>/dev/video*</filename> entries. If they exist, TV support will
|
|
|
|
be built (see the output of <filename>./configure</filename>).
|
|
|
|
</para></step>
|
|
|
|
<step><para>
|
|
|
|
Make sure your tuner works with another TV software in Linux, for
|
2003-03-31 22:31:35 +00:00
|
|
|
example <application>XawTV</application>.
|
2003-03-23 23:35:12 +00:00
|
|
|
</para></step>
|
|
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="tv-tips">
|
|
|
|
<title>Usage tips</title>
|
|
|
|
<para>
|
|
|
|
The full listing of the options is available on the manual page.
|
|
|
|
Here are just a few tips:
|
|
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Use the <option>channels</option> option. An example:
|
2003-04-20 17:08:57 +00:00
|
|
|
<screen>-tv channels=26-MTV1,23-TV2</screen>
|
2003-03-23 23:35:12 +00:00
|
|
|
Explanation: using this option, only the 26 and 23 channels will be usable,
|
|
|
|
and there will be a nice OSD text upon channel switching, displaying the
|
|
|
|
channel's name. Spaces in the channel name must be replaced by the
|
|
|
|
"_" character.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Choose some sane image dimensions. The dimensions of the resulting image should
|
|
|
|
be divisible by 16.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
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
|
2003-03-24 17:24:25 +00:00
|
|
|
deinterlacing with <option>-vf pp=DEINT_TYPE</option>. Usually
|
2003-03-23 23:35:12 +00:00
|
|
|
<option>pp=lb</option> does a good job, but it can be matter of personal
|
|
|
|
preference. See other deinterlacing algorithms in the manual and give it a try.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
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 <option>crop</option> option so that all the
|
|
|
|
crap at the margins is cropped out. Again, don't forget to keep the resulting
|
|
|
|
dimensions sane.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Watch out for CPU load. It shouldn't cross the 90% boundary for most of the
|
2003-11-30 13:07:40 +00:00
|
|
|
time. If you have a large capture buffer, <application>MEncoder</application>
|
|
|
|
can survive an overload for few seconds but nothing more. It's better to
|
|
|
|
turn off the 3D OpenGL screensavers and similar stuff.
|
2003-03-23 23:35:12 +00:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Don't mess with the system clock. <application>MEncoder</application> uses the
|
|
|
|
system clock for doing A/V sync. If you adjust the system clock (especially
|
2003-11-30 13:07:40 +00:00
|
|
|
backwards in time), <application>MEncoder</application> 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.
|
2003-03-23 23:35:12 +00:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Don't change the <option>outfmt</option> unless you know what you are doing
|
|
|
|
or your card/driver really doesn't support the default (YV12 colorspace).
|
|
|
|
In the older versions of <application>MPlayer</application>/
|
|
|
|
<application>MEncoder</application> it was necessary to specify the output
|
|
|
|
format. This issue should be fixed in the current releases and <option>outfmt</option>
|
|
|
|
isn't required anymore, and the default suits the most purposes. For example,
|
2004-01-21 19:25:18 +00:00
|
|
|
if you are capturing into DivX using
|
|
|
|
<systemitem class="library">libavcodec</systemitem> and specify
|
2003-03-23 23:35:12 +00:00
|
|
|
<option>outfmt=RGB24</option> 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.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
To specify the I420 colorspace (<option>outfmt=i420</option>), you have to add an
|
|
|
|
option <option>-vc rawi420</option> due to a fourcc conflict with an Intel Indeo
|
|
|
|
video codec.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
There are several ways of capturing audio. You can grab the sound either using
|
|
|
|
your soundcard via an external cable connection between video card and line-in,
|
|
|
|
or using the built-in ADC in the bt878 chip. In the latter case, you have to
|
|
|
|
load the <emphasis role="bold">btaudio</emphasis> driver. Read the
|
|
|
|
<filename>linux/Documentation/sound/btaudio</filename> file (in the kernel
|
2004-06-13 17:46:07 +00:00
|
|
|
tree, not <application>MPlayer</application>'s) for some instructions on using
|
2003-11-30 13:07:40 +00:00
|
|
|
this driver.
|
2003-03-23 23:35:12 +00:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
If <application>MEncoder</application> 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.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
|
|
<sect2 id="tv-examples">
|
|
|
|
<title>Examples</title>
|
|
|
|
|
|
|
|
<informalexample>
|
|
|
|
<para>
|
|
|
|
Dummy output, to AAlib :)
|
|
|
|
<screen>
|
2003-04-20 17:08:57 +00:00
|
|
|
mplayer -tv driver=dummy:width=640:height=480 -vo aa tv://<!--
|
2003-03-23 23:35:12 +00:00
|
|
|
--></screen>
|
|
|
|
</para>
|
|
|
|
</informalexample>
|
|
|
|
|
|
|
|
<informalexample>
|
|
|
|
<para>
|
|
|
|
Input from standard V4L:
|
|
|
|
<screen>
|
2003-04-20 17:08:57 +00:00
|
|
|
mplayer -tv driver=v4l:width=640:height=480:outfmt=i420 -vc rawi420 -vo xv tv://<!--
|
2003-03-23 23:35:12 +00:00
|
|
|
--></screen>
|
|
|
|
</para>
|
|
|
|
</informalexample>
|
|
|
|
|
|
|
|
<informalexample>
|
|
|
|
<para>
|
2003-11-30 13:07:40 +00:00
|
|
|
A more sophisticated example. This makes <application>MEncoder</application>
|
|
|
|
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.
|
2003-03-23 23:35:12 +00:00
|
|
|
<screen>
|
2003-04-20 17:08:57 +00:00
|
|
|
mencoder -tv driver=v4l:width=768:height=576 \
|
2003-03-23 23:35:12 +00:00
|
|
|
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=900 \
|
|
|
|
-oac mp3lame -lameopts cbr:br=64 \
|
2004-01-01 17:44:41 +00:00
|
|
|
-vf crop=720:544:24:16,pp=lb -o <replaceable>output.avi</replaceable> tv://
|
2003-03-23 23:35:12 +00:00
|
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
</informalexample>
|
|
|
|
|
|
|
|
<informalexample>
|
|
|
|
<para>
|
|
|
|
This will additionally rescale the image to 384x288 and compresses the
|
|
|
|
video with the bitrate of 350kbps in high quality mode. The vqmax option
|
2003-10-26 14:58:17 +00:00
|
|
|
looses the quantizer and allows the video compressor to actually reach so
|
2003-03-23 23:35:12 +00:00
|
|
|
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.
|
|
|
|
<screen>
|
2003-04-20 17:08:57 +00:00
|
|
|
mencoder -tv driver=v4l:width=768:height=576 \
|
2003-03-23 23:35:12 +00:00
|
|
|
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=350:vhq:vqmax=31:keyint=300 \
|
|
|
|
-oac mp3lame -lameopts cbr:br=48 \
|
2004-01-01 17:44:41 +00:00
|
|
|
-vf crop=720:540:24:18,pp=tn/lb,scale=384:288 -sws 1 -o <replaceable>output.avi</replaceable> tv://
|
2003-03-23 23:35:12 +00:00
|
|
|
</screen>
|
|
|
|
It's also possible to specify smaller image dimensions in the <option>-tv</option>
|
|
|
|
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.
|
|
|
|
</para>
|
|
|
|
</informalexample>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|