re-organize MEncoder doc in a more sensible way: splitting "basic mencoder usage" and "encoding with mencoder".

note: if you can't generate the doc on your machine, make sure you run "make distclean" beforehand


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

3 files changed, 3652 insertions, 3643 deletions

diff --git a/DOCS/xml/en/documentation.xml b/DOCS/xml/en/documentation.xml
index c03c0203a7..664accf392 100644
--- a/DOCS/xml/en/documentation.xml
+++ b/DOCS/xml/en/documentation.xml
@@ -181,6 +181,7 @@ can be distributed under the terms of the GNU General Public License Version 2.
 &cd-dvd.xml;
 &ports.xml;
 &mencoder.xml;
+&encoding-guide.xml;
 &mail-lists.xml;
 &bugreports.xml;
 &bugs.xml;
diff --git a/DOCS/xml/en/encoding-guide.xml b/DOCS/xml/en/encoding-guide.xml
new file mode 100644
index 0000000000..e0229dc054
--- /dev/null
+++ b/DOCS/xml/en/encoding-guide.xml
@@ -0,0 +1,3650 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!-- $Revision$ -->
+<chapter id="encoding-guide">
+<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>
+
+<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."
+</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.
+</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.
+</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.
+</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://mplayerhq.hu/homepage/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.
+</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.
+  In order to produce a suitable encode, you need to know the original
+  format.
+  Failure to take this into account will result in ugly combing
+  (interlacing) artifacts in your encode.
+  Besides being ugly, the artifacts also harm coding efficiency:
+  You will get worse quality per 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:
+</para>
+<itemizedlist>
+<listitem><para>
+  <emphasis role="bold">Standard Film</emphasis>: Produced for
+  theatrical display at 24fps.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">PAL video</emphasis>: Recorded with a PAL
+  video camera at 50 fields per second.
+  A field consists of just the odd- or even-numbered lines of a
+  frame.
+  Television was designed to refresh these in alternation as a
+  cheap form of analog compression.
+  The human eye supposedly compensates for this, but once you
+  understand interlacing you will learn to see it on TV too and
+  never enjoy TV again.
+  Two fields do <emphasis role="bold">not</emphasis> make a
+  complete frame, because they are captured 1/50 of a second apart
+  in time, and thus they do not line up unless there is no motion.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">NTSC Video</emphasis>: Recorded with an
+  NTSC video camera at 60000/1001 fields per second, or 60 fields per
+  second in the pre-color era.
+  Otherwise similar to PAL.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Animation</emphasis>: Usually drawn at
+  24fps, but also comes in mixed-framerate varieties.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Computer Graphics (CG)</emphasis>: Can be
+  any framerate, but some are more common than others; 24 and
+  30 frames per second are typical for NTSC, and 25fps is typical
+  for PAL.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Old Film</emphasis>: Various lower
+  framerates.
+</para></listitem>
+</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.
+</para>
+<para>
+  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 "pulldown", of which the infamous NTSC
+  "3:2 telecine" 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>
+<title>There are several common types of pulldown:</title>
+<listitem><para>
+  <emphasis role="bold">PAL 2:2 pulldown</emphasis>: The nicest of
+  them all.
+  Each frame is shown for the duration of two fields, by extracting the
+  even and odd lines and showing them in alternation.
+  If the original material is 24fps, this process speeds up the
+  movie by 4%.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">PAL 2:2:2:2:2:2:2:2:2:2:2:3 pulldown</emphasis>:
+  Every 12th frame is shown for the duration of three fields, instead of
+  just two.
+  This avoids the 4% speedup issue, but makes the process much
+  more difficult to reverse.
+  It is usually seen in musical productions where adjusting the
+  speed by 4% would seriously damage the musical score.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">NTSC 3:2 telecine</emphasis>: Frames are
+  shown alternately for the duration of 3 fields or 2 fields.
+  This gives a fieldrate 2.5 times the original framerate.
+  The result is also slowed down very slightly from 60 fields per
+  second to 60000/1001 fields per second to maintain NTSC fieldrate.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">NTSC 2:2 pulldown</emphasis>: Used for
+  showing 30fps material on NTSC.
+  Nice, just like 2:2 PAL pulldown.
+</para></listitem>
+</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 later
+  in this guide.
+  For now, we leave you with some guides to identifying which type
+  of material you are dealing with:
+</para>
+
+<itemizedlist>
+<title>NTSC regions:</title>
+<listitem><para>
+  If <application>MPlayer</application> prints that the framerate
+  has changed to 24000/1001 when watching your movie, and never changes
+  back, it is almost certainly progressive content that has been
+  "soft telecined".
+</para></listitem>
+<listitem><para>
+  If <application>MPlayer</application> shows the framerate
+  switching back and forth between 24000/1001 and 30000/1001, and you see
+  "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.
+</para></listitem>
+<listitem><para>
+  If <application>MPlayer</application> never shows the framerate
+  changing, and every single frame with motion appears combed, your
+  movie is NTSC video at 60000/1001 fields per second.
+</para></listitem>
+<listitem><para>
+  If <application>MPlayer</application> never shows the framerate
+  changing, and two frames out of every five appear combed, your
+  movie is "hard telecined" 24000/1001fps content.
+</para></listitem>
+</itemizedlist>
+
+<itemizedlist>
+<title>PAL regions:</title>
+<listitem><para>
+  If you never see any combing, your movie is 2:2 pulldown.
+</para></listitem>
+<listitem><para>
+  If you see combing alternating in and out every half second,
+  then your movie is 2:2:2:2:2:2:2:2:2:2:2:3 pulldown.
+</para></listitem>
+<listitem><para>
+  If you always see combing during motion, then your movie is PAL
+  video at 50 fields per second.
+</para></listitem>
+</itemizedlist>
+
+<note><title>Hint:</title>
+<para>
+  <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.
+</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.
+</para>
+
+<para>
+  There are three approaches to encoding the video: constant bitrate
+  (CBR), constant quantizer, and multipass (ABR, or average bitrate).
+</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>
+  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, <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
+  <systemitem class="library">libavcodec</systemitem> 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, <systemitem
+  class="library">libavcodec</systemitem> 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
+  <systemitem class="library">libavcodec</systemitem> will use the lowest
+  possible quantizer for each macroblock (as specified by
+  <option>vqmin</option>, which is 2 by default). As soon as you specify a
+  low enough bitrate that <systemitem class="library">libavcodec</systemitem>
+  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, <systemitem
+  class="library">libavcodec</systemitem> uses the same quantizer, as
+  specified by the <option>vqscale</option> option, 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.
+</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 low
+  detail scenes, higher quantizers will likely be used, and during
+  slow moving or high detail scenes, lower quantizers will be used.
+</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>.
+</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.
+</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.
+</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>
+</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.
+</para>
+
+<para>
+  Most DVDs also have some degree of black borders at the edges. Leaving
+  these in place can hurt quality in several ways.
+</para>
+
+<orderedlist>
+<listitem>
+<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
+  efficient for representing patterns and smooth transitions, but it
+  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>
+  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>
+</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:
+</para>
+
+<orderedlist continuation="continues">
+<listitem>
+<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
+  remaining differences need to be encoded. If a macroblock spans the
+  edge of the picture and contains part of the black border, then
+  motion vectors from other parts of the picture will overwrite the
+  black border. This means that lots of bits must be spent either
+  re-blackening the border that was overwritten, or (more likely) a
+  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>
+  Again, this problem only applies if black borders do not line up on
+  multiple-of-16 boundaries.
+</para>
+</listitem>
+
+<listitem>
+<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>
+  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>
+</listitem>
+
+<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>
+</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.
+</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.
+</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.
+</para>
+
+<informaltable>
+<?dbhtml table-width="40%" ?>
+<?dbfo table-width="40%" ?>
+<tgroup cols="8" align="center">
+<colspec colnum="1" colname="col1"/>
+<colspec colnum="2" colname="col2"/>
+<colspec colnum="3" colname="col3"/>
+<colspec colnum="4" colname="col4"/>
+<colspec colnum="5" colname="col5"/>
+<colspec colnum="6" colname="col6"/>
+<colspec colnum="7" colname="col7"/>
+<colspec colnum="8" colname="col8"/>
+<spanspec spanname="spa1-2" namest="col1" nameend="col2"/>
+<spanspec spanname="spa3-4" namest="col3" nameend="col4"/>
+<spanspec spanname="spa5-6" namest="col5" nameend="col6"/>
+<spanspec spanname="spa7-8" namest="col7" nameend="col8"/>
+  <tbody>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+  </tbody>
+</tgroup>
+</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.
+</para>
+
+<para>
+  Further, interlaced video is sampled as follows:
+</para>
+
+<informaltable>
+<?dbhtml table-width="80%" ?>
+<?dbfo table-width="80%" ?>
+<tgroup cols="16" align="center">
+<colspec colnum="1"  colname="col1"/>
+<colspec colnum="2"  colname="col2"/>
+<colspec colnum="3"  colname="col3"/>
+<colspec colnum="4"  colname="col4"/>
+<colspec colnum="5"  colname="col5"/>
+<colspec colnum="6"  colname="col6"/>
+<colspec colnum="7"  colname="col7"/>
+<colspec colnum="8"  colname="col8"/>
+<colspec colnum="9"  colname="col9"/>
+<colspec colnum="10" colname="col10"/>
+<colspec colnum="11" colname="col11"/>
+<colspec colnum="12" colname="col12"/>
+<colspec colnum="13" colname="col13"/>
+<colspec colnum="14" colname="col14"/>
+<colspec colnum="15" colname="col15"/>
+<colspec colnum="16" colname="col16"/>
+<spanspec spanname="spa1-2"   namest="col1" nameend="col2"/>
+<spanspec spanname="spa3-4"   namest="col3" nameend="col4"/>
+<spanspec spanname="spa5-6"   namest="col5" nameend="col6"/>
+<spanspec spanname="spa7-8"   namest="col7" nameend="col8"/>
+<spanspec spanname="spa9-10"  namest="col9" nameend="col10"/>
+<spanspec spanname="spa11-12" namest="col11" nameend="col12"/>
+<spanspec spanname="spa13-14" namest="col13" nameend="col14"/>
+<spanspec spanname="spa15-16" namest="col15" nameend="col16"/>
+  <tbody>
+    <row>
+      <entry namest="col1" nameend="col8">Top field</entry>
+      <entry namest="col9" nameend="col16">Bottom field</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry spanname="spa9-10">C</entry>
+      <entry spanname="spa11-12">C</entry>
+      <entry spanname="spa13-14">C</entry>
+      <entry spanname="spa15-16">C</entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry spanname="spa9-10">C</entry>
+      <entry spanname="spa11-12">C</entry>
+      <entry spanname="spa13-14">C</entry>
+      <entry spanname="spa15-16">C</entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>