Few fixes and suggestions by Jeff and Diego

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15925 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
gpoirier 2005-07-06 07:56:41 +00:00
parent 2aa6a03251
commit 3249e16758
1 changed files with 13 additions and 11 deletions

View File

@ -2726,25 +2726,27 @@ codec</title>
The quality of the encode yielded by this option highly depends The quality of the encode yielded by this option highly depends
on personal preferences and on the type and monitor settings on personal preferences and on the type and monitor settings
used to watch it (typically, it will not look as good if it is used to watch it (typically, it will not look as good if it is
bright or if it is a TFT monitor. bright or if it is a TFT monitor).
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<emphasis role="bold">qpel</emphasis> <emphasis role="bold">qpel</emphasis>
Increases the precision of the motion estimation from halfpel to Raise the number of candidate motion vectors's by increasing
the precision of the motion estimation from halfpel to
quarterpel. quarterpel.
The idea is to find better motion vectors which will in return The idea is to find better motion vectors which will in return
reduce bitrate (hence increasing quality). reduce bitrate (hence increasing quality).
However, quarterpel precision motion vectors are coded in the However, motion vectors with quarterpel precision require a
bitstream with a few bits, so if the content do not feature few extra bits to code, but the candidate vectors do not always
enough possibilities to find better motion vectors through give (much) better results.
<option>qpel</option>, it will in fact hurt compressibility. Quite often, the codec still spends bits on the extra precision,
but little or no extra quality is gained in return.
Unfortunately, there is no way to foresee the possible gains of Unfortunately, there is no way to foresee the possible gains of
<option>qpel</option>, so you need to actually encode with and <option>qpel</option>, so you need to actually encode with and
without it to know for sure. without it to know for sure.
</para><para> </para><para>
<option>qpel</option> can be almost double encoding time, and <option>qpel</option> can be almost double encoding time, and
requires as much as 30-60% more processing power to decode. requires as much as 25% more processing power to decode.
It is not supported by all standalone players. It is not supported by all standalone players.
</para></listitem> </para></listitem>
@ -2752,12 +2754,12 @@ codec</title>
<emphasis role="bold">gmc</emphasis> <emphasis role="bold">gmc</emphasis>
Tries to save bits on panning scenes by using a single motion Tries to save bits on panning scenes by using a single motion
vector for the whole frame. vector for the whole frame.
This almost always raise PSNR, but significant slows down This almost always raise PSNR, but significantly slows down
encoding (and also needs more processing power to decode). encoding (significantly slows down encoding).
Therefore, you should only use it when you have turned Therefore, you should only use it when you have turned
<option>vhq</option> to the maximum. <option>vhq</option> to the maximum.
<systemitem class="library">XviD</systemitem>'s GMC (which are <systemitem class="library">XviD</systemitem>'s GMC is more
more sophisticated than DivX's are not supported by all sophisticated than DivX's, but is only supported by few
standalone players. standalone players.
</para></listitem> </para></listitem>