Fixes suggested by Diego

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

2 files changed, 8 insertions, 8 deletions

diff --git a/DOCS/xml/en/codecs.xml b/DOCS/xml/en/codecs.xml
index fdecd948c0..c0af573998 100644
--- a/DOCS/xml/en/codecs.xml
+++ b/DOCS/xml/en/codecs.xml
@@ -589,11 +589,11 @@ decoders:
   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 @@ decoders:
 <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>
diff --git a/DOCS/xml/en/mencoder.xml b/DOCS/xml/en/mencoder.xml
index 00e1376cac..d723e4802e 100644
--- a/DOCS/xml/en/mencoder.xml
+++ b/DOCS/xml/en/mencoder.xml
@@ -1814,7 +1814,7 @@ vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,
 <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 @@ vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,
   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 @@ vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,
   <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 @@ vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,
 
 <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 @@ vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,
 <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.