Update of the x264 encoding guide:

- Reorganized things, options are now divided into "speed vs quality"
  and "other" (more or less). subq is now where it belongs.
- subq=6 is documented
- explanation of what 2-pass really does, and why you'd better use it
- mention 3-pass (and the fact that it usually doesn't help)
- documented qcomp
- documented keyint (not like it needed any more explanation, though)
- deblocking parameter tweaking no longer categorized as options that
  "affect speed and quality ;)
- updated example cpu requirements for decoding, in codecs.xml
  (720x480 @ 1500kbps 50%->35%, for my CPU)


git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15916 b3059339-0415-0410-9bf9-f77b7e298cf2

1 files changed, 4 insertions, 4 deletions

diff --git a/DOCS/xml/en/codecs.xml b/DOCS/xml/en/codecs.xml
index 17f0dee41f..bfc69459a0 100644
--- a/DOCS/xml/en/codecs.xml
+++ b/DOCS/xml/en/codecs.xml
@@ -574,10 +574,10 @@ decoders:
   encoder.
   The gains from using H.264 do not come for free: Decoding H.264
   streams seems to have steep CPU and memory requirements.
-  For instance, on a 1733 MHz Athlon, a 1500kbps H.264 video uses
-  around 50% CPU to decode.
-  By comparison, decoding a 1500kbps MPEG-4 ASP stream requires
-  around 10% CPU.
+  For instance, on a 1733 MHz Athlon, a DVD-resolution 1500kbps H.264
+  video requires around 35% CPU to decode.
+  By comparison, decoding a DVD-resolution 1500kbps MPEG-4 ASP stream
+  requires around 10% CPU.
   This means that decoding high-definition streams is almost out of
   the question for most users.
   It also means that even a decent DVD rip may sometimes stutter on