changeset 15370:bd6adbd632e4

Fixes suggested by Diego
author gpoirier
date Sun, 08 May 2005 21:48:02 +0000
parents 37861a573823
children 0ac7f66d02ef
files DOCS/xml/en/codecs.xml DOCS/xml/en/mencoder.xml
diffstat 2 files changed, 8 insertions(+), 8 deletions(-) [+]
line wrap: on
line diff
--- a/DOCS/xml/en/codecs.xml	Sun May 08 20:56:59 2005 +0000
+++ b/DOCS/xml/en/codecs.xml	Sun May 08 21:48:02 2005 +0000
@@ -589,11 +589,11 @@
   bitrate.
   Actual results will depend on both the source material and the
   encoder.
-  The gains from using H.264 do not come for free: decoding H.264
+  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 MPEG4-ASP stream requires
+  By comparison, decoding a 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.
@@ -603,7 +603,7 @@
 <para>
   At least with <systemitem class="library">x264</systemitem>,
   encoding requirements are not much worse than what you are used to
-  with MPEG4-ASP.
+  with MPEG-4 ASP.
   For instance, on a 1733 MHz Athlon a typical DVD encode would run
   at 5-15fps.
 </para>
--- a/DOCS/xml/en/mencoder.xml	Sun May 08 20:56:59 2005 +0000
+++ b/DOCS/xml/en/mencoder.xml	Sun May 08 21:48:02 2005 +0000
@@ -1814,7 +1814,7 @@
 <title>Encoding with the <systemitem class="library">x264</systemitem> codec</title>
 <para>
   <systemitem class="library">x264</systemitem> is a free library for
-  encoding H264/AVC video streams.
+  encoding H.264/AVC video streams.
   Before starting to encode, you need to <link linkend="codec-x264-encode">
   set up <application>MEncoder</application> to support it</link>.
 </para>
@@ -1862,7 +1862,7 @@
   First, using two pass often gains around 1dB PSNR, which is a
   very big difference.
   Secondly, testing options by doing direct quality comparisons
-  with 1-pass encodes is a dubious proposition because bitrate
+  with one pass encodes is a dubious proposition because bitrate
   often varies significantly with each encode.
   It is not always easy to tell whether quality changes are due
   mainly to changed options, or if they mostly reflect
@@ -1945,7 +1945,7 @@
   <option>subq</option> and <option>frameref</option> values on
   the first pass, and then raise them on the second pass.
   Typically, this has a negligible negative effect on the final
-  quality: you will probably lose well under 0.1dB PSNR, which
+  quality: You will probably lose well under 0.1dB PSNR, which
   should be much too small of a difference to see.
   However, different values of <option>frameref</option> can
   occasionally affect frametype decision.
@@ -1992,7 +1992,7 @@
 
 <listitem><para>
   <emphasis role="bold">b_adapt</emphasis>:
-  Note: this is on by default.
+  Note: This is on by default.
 </para>
 <para>
   With this option enabled, the encoder will use some simple
@@ -2012,7 +2012,7 @@
 <listitem><para>
   <emphasis role="bold">b_pyramid</emphasis>:
   You might as well enable this option if you are using >2 B-frames;
-  as the man page says, you get a little quality improvement with no
+  as the man page says, you get a little quality improvement at no
   speed cost.
   Note that these videos cannot be read by libavcodec-based decoders
   older than about March 5, 2005.