Mercurial > mplayer.hg

changeset 8095:6b4200d4b64b

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
cosmetics
author diego
date Mon, 04 Nov 2002 02:11:20 +0000
parents b8a90a2af611
children f6ffe802f526
files DOCS/documentation.html
diffstat 1 files changed, 55 insertions(+), 83 deletions(-) [+]
line wrap: on
line diff
--- a/DOCS/documentation.html	Mon Nov 04 00:23:53 2002 +0000
+++ b/DOCS/documentation.html	Mon Nov 04 02:11:20 2002 +0000
@@ -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>