summaryrefslogtreecommitdiffstats
path: root/DOCS/xml/en/encoding-guide.xml
diff options
context:
space:
mode:
Diffstat (limited to 'DOCS/xml/en/encoding-guide.xml')
-rw-r--r--DOCS/xml/en/encoding-guide.xml5545
1 files changed, 1 insertions, 5544 deletions
diff --git a/DOCS/xml/en/encoding-guide.xml b/DOCS/xml/en/encoding-guide.xml
index 9309df9df7..d458f31b1c 100644
--- a/DOCS/xml/en/encoding-guide.xml
+++ b/DOCS/xml/en/encoding-guide.xml
@@ -3,5550 +3,7 @@
<chapter id="encoding-guide">
<title>Encoding with <application>MEncoder</application></title>
-<sect1 id="menc-feat-dvd-mpeg4">
-<title>Making a high quality MPEG-4 ("DivX")
- 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://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.
-</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.
-</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 "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>
-<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
-<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>
-<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>
-
-<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.
-</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.
-</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.)
-</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.
-</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.
-</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 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>.
-</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 file size, 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.
-</para>
-
-<orderedlist>
-<listitem>
- <para>
- MPEG-type compression is 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>
- <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>
- </tbody>
-</tgroup>
-</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.
-</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.
-</para>
-
-<para>
-<applicat