General reformatting round:

 - fix some " -> "
 - reindent with more consistency
 - visual markup of <sect?> tags
 - break overly long lines
 - add missing <replaceable> tags in examples
 - cola truck standing by


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

1 files changed, 2216 insertions, 2076 deletions

diff --git a/DOCS/xml/en/encoding-guide.xml b/DOCS/xml/en/encoding-guide.xml
index c0255a0b2a..eaf954809e 100644
--- a/DOCS/xml/en/encoding-guide.xml
+++ b/DOCS/xml/en/encoding-guide.xml
@@ -4,82 +4,90 @@
 <title>Encoding with <application>MEncoder</application></title>
 
 <sect1 id="menc-feat-dvd-mpeg4">
-<title>Making a high quality MPEG-4 (&quot;DivX&quot;) rip of a DVD movie</title>
+<title>Making a high quality MPEG-4 (&quot;DivX&quot;)
+  rip of a DVD movie</title>
 
 <para>
-  One frequently asked question is "How do I make the highest quality rip for
-  a given size?". Another question is "How do I make the highest quality DVD
-  rip possible? I do not care about file size, I just want the best quality."
+One frequently asked question is &quot;How do I make the highest quality rip
+for a given size?&quot;. Another question is &quot;How do I make the highest
+quality DVD rip possible? I do not care about file size, I just want the best
+quality.&quot;
 </para>
 
 <para>
-  The latter question is perhaps at least somewhat wrongly posed. After all, if
-  you do not care about file size, why not simply copy the entire MPEG-2 video
-  stream from the the DVD? Sure, your AVI will end up being 5GB, give
-  or take, but if you want the best quality and do not care about size,
-  this is certainly your best option.
+The latter question is perhaps at least somewhat wrongly posed. After all, if
+you do not care about file size, why not simply copy the entire MPEG-2 video
+stream from the the DVD? Sure, your AVI will end up being 5GB, give
+or take, but if you want the best quality and do not care about size,
+this is certainly your best option.
 </para>
 
 <para>
-  In fact, the reason you want to transcode a DVD into MPEG-4 is
-  specifically because you <emphasis role="bold">do</emphasis> care about
-  file size.
+In fact, the reason you want to transcode a DVD into MPEG-4 is
+specifically because you <emphasis role="bold">do</emphasis> care about
+file size.
 </para>
 
 <para>
-  It is difficult to offer a cookbook recipe on how to create a very high
-  quality DVD rip. There are several factors to consider, and you should
-  understand these details or else you are likely to end up disappointed
-  with your results. Below we will investigate some of these issues, and
-  then have a look at an example. We assume you are using
-  <systemitem class="library">libavcodec</systemitem> to encode the video,
-  although the theory applies to other codecs as well.
+It is difficult to offer a cookbook recipe on how to create a very high
+quality DVD rip. There are several factors to consider, and you should
+understand these details or else you are likely to end up disappointed
+with your results. Below we will investigate some of these issues, and
+then have a look at an example. We assume you are using
+<systemitem class="library">libavcodec</systemitem> to encode the video,
+although the theory applies to other codecs as well.
 </para>
 
 <para>
-  If this seems to be too much for you, you should probably use one of the
-  many fine frontends that are listed in the
-  <ulink url="http://www.mplayerhq.hu/design7/projects.html#mencoder_frontends">MEncoder section</ulink>
-  of our related projects page.
-  That way, you should be able to achieve high quality rips without too much
-  thinking, because most of those tools are designed to take clever decisions
-  for you.
+If this seems to be too much for you, you should probably use one of the
+many fine frontends that are listed in the
+<ulink url="http://www.mplayerhq.hu/design7/projects.html#mencoder_frontends">MEncoder section</ulink>
+of our related projects page.
+That way, you should be able to achieve high quality rips without too much
+thinking, because most of those tools are designed to take clever decisions
+for you.
 </para>
 
+<!-- ********** -->
+
 <sect2 id="menc-feat-dvd-mpeg4-preparing-encode">
 <title>Preparing to encode: Identifying source material and framerate</title>
+
 <para>
-  Before you even think about encoding a movie, you need to take
-  several preliminary steps.
+Before you even think about encoding a movie, you need to take
+several preliminary steps.
 </para>
 
 <para>
-  The first and most important step before you encode should be
-  determining what type of content you are dealing with.
-  If your source material comes from DVD or broadcast/cable/satellite
-  TV, it will be stored in one of two formats: NTSC for North
-  America and Japan, PAL for Europe, etc.
-  It is important to realize, however, that this is just the formatting for
-  presentation on a television, and often does
-  <emphasis role="bold">not</emphasis> correspond to the
-  original format of the movie.
-  Experience shows that NTSC material is a lot more difficult to encode,
-  because there more elements to identify in the source.
-  In order to produce a suitable encode, you need to know the original
-  format.
-  Failure to take this into account will result in various flaws in your
-  encode, including ugly combing (interlacing) artifacts and duplicated
-  or even lost frames.
-  Besides being ugly, the artifacts also harm coding efficiency:
-  You will get worse quality per unit bitrate.
+The first and most important step before you encode should be
+determining what type of content you are dealing with.
+If your source material comes from DVD or broadcast/cable/satellite
+TV, it will be stored in one of two formats: NTSC for North
+America and Japan, PAL for Europe, etc.
+It is important to realize, however, that this is just the formatting for
+presentation on a television, and often does
+<emphasis role="bold">not</emphasis> correspond to the
+original format of the movie.
+Experience shows that NTSC material is a lot more difficult to encode,
+because there more elements to identify in the source.
+In order to produce a suitable encode, you need to know the original
+format.
+Failure to take this into account will result in various flaws in your
+encode, including ugly combing (interlacing) artifacts and duplicated
+or even lost frames.
+Besides being ugly, the artifacts also harm coding efficiency:
+You will get worse quality per unit bitrate.
 </para>
 
+
 <sect3 id="menc-feat-dvd-mpeg4-preparing-encode-fps">
 <title>Identifying source framerate</title>
+
 <para>
-  Here is a list of common types of source material, where you are
-  likely to find them, and their properties:
+Here is a list of common types of source material, where you are
+likely to find them, and their properties:
 </para>
+
 <itemizedlist>
 <listitem><para>
   <emphasis role="bold">Standard Film</emphasis>: Produced for
@@ -122,31 +130,35 @@
 </itemizedlist>
 </sect3>
 
+
 <sect3 id="menc-feat-dvd-mpeg4-preparing-encode-material">
 <title>Identifying source material</title>
+
 <para>
-  Movies consisting of frames are referred to as progressive,
-  while those consisting of independent fields are called
-  either interlaced or video - though this latter term is
-  ambiguous.
+Movies consisting of frames are referred to as progressive,
+while those consisting of independent fields are called
+either interlaced or video - though this latter term is
+ambiguous.
 </para>
+
 <para>
-  To further complicate matters, some movies will be a mix of
-  several of the above.
+To further complicate matters, some movies will be a mix of
+several of the above.
 </para>
+
 <para>
-  The most important distinction to make between all of these
-  formats is that some are frame-based, while others are
-  field-based.
-  <emphasis role="bold">Whenever</emphasis> a movie is prepared
-  for display on television (including DVD), it is converted to a
-  field-based format.
-  The various methods by which this can be done are collectively
-  referred to as "telecine", of which the infamous NTSC
-  "3:2 pulldown" is one variety.
-  Unless the original material was also field-based (and the same
-  fieldrate), you are getting the movie in a format other than the
-  original.
+The most important distinction to make between all of these
+formats is that some are frame-based, while others are
+field-based.
+<emphasis role="bold">Whenever</emphasis> a movie is prepared
+for display on television (including DVD), it is converted to a
+field-based format.
+The various methods by which this can be done are collectively
+referred to as "telecine", of which the infamous NTSC
+"3:2 pulldown" is one variety.
+Unless the original material was also field-based (and the same
+fieldrate), you are getting the movie in a format other than the
+original.
 </para>
 
 <itemizedlist>
@@ -183,39 +195,41 @@
 </itemizedlist>
 
 <para>
-  There are also methods for converting between NTSC and PAL video,
-  but such topics are beyond the scope of this guide.
-  If you encounter such a movie and want to encode it, your best
-  bet is to find a copy in the original format.
-  Conversion between these two formats is highly destructive and
-  cannot be reversed cleanly, so your encode will greatly suffer
-  if it is made from a converted source.
-</para>
-<para>
-  When video is stored on DVD, consecutive pairs of fields are
-  grouped as a frame, even though they are not intended to be shown
-  at the same moment in time.
-  The MPEG-2 standard used on DVD and digital TV provides a
-  way both to encode the original progressive frames and to store
-  the number of fields for which a frame should be shown in the
-  header of that frame.
-  If this method has been used, the movie will often be described
-  as "soft-telecined", since the process only directs the
-  DVD player to apply pulldown to the movie rather than altering
-  the movie itself.
-  This case is highly preferable since it can easily be reversed
-  (actually ignored) by the encoder, and since it preserves maximal
-  quality.
-  However, many DVD and broadcast production studios do not use
-  proper encoding techniques but instead produce movies with
-  "hard telecine", where fields are actually duplicated in the
-  encoded MPEG-2.
-</para>
-<para>
-  The procedures for dealing with these cases will be covered
-  <link linkend="menc-feat-telecine">later in this guide</link>.
-  For now, we leave you with some guides to identifying which type
-  of material you are dealing with:
+There are also methods for converting between NTSC and PAL video,
+but such topics are beyond the scope of this guide.
+If you encounter such a movie and want to encode it, your best
+bet is to find a copy in the original format.
+Conversion between these two formats is highly destructive and
+cannot be reversed cleanly, so your encode will greatly suffer
+if it is made from a converted source.
+</para>
+
+<para>
+When video is stored on DVD, consecutive pairs of fields are
+grouped as a frame, even though they are not intended to be shown
+at the same moment in time.
+The MPEG-2 standard used on DVD and digital TV provides a
+way both to encode the original progressive frames and to store
+the number of fields for which a frame should be shown in the
+header of that frame.
+If this method has been used, the movie will often be described
+as "soft-telecined", since the process only directs the
+DVD player to apply pulldown to the movie rather than altering
+the movie itself.
+This case is highly preferable since it can easily be reversed
+(actually ignored) by the encoder, and since it preserves maximal
+quality.
+However, many DVD and broadcast production studios do not use
+proper encoding techniques but instead produce movies with
+"hard telecine", where fields are actually duplicated in the
+encoded MPEG-2.
+</para>
+
+<para>
+The procedures for dealing with these cases will be covered
+<link linkend="menc-feat-telecine">later in this guide</link>.
+For now, we leave you with some guides to identifying which type
+of material you are dealing with:
 </para>
 
 <itemizedlist>
@@ -232,9 +246,9 @@
   "combing" at times, then there are several possibilities.
   The 24000/1001 fps segments are almost certainly progressive
   content, "soft telecined", but the 30000/1001 fps parts could be
-  either hard-telecined 24000/1001 fps content or 60000/1001 fields per second NTSC video.
-  Use the same guidelines as the following two cases to determine
-  which.
+  either hard-telecined 24000/1001 fps content or 60000/1001 fields per second
+  NTSC video.
+  Use the same guidelines as the following two cases to determine which.
 </para></listitem>
 <listitem><para>
   If <application>MPlayer</application> never shows the framerate
@@ -268,192 +282,194 @@
   <application>MPlayer</application> can slow down movie playback
   with the -speed option or play it frame-by-frame.
   Try using <option>-speed</option> 0.2 to watch the movie very
-  slowly or press the "<keycap>.</keycap>" key repeatedly to play one frame at a time
-  and identify the pattern, if you cannot see it at full speed.
+  slowly or press the "<keycap>.</keycap>" key repeatedly to play one frame at
+  a time and identify the pattern, if you cannot see it at full speed.
 </para>
 </note>
 </sect3>
 </sect2>
 
+<!-- ********** -->
+
 <sect2 id="menc-feat-dvd-mpeg4-2pass">
 <title>Constant quantizer vs. multipass</title>
 
 <para>
-  It is possible to encode your movie at a wide range of qualities.
-  With modern video encoders and a bit of pre-codec compression
-  (downscaling and denoising), it is possible to achieve very good
-  quality at 700 MB, for a 90-110 minute widescreen movie.
-  Furthermore, all but the longest movies can be encoded with near-perfect
-  quality at 1400 MB.
+It is possible to encode your movie at a wide range of qualities.
+With modern video encoders and a bit of pre-codec compression
+(downscaling and denoising), it is possible to achieve very good
+quality at 700 MB, for a 90-110 minute widescreen movie.
+Furthermore, all but the longest movies can be encoded with near-perfect
+quality at 1400 MB.
 </para>
 
 <para>
-  There are three approaches to encoding the video: constant bitrate
-  (CBR), constant quantizer, and multipass (ABR, or average bitrate).
+There are three approaches to encoding the video: constant bitrate
+(CBR), constant quantizer, and multipass (ABR, or average bitrate).
 </para>
 
 <para>
-  The complexity of the frames of a movie, and thus the number of bits
-  required to compress them, can vary greatly from one scene to another.
-  Modern video encoders can adjust to these needs as they go and vary
-  the bitrate.
-  In simple modes such as CBR, however, the encoders do not know the
-  bitrate needs of future scenes and so cannot exceed the requested
-  average bitrate for long stretches of time.
-  More advanced modes, such as multipass encode, can take into account
-  the statistics from previous passes; this fixes the problem mentioned
-  above.
+The complexity of the frames of a movie, and thus the number of bits
+required to compress them, can vary greatly from one scene to another.
+Modern video encoders can adjust to these needs as they go and vary
+the bitrate.
+In simple modes such as CBR, however, the encoders do not know the
+bitrate needs of future scenes and so cannot exceed the requested
+average bitrate for long stretches of time.
+More advanced modes, such as multipass encode, can take into account
+the statistics from previous passes; this fixes the problem mentioned
+above.
 </para>
 
 <note><title>Note:</title>
 <para>
-  Most codecs which support ABR encode only support two pass encode
-  while some others such as <systemitem class="library">x264</systemitem>,
-  <systemitem class="library">Xvid</systemitem>
-  and <systemitem class="library">libavcodec</systemitem> support
-  multipass, which slightly improves quality at each pass,
-  yet this improvement is no longer measurable nor noticeable after the
-  4th or so pass.
-  Therefore, in this section, two pass and multipass will be used
-  interchangeably.
+Most codecs which support ABR encode only support two pass encode
+while some others such as <systemitem class="library">x264</systemitem>,
+<systemitem class="library">Xvid</systemitem>
+and <systemitem class="library">libavcodec</systemitem> support
+multipass, which slightly improves quality at each pass,
+yet this improvement is no longer measurable nor noticeable after the
+4th or so pass.
+Therefore, in this section, two pass and multipass will be used
+interchangeably.
 </para>
 </note>
 
 <para>
-  In each of these modes, the video codec (such as
-  <systemitem class="library">libavcodec</systemitem>)
-  breaks the video frame into 16x16 pixel macroblocks and then applies a
-  quantizer to each macroblock. The lower the quantizer, the better the
-  quality and higher the bitrate.
-  The method the movie encoder uses to determine
-  which quantizer to use for a given macroblock varies and is highly
-  tunable. (This is an extreme over-simplification of the actual
-  process, but the basic concept is useful to understand.)
+In each of these modes, the video codec (such as
+<systemitem class="library">libavcodec</systemitem>)
+breaks the video frame into 16x16 pixel macroblocks and then applies a
+quantizer to each macroblock. The lower the quantizer, the better the
+quality and higher the bitrate.
+The method the movie encoder uses to determine
+which quantizer to use for a given macroblock varies and is highly
+tunable. (This is an extreme over-simplification of the actual
+process, but the basic concept is useful to understand.)
 </para>
 
 <para>
-  When you specify a constant bitrate, the video codec will encode the video,
-  discarding
-  detail as much as necessary and as little as possible in order to remain
-  lower than the given bitrate. If you truly do not care about file size,
-  you could as well use CBR and specify a bitrate of infinity. (In
-  practice, this means a value high enough so that it poses no limit, like
-  10000Kbit.) With no real restriction on bitrate, the result is that
-  the codec will use the lowest
-  possible quantizer for each macroblock (as specified by
-  <option>vqmin</option> for 
-  <systemitem class="library">libavcodec</systemitem>, which is 2 by default).
-  As soon as you specify a
-  low enough bitrate that the codec
-  is forced to use a higher quantizer, then you are almost certainly ruining
-  the quality of your video.
-  In order to avoid that, you should probably downscale your video, according
-  to the method described later on in this guide.
-  In general, you should avoid CBR altogether if you care about quality.
+When you specify a constant bitrate, the video codec will encode the video,
+discarding
+detail as much as necessary and as little as possible in order to remain
+lower than the given bitrate. If you truly do not care about file size,
+you could as well use CBR and specify a bitrate of infinity. (In
+practice, this means a value high enough so that it poses no limit, like
+10000Kbit.) With no real restriction on bitrate, the result is that
+the codec will use the lowest
+possible quantizer for each macroblock (as specified by
+<option>vqmin</option> for 
+<systemitem class="library">libavcodec</systemitem>, which is 2 by default).
+As soon as you specify a
+low enough bitrate that the codec
+is forced to use a higher quantizer, then you are almost certainly ruining
+the quality of your video.
+In order to avoid that, you should probably downscale your video, according
+to the method described later on in this guide.
+In general, you should avoid CBR altogether if you care about quality.
 </para>
 
 <para>
-  With constant quantizer, the codec uses the same quantizer, as
-  specified by the <option>vqscale</option> option (for
-  <systemitem class="library">libavcodec</systemitem>), on every macroblock.
-  If you want the highest quality rip possible, again ignoring bitrate,
-  you can use <option>vqscale=2</option>.
-  This will yield the same bitrate and PSNR (peak signal-to-noise ratio)
-  as CBR with
-  <option>vbitrate</option>=infinity and the default <option>vqmin</option>
-  of 2.
+With constant quantizer, the codec uses the same quantizer, as
+specified by the <option>vqscale</option> option (for
+<systemitem class="library">libavcodec</systemitem>), on every macroblock.
+If you want the highest quality rip possible, again ignoring bitrate,
+you can use <option>vqscale=2</option>.
+This will yield the same bitrate and PSNR (peak signal-to-noise ratio)
+as CBR with
+<option>vbitrate</option>=infinity and the default <option>vqmin</option>
+of 2.
 </para>
 
 <para>
-  The problem with constant quantizing is that it uses the given quantizer
-  whether the macroblock needs it or not. That is, it might be possible
-  to use a higher quantizer on a macroblock without sacrificing visual
-  quality. Why waste the bits on an unnecessarily low quantizer? Your
-  CPU has as many cycles as there is time, but there is only so many bits
-  on your hard disk.
+The problem with constant quantizing is that it uses the given quantizer
+whether the macroblock needs it or not. That is, it might be possible
+to use a higher quantizer on a macroblock without sacrificing visual
+quality. Why waste the bits on an unnecessarily low quantizer? Your
+CPU has as many cycles as there is time, but there is only so many bits
+on your hard disk.
 </para>
 
 <para>
-  With a two pass encode, the first pass will rip the movie as though it
-  were CBR, but it will keep a log of properties for each frame. This
-  data is then used during the second pass in order to make intelligent
-  decisions about which quantizers to use. During fast action or high
-  detail scenes, higher quantizers will likely be used, and during
-  slow moving or low detail scenes, lower quantizers will be used.
-  Normally, the amount of motion is much more important than the
-  amount of detail.
+With a two pass encode, the first pass will rip the movie as though it
+were CBR, but it will keep a log of properties for each frame. This
+data is then used during the second pass in order to make intelligent
+decisions about which quantizers to use. During fast action or high
+detail scenes, higher quantizers will likely be used, and during
+slow moving or low detail scenes, lower quantizers will be used.
+Normally, the amount of motion is much more important than the
+amount of detail.
 </para>
 
 <para>
-  If you use <option>vqscale=2</option>, then you are wasting bits. If you
-  use <option>vqscale=3</option>, then you are not getting the highest
-  quality rip. Suppose you rip a DVD at <option>vqscale=3</option>, and
-  the result is 1800Kbit. If you do a two pass encode with
-  <option>vbitrate=1800</option>, the resulting video will have <emphasis
-  role="bold">higher quality</emphasis> for the
-  <emphasis role="bold">same bitrate</emphasis>.
+If you use <option>vqscale=2</option>, then you are wasting bits. If you
+use <option>vqscale=3</option>, then you are not getting the highest
+quality rip. Suppose you rip a DVD at <option>vqscale=3</option>, and
+the result is 1800Kbit. If you do a two pass encode with
+<option>vbitrate=1800</option>, the resulting video will have
+<emphasis role="bold">higher quality</emphasis> for the
+<emphasis role="bold">same bitrate</emphasis>.
 </para>
 
 <para>
-  Since you are now convinced that two pass is the way to go, the real
-  question now is what bitrate to use? The answer is that there is no
-  single answer. Ideally you want to choose a bitrate that yields the
-  best balance between quality and file size. This is going to vary
-  depending on the source video.
+Since you are now convinced that two pass is the way to go, the real
+question now is what bitrate to use? The answer is that there is no
+single answer. Ideally you want to choose a bitrate that yields the
+best balance between quality and file size. This is going to vary
+depending on the source video.
 </para>
 
 <para>
-  If size does not matter, a good starting point for a very high quality
-  rip is about 2000Kbit plus or minus 200Kbit.
-  For fast action or high detail source video, or if you just have a very
-  critical eye, you might decide on 2400 or 2600.
-  For some DVDs, you might not notice a difference at 1400Kbit. It is a
-  good idea to experiment with scenes at different bitrates to get a feel.
+If size does not matter, a good starting point for a very high quality
+rip is about 2000Kbit plus or minus 200Kbit.
+For fast action or high detail source video, or if you just have a very
+critical eye, you might decide on 2400 or 2600.
+For some DVDs, you might not notice a difference at 1400Kbit. It is a
+good idea to experiment with scenes at different bitrates to get a feel.
 </para>
 
 <para>
-  If you aim at a certain size, you will have to somehow calculate the bitrate.
-  But before that, you need to know how much space you should reserve for the
-  audio track(s), so you should <link linkend="menc-feat-dvd-mpeg4-audio">rip
-  those</link> first.
-  You can compute the bitrate with the following equation:
-  <systemitem>bitrate = (target_size_in_Mbytes - sound_size_in_Mbytes) *
-  1024 * 1024 / length_in_secs * 8 / 1000</systemitem>
-  For instance, to squeeze a two-hour movie onto a 702MB CD, with 60MB
-  of audio track, the video bitrate will have to be:
-  <systemitem>(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000
-  = 740kbps</systemitem>
+If you aim at a certain size, you will have to somehow calculate the bitrate.
+But before that, you need to know how much space you should reserve for the
+audio track(s), so you should
+<link linkend="menc-feat-dvd-mpeg4-audio">rip those</link> first.
+You can compute the bitrate with the following equation:
+<systemitem>bitrate = (target_size_in_Mbytes - sound_size_in_Mbytes) *
+1024 * 1024 / length_in_secs * 8 / 1000</systemitem>
+For instance, to squeeze a two-hour movie onto a 702MB CD, with 60MB
+of audio track, the video bitrate will have to be:
+<systemitem>(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000
+= 740kbps</systemitem>
 </para>
-
 </sect2>
 
+<!-- ********** -->
 
 <sect2 id="menc-feat-dvd-mpeg4-constraints">
 <title>Constraints for efficient encoding</title>
 
 <para>
-  Due to the nature of MPEG-type compression, there are various
-  constraints you should follow for maximal quality.
-  MPEG splits the video up into 16x16 squares called macroblocks,
-  each composed of 4 8x8 blocks of luma (intensity) information and two
-  half-resolution 8x8 chroma (color) blocks (one for red-cyan axis and
-  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
-  a bad idea to use dimensions that are not multiples of 16.
+Due to the nature of MPEG-type compression, there are various
+constraints you should follow for maximal quality.
+MPEG splits the video up into 16x16 squares called macroblocks,
+each composed of 4 8x8 blocks of luma (intensity) information and two
+half-resolution 8x8 chroma (color) blocks (one for red-cyan axis and
+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
+a bad idea to use dimensions that are not multiples of 16.
 </para>
 
 <para>
-  Most DVDs also have some degree of black borders at the edges. Leaving
-  these in place will hurt quality <emphasis role="bold">a lot</emphasis>
-  in several ways.
+Most DVDs also have some degree of black borders at the edges. Leaving
+these in place will hurt quality <emphasis role="bold">a lot</emphasis>
+in several ways.
 </para>
 
 <orderedlist>
 <listitem>
-<para>
+  <para>
   MPEG-type compression is also highly dependent on frequency domain
   transformations, in particular the Discrete Cosine Transform (DCT),
   which is similar to the Fourier transform. This sort of encoding is
@@ -461,33 +477,33 @@
   has a hard time with sharp edges. In order to encode them it must
   use many more bits, or else an artifact known as ringing will
   appear.
-</para>
+  </para>
 
-<para>
+  <para>
   The frequency transform (DCT) takes place separately on each
   macroblock (actually each block), so this problem only applies when
   the sharp edge is inside a block. If your black borders begin
   exactly at multiple-of-16 pixel boundaries, this is not a problem.
   However, the black borders on DVDs rarely come nicely aligned, so
   in practice you will always need to crop to avoid this penalty.
-</para>
+  </para>
 </listitem>
 </orderedlist>
 
 <para>
-  In addition to frequency domain transforms, MPEG-type compression uses
-  motion vectors to represent the change from one frame to the next.
-  Motion vectors naturally work much less efficiently for new content
-  coming in from the edges of the picture, because it is not present in
-  the previous frame. As long as the picture extends all the way to the
-  edge of the encoded region, motion vectors have no problem with
-  content moving out the edges of the picture. However, in the presence
-  of black borders, there can be trouble:
+In addition to frequency domain transforms, MPEG-type compression uses
+motion vectors to represent the change from one frame to the next.
+Motion vectors naturally work much less efficiently for new content
+coming in from the edges of the picture, because it is not present in
+the previous frame. As long as the picture extends all the way to the
+edge of the encoded region, motion vectors have no problem with
+content moving out the edges of the picture. However, in the presence
+of black borders, there can be trouble:
 </para>
 
 <orderedlist continuation="continues">
 <listitem>
-<para>
+  <para>
   For each macroblock, MPEG-type compression stores a vector
   identifying which part of the previous frame should be copied into
   this macroblock as a base for predicting the next frame. Only the
@@ -499,72 +515,71 @@
   motion vector will not be used at all and all the changes in this
   macroblock will have to be coded explicitly. Either way, encoding
   efficiency is greatly reduced.
-</para>
+  </para>
 
-<para>
+  <para>
   Again, this problem only applies if black borders do not line up on
   multiple-of-16 boundaries.
-</para>
+  </para>
 </listitem>
 
 <listitem>
-<para>
+  <para>
   Finally, suppose we have a macroblock in the interior of the
   picture, and an object is moving into this block from near the edge
   of the image. MPEG-type coding cannot say "copy the part that is
   inside the picture but not the black border." So the black border
   will get copied inside too, and lots of bits will have to be spent
   encoding the part of the picture that is supposed to be there.
-</para>
+  </para>
 
-<para>
+  <para>
   If the picture runs all the way to the edge of the encoded area,
   MPEG has special optimizations to repeatedly copy the pixels at the
   edge of the picture when a motion vector comes from outside the
   encoded area. This feature becomes useless when the movie has black
   borders. Unlike problems 1 and 2, aligning the borders at multiples
   of 16 does not help here.
-</para>
+  </para>
 </listitem>
 
-<listitem>
-<para>
+<listitem><para>
   Despite the borders being entirely black and never changing, there
   is at least a minimal amount of overhead involved in having more
   macroblocks.
-</para>
-</listitem>
+</para></listitem>
 </orderedlist>
 
 <para>
-  For all of these reasons, it is recommended to fully crop black
-  borders. Further, if there is an area of noise/distortion at the edge
-  of the picture, cropping this will improve encoding efficiency as
-  well. Videophile purists who want to preserve the original as close as
-  possible may object to this cropping, but unless you plan to encode at
-  constant quantizer, the quality you gain from cropping will
-  considerably exceed the amount of information lost at the edges.
+For all of these reasons, it is recommended to fully crop black
+borders. Further, if there is an area of noise/distortion at the edge
+of the picture, cropping this will improve encoding efficiency as
+well. Videophile purists who want to preserve the original as close as
+possible may object to this cropping, but unless you plan to encode at
+constant quantizer, the quality you gain from cropping will
+considerably exceed the amount of information lost at the edges.
 </para>
 </sect2>
 
+<!-- ********** -->
 
 <sect2 id="menc-feat-dvd-mpeg4-crop">
 <title>Cropping and Scaling</title>
 
 <para>
-  Recall from the previous section that the final picture size you
-  encode should be a multiple of 16 (in both width and height).
-  This can be achieved by cropping, scaling, or a combination of both.
+Recall from the previous section that the final picture size you
+encode should be a multiple of 16 (in both width and height).
+This can be achieved by cropping, scaling, or a combination of both.
 </para>
 
 <para>
-  When cropping, there are a few guidelines that must be followed to
-  avoid damaging your movie.
-  The normal YUV format, 4:2:0, stores chroma (color) information
-  subsampled, i.e. chroma is only sampled half as often in each
-  direction as luma (intensity) information.
-  Observe this diagram, where L indicates luma sampling points and C
-  chroma.
+When cropping, there are a few guidelines that must be followed to
+avoid damaging your movie.
+The normal YUV format, 4:2:0, stores chroma (color) information
+subsampled, i.e. chroma is only sampled half as often in each
+direction as luma (intensity) information.
+Observe this diagram, where L indicates luma sampling points and C
+chroma.
 </para>
 
 <informaltable>
@@ -641,18 +656,18 @@
 </informaltable>
 
 <para>
-  As you can see, rows and columns of the image naturally come in pairs.
-  Thus your crop offsets and dimensions <emphasis>must</emphasis> be
-  even numbers.
-  If they are not, the chroma will no longer line up correctly with the
-  luma.
-  In theory, it is possible to crop with odd offsets, but it requires
-  resampling the chroma which is potentially a lossy operation and not
-  supported by the crop filter.
+As you can see, rows and columns of the image naturally come in pairs.
+Thus your crop offsets and dimensions <emphasis>must</emphasis> be
+even numbers.
+If they are not, the chroma will no longer line up correctly with the
+luma.
+In theory, it is possible to crop with odd offsets, but it requires
+resampling the chroma which is potentially a lossy operation and not
+supported by the crop filter.
 </para>
 
 <para>
-  Further, interlaced video is sampled as follows:
+Further, interlaced video is sampled as follows:
 </para>
 
 <informaltable>
@@ -893,164 +908,169 @@
 </informaltable>
 
 <para>
-  As you can see, the pattern does not repeat until after 4 lines.
-  So for interlaced video, your y-offset and height for cropping must
-  be multiples of 4.
+As you can see, the pattern does not repeat until after 4 lines.
+So for interlaced video, your y-offset and height for cropping must
+be multiples of 4.
 </para>
 
 <para>
-  Native DVD resolution is 720x480 for NTSC, and 720x576 for PAL, but
-  there is an aspect flag that specifies whether it is full-screen (4:3) or
-  wide-screen (16:9). Many (if not most) widescreen DVDs are not strictly
-  16:9, and will be either 1.85:1 or 2.35:1 (cinescope). This means that
-  there will be black bands in the video that will need to be cropped out.
+Native DVD resolution is 720x480 for NTSC, and 720x576 for PAL, but
+there is an aspect flag that specifies whether it is full-screen (4:3) or
+wide-screen (16:9). Many (if not most) widescreen DVDs are not strictly
+16:9, and will be either 1.85:1 or 2.35:1 (cinescope). This means that
+there will be black bands in the video that will need to be cropped out.
 </para>
 
 <para>
-  <application>MPlayer</application> provides a crop detection filter that
-  will determine the crop rectangle