From 3249e16758c1a0112dea9eade5d515ce2fd0c14d Mon Sep 17 00:00:00 2001
From: gpoirier <gpoirier@b3059339-0415-0410-9bf9-f77b7e298cf2>
Date: Wed, 6 Jul 2005 07:56:41 +0000
Subject: Few fixes and suggestions by Jeff and Diego

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15925 b3059339-0415-0410-9bf9-f77b7e298cf2
---
 DOCS/xml/en/mencoder.xml | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

(limited to 'DOCS/xml')

diff --git a/DOCS/xml/en/mencoder.xml b/DOCS/xml/en/mencoder.xml
index bd6c2d5535..7853925992 100644
--- a/DOCS/xml/en/mencoder.xml
+++ b/DOCS/xml/en/mencoder.xml
@@ -2726,25 +2726,27 @@ codec</title>
     The quality of the encode yielded by this option highly depends
     on personal preferences and on the type and monitor settings
     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>
 
 <listitem><para>
   <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.
     The idea is to find better motion vectors which will in return
     reduce bitrate (hence increasing quality).
-    However, quarterpel precision motion vectors are coded in the
-    bitstream with a few bits, so if the content do not feature
-    enough possibilities to find better motion vectors through
-    <option>qpel</option>, it will in fact hurt compressibility.
+    However, motion vectors with quarterpel precision require a
+    few extra bits to code, but the candidate vectors do not always
+    give (much) better results.
+    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
     <option>qpel</option>, so you need to actually encode with and
     without it to know for sure.
   </para><para>
     <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.
 </para></listitem>
 
@@ -2752,12 +2754,12 @@ codec</title>
   <emphasis role="bold">gmc</emphasis>
     Tries to save bits on panning scenes by using a single motion
     vector for the whole frame.
-    This almost always raise PSNR, but significant slows down
-    encoding (and also needs more processing power to decode).
+    This almost always raise PSNR, but significantly slows down
+    encoding (significantly slows down encoding).
     Therefore, you should only use it when you have turned
     <option>vhq</option> to the maximum.
-    <systemitem class="library">XviD</systemitem>'s GMC (which are
-    more sophisticated than DivX's are not supported by all
+    <systemitem class="library">XviD</systemitem>'s GMC is more
+    sophisticated than DivX's, but is only supported by few
     standalone players.
 </para></listitem>
 
-- 
cgit v1.2.3