RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2025-01-29 19:22:48 +00:00
Code Issues Releases Wiki Activity

cosmetics

Browse Source 
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@8096 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
diego 2002-11-04 02:11:20 +00:00
parent 2dd245f0dd
commit 3aff75a6ac
1 changed files with 55 additions and 83 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
DOCS/documentation.html
View File

@ -964,86 +964,60 @@ The full listing of the options is available on the manual page. Here
are just a few tips: are just a few tips:
<UL> <UL>
<LI>Choose some sane image dimensions. The dimensions of the resulting image
<LI> should be divisible by 16.</LI>
Choose some sane image dimensions. The dimensions of the resulting <LI>If you capture the video with the vertical resolution higher than half of
image should be divisible by 16. the full resolution (i.e. 288 for PAL or 240 for NTSC), make sure you
</LI> turned deinterlacing on. Otherwise you'll get a movie which is distorted
during fast-motion scenes and the bitrate controller will be probably even
<LI>If you capture the video with the vertical resolution higher than unable to retain the specified bitrate as the interlacing artifacts produce
half of the full resolution (i.e. 288 for PAL or 240 for NTSC), make high amount of detail and thus consume lot of bandwidth. You can enable
sure you turned deinterlacing on. Otherwise you'll get a movie which deinterlacing with <CODE>-vop pp=DEINT_TYPE</CODE>. Usually
is distorted during fast-motion scenes and the bitrate controller will <CODE>pp=lb</CODE> does a good job, but it can be matter of personal
be probably even unable to retain the specified bitrate as the preference. See other deinterlacing algorithms in the manual and give it a
interlacing artifacts produce high amount of detail and thus consume try.</LI>
lot of bandwidth. You can enable deinterlacing with <CODE>-vop <LI>Crop out the dead space. When you capture the video, the areas at the
pp=DEINT_TYPE</CODE>. Usually <CODE>pp=lb</CODE> does a good edges are usually black or contain some noise. These again consume lots of
job, but it can be matter of personal preference. See other unnecessary bandwidth. More precisely it's not the black areas themselves
deinterlacing algorithms in the manual and give it a try.</LI> 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,
<LI> adjust the arguments of the <CODE>crop</CODE> option so that all the crap
Crop out the dead space. When you capture the video, the areas at the at the margins is cropped out. Again, don't forget to keep the resulting
edges are usually black or contain some noise. These again consume dimensions sane.</LI>
lots of unnecessary bandwidth. More precisely it's not the black <LI>Watch out for CPU load. It shouldn't cross the 90% boundary for most of
areas themselves but the sharp transitions between the black and the the time. If you have a large capture buffer, MEncoder can survive an
brighter video image which do but that's not important for now. Before overload for few seconds but nothing more. It's better to turn off the 3D
you start capturing, adjust the arguments of the <CODE>crop</CODE> OpenGL screensavers and similar stuff.</LI>
option so that all the crap at the margins is cropped out. Again, <LI>Don't mess with the system clock. MEncoder uses the system clock for
don't forget to keep the resulting dimensions sane. doing A/V sync. If you adjust the system clock (especially backwards in
</LI> 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
<LI> synchronization software like NTP. You have to turn NTP off during the
Watch out for CPU load. It shouldn't cross the 90% boundary for most capture process if you want to capture reliably.</LI>
of the time. If you have a large capture buffer, MEncoder can survive <LI>Don't change the <CODE>outfmt</CODE> unless you know what you are doing
an overload for few seconds but nothing more. It's better to turn off or your card/driver really doesn't support the default (YV12 colorspace).
the 3D OpenGL screensavers and similar stuff. In the older versions of MPlayer/MEncoder it was necessary to specify the
</LI> 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
<LI> purposes. For example, if you are capturing into DivX using libavcodec and
Don't mess with the system clock. MEncoder uses the system clock for specify <CODE>outfmt=RGB24</CODE> in order to increase the quality of the
doing A/V sync. If you adjust the system clock (especially backwards captured images, the captured image will be actually later converted back
in time), MEncoder gets confused and you will lose frames. This is an into YV12 so the only thing you achieve is a massive waste of CPU power.
important issue if you are hooked to a network and run some time </LI>
synchronization software like NTP. You have to turn NTP off during the <LI>To specify the I420 colorspace (<CODE>outfmt=i420</CODE>), you have to
capture process if you want to capture reliably. add an option <CODE>-vc rawi420</CODE> due to a fourcc conflict with an
</LI> Intel Indeo video codec.</LI>
<LI>There are several ways of capturing audio. You can grab the sound either
<LI> using your soundcard via an external cable connection between video card
Don't change the <CODE>outfmt</CODE> unless you know what you are and line-in, or using the built-in ADC in the bt878 chip. In the latter
doing or your card/driver really doesn't support the default (YV12 case, you have to load the <b>btaudio</b> driver. Read the
colorspace) . In the older versions of MPlayer/MEncoder it was necessary <CODE>linux/Documentation/sound/btaudio</CODE> file (in the kernel tree,
to specify the output format. This issue should be fixed in the not MPlayer's) for some instructions on using this driver.</LI>
current releases and <CODE>outfmt</CODE> isn't required anymore, and <LI>If MEncoder cannot open the audio device, make sure that it is really
the default suits the most purposes. For example, if you are capturing available. There can be some trouble with the sound servers like arts
into DivX using libavcodec and specify <CODE>outfmt=RGB24</CODE> in (KDE) or esd (GNOME). If you have a full duplex soundcard (almost any
order to increase the quality of the captured images, the captured decent card supports it today), and you are using KDE, try to check the
image will be actually later converted back into YV12 so the only "full duplex" option in the sound server preference menu.</LI>
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> </UL>
<H3><A NAME="tv_examples">2.5.3 Examples</A></H3> <H3><A NAME="tv_examples">2.5.3 Examples</A></H3>
@ -1085,9 +1059,7 @@ on:driver=v4l:width=640:height=480 -vo xv</CODE><BR>
<CODE>-tv</CODE> option and omit the software scaling but this <CODE>-tv</CODE> option and omit the software scaling but this
approach uses the maximum available information and is a little more approach uses the maximum available information and is a little more
resistant to noise. The bt8x8 chips can do the pixel averaging only resistant to noise. The bt8x8 chips can do the pixel averaging only
in the horizontal direction due to a hardware limitation. in the horizontal direction due to a hardware limitation.</P>
</P>