Run the whole documentation through ispell.

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

16 files changed, 67 insertions, 67 deletions

diff --git a/DOCS/xml/en/audio.xml b/DOCS/xml/en/audio.xml
index 77a815012e..9285f9c662 100644
--- a/DOCS/xml/en/audio.xml
+++ b/DOCS/xml/en/audio.xml
@@ -24,7 +24,7 @@ efficient as <application>MPlayer</application>'s.
 
 <para>
 Using <application>MPlayer</application> with a properly written audio
-driver will never result in A/V desyncs related to the audio, except
+driver will never result in A/V desynchronisation related to the audio, except
 only with very badly created files (check the man page for workarounds).
 </para>
 
diff --git a/DOCS/xml/en/bugreports.xml b/DOCS/xml/en/bugreports.xml
index cb5204024c..6891891b40 100644
--- a/DOCS/xml/en/bugreports.xml
+++ b/DOCS/xml/en/bugreports.xml
@@ -18,7 +18,7 @@ we request and follow the instructions in this document closely.
 
 
 <sect1 id="bugreports_security">
-<title>Report security releated bugs</title>
+<title>Report security related bugs</title>
 
 <para>
 In case you have found an exploitable bug and you would like to do the
diff --git a/DOCS/xml/en/bugs.xml b/DOCS/xml/en/bugs.xml
index 39266d8318..35e0b55c1b 100644
--- a/DOCS/xml/en/bugs.xml
+++ b/DOCS/xml/en/bugs.xml
@@ -88,7 +88,7 @@
 <!-- ********** -->
 
 <sect2 id="bugs-delay-specific">
-<title>Audio delay/de-sync specific to one or a few files</title>
+<title>Audio delay/desync specific to one or a few files</title>
 
 <itemizedlist>
 <listitem>
diff --git a/DOCS/xml/en/cd-dvd.xml b/DOCS/xml/en/cd-dvd.xml
index 0c200212b5..fafc76410d 100644
--- a/DOCS/xml/en/cd-dvd.xml
+++ b/DOCS/xml/en/cd-dvd.xml
@@ -222,11 +222,11 @@ form 1 and 2 tracks:
 <itemizedlist>
 <listitem><para>
   The first track is in mode 2 form 2 format which means it uses L2
-  error correction. The track contains an ISO-9660 filesystem with 2048
-  bytes/sector. This filesystem contains VCD metadata information, as
+  error correction. The track contains an ISO-9660 file system with 2048
+  bytes/sector. This file system contains VCD metadata information, as
   well as still frames often used in menus. MPEG segments for menus can
   also be stored in this first track, but the MPEGs have to be broken up
-  into a series of 150-sector chunks. The ISO-9660 filesystem may
+  into a series of 150-sector chunks. The ISO-9660 file system may
   contain other files or programs that are not essential for VCD
   operation.
 </para></listitem>
@@ -238,7 +238,7 @@ form 1 and 2 tracks:
   sector at the loss of some error correction. It is also legal to have
   CD-DA tracks in a VCD after the first track as well.
   On some operating systems there is some trickery that goes on to make
-  these non-ISO-9660 tracks appear in a filesystem. On other operating
+  these non-ISO-9660 tracks appear in a file system. On other operating
   systems like GNU/Linux this is not the case (yet). Here the MPEG data
   <emphasis role="bold">cannot be mounted</emphasis>. As most movies are
   inside this kind of track, you should try <option>vcd://2</option>
@@ -246,7 +246,7 @@ form 1 and 2 tracks:
 </para></listitem>
 
 <listitem><para>
-  There exist VCD disks without the first track (single track and no filesystem
+  There exist VCD disks without the first track (single track and no file system
   at all). They are still playable, but cannot be mounted.
 </para></listitem>
 
@@ -270,7 +270,7 @@ tracks (Windows does not allow raw device access to applications at all).
 Under Linux you cannot copy or play such files (they contain garbage). Under
 Windows it is possible as its iso9660 driver emulates the raw reading of
 tracks in this file. To play a .DAT file you need the kernel driver which can
-be found in the Linux version of PowerDVD. It has a modified iso9660 filesystem
+be found in the Linux version of PowerDVD. It has a modified iso9660 file system
 (<filename>vcdfs/isofs-2.4.X.o</filename>) driver, which is able to emulate the
 raw tracks through this shadow .DAT file. If you mount the disc using their
 driver, you can copy and even play .DAT files with
diff --git a/DOCS/xml/en/codecs.xml b/DOCS/xml/en/codecs.xml
index 860d303f14..36f4a2e0e9 100644
--- a/DOCS/xml/en/codecs.xml
+++ b/DOCS/xml/en/codecs.xml
@@ -281,7 +281,7 @@ but if you are interested in a brief overview, you may want to read
 <systemitem class="library">libavcodec</systemitem> has had at
 least minimally usable H.264 decoding since around July 2004,
 however major changes and improvements have been implemented since
-that time, both in terms of more functionalities supported and in
+that time, both in terms of more functionality supported and in
 terms of improved CPU usage.
 Just to be certain, it is always a good idea to use a recent Subversion
 checkout.
@@ -382,7 +382,7 @@ satisfied the requirements for <systemitem class="library">x264</systemitem>.
   Voxware audio (using DirectShow DLL)
 </para></listitem>
 <listitem><para>
-  alaw and ulaw, various gsm, adpcm and pcm formats and other simple old
+  alaw and ulaw, various GSM, ADPCM and PCM formats and other simple old
   audio codecs
 </para></listitem>
 <listitem><para>
diff --git a/DOCS/xml/en/containers.xml b/DOCS/xml/en/containers.xml
index e173bcba43..6d0d736477 100644
--- a/DOCS/xml/en/containers.xml
+++ b/DOCS/xml/en/containers.xml
@@ -83,7 +83,7 @@ functional.
 </para>
 
 <para>
-One important feature of MPGs is that they have a field to describe the
+One important feature of MPEG files is that they have a field to describe the
 aspect ratio of the video stream within. For example SVCDs have 480x480
 resolution video, and in the header that field is set to 4:3, so that it is
 played at 640x480. AVI files often lack this field, so they have to be
@@ -319,8 +319,8 @@ Return to Castle Wolfenstein.
 <title>OGG/OGM files</title>
 
 <para>
-This is a new fileformat from
-<ulink url="http://www.xiph.org">Xiphophorus</ulink>.
+This is a new file format from the
+<ulink url="http://www.xiph.org">Xiph.Org Foundation</ulink>.
 It can contain any video or audio codec, CBR or VBR. You'll need
 <systemitem class="library">libogg</systemitem> and
 <systemitem class="library">libvorbis</systemitem> installed before
@@ -503,7 +503,7 @@ options to <application>cdparanoia</application>.
 <para>
 <application>MPlayer</application> can use <application>XMMS</application> input
 plugins to play many file formats. There are plugins for SNES game tunes, SID
-tunes (from Commodore 64), many Amiga formats, .xm, .it, VQF, musepack, Bonk,
+tunes (from Commodore 64), many Amiga formats, .xm, .it, VQF, Musepack, Bonk,
 shorten and many others. You can find them at the
 <ulink url="http://www.xmms.org/plugins.php?category=input">XMMS input plugin page</ulink>.
 </para>
diff --git a/DOCS/xml/en/documentation.xml b/DOCS/xml/en/documentation.xml
index c019099056..13ee22989a 100644
--- a/DOCS/xml/en/documentation.xml
+++ b/DOCS/xml/en/documentation.xml
@@ -62,15 +62,15 @@ is a lot of valuable information to be found there.
 <para>
 <application>MPlayer</application> is a movie player for Linux (runs on
 many other Unices, and non-x86 CPUs, see <xref linkend="ports"/>).
-It plays most MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM,
+It plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM,
 NuppelVideo, yuv4mpeg, FILM, RoQ, PVA, Matroska files, supported by
 many native, XAnim, RealPlayer, and Win32 DLL codecs. You can watch
-VideoCD, SVCD, DVD, 3ivx, RealMedia, Sorenson, Theora,
-and MPEG-4 (DivX) movies too. Another big
+Video CD, SVCD, DVD, 3ivx, RealMedia, Sorenson, Theora,
+and MPEG-4 (DivX) movies, too. Another big
 feature of <application>MPlayer</application> is the wide range of
 supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib,
 fbdev, AAlib, libcaca, DirectFB, but you can use GGI and SDL (and this way all
-their drivers) and some lowlevel card-specific drivers (for Matrox, 3Dfx and
+their drivers) and some low level card-specific drivers (for Matrox, 3Dfx and
 Radeon, Mach64, Permedia3) too! Most of them support software or hardware
 scaling, so you can enjoy movies in fullscreen.
 <application>MPlayer</application> supports displaying through some
@@ -106,7 +106,7 @@ PCM/MP3/VBR MP3 audio.
 <itemizedlist>
 <title><application>MEncoder</application> features</title>
 <listitem><para>
-  Encoding from the wide range of fileformats and decoders of
+  Encoding from the wide range of file formats and decoders of
   <application>MPlayer</application>
 </para></listitem>
 <listitem><para>
@@ -135,7 +135,7 @@ PCM/MP3/VBR MP3 audio.
   Stream copying
 </para></listitem>
 <listitem><para>
-  Input A/V synchronizing (PTS-based, can be disabled with
+  Input A/V synchronizing (pts-based, can be disabled with
   <option>-mc 0</option> option)
 </para></listitem>
 <listitem><para>
@@ -144,7 +144,7 @@ PCM/MP3/VBR MP3 audio.
 </para></listitem>
 <listitem><para>
   Using our very powerful filter system (crop, expand, flip, postprocess,
-  rotate, scale, rgb/yuv conversion)
+  rotate, scale, RGB/YUV conversion)
 </para></listitem>
 <listitem><para>
   Can encode DVD/VOBsub and text subtitles
diff --git a/DOCS/xml/en/encoding-guide.xml b/DOCS/xml/en/encoding-guide.xml
index 2072cdfc6f..a5f5d6f8fd 100644
--- a/DOCS/xml/en/encoding-guide.xml
+++ b/DOCS/xml/en/encoding-guide.xml
@@ -457,7 +457,7 @@ the other for the blue-yellow axis).
 Even if your movie width and height are not multiples of 16, the
 encoder will use enough 16x16 macroblocks to cover the whole picture
 area, and the extra space will go to waste.
-So in the interests of maximizing quality at a fixed filesize, it is
+So in the interests of maximizing quality at a fixed file size, it is
 a bad idea to use dimensions that are not multiples of 16.
 </para>
 
@@ -1212,7 +1212,7 @@ Again, it is a matter of putting those bits to better use: why waste them
 encoding noise when you can just add that noise back in during playback?
 Increasing the parameters for <option>hqdn3d</option> will further
 improve compressibility, but if you increase the values too much, you
-risk degrading the image visibily. The suggested values above
+risk degrading the image visibly. The suggested values above
 (<option>2:1:2</option>) are quite conservative; you should feel free to
 experiment with higher values and observe the results for yourself.
 </para>
@@ -1558,7 +1558,7 @@ to get proper sync.
 
 <para>
 You need to have <application>MEncoder</application> process the sound.
-You can for example copy the orignal soundtrack during the encode with
+You can for example copy the original soundtrack during the encode with
 <option>-oac copy</option> or convert it to a "light" 4 kHz mono WAV
 PCM with <option>-oac pcm -channels 1 -srate 4000</option>.
 Otherwise, in some cases, it will generate a video file that will not sync
@@ -1571,11 +1571,11 @@ cut audio at these points.
 However <application>MPlayer</application> cannot do that, so if you
 demux the AC-3 audio and encode it with a separate app (or dump it to PCM with
 <application>MPlayer</application>), the splices will be left incorrect
-and the only way to correct them is to drop/dup video frames at the
+and the only way to correct them is to drop/duplicate video frames at the
 splice.
 As long as <application>MEncoder</application> sees the audio when it is
 encoding the video, it can do this dropping/duping (which is usually OK
-since it takes place at full black/scenechange), but if
+since it takes place at full black/scene change), but if
 <application>MEncoder</application> cannot see the audio, it will just
 process all frames as-is and they will not fit the final audio stream when
 you for example merge your audio and video track into a Matroska file.
@@ -1830,7 +1830,7 @@ numbers to 60, 30, and 24.
 <para>
 Strictly speaking, all those numbers are approximations. Black and
 white NTSC video was exactly 60 fields per second, but 60000/1001
-was later chosen to accomodate color data while remaining compatible
+was later chosen to accommodate color data while remaining compatible
 with contemporary black and white televisions. Digital NTSC video
 (such as on a DVD) is also 60000/1001 fields per second. From this,
 interlaced and telecined video are derived to be 30000/1001 frames
@@ -2413,7 +2413,7 @@ duration/location of each type.
   It is safe to use <option>pullup</option> (along with <option>softskip
   </option>) on progressive video, and is usually a good idea unless
   the source has been definitively verified to be entirely progressive.
-  The performace loss is small for most cases. On a bare-minimum encode,
+  The performance loss is small for most cases. On a bare-minimum encode,
   <option>pullup</option> causes <application>MEncoder</application> to
   be 50% slower. Adding sound processing and advanced <option>lavcopts
   </option> overshadows that difference, bringing the performance
@@ -2877,7 +2877,7 @@ That would probably be nice, but unfortunately hard to implement as different
 encoding options yield different quality results depending on the source
 material. That is because compression depends on the visual properties of the
 video in question.
-For example, anime and live action have very different properties and
+For example, Anime and live action have very different properties and
 thus require different options to obtain optimum encoding.
 The good news is that some options should never be left out, like
 <option>mbd=2</option>, <option>trell</option>, and <option>v4mv</option>.
@@ -2917,7 +2917,7 @@ See below for a detailed description of common encoding options.
   Experiment with values of 0 (default), 2 (hadamard), 3 (dct), and 6 (rate
   distortion).
   0 is fastest, and sufficient for precmp.
-  For cmp and subcmp, 2 is good for anime, and 3 is good for live action.
+  For cmp and subcmp, 2 is good for Anime, and 3 is good for live action.
   6 may or may not be slightly better, but is slow.
 </para></listitem>
 <listitem><para>
@@ -2961,7 +2961,7 @@ See below for a detailed description of common encoding options.
   when the change in a block is less than the threshold you specify, and in
   such a case, to just  encode the block as "no change".
   This saves bits and perhaps speeds up encoding. vlelim=-4 and vcelim=9
-  seem to be good for live movies, but seem not to help with anime;
+  seem to be good for live movies, but seem not to help with Anime;
   when encoding animation, you should probably leave them unchanged.
 </para></listitem>
 <listitem><para>
@@ -2970,7 +2970,7 @@ See below for a detailed description of common encoding options.
   therefore this option comes with an overhead as more information will be
   stored in the encoded file.
   The compression gain/loss depends on the movie, but it is usually not very
-  effective on anime.
+  effective on Anime.
   qpel always incurs a significant cost in CPU decode time (+25% in
   practice).
 </para></listitem>
@@ -3235,7 +3235,7 @@ this parameter (refer to the man page for the possible values) as
 different functions can have a large impact on quality depending on the
 source material. For example, if you find
 <systemitem class="library">libavcodec</systemitem> produces too much
-blocky artifacting, you could try selecting the experimental NSSE as
+blocky artifacts, you could try selecting the experimental NSSE as
 comparison function via <option>*cmp=10</option>.
 </para>
 
@@ -3376,7 +3376,7 @@ the following section puzzles you.
 <listitem><para>
   <emphasis role="bold">hq_ac</emphasis>
   Activates a better coefficient cost estimation method, which slightly
-  reduces filesize by around 0.15 to 0.19% (which corresponds to less
+  reduces file size by around 0.15 to 0.19% (which corresponds to less
   than 0.01dB PSNR increase), while having a negligible impact on speed.
   It is therefore recommended to always leave it on.
 </para></listitem>
@@ -3409,7 +3409,7 @@ the following section puzzles you.
   information into account, whereas <option>me_quality</option>
   alone only uses luma (grayscale).
   This slows down encoding by 5-10% but improves visual quality
-  quite a bit by reducing blocking effects and reduces filesize by
+  quite a bit by reducing blocking effects and reduces file size by
   around 1.3%.
   If you are looking for speed, you should disable this option before
   starting to consider reducing <option>me_quality</option>.
@@ -3703,7 +3703,7 @@ The following table shows what each profile supports.
   <entry>X</entry>
 </row>
 <row>
-  <entry>Quaterpixel</entry>
+  <entry>Quarterpixel</entry>
   <entry></entry>
   <entry></entry>
   <entry></entry>
@@ -3986,7 +3986,7 @@ random differences in the achieved bitrate.
   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.
+  occasionally affect frame type decision.
   Most likely, these are rare outlying cases, but if you want to
   be pretty sure, consider whether your video has either
   fullscreen repetitive flashing patterns or very large temporary
@@ -4070,7 +4070,7 @@ random differences in the achieved bitrate.
   The speed penalty of adaptive B-frames is currently rather modest,
   but so is the potential quality gain.
   It usually does not hurt, however.
-  Note that this only affects speed and frametype decision on the
+  Note that this only affects speed and frame type decision on the
   first pass.
   <option>b_adapt</option> and <option>b_bias</option> have no
   effect on subsequent passes.
@@ -4149,7 +4149,7 @@ random differences in the achieved bitrate.
   which, in isolation, requires about 2500kbps in order to look decent.
   Immediately following it is a much less demanding 60-second scene
   that looks good at 300kbps. Suppose you ask for 1400kbps on the theory
-  that this is enough to accomodate both scenes. Single pass ratecontrol
+  that this is enough to accommodate both scenes. Single pass ratecontrol
   will make a couple of "mistakes" in such a case. First of all, it
   will target 1400kbps in both segments. The first segment may end up
   heavily overquantized, causing it to look unacceptably and unreasonably
@@ -4196,7 +4196,7 @@ random differences in the achieved bitrate.
   pass will both read the statistics from the previous pass, and write
   its own statistics. An additional pass following this one will have
   a very good base from which to make highly accurate predictions of
-  framesizes at a chosen quantizer. In practice, the overall quality
+  frame sizes at a chosen quantizer. In practice, the overall quality
   gain from this is usually close to zero, and quite possibly a third
   pass will result in slightly worse global PSNR than the pass before
   it. In typical usage, three passes help if you get either bad bitrate
@@ -4296,7 +4296,7 @@ random differences in the achieved bitrate.
   If your H.264 encodes look too blurry or smeared, try playing with
   <option>-vf noise</option> when you play your encoded movie.
   <option>-vf noise=8a:4a</option> should conceal most mild
-  artifacting.
+  artifacts.
   It will almost certainly look better than the results you
   would have gotten just by fiddling with the deblocking filter.
   </para>
@@ -4457,7 +4457,7 @@ if a codec fails or gives wrong output.
 </row>
 <row>
   <entry>m3jpeg32.dll</entry>
-  <entry>Morgan Motion JPEG Codec (MJPG)</entry>
+  <entry>Morgan Motion JPEG Codec (MJPEG)</entry>
   <entry>1cd13fff5960aa2aae43790242c323b1</entry>
   <entry></entry>
 </row>
@@ -4828,7 +4828,7 @@ me=umh:partitions=all:trellis=1:qp_step=4:qcomp=0.7:direct_pred=auto:keyint=300
   <screen>mplayer narnia.avi -dumpaudio -dumpfile narnia.aac
 mplayer narnia.avi -dumpvideo -dumpfile narnia.h264</screen>
 
-  The filenames are important; <application>mp4creator</application>
+  The file names are important; <application>mp4creator</application>
   requires that AAC audio streams be named <systemitem>.aac</systemitem>
   and H.264 video streams be named <systemitem>.h264</systemitem>.
 </para>
@@ -5076,7 +5076,7 @@ The GOP size is set using the <option>keyint</option> option.
 
 <para>
 VCD video is required to be CBR at 1152 kbps.
-This highly limiting constraint also comes along with an extremly low vbv
+This highly limiting constraint also comes along with an extremely low vbv
 buffer size of 327 kilobits.
 SVCD allows varying video bitrates up to 2500 kbps, and a somewhat less 
 restrictive vbv buffer size of 917 kilobits is allowed.
@@ -5126,7 +5126,7 @@ DVD (with timestamps on every frame, if possible):
 DVD with NTSC Pullup:
 <screen>-of mpeg -mpegopts format=dvd:tsaf:telecine -ofps 24000/1001</screen>
 This allows 24000/1001 fps progressive content to be encoded at 30000/1001 
-fps whilst maintaing DVD-compliance.
+fps whilst maintaining DVD-compliance.
 </para>
 
 
diff --git a/DOCS/xml/en/faq.xml b/DOCS/xml/en/faq.xml
index 1c3f269222..7f1f781787 100644
--- a/DOCS/xml/en/faq.xml
+++ b/DOCS/xml/en/faq.xml
@@ -831,7 +831,7 @@ What about DVD navigation/menus?
 architectural limitations that prevent proper handling of still images and
 interactive content. If you want to have fancy menus, you will have to use
 another player like <application>xine</application>,
-<application>vlc</application> or <application>Ogle</application>.
+<application>VLC</application> or <application>Ogle</application>.
 If you want to see DVD navigation in <application>MPlayer</application> you
 will have to implement it yourself, but be aware that it is a major
 undertaking.
diff --git a/DOCS/xml/en/history.xml b/DOCS/xml/en/history.xml
index 521ff2aeba..fc111f8c91 100644
--- a/DOCS/xml/en/history.xml
+++ b/DOCS/xml/en/history.xml
@@ -106,7 +106,7 @@ audio), even more stable than ever, and so on. It's a MUST!
 <para>
 Hmm. Release again. Tons of new features, beta GUI version,
 bugs fixed, new vo and ao drivers, ported to many systems, including
-opensource DivX codecs and much more. Try it!
+open source DivX codecs and much more. Try it!
 </para>
 </listitem>
 
@@ -115,7 +115,7 @@ opensource DivX codecs and much more. Try it!
 <emphasis role="bold"><application>MPlayer</application> 0.60 "The RTFMCounter"</emphasis>: Jan 3, 2002
 </para>
 <para>
-MOV/VIVO/RM/FLI/NUV fileformats support, native CRAM, Cinepak,
+MOV/VIVO/RM/FLI/NUV file formats support, native CRAM, Cinepak,
 ADPCM codecs, and support for XAnim's binary codecs; DVD subtitles support,
 first release of <application>MEncoder</application>, TV grabbing, cache,
 liba52, countless fixes.
diff --git a/DOCS/xml/en/install.xml b/DOCS/xml/en/install.xml
index 4a93e66e73..6821df7e0d 100644
--- a/DOCS/xml/en/install.xml
+++ b/DOCS/xml/en/install.xml
@@ -287,7 +287,7 @@ ln -s <replaceable>$PREFIX/share/mplayer/arial-24</replaceable> $PREFIX/share/mp
 
 <para>
 Fonts should have an appropriate <filename>font.desc</filename> file
-which maps unicode font positions to the actual code page of the
+which maps Unicode font positions to the actual code page of the
 subtitle text. Another solution is to have UTF-8-encoded subtitles
 and use the <option>-utf8</option> option or give the subtitles
 file the same name as your video file with a <filename>.utf</filename>
@@ -301,7 +301,7 @@ extension and have it in the same directory as the video file.
 <title>OSD menu</title>
 
 <para>
-<application>MPlayer</application> has a completely user definiable
+<application>MPlayer</application> has a completely user-definable
 OSD Menu interface.
 </para>
 
@@ -368,7 +368,7 @@ There are three timing methods in <application>MPlayer</application>.
   but a properly set up kernel is required.
   If you are running kernel 2.4.19pre8 or later you can adjust the maximum RTC
   frequency for normal users through the <systemitem class="systemname">/proc
-  </systemitem> filesystem. Use one of the following two commands to
+  </systemitem> file system. Use one of the following two commands to
   enable RTC for normal users:
   <screen>echo 1024 &gt; /proc/sys/dev/rtc/max-user-freq</screen>
   <screen>sysctl dev/rtc/max-user-freq=1024</screen>
diff --git a/DOCS/xml/en/mencoder.xml b/DOCS/xml/en/mencoder.xml
index 48c6577432..b52ada1986 100644
--- a/DOCS/xml/en/mencoder.xml
+++ b/DOCS/xml/en/mencoder.xml
@@ -300,7 +300,7 @@ You can use the <option>-chapter</option> option for this purpose.
 For example, <option>-chapter</option> <replaceable>1-4</replaceable>
 will only encode chapters 1 through 4 from the DVD.
 This is especially useful if you will be making a 1400 MB encode
-targetted for two CDs, since you can ensure the split occurs exactly
+targeted for two CDs, since you can ensure the split occurs exactly
 at a chapter boundary rather than in the middle of a scene.
 </para>
 
@@ -478,7 +478,7 @@ all passes are run with target bitrates that do not differ very much.
 <title>Rescaling movies</title>
 
 <para>
-Often the need to resize movie images' size emerges. Its reasons can be
+Often the need to resize movie images emerges. The reasons can be
 many: decreasing file size, network bandwidth, etc. Most people even do
 rescaling when converting DVDs or SVCDs to DivX AVI. If you wish to rescale,
 read the <link linkend="aspect">Preserving aspect ratio</link> section.
diff --git a/DOCS/xml/en/ports.xml b/DOCS/xml/en/ports.xml
index 0c8d23aebe..b752941c1e 100644
--- a/DOCS/xml/en/ports.xml
+++ b/DOCS/xml/en/ports.xml
@@ -68,7 +68,7 @@ from <ulink url="http://rpm.livna.org/">Livna repository</ulink>.
 <para>
 Mandrake/Mandriva RPM packages are available from the
 <ulink url="http://plf.zarb.org/">P.L.F.</ulink>.
-SuSE used to include a crippled version of <application>MPlayer</application>
+SUSE used to include a crippled version of <application>MPlayer</application>
 in their distribution. They have removed it in their latest releases. You can
 get working RPMs from
 <ulink url="http://packman.links2linux.de/?action=128">links2linux.de</ulink>.
@@ -325,12 +325,12 @@ you may not be able to play DVD discs larger than 4 GB:
 </para></listitem>
 
 <listitem><para>
-  A similar bug is present in the hsfs(7FS) filesystem code (AKA ISO9660),
+  A similar bug is present in the hsfs(7FS) file system code (AKA ISO9660),
   hsfs may not not support partitions/disks larger than 4GB, all data is
   accessed modulo 4GB
   (<ulink url="http://groups.yahoo.com/group/solarisonintel/message/22592"/>).
   The hsfs problem can be fixed by installing
-  patch 109764-04 (sparc) / 109765-04 (x86).
+  patch 109764-04 (SPARC) / 109765-04 (x86).
 </para></listitem>
 </itemizedlist>
 </listitem>
@@ -768,7 +768,7 @@ Later examples will be based on MacPorts.
 
 <para>
 For instance, to compile <application>MPlayer</application> with OSD support:
-<screen>sudo port install pkgconfig</screen>
+<screen>sudo port install pkg-config</screen>
 This will install <application>pkg-config</application>, which is a system for
 managing library compile/link flags.
 <application>MPlayer</application>'s <systemitem>configure</systemitem> script
diff --git a/DOCS/xml/en/skin.xml b/DOCS/xml/en/skin.xml
index 278279b708..2be4e940d4 100644
--- a/DOCS/xml/en/skin.xml
+++ b/DOCS/xml/en/skin.xml
@@ -1107,14 +1107,14 @@ menu entries.
 <varlistentry>
   <term><emphasis role="bold">evLoadSubtitle</emphasis></term>
   <listitem><para>
-  Loads a subtitle file (with the fileselector)
+  Loads a subtitle file (with the file selector).
   </para></listitem>
 </varlistentry>
 
 <varlistentry>
   <term><emphasis role="bold">evLoadAudioFile</emphasis></term>
   <listitem><para>
-  Loads an audio file (with the fileselector)
+  Loads an audio file (with the file selector).
   </para></listitem>
 </varlistentry>
 
diff --git a/DOCS/xml/en/usage.xml b/DOCS/xml/en/usage.xml
index 11d8d2356f..9fc3cdac4e 100644
--- a/DOCS/xml/en/usage.xml
+++ b/DOCS/xml/en/usage.xml
@@ -291,7 +291,7 @@ ENTER pt_step 1 1<!--
 <title>Control from LIRC</title>
 
 <para>
-Linux Infrared Remote Control - use an easy to build home-brewn IR-receiver,
+Linux Infrared Remote Control - use an easy to build home-brewed IR-receiver,
 an (almost) arbitrary remote control and control your Linux box with it!
 More about it on the <ulink url="http://www.lirc.org">LIRC homepage</ulink>.
 </para>
@@ -421,7 +421,7 @@ will save the content streamed from
 <replaceable>http://217.71.208.37:8006</replaceable> into
 <replaceable>stream.asf</replaceable>.
 This works with all protocols supported by
-<application>MPlayer</application>, like MMS, RSTP, and so forth.
+<application>MPlayer</application>, like MMS, RTSP, and so forth.
 </para>
 </sect2>
 </sect1>
diff --git a/DOCS/xml/en/video.xml b/DOCS/xml/en/video.xml
index f61e4fa028..3284c6545b 100644
--- a/DOCS/xml/en/video.xml
+++ b/DOCS/xml/en/video.xml
@@ -195,7 +195,7 @@ xv support, but the card itself is very slow, so you better sell it.
 <para>
 There is now a native framebuffer driver for S3 Virge cards similar to
 tdfxfb. Set up your framebuffer (e.g. append
-"<option>vga=792 video=vesa:mtrr</option>" to your kernel comand line) and use
+"<option>vga=792 video=vesa:mtrr</option>" to your kernel command line) and use
 <option>-vo s3fb</option> (<option>-vf yuy2</option> and <option>-dr</option>
 will also help).
 </para>
@@ -838,7 +838,7 @@ framebuffer, and don't ask for it, since it's not an
 
 <para>
 <systemitem>mga_vid</systemitem> is a combination of a video output driver and
-a Linux kernel module that utilitizes the Matrox G200/G400/G450/G550 video
+a Linux kernel module that utilizes the Matrox G200/G400/G450/G550 video
 scaler/overlay unit to perform YUV->RGB colorspace conversion and arbitrary
 video scaling.
 <systemitem>mga_vid</systemitem> has hardware VSYNC support with triple
@@ -1857,7 +1857,7 @@ have <command>scan</command> compile it for you.
 </para>
 
 <para>
-If you have more than one card type (e.g. Satellitar, Terrestrial, Cable and ATSC)
+If you have more than one card type (e.g. Satellite, Terrestrial, Cable and ATSC)
 you can save your channels files as
 <filename>~/.mplayer/channels.conf.sat</filename>,
 <filename>~/.mplayer/channels.conf.ter</filename>,
@@ -2245,7 +2245,7 @@ mplayer -vo zr -vf crop=720:320:80:0 <replaceable>benhur.avi</replaceable>
 <para>
 Extra occurrences of <option>-zrcrop</option> invoke
 <emphasis>cinerama</emphasis> mode, i.e. you can distribute the movie over
-several TV's or beamers to create a larger screen.
+several TVs or beamers to create a larger screen.
 Suppose you have two beamers. The left one is connected to your
 Buz at <filename>/dev/video1</filename> and the right one is connected to
 your DC10+ at <filename>/dev/video0</filename>. The movie has a resolution
@@ -2337,7 +2337,7 @@ for Matrox G450/G550 TV-out instructions, please see the next section!
     <emphasis role="bold">SLOW</emphasis>, and has
     <emphasis role="bold">Macrovision</emphasis> copy protection enabled
     (you can "workaround" Macrovision using this
-    <ulink url="http://avifile.sf.net/mgamacro.pl">perl script</ulink>).
+    <ulink url="http://avifile.sf.net/mgamacro.pl">Perl script</ulink>).
     </para>
   </listitem>
 </varlistentry>