[Mplayer-cvslog] CVS: main/DOCS documentation.html,1.325,1.326
Diego Biurrun CVS
diego at mplayerhq.hu
Mon Nov 4 03:11:40 CET 2002
Update of /cvsroot/mplayer/main/DOCS
In directory mail:/var/tmp.root/cvs-serv17053/DOCS
Modified Files:
documentation.html
Log Message:
cosmetics
Index: documentation.html
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/documentation.html,v
retrieving revision 1.325
retrieving revision 1.326
diff -u -r1.325 -r1.326
--- documentation.html 3 Nov 2002 13:05:58 -0000 1.325
+++ documentation.html 4 Nov 2002 02:11:20 -0000 1.326
@@ -964,86 +964,60 @@
are just a few tips:
<UL>
-
-<LI>
-Choose some sane image dimensions. The dimensions of the resulting
-image should be divisible by 16.
-</LI>
-
-<LI>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 <CODE>-vop
-pp=DEINT_TYPE</CODE>. Usually <CODE>pp=lb</CODE> does a good
-job, but it can be matter of personal preference. See other
-deinterlacing algorithms in the manual and give it a try.</LI>
-
-<LI>
-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 <CODE>crop</CODE>
-option so that all the crap at the margins is cropped out. Again,
-don't forget to keep the resulting dimensions sane.
-</LI>
-
-<LI>
-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.
-</LI>
-
-<LI>
-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.
-</LI>
-
-<LI>
-Don't change the <CODE>outfmt</CODE> 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 <CODE>outfmt</CODE> isn't required anymore, and
-the default suits the most purposes. For example, if you are capturing
-into DivX using libavcodec and specify <CODE>outfmt=RGB24</CODE> 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.
-</LI>
-
-<LI>
-To specify the I420 colorspace (<CODE>outfmt=i420</CODE>), you have to
-add an option <CODE>-vc rawi420</CODE> due to a fourcc conflict with
-an Intel Indeo video codec.
-</LI>
-
-<LI>
-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 <b>btaudio</b>
-driver. Read the <CODE>linux/Documentation/sound/btaudio</CODE> file
-(in the kernel tree, not MPlayer's) for some instructions on using this driver.
-</LI>
-
-<LI>
-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.
-</LI>
-
+ <LI>Choose some sane image dimensions. The dimensions of the resulting image
+ should be divisible by 16.</LI>
+ <LI>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 <CODE>-vop pp=DEINT_TYPE</CODE>. Usually
+ <CODE>pp=lb</CODE> does a good job, but it can be matter of personal
+ preference. See other deinterlacing algorithms in the manual and give it a
+ try.</LI>
+ <LI>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 <CODE>crop</CODE> option so that all the crap
+ at the margins is cropped out. Again, don't forget to keep the resulting
+ dimensions sane.</LI>
+ <LI>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.</LI>
+ <LI>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.</LI>
+ <LI>Don't change the <CODE>outfmt</CODE> 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
+ <CODE>outfmt</CODE> isn't required anymore, and the default suits the most
+ purposes. For example, if you are capturing into DivX using libavcodec and
+ specify <CODE>outfmt=RGB24</CODE> 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.
+ </LI>
+ <LI>To specify the I420 colorspace (<CODE>outfmt=i420</CODE>), you have to
+ add an option <CODE>-vc rawi420</CODE> due to a fourcc conflict with an
+ Intel Indeo video codec.</LI>
+ <LI>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 <b>btaudio</b> driver. Read the
+ <CODE>linux/Documentation/sound/btaudio</CODE> file (in the kernel tree,
+ not MPlayer's) for some instructions on using this driver.</LI>
+ <LI>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.</LI>
</UL>
<H3><A NAME="tv_examples">2.5.3 Examples</A></H3>
@@ -1085,9 +1059,7 @@
<CODE>-tv</CODE> 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.
-
-</P>
+ in the horizontal direction due to a hardware limitation.</P>
More information about the MPlayer-cvslog
mailing list