Mercurial > mplayer.hg
changeset 16080:baae7cdb0726
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
| author | gpoirier |
|---|---|
| date | Sun, 24 Jul 2005 14:22:14 +0000 |
| parents | 96d10b705bc6 |
| children | 72c352edce8f |
| files | DOCS/xml/en/documentation.xml DOCS/xml/en/encoding-guide.xml DOCS/xml/en/mencoder.xml |
| diffstat | 3 files changed, 3652 insertions(+), 3643 deletions(-) [+] |
line wrap: on
line diff
--- a/DOCS/xml/en/documentation.xml Sun Jul 24 12:56:07 2005 +0000 +++ b/DOCS/xml/en/documentation.xml Sun Jul 24 14:22:14 2005 +0000 @@ -181,6 +181,7 @@ &cd-dvd.xml; &ports.xml; &mencoder.xml; +&encoding-guide.xml; &mail-lists.xml; &bugreports.xml; &bugs.xml;
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/DOCS/xml/en/encoding-guide.xml Sun Jul 24 14:22:14 2005 +0000 @@ -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 ("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://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> + <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> + <application>MPlayer</application> provides a crop detection filter that + will determine the crop rectangle (<option>-vf cropdetect</option>). + Run <application>MPlayer</application> with + <option>-vf cropdetect</option> and it will print out the crop + settings to remove the borders. + You should let the movie run long enough that the whole picture + area is used, in order to get accurate crop values. +</para> + +<para> + Then, test the values you get with <application>MPlayer</application>, + using the command line which was printed by + <option>cropdetect</option>, and adjust the rectangle as needed. + The <option>rectangle</option> filter can help by allowing you to + interactively position the crop rectangle over your movie. + Remember to follow the above divisibility guidelines so that you + do not misalign the chroma planes. +</para> + +<para> + In certain cases, scaling may be undesirable. + Scaling in the vertical direction is difficult with interlaced + video, and if you wish to preserve the interlacing, you should + usually refrain from scaling. + If you will not be scaling but you still want to use multiple-of-16 + dimensions, you will have to overcrop. + Do not undercrop, since black borders are very bad for encoding! +</para> + +<para> + Because MPEG-4 uses 16x16 macroblocks, you will want to make sure that each + dimension of the video you are encoding is a multiple of 16 or else you + will be degrading quality, especially at lower bitrates. You can do this + by rounding the width and height of the crop rectangle down to the nearest + multiple of 16. + As stated earlier, when cropping, you will want to increase the Y offset by + half the difference of the old and the new height so that the resulting + video is taken from the center of the frame. And because of the way DVD + video is sampled, make sure the offset is an even number. (In fact, as a + rule, never use odd values for any parameter when you are cropping and + scaling video.) If you are not comfortable throwing a few extra pixels + away, you might prefer instead to scale the video instead. We will look + at this in our example below. + You can actually let the <option>cropdetect</option> filter do all of the + above for you, as it has an optional <option>round</option> parameter that + is equal to 16 by default. +</para> + +<para> + Also, be careful about "half black" pixels at the edges. Make sure you + crop these out too, or else you will be wasting bits there that + are better spent elsewhere. +</para> + +<para> + After all is said and done, you will probably end up with video whose pixels + are not quite 1.85:1 or 2.35:1, but rather something close to that. You + could calculate the new aspect ratio manually, but + <application>MEncoder</application> offers an option for <systemitem + class="library">libavcodec</systemitem> called <option>autoaspect</option> + that will do this for you. Absolutely do not scale this video up in order to + square the pixels unless you like to waste your hard disk space. Scaling + should be done on playback, and the player will use the aspect stored in + the AVI to determine the correct resolution. + Unfortunately, not all players enforce this auto-scaling information, + therefore you may still want to rescale. +</para> + +<para> + First, you should compute the encoded aspect ratio: + <systemitem>ARc = (Wc x (ARa / PRdvd )) / Hc</systemitem> +<itemizedlist> +<title>where:</title> +<listitem><para> + Wc and Hc are the width and height of the cropped video, +</para></listitem> +<listitem><para> + ARa is the displayed aspect ratio, which usually is 4/3 or 16/9, +</para></listitem> +<listitem><para> + PRdvd is the pixel ratio of the DVD which is equal to 1.25=(720/576) for PAL + DVDs and 1.5=(720/480) for NTSC DVDs, +</para></listitem> +</itemizedlist> +</para> + +<para> + Then, you can compute the X and Y resolution, according to a certain + Compression Quality (CQ) factor: + <systemitem>ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16</systemitem> + and + <systemitem>ResX = INT( ResY * ARc / 16) * 16</systemitem> +</para> + +<para> + Okay, but what is the CQ? + The CQ represents the number of bits per pixel and per frame of the encode. + Roughly speaking, the greater the CQ, the less the likelihood to see + encoding artifacts. + However, if you have a target size for your movie (1 or 2 CDs for instance), + there is a limited total number of bits that you can spend; therefore it is + necessary to find a good tradeoff between compressibility and quality. +</para> + +<para> + The CQ depends both on the bitrate and the movie resolution. + In order to raise the CQ, typically you would downscale the movie given that the + bitrate is computed in function of the target size and the length of the + movie, which are constant. + A CQ below 0.18 usually ends up in a very blocky picture, because there + are not enough bits to code the information of each macroblock (MPEG4, like + many other codecs, groups pixels by blocks of several pixels to compress the + image; if there are not enough bits, the edges of those blocks are + visible). + It is therefore wise to take a CQ ranging from 0.20 to 0.22 for a 1 CD rip, + and 0.26-0.28 for 2 CDs. +</para> + +<para> + Please take note that the CQ is just an indicative figure, as depending on + the encoded content, a CQ of 0.18 may look just fine for a Bergman, contrary + to a movie such as The Matrix, which contains many high-motion scenes. + On the other hand, it is worthless to raise CQ higher than 0.30 as you would + be wasting bits without any noticeable quality gain. +</para> + +</sect2> + +<sect2 id="menc-feat-dvd-mpeg4-audio"> +<title>Audio</title> + +<para> + Audio is a much simpler problem to solve: if you care about quality, just + leave it as is. + Even AC3 5.1 streams are at most 448Kbit/s, and they are worth every bit. + You might be tempted to transcode the audio to high quality Vorbis, but + just because you do not have an A/V receiver for AC3 pass-through today + does not mean you will not have one tomorrow. Future-proof your DVD rips by + preserving the AC3 stream. + You can keep the AC3 stream either by copying it directly into the video + stream <link linkend="menc-feat-mpeg4">during the encoding</link>. + You can also extract the AC3 stream in order to mux it into containers such + as NUT or Matroska. + <screen>mplayer <replaceable>source_file.vob</replaceable> -aid 129 -dumpaudio -dumpfile <replaceable>sound.ac3</replaceable></screen> + will dump into the file <replaceable>sound.ac3</replaceable> the + audio track number 129 from the file + <replaceable>source_file.vob</replaceable> (NB: DVD VOB files + usually use a different audio numbering, + which means that the VOB audio track 129 is the 2nd audio track of the file). +</para> + +<para> + But sometimes you truly have no choice but to further compress the + sound so that more bits can be spent on the video. + Most people choose to compress audio with either MP3 or Vorbis audio + codecs. + While the latter is a very space-efficient codec, MP3 is better supported + by hardware players, although this trend is changing. +</para> + +<para> + First of all, you will have to convert the DVD sound into a WAV file that the + audio codec can use as input. + For example: + <screen>mplayer <replaceable>source_file.vob</replaceable> -ao pcm:file=<replaceable>destination_sound.wav</replaceable> -vc dummy -aid 1 -vo null</screen> + will dump the second audio track from the file + <replaceable>source_file.vob</replaceable> into the file + <replaceable>destination_sound.wav</replaceable>. + You may want to normalize the sound before encoding, as DVD audio tracks + are commonly recorded at low volumes. + You can use the tool <application>normalize</application> for instance, + which is available in most distributions. + If you are using Windows, a tool such as <application>BeSweet</application> + can do the same job. + You will compress in either Vorbis or MP3. + For example: + <screen>oggenc -q1 <replaceable>destination_sound.wav</replaceable></screen> + will encode <replaceable>destination_sound.wav</replaceable> with + the encoding quality 1, which is roughly equivalent to 80Kb/s, and + is the minimum quality at which you should encode if you care about + quality. + Please note that MEncoder currently cannot mux Vorbis audio tracks + into the output file because it only supports AVI and MPEG + containers as an output, each of which may lead to audio/video + playback synchronization problems with some players when the AVI file + contain VBR audio streams such as Vorbis. + Do not worry, this document will show you how you can do that with third + party programs. +</para> + +</sect2> + +<sect2 id="menc-feat-dvd-mpeg4-interlacing"> +<title>Interlacing and Telecine</title> + +<para> + Almost all movies are shot at 24 fps. Because NTSC is 30000/1001 fps, some + processing must be done to this 24 fps video to make it run at the correct + NTSC framerate. The process is called 3:2 pulldown, commonly referred to + as telecine (because pulldown is often applied during the telecine + process), and, naively described, it works by slowing the film down to + 24000/1001 fps, and repeating every fourth frame. +</para> + +<para> + No special processing, however, is done to the video for PAL DVDs, which + run at 25 fps. (Technically, PAL can be telecined, called 2:2 pulldown, + but this does not become an issue in practice.) The 24 fps film is simply + played back at 25 fps. The result is that the movie runs slightly faster, + but unless you are an alien, you probably will not notice the difference. + Most PAL DVDs have pitch-corrected audio, so when they are played back at + 25 fps things will sound right, even though the audio track (and hence the + whole movie) has a running time that is 4% less than NTSC DVDs. +</para> + +<para> + Because the video in a PAL DVD has not been altered, you needn't worry + much about framerate. The source is 25 fps, and your rip will be 25 + fps. However, if you are ripping an NTSC DVD movie, you may need to + apply inverse telecine. +</para> + +<para> + For movies shot at 24 fps, the video on the NTSC DVD is either telecined + 30000/1001, or else it is progressive 24000/1001 fps and intended to be telecined + on-the-fly by a DVD player. On the other hand, TV series are usually + only interlaced, not telecined. This is not a hard rule: some TV series + are interlaced (such as Buffy the Vampire Slayer) whereas some are a + mixture of progressive and interlaced (such as Angel, or 24). +</para> + +<para> + It is highly recommended that you read the section on + <link linkend="menc-feat-telecine">How to deal with telecine and interlacing in NTSC DVDs</link> + to learn how to handle the different possibilities. +</para> + +<para> + However, if you are mostly just ripping movies, likely you are either + dealing with 24 fps progressive or telecined video, in which case you can + use the <option>pullup</option> filter <option>-vf + pullup,softskip</option>. +</para> + +</sect2> + +<sect2 id="menc-feat-dvd-mpeg4-encoding-interlaced"> +<title>Encoding interlaced video</title> + +<para> + If the movie you want to encode is interlaced (NTSC video or + PAL video), you will need to choose whether you want to + deinterlace or not. + While deinterlacing will make your movie usable on progressive + scan displays such a computer monitors and projectors, it comes + at a cost: The fieldrate of 50 or 60000/1001 fields per second + is halved to 25 or 30000/1001 frames per second, and roughly half of + the information in your movie will be lost during scenes with + significant motion. +</para> + +<para> + Therefore, if you are encoding for high quality archival purposes, + it is recommended not to deinterlace. + You can always deinterlace the movie at playback time when + displaying it on progressive scan devices, and future players will + be able to deinterlace to full fieldrate, interpolating 50 or + 60000/1001 entire frames per second from the interlaced video. +</para> + +<para> +Special care must be taken when working with interlaced video: +</para> + +<orderedlist> +<listitem><para> + Crop height and y-offset must be multiples of 4. +</para></listitem> +<listitem><para> + Any vertical scaling must be performed in interlaced mode. +</para></listitem> +<listitem><para> + Postprocessing and denoising filters may not work as expected + unless you take special care to operate them a field at a time, + and they may damage the video if used incorrectly. +</para></listitem> +</orderedlist> + +<para> +With these things in mind, here is our first example: +</para> +<screen> + mencoder <replaceable>capture.avi</replaceable> -mc 0 -oac lavc -ovc lavc -lavcopts \ + vcodec=mpeg2video:vbitrate=6000:ilmv:ildct:acodec=mp2:abitrate=224 +</screen> +<para> +Note the <option>ilmv</option> and <option>ildct</option> options. +</para> +</sect2> + +<sect2 id="menc-feat-dvd-mpeg4-filtering"> +<title>Filtering</title> + +<para> + In general, you want to do as little filtering as possible to the movie + in order to remain close to the original DVD source. Cropping is often + necessary (as described above), but do not scale the video. Although + scaling down is sometimes preferred to using higher quantizers, we want + to avoid both these things: remember that we decided from the start to + trade bits for quality. +</para> + +<para> + Also, do not adjust gamma, contrast, brightness, etc. What looks good + on your display may not look good on others. These adjustments should + be done on playback only. +</para> + +<para> + One thing you might want to do, however, is pass the video through a + very light denoise filter, such as <option>-vf hqdn3d=2:1:2</option>. + Again, it is a matter of putting those bits to better use: why waste them + encoding noise when you can just add that noise back in during playback? + Increasing the parameters for <option>hqdn3d</option> will further + improve compressibility, but if you increase the values too much, you + risk degrading the image visibily. The suggested values above + (<option>2:1:2</option>) are quite conservative; you should feel free to + experiment with higher values and observe the results for yourself. +</para> + +</sect2> + + +<sect2 id="menc-feat-dvd-mpeg4-muxing"> +<title>Muxing</title> +<para> + Now that you have encoded your video, you will most likely want + to mux it with one or more audio tracks into a movie container, such + as AVI, MPEG, Matroska or NUT. + <application>MEncoder</application> is currently only able to output + audio and video into MPEG and AVI container formats. + for example: + <screen>mencoder -oac copy -ovc copy -o <replaceable>output_movie.avi</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable></screen> + This would merge the video file <replaceable>input_video.avi</replaceable> + and the audio file <replaceable>input_audio.mp2</replaceable> + into the AVI file <replaceable>output_movie.avi</replaceable>. + This command works with MPEG-1 layer I, II and III (more commonly known + as MP3) audio, WAV and a few other audio formats too. +</para> + +<para> + MEncoder features experimental support for + <systemitem class="library">libavformat</systemitem>, which is a + library from the FFmpeg project that supports muxing and demuxing + a variety of containers. + For example: + <screen>mencoder -oac copy -ovc copy -o <replaceable>output_movie.asf</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable> -of lavf -lavfopts format=asf</screen> + This will do the same thing as the previous example, except that + the output container will be ASF. + Please note that this support is highly experimental (but getting + better every day), and will only work if you compiled + <application>MPlayer</application> with the support for + <systemitem class="library">libavformat</systemitem> enabled (which + means that a pre-packaged binary version will not work in most cases). +</para> + +<sect3 id="menc-feat-dvd-mpeg4-muxing-avi-limitations"> +<title>Limitations of the AVI container</title> +<para> + Although it is the most widely-supported container format after MPEG-1, + AVI also has some major drawbacks. + Perhaps the most obvious is the overhead. + For each chunk of the AVI file, 24 bytes are wasted on headers and + index. + This translates into a little over 5 MB per hour, or 1-2.5% + overhead for a 700 MB movie. This may not seem like much, but it could + mean the difference between being able to use 700 kbit/sec video or + 714 kbit/sec, and every bit of quality counts. +</para> + +<para> + In addition this gross inefficiency, AVI also has the following major + limitations: +</para> + +<orderedlist> +<listitem> +<para> + Only fixed-fps content can be stored. This is particularly limiting + if the original material you want to encode is mixed content, for + example a mix of NTSC video and film material. + Actually there are hacks that can be used to store mixed-framerate + content in AVI, but they increase the (already huge) overhead + fivefold or more and so are not practical. +</para> +</listitem> +<listitem> +<para> + Audio in AVI files must be either constant-bitrate (CBR) or + constant-framesize (i.e. all frames decode to the same number of + samples). + Unfortunately, the most efficient codec, Vorbis, does not meet + either of these requirements. + Therefore, if you plan to store your movie in AVI, you will have to + use a less efficient codec such as MP3 or AC3. +</para> +</listitem> +</orderedlist> + +<para> + Having said all that, <application>MEncoder</application> does not + currently support variable-fps output or Vorbis encoding. + Therefore, you may not see these as limitations if + <application>MEncoder</application> is the + only tool you will be using to produce your encodes. + However, it is possible to use <application>MEncoder</application> + only for video encoding, and then use external tools to encode + audio and mux it into another container format. +</para> +</sect3> + +<sect3 id="menc-feat-dvd-mpeg4-muxing-matroska"> +<title>Muxing into the Matroska container</title> +<para> + Matroska is a free, open standard container format, aiming + to offer a lot of advanced features, which older containers + like AVI cannot handle. + For example, Matroska supports variable bitrate audio content + (VBR), variable framerates (VFR), chapters, file attachments, + error detection code (EDC) and modern A/V Codecs like "Advanced Audio + Coding" (AAC), "Vorbis" or "MPEG-4 AVC" (H.264), next to nothing + handled by AVI. +</para> + +<para> + The tools required to create Matroska files are collectively called + <application>mkvtoolnix</application>, and are available for most + Unix platforms as well as <application>Windows</application>. + Because Matroska is an open standard you may find other + tools that suit you better, but since mkvtoolnix is the most + common, and is supported by the Matroska team itself, we will + only cover its usage. +</para> + +<para> + Probably the easiest way to get started with Matroska is to use + <application>MMG</application>, the graphical frontend shipped with + <application>mkvtoolnix</application>, and follow the + <ulink url="http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge-gui.html">guide to mkvmerge GUI (mmg)</ulink> +</para> + +<para> + You may also mux audio and video files using the command line: + <screen>mkvmerge -o <replaceable>output.mkv</replaceable> <replaceable>input_video.avi</replaceable> <replaceable>input_audio1.mp3</replaceable> <replaceable>input_audio2.ac3</replaceable></screen> + This would merge the video file <replaceable>input_video.avi</replaceable> + and the two audio files <replaceable>input_audio1.mp3</replaceable> + and <replaceable>input_audio2.ac3</replaceable> into the Matroska + file <replaceable>output.mkv</replaceable>. + Matroska, as mentioned earlier, is able to do much more than that, like + multiple audio tracks (including fine-tuning of audio/video + synchronization), chapters, subtitles, splitting, etc... + Please refer to the documentation of those applications for + more details. +</para> + +</sect3> + +</sect2> + +</sect1> + +<sect1 id="menc-feat-telecine"> +<title>How to deal with telecine and interlacing within NTSC DVDs</title> + +<sect2 id="menc-feat-telecine-intro"> +<title>Introduction</title> +<formalpara> +<title>What is telecine?</title> +<para> + I suggest you visit this page if you do not understand much of what + is written in this document: + <ulink url="http://www.divx.com/support/guides/guide.php?gid=10">http://www.divx.com/support/guides/guide.php?gid=10</ulink> + This URL links to an understandable and reasonably comprehensive + description of what telecine is. +</para></formalpara> + +<formalpara> +<title>A note about the numbers.</title> +<para> + Many documents, including the guide linked above, refer to the fields + per second value of NTSC video as 59.94 and the corresponding frames + per second values as 29.97 (for telecined and interlaced) and 23.976 + (for progressive). For simplicity, some documents even round these + numbers to 60, 30, and 24. +</para></formalpara> + +<para> + Strictly speaking, all those numbers are approximations. Black and + white NTSC video was exactly 60 fields per second, but 60000/1001 + was later chosen to accomodate color data while remaining compatible + with contemporary black and white televisions. Digital NTSC video + (such as on a DVD) is also 60000/1001 fields per second. From this, + interlaced and telecined video are derived to be 30000/1001 frames + per second; progressive video is 24000/1001 frames per second. +</para> + +<para> + Older versions of the <application>MEncoder</application> documentation + and many archived mailing list posts refer to 59.94, 29.97, and 23.976. + All <application>MEncoder</application> documentation has been updated + to use the fractional values, and you should use them too. +</para> + +<para> + <option>-ofps 23.976</option> is incorrect. + <option>-ofps 24000/1001</option> should be used instead. +</para> + +<formalpara> +<title>How telecine is used.</title> +<para> + All video intended to be displayed on an NTSC + television set must be 60000/1001 fields per second. Made-for-TV movies +4 and shows are often filmed directly at 60000/1001 fields per second, but + the majority of cinema is filmed at 24 or 24000/1001 frames per + second. When cinematic movie DVDs are mastered, the video is then + converted for television using a process called telecine. +</para></formalpara> + +<para> + On a DVD, the video is never actually stored as 60000/1001 fields per + second. For video that was originally 60000/1001, each pair of fields is + combined to form a frame, resulting in 30000/1001 frames per + second. Hardware DVD players then read a flag embedded in the video + stream to determine whether the odd- or even-numbered lines should + form the first field. +</para> + +<para> + Usually, 24000/1001 frames per second content stays as it is when + encoded for a DVD, and the DVD player must perform telecining + on-the-fly. Sometimes, however, the video is telecined + <emphasis>before</emphasis> being stored on the DVD; even though it + was originally 24000/1001 frames per second, it becomes 60000/1001 fields per + second. When it is stored on the DVD, pairs of fields are combined to form + 30000/1001 frames per second. +</para> + +<para> + When looking at individual frames formed from 60000/10001 fields per + second video, telecined or otherwise, interlacing is clearly visible + wherever there is any motion, because one field (say, the + even-numbered lines) represents a moment in time 1/(60000/1001) + seconds later than the other. Playing interlaced video on a computer + looks ugly both because the monitor is higher resolution and because + the video is shown frame-after-frame instead of field-after-field. +</para> + +<itemizedlist> +<title>Notes:</title> +<listitem><para> + This section only applies to NTSC DVDs, and not PAL. + </para></listitem> +<listitem><para> + The example <application>MEncoder</application> lines throughout the + document are <emphasis role="bold">not</emphasis> intended for + actual use. They are simply the bare minimum required to encode the + pertaining video category. How to make good DVD rips or fine-tune + <systemitem class="library">libavcodec</systemitem> for maximal + quality is not within the scope of this document. + </para></listitem> +<listitem><para> + There are a couple footnotes specific to this guide, linked like this: + <link linkend="menc-feat-telecine-footnotes">[1]</link> + </para></listitem> +</itemizedlist> +</sect2> + +<sect2 id="menc-feat-telecine-ident"> +<title>How to tell what type of video you have</title> + +<sect3 id="menc-feat-telecine-ident-progressive"> +<title>Progressive</title> +<para> + Progressive video was originally filmed at 24000/1001 fps, and stored + on the DVD without alteration. +</para> + +<para> + When you play a progressive DVD in <application>MPlayer</application>, + <application>MPlayer</application> will print the following line as + soon as the movie begins to play: + + <screen> demux_mpg: 24000/1001 fps progressive NTSC content detected, switching framerate.</screen> + + From this point forward, demux_mpg should never say it finds + "30000/1001 fps NTSC content." +</para> + +<para> + When you watch progressive video, you should never see any + interlacing. Beware, however, because sometimes there is a tiny bit + of telecine mixed in where you would not expect. I have encountered TV + show DVDs that have one second of telecine at every scene change, or + at seemingly random places. I once watched a DVD that had a + progressive first half, and the second half was telecined. If you + want to be <emphasis>really</emphasis> thorough, you can scan the + entire movie: + + <screen>mplayer dvd://1 -nosound -vo null -benchmark</screen> + + Using <option>-benchmark</option> makes + <application>MPlayer</application> play the movie as quickly as it + possibly can; still, depending on your hardware, it can take a + while. Every time demux_mpg reports a framerate change, the line + immediately above will show you the time at which the change + occurred. +</para> + +<para> + Sometimes progressive video on DVDs is referred to as + "soft-telecine" because it is intended to + be telecined by the DVD player. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-telecined"> +<title>Telecined</title> +<para> + Telecined video was originally filmed at 24000/1001, but was telecined + <emphasis>before</emphasis> it was written to the DVD. +</para> + +<para> + <application>MPlayer</application> does not (ever) report any + framerate changes when it plays telecined video. +</para> + +<para> + Watching a telecined video, you will see interlacing artifacts that + seem to "blink": they repeatedly appear and disappear. + You can look closely at this by + <orderedlist> + <listitem> + <screen>mplayer dvd://1</screen> + </listitem> + <listitem><para> + Seek to a part with motion. + </para></listitem> + <listitem><para> + Use the <keycap>.</keycap> key to step forward one frame at a time. + </para></listitem> + <listitem><para> + Look at the pattern of interlaced-looking and progressive-looking + frames. If the pattern you see is PPPII,PPPII,PPPII,... then the + video is telecined. If you see some other pattern, then the video + may have been telecined using some non-standard method; + <application>MEncoder</application> cannot losslessly convert + non-standard telecine to progressive. If you do not see any + pattern at all, then it is most likely interlaced. + </para></listitem> + </orderedlist> +</para> + +<para> + Sometimes telecined video on DVDs is referred to as + "hard-telecine". Since hard-telecine is already 60000/1001 fields + per second, the DVD player plays the video without any manipulation. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-interlaced"> +<title>Interlaced</title> +<para> + Interlaced video was originally filmed at 60000/1001 fields per second, + and stored on the DVD as 30000/1001 frames per second. The interlacing effect + (often called "combing") is a result of combining pairs of + fields into frames. Each field is supposed to be 1/(60000/1001) seconds apart, + and when they are displayed simultaneously the difference is apparent. +</para> + +<para> + As with telecined video, <application>MPlayer</application> should + not ever report any framerate changes when playing interlaced content. +</para> + +<para> + When you view an interlaced video closely by frame-stepping with the + <keycap>.</keycap> key, you will see that every single frame is interlaced. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-mixedpt"> +<title>Mixed progressive and telecine</title> +<para> + All of a "mixed progressive and telecine" video was originally + 24000/1001 frames per second, but some parts of it ended up being telecined. +</para> + +<para> + When <application>MPlayer</application> plays this category, it will + (often repeatedly) switch back and forth between "30000/1001 fps NTSC" + and "24000/1001 fps progressive NTSC". Watch the bottom of + <application>MPlayer</application>'s output to see these messages. +</para> + +<para> + You should check the "30000/1001 fps NTSC" sections to make sure + they are actually telecine, and not just interlaced. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-ident-mixedpi"> +<title>Mixed progressive and interlaced</title> +<para> + In "mixed progressive and interlaced" content, progressive + and interlaced video have been spliced together. +</para> + +<para> + This category looks just like "mixed progressive and telecine", + until you examine the 30000/1001 fps sections and see that they do not have the + telecine pattern. +</para> +</sect3> + +</sect2> + +<sect2 id="menc-feat-telecine-encode"> +<title>How to encode each category</title> +<para> + As I mentioned in the beginning, example <application>MEncoder</application> + lines below are <emphasis role="bold">not</emphasis> meant to actually be used; + they only demonstrate the minimum parameters to properly encode each category. +</para> + +<sect3 id="menc-feat-telecine-encode-progressive"> +<title>Progressive</title> +<para> + Progressive video requires no special filtering to encode. The only + parameter you need to be sure to use is + <option>-ofps 24000/1001</option>. Otherwise, <application>MEncoder</application> + will try to encode at 30000/1001 fps and will duplicate frames. +</para> + +<para> + <screen>mencoder dvd://1 -nosound -ovc lavc -ofps 24000/1001</screen> +</para> + +<para> + It is often the case, however, that a video that looks progressive + actually has very short parts of telecine mixed in. Unless you are + sure, it is safest to treat the video as + <link linkend="menc-feat-telecine-encode-mixedpt">mixed progressive and telecine</link>. + The performance loss is small + <link linkend="menc-feat-telecine-footnotes">[3]</link>. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-encode-telecined"> +<title>Telecined</title> +<para> + Telecine can be reversed to retrieve the original 24000/1001 content, + using a process called inverse-telecine. + <application>MPlayer</application> contains several filters to + accomplish this; the best filter, <option>pullup</option>, is described + in the <link linkend="menc-feat-telecine-encode-mixedpt">mixed + progressive and telecine</link> section. +</para> +</sect3> + +<sect3 id="menc-feat-telecine-encode-interlaced"> +<title>Interlaced</title> +<para> + For most practical cases it is not possible to retrieve a complete + progressive video from interlaced content. The only way to do so + without losing half of the vertical resolution is to double the + framerate and try to "guess" what ought to make up the + corresponding lines for each field (this has drawbacks - see method + 3). +</para> + +<orderedlist> +<listitem><para> + + Encode the video in interlaced form. Normally, interlacing wreaks + havoc with the encoder's ability to compress well, but + <systemitem class="library">libavcodec</systemitem> has two + parameters specifically for dealing with storing interlaced video a + bit better: <option> ildct</option> and <option>ilme</option>. Also, + using <option>mbd=2</option> is strongly recommended + <link linkend="menc-feat-telecine-footnotes">[2] </link> because it + will encode macroblocks as non-interlaced in places where there is + no motion. Note that <option>-ofps</option> is NOT needed here. + + <screen>mencoder dvd://1 -nosound -ovc lavc -lavcopts ildct:ilme:mbd=2</screen> + </para></listitem> +<listitem><para> + Use a deinterlacing filter before encoding. There are several of + these filters available to choose from, each with its own advantages + and disadvantages. Consult <option>mplayer -pphelp</option> to see + what is available (grep for "deint"), and search the + <ulink url="http://www.mplayerhq.hu/homepage/design6/info.html#mailing_lists"> + MPlayer mailing lists</ulink> to find many discussions about the + various filters. Again, the framerate is not changing, so no + <option>-ofps</option>. Also, deinterlacing should be done after + cropping <link linkend="menc-feat-telecine-footnotes">[1]</link> and + before scaling. + + <screen>mencoder dvd://1 -nosound -vf pp=lb -ovc lavc</screen> + </para></listitem> +<listitem><para> + Unfortunately, this option is buggy with + <application>MEncoder</application>; it ought to work well with + <application>MEncoder G2</application>, but that is not here yet. You + might experience crahes. Anyway, the purpose of <option> -vf + tfields</option> is to create a full frame out of each field, which + makes the framerate 60000/1001. The advantage of this approach is that no + data is ever lost; however, since each frame comes from only one + field, the missing lines have to be interpolated somehow. There are + no very good methods of generating the missing data, and so the + result will look a bit similar to when using some deinterlacing + filters. Generating the missing lines creates other issues, as well, + simply because the amount of data doubles. So, higher encoding + bitrates are required to maintain quality, and more CPU power is + used for both encoding and decoding. tfields has several different + options for how to create the missing lines of each frame. If you + use this method, then Reference the manual, and chose whichever + option looks best for your material. Note that when using + <option>tfields</option> you + <emphasis role="bold">have to</emphasis> specify both + <option>-fps</option> and <option>-ofps</option> to be twice the + framerate of your original source. + + <screen>mencoder dvd://1 -nosound -vf tfields=2 -ovc lavc -fps 60000/1001 -ofps 60000/1001</screen> + </para></listitem> +<listitem><para> + If you plan on downscaling dramatically, you can extract and encode + only one of the two fields. Of course, you will lose half the vertical + resolution, but if you plan on downscaling to at most 1/2 of the + original, the loss will not matter much. The result will be a + progressive 30000/1001 frames per second file. The procedure is to use + <option>-vf field</option>, then crop + <link linkend="menc-feat-telecine-footnotes">[1]</link> and scale + appropriately. Remember that you will have to adjust the scale to + compensate for the vertical resolution being halved. + <screen>mencoder dvd://1 -nosound -vf field=0 -ovc lavc</screen> + </para></listitem> +</orderedlist> +</sect3> + +<sect3 id="menc-feat-telecine-encode-mixedpt"> +<title>Mixed progressive and telecine</title> +<para> + In order to turn mixed progressive and telecine video into entirely + progressive video, the telecined parts have to be + inverse-telecined. There are three ways to accomplish this, + described below. Note that you should + <emphasis role="bold">always</emphasis> inverse-telecine before any + rescaling; unless you really know what you are doing, + inverse-telecine before cropping, too + <link linkend="menc-feat-telecine-footnotes">[1]</link>. + <option>-ofps 24000/1001</option> is needed here because the output video + will be 24000/1001 frames per second. +</para> + +<itemizedlist> +<listitem><para> + <option>-vf pullup</option> is designed to inverse-telecine + telecined material while leaving progressive data alone. In order to + work properly, <option>pullup</option> <emphasis role="bold">must</emphasis> + be followed by the <option>softskip</option> filter or + else <application>MEncoder</application> will crash. + <option>pullup</option> is, however, the cleanest and most + accurate method available for encoding both telecine and + "mixed progressive and telecine". + + <screen>mencoder dvd://1 -nosound -vf pullup,softskip -ovc lavc -ofps 24000/1001</screen> + </para> + + + </listitem> + <listitem><para> + An older method + is to, rather than inverse-telecine the telecined parts, telecine + the non-telecined parts and then inverse-telecine the whole + video. Sound confusing? softpulldown is a filter that goes through + a video and makes the entire file telecined. If we follow + softpulldown with either <option>detc</option> or + <option>ivtc</option>, the final result will be entirely + progressive. <option>-ofps 24000/1001</option> is needed. + + <screen>mencoder dvd://1 -nosound -vf softpulldown,ivtc=1 -ovc lavc -ofps 24000/1001</screen> + </para> + </listitem> + +<listitem><para> + I have not used <option>-vf filmdint</option> myself, but here is what + D Richard Felker III has to say: + + <blockquote><para>It is OK, but IMO it tries to deinterlace rather + than doing inverse telecine too often (much like settop DVD + players & progressive TVs) which gives ugly flickering and + other artifacts. If you are going to use it, you at least need to + spend some time tuning the options and watching the output first + to make sure it is not messing up.</para></blockquote> + </para></listitem> +</itemizedlist> +</sect3> + +<sect3 id="menc-feat-telecine-encode-mixedpi"> +<title>Mixed progressive and interlaced</title> +<para> + There are two options for dealing with this category, each of + which is a compromise. You should decide based on the + duration/location of each type. +</para> + +<itemizedlist> +<listitem><para> + Treat it as progressive. The interlaced parts will look interlaced, + and some of the interlaced fields will have to be dropped, resulting + in a bit of uneven jumpiness. You can use a postprocessing filter if + you want to, but it may slightly degrade the progressive parts. + </para> + + <para> + This option should definitely not be used if you want to eventually + display the video on an interlaced device (with a TV card, for + example). If you have interlaced frames in a 24000/1001 frames per + second video, they will be telecined along with the progressive + frames. Half of the interlaced "frames" will be displayed for three + fields' duration (3/(60000/1001) seconds), resulting in a flicking + "jump back in time" effect that looks quite bad. If you + even attempt this, you <emphasis role="bold">must</emphasis> use a + deinterlacing filter like <option>lb</option> or + <option>l5</option>. + </para> + + <para> + It may also be a bad idea for progressive display, too. It will drop + pairs of consecutive interlaced fields, resulting in a discontinuity + that can be more visible than with the second method, which shows + some progressive frames twice. 30000/1001 frames per second interlaced + video is already a bit choppy because it really should be shown at + 60000/1001 fields per second, so the duplicate frames do not stand out as + much. + </para> + + <para> + Either way, it is best to consider your content and how you intend to + display it. If your video is 90% progressive and you never intend to + show it on a TV, you should favor a progressive approach. If it is + only half progressive, you probably want to encode it as if it is all + interlaced. + </para> + </listitem> + +<listitem><para> + Treat it as interlaced. Some frames of the progressive parts will + need to be duplicated, resulting in uneven jumpiness. Again, + deinterlacing filters may slightly degrade the progressive parts. + </para></listitem> + +</itemizedlist> +</sect3> + +</sect2> + +<sect2 id="menc-feat-telecine-footnotes"> +<title>Footnotes</title> +<orderedlist> +<listitem><formalpara> + <title>About cropping:</title> + <para> + Video data on DVDs are stored in a format called YUV 4:2:0. In YUV + video, luma ("brightness") and chroma ("color") + are stored separately. Because the human eye is somewhat less + sensitive to color than it is to brightness, in a YUV 4:2:0 picture + there is only one chroma pixel for every four luma pixels. In a + progressive picture, each square of four luma pixels (two on each + side) has one common chroma pixel. You must crop progressive YUV + 4:2:0 to even resolutions, and use even offsets. For example, + <option>crop=716:380:2:26</option> is OK but + <option>crop=716:380:3:26 </option> is not. + </para> + </formalpara> + + <para> + When you are dealing with interlaced YUV 4:2:0, the situation is a + bit more complicated. Instead of every four luma pixels in the + <emphasis>frame</emphasis> sharing a chroma pixel, every four luma + pixels in each <emphasis> field</emphasis> share a chroma + pixel. When fields are interlaced to form a frame, each scanline is + one pixel high. Now, instead of all four luma pixels being in a + square, there are two pixels side-by-side, and the other two pixels + are side-by-side two scanlines down. The two luma pixels in the + intermediate scanline are from the other field, and so share a + different chroma pixel with two luma pixels two scanlines away. All + this confusion makes it necessary to have vertical crop dimensions + and offsets be multiples of four. Horizontal can stay even. + </para> + + <para> + For telecined video, I recommend that cropping take place after + inverse telecining. Once the video is progressive you only need to + crop by even numbers. If you really want to gain the slight speedup + that cropping first may offer, you must crop vertically by multiples + of four or else the inverse-telecine filter will not have proper data. + </para> + + <para> + For interlaced (not telecined) video, you must always crop + vertically by multiples of four unless you use <option>-vf + field</option> before cropping. + </para> + </listitem> + +<listitem><formalpara> + <title>About encoding parameters and quality:</title> + <para> + Just because I recommend <option>mbd=2</option> here does not mean it + should not be used elsewhere. Along with <option>trell</option>, + <option>mbd=2</option> is one of the two + <systemitem class="library">libavcodec</systemitem> options that + increases quality the most, and you should always use at least those + two unless the drop in encoding speed is prohibitive (e.g. realtime + encoding). There are many other options to + <systemitem class="library">libavcodec</systemitem> that increase + encoding quality (and decrease encoding speed) but that is beyond + the scope of this document. + </para> + </formalpara> + </listitem> + +<listitem><formalpara> + <title>About the performance of pullup:</title> + <para> + It is safe to use <option>pullup</option> (along with <option>softskip + </option>) on progressive video, and is usually a good idea unless + the source has been definitively verified to be entirely progressive. + The performace loss is small for most cases. On a bare-minimum encode, + <option>pullup</option> causes <application>MEncoder</application> to + be 50% slower. Adding sound processing and advanced <option>lavcopts + </option> overshadows that difference, bringing the performance + decrease of using <option>pullup</option> down to 2%. + </para> + </formalpara> + </listitem> + +</orderedlist> + +</sect2> + +</sect1> + + +<sect1 id="menc-feat-enc-libavcodec"> +<title>Encoding with the <systemitem class="library">libavcodec</systemitem> + codec family</title> + +<para> +<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link> +provides simple encoding to a lot of interesting video and audio formats. +You can encode to the following codecs (more or less up to date): + +<informaltable frame="all"> +<tgroup cols="2"> +<thead> +<row><entry>Codec name</entry><entry>Description</entry></row> +</thead> +<tbody> +<row><entry>mjpeg</entry><entry> + Motion JPEG + </entry></row> +<row><entry>ljpeg</entry><entry> + Lossless JPEG + </entry></row> +<row><entry>h263</entry><entry> + H.263 + </entry></row> +<row><entry>h263p</entry><entry> + H.263+ + </entry></row> +<row><entry>mpeg4</entry><entry> + ISO standard MPEG-4 (DivX 5, XVID compatible) + </entry></row> +<row><entry>msmpeg4</entry><entry> + pre-standard MPEG-4 variant by MS, v3 (AKA DivX3) + </entry></row> +<row><entry>msmpeg4v2</entry><entry> + pre-standard MPEG-4 by MS, v2 (used in old asf files) + </entry></row> +<row><entry>wmv1</entry><entry> + Windows Media Video, version 1 (AKA WMV7) + </entry></row> +<row><entry>wmv2</entry><entry> + Windows Media Video, version 2 (AKA WMV8) + </entry></row> +<row><entry>rv10</entry><entry> + an old RealVideo codec + </entry></row> +<row><entry>mpeg1video</entry><entry> + MPEG-1 video + </entry></row> +<row><entry>mpeg2video</entry><entry> + MPEG-2 video + </entry></row> +<row><entry>huffyuv</entry><entry> + lossless compression + </entry></row> +<row><entry>asv1</entry><entry> + ASUS Video v1 + </entry></row> +<row><entry>asv2</entry><entry> + ASUS Video v2 + </entry></row> +<row><entry>ffv1</entry><entry> + FFmpeg's lossless video codec + </entry></row> +</tbody> +</tgroup> +</informaltable> + +The first column contains the codec names that should be passed after the +<literal>vcodec</literal> config, like: <option>-lavcopts vcodec=msmpeg4</option> +</para> + +<informalexample> +<para> +An example, with MJPEG compression: +<screen>mencoder dvd://2 -o title2.avi -ovc lavc -lavcopts vcodec=mjpeg -oac copy</screen> +</para> +</informalexample> + +<sect2 id="menc-feat-dvd-mpeg4-lavc-encoding-options"> +<title>Encoding options of libavcodec</title> + +<para> + Ideally, you would probably want to be able to just tell the encoder to switch + into "high quality" mode and move on. + That would probably be nice, but unfortunately hard to implement as different + encoding options yield different quality results depending on the source material. + That is because compression depends on the visual properties of the video + in question. + For example, anime and live action have very different properties and + thus require different options to obtain optimum encoding. + The good news is that some options should never be left out, like + <option>mbd=2</option>, <option>trell</option>, and <option>v4mv</option>. + See below for a detailed description of common encoding options. +</para> + + +<itemizedlist> +<title>Options to adjust:</title> +<listitem><para> + <emphasis role="bold">vmax_b_frames</emphasis>: 1 or 2 is good, depending on + the movie. + Note that if you need to have your encode be decodable by DivX5, you + need to activate closed GOP support, using + <systemitem class="library">libavcodec</systemitem>'s <option>cgop</option> + option, but you need to deactivate scene detection, which + is not a good idea as it will hurt encode efficiency a bit. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vb_strategy=1</emphasis>: helps in high-motion scenes. + Requires vmax_b_frames >= 2. + On some videos, vmax_b_frames may hurt quality, but vmax_b_frames=2 along + with vb_strategy=1 helps. +</para></listitem> + +<listitem><para> + <emphasis role="bold">dia</emphasis>: motion search range. Bigger is better + and slower. + Negative values are a completely different scale. + Good values are -1 for a fast encode, or 2-4 for slower. +</para></listitem> + +<listitem><para> + <emphasis role="bold">predia</emphasis>: motion search pre-pass. + Not as important as dia. Good values are 1 (default) to 4. Requires preme=2 + to really be useful. +</para></listitem> + +<listitem><para> + <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Comparison function for + motion estimation. + Experiment with values of 0 (default), 2 (hadamard), 3 (dct), and 6 (rate + distortion). + 0 is fastest, and sufficient for precmp. + For cmp and subcmp, 2 is good for anime, and 3 is good for live action. + 6 may or may not be slightly better, but is slow. +</para></listitem> + +<listitem><para> + <emphasis role="bold">last_pred</emphasis>: Number of motion predictors to + take from the previous frame. + 1-3 or so help at little speed cost. + Higher values are slow for no extra gain. +</para></listitem> + +<listitem><para> + <emphasis role="bold">cbp, mv0</emphasis>: Controls the selection of macroblocks. + Small speed cost for small quality gain. +</para></listitem> + +<listitem><para> + <emphasis role="bold">qprd</emphasis>: adaptive quantization based on the + macroblock's complexity. + May help or hurt depending on the video and other options. + This can cause artifacts unless you set vqmax to some reasonably small value + (6 is good, maybe as low as 4); vqmin=1 should also help. +</para></listitem> + +<listitem><para> + <emphasis role="bold">qns</emphasis>: very slow, especially when combined + with qprd. + This option will make the encoder minimize noise due to compression + artifacts instead of making the encoded video strictly match the source. + Do not use this unless you have already tweaked everything else as far as it + will go and the results still are not good enough. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vqcomp</emphasis>: Tweak ratecontrol. + What values are good depends on the movie. + You can safely leave this alone if you want. + Reducing vqcomp puts more bits on low-complexity scenes, increasing it puts + them on high-complexity scenes (default: 0.5, range: 0-1. recommended range: + 0.5-0.7). +</para></listitem> + +<listitem><para> + <emphasis role="bold">vlelim, vcelim</emphasis>: Sets the single coefficient + elimination threshold for luminance and chroma planes. + These are encoded separately in all MPEG-like algorithms. + The idea behind these options is to use some good heuristics to determine + when the change in a block is less than the threshold you specify, and in + such a case, to just encode the block as "no change". + This saves bits and perhaps speeds up encoding. vlelim=-4 and vcelim=9 + seem to be good for live movies, but seem not to help with anime; + when encoding animation, you should probably leave them unchanged. +</para></listitem> + +<listitem><para> + <emphasis role="bold">qpel</emphasis>: Quarter pixel motion estimation. + MPEG-4 uses half pixel precision for its motion search by default, + therefore this option comes with an overhead as more information will be + stored in the encoded file. + The compression gain/loss depends on the movie, but it is usually not very + effective on anime. + qpel always incurs a significant cost in CPU decode time (+20% in + practice). +</para></listitem> + +<listitem><para> + <emphasis role="bold">psnr</emphasis>: does not affect the actual encoding, + but writes a log file giving the type/size/quality of each frame, and + prints a summary of PSNR (Peak Signal to Noise Ratio) at the end. +</para></listitem> + +</itemizedlist> + +<itemizedlist> +<title>Options not recommended to play with:</title> +<listitem><para> + <emphasis role="bold">vme</emphasis>: The default is best. +</para></listitem> + +<listitem><para> + <emphasis role="bold">lumi_mask, dark_mask</emphasis>: Psychovisual adaptive + quantization. + You do not want to play with those options if you care about quality. + Reasonable values may be effective in your case, but be warned this is very + subjective. +</para></listitem> + +<listitem><para> + <emphasis role="bold">scplx_mask</emphasis>: Tries to prevent blocky + artifacts, but postprocessing is better. +</para></listitem> +</itemizedlist> +</sect2> + + +<sect2 id="custommatrices"><title>Custom inter/intra matrices</title> + +<para> +With this feature of +<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link> +you are able to set custom inter (I-frames/keyframes) and intra +(P-frames/predicted frames) matrices. It is supported by many of the codecs: +<systemitem>mpeg1video</systemitem> and <systemitem>mpeg2video</systemitem> +are reported as working. +</para> + +<para> +A typical usage of this feature is to set the matrices preferred by the +<ulink url="http://www.kvcd.net/">KVCD</ulink> specifications. +</para> + +<para> +The <emphasis role="bold">KVCD "Notch" Quantization Matrix:</emphasis> +</para> + +<para> +Intra: +<screen> + 8 9 12 22 26 27 29 34 + 9 10 14 26 27 29 34 37 +12 14 18 27 29 34 37 38 +22 26 27 31 36 37 38 40 +26 27 29 36 39 38 40 48 +27 29 34 37 38 40 48 58 +29 34 37 38 40 48 58 69 +34 37 38 40 48 58 69 79 +</screen> + +Inter: +<screen> +16 18 20 22 24 26 28 30 +18 20 22 24 26 28 30 32 +20 22 24 26 28 30 32 34 +22 24 26 30 32 32 34 36 +24 26 28 32 34 34 36 38 +26 28 30 32 34 36 38 40 +28 30 32 34 36 38 42 42 +30 32 34 36 38 40 42 44 +</screen> +</para> + +<para> +Usage: +<screen> +$ mencoder <replaceable>input.avi</replaceable> -o <replaceable>output.avi</replaceable> -oac copy -ovc lavc -lavcopts inter_matrix=...:intra_matrix=... +</screen> +</para> + +<para> +<screen> +$ mencoder <replaceable>input.avi</replaceable> -ovc lavc -lavcopts +vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37, +12,14,18,27,29,34,37,38,22,26,27,31,36,37,38,40,26,27,29,36,39,38,40,48,27, +29,34,37,38,40,48,58,29,34,37,38,40,48,58,69,34,37,38,40,48,58,69,79 +:inter_matrix=16,18,20,22,24,26,28,30,18,20,22,24,26,28,30,32,20,22,24,26, +28,30,32,34,22,24,26,30,32,32,34,36,24,26,28,32,34,34,36,38,26,28,30,32,34, +36,38,40,28,30,32,34,36,38,42,42,30,32,34,36,38,40,42,44 -oac copy -o svcd.mpg +</screen> +</para> +</sect2> + + +<sect2 id="menc-feat-dvd-mpeg4-example"> +<title>Example</title> + +<para> + So, you have just bought your shiny new copy of Harry Potter and the Chamber + of Secrets (widescreen edition, of course), and you want to rip this DVD + so that you can add it to your Home Theatre PC. This is a region 1 DVD, + so it is NTSC. The example below will still apply to PAL, except you will + omit <option>-ofps 24000/1001</option> (because the output framerate is the + same as the input framerate), and of course the crop dimensions will be + different. +</para> + +<para> + After running <option>mplayer dvd://1</option>, we follow the process + detailed in the section <link linkend="menc-feat-telecine">How to deal + with telecine and interlacing in NTSC DVDs</link> and discover that it is + 24000/1001 fps progressive video, which means that we needn't use an inverse + telecine filter, such as <option>pullup</option> or + <option>filmdint</option>. +</para> + +<para> + Next, we want to determine the appropriate crop rectangle, so we use the + cropdetect filter: + + <screen>mplayer dvd://1 -vf cropdetect</screen> + + Make sure you seek to a fully filled frame (such as a bright scene), and + you will see in <application>MPlayer</application>'s console output: + + <screen>crop area: X: 0..719 Y: 57..419 (-vf crop=720:362:0:58)</screen> + + We then play the movie back with this filter to test its correctness: + + <screen>mplayer dvd://1 -vf crop=720:362:0:58</screen> + + And we see that it looks perfectly fine. Next, we ensure the width and + height are a multiple of 16. The width is fine, however the height is + not. Since we did not fail 7th grade math, we know that the nearest + multiple of 16 lower than 362 is 352. +</para> + +<para> + We could just use <option>crop=720:352:0:58</option>, but it would be nice + to take a little off the top and a little off the bottom so that we + retain the center. We have shrunk the height by 10 pixels, but we do not + want to increase the y-offset by 5-pixels since that is an odd number and + will adversely affect quality. Instead, we will increase the y-offset by + 4 pixels: + + <screen>mplayer dvd://1 -vf crop=720:352:0:62</screen> + + Another reason to shave pixels from both the top and the bottom is that we + ensure we have eliminated any half-black pixels if they exist. Note that if + your video is telecined, make sure the <option>pullup</option> filter (or + whichever inverse telecine filter you decide to use) appears in the filter + chain before you crop. If it is interlaced, deinterlace before cropping. + (If you choose to preserve the interlaced video, then make sure your + vertical crop offset is a multiple of 4.) +</para> + +<para> + If you are really concerned about losing those 10 pixels, you might + prefer instead to scale the dimensions down to the nearest multiple of 16. + The filter chain would look like: + + <screen>-vf crop=720:362:0:58,scale=720:352</screen> + + Scaling the video down like this will mean that some small amount of + detail is lost, though it probably will not be perceptible. Scaling up will + result in lower quality (unless you increase the bitrate). Cropping + discards those pixels altogether. It is a tradeoff that you will want to + consider for each circumstance. For example, if the DVD video was made + for television, you might want to avoid vertical scaling, since the line + sampling corresponds to the way the content was originally recorded. +</para> + +<para> + On inspection, we see that our movie has a fair bit of action and high + amounts of detail, so we pick 2400Kbit for our bitrate. +</para> + +<para> + We are now ready to do the two pass encode. Pass one: + + <screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \ +-lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=1 \ +-o Harry_Potter_2.avi</screen> + + And pass two is the same, except that we specify <option>vpass=2</option>: + + <screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \ +-lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=2 \ +-o Harry_Potter_2.avi</screen> +</para> + +<para> + The options <option>v4mv:mbd=2:trell</option> will greatly increase the + quality at the expense of encoding time. There is little reason to leave + these options out when the primary goal is quality. The options + <option>cmp=3:subcmp=3:mbcmp=3</option> select a comparison function that + yields higher quality than the defaults. You might try experimenting with + this parameter (refer to the man page for the possible values) as + different functions can have a large impact on quality depending on the + source material. For example, if you find + <systemitem class="library">libavcodec</systemitem> produces too much + blocky artifacting, you could try selecting the experimental NSSE as + comparison function via <option>*cmp=10</option>. +</para> + +<para> + For this movie, the resulting AVI will be 138 minutes long and nearly + 3GB. And because you said that file size does not matter, this is a + perfectly acceptable size. However, if you had wanted it smaller, you + could try a lower bitrate. Increasing bitrates have diminishing + returns, so while we might clearly see an improvement from 1800Kbit to + 2000Kbit, it might not be so noticeable above 2000Kbit. Feel + free to experiment until you are happy. +</para> + +<para> + Because we passed the source video through a denoise filter, you may want + to add some of it back during playback. This, along with the + <option>spp</option> post-processing filter, drastically improves the + perception of quality and helps eliminate blocky artifacts in the video. + With <application>MPlayer</application>'s <option>autoq</option> option, + you can vary the amount of post-processing done by the spp filter + depending on available CPU. Also, at this point, you may want to apply + gamma and/or color correction to best suit your display. For example: + + <screen>mplayer Harry_Potter_2.avi -vf spp,noise=9ah:5ah,eq2=1.2 -autoq 3</screen> + +</para> +</sect2> +</sect1> + + +<sect1 id="menc-feat-xvid"> +<title>Encoding with the <systemitem class="library">XviD</systemitem> +codec</title> +<para> + <systemitem class="library">XviD</systemitem> is a free library for + encoding MPEG-4 ASP video streams. + Before starting to encode, you need to <link linkend="xvid"> + set up <application>MEncoder</application> to support it</link>. +</para> +<para> + This guide mainly aims at featuring the same kind of information + as x264's encoding guide. + Therefore, please begin by reading + <link linkend="menc-feat-x264-encoding-options-intro">the first part</link> + of that guide. +</para> + + +<sect2 id="menc-feat-xvid-intro"> +<title>What options should I use to get the best results?</title> + +<para> + Please begin by reviewing the + <systemitem class="library">XviD</systemitem> section of + <application>MPlayer</application>'s man page. + This section is intended to be a supplement to the man page. +</para> +<para> + The XviD default settings are already a good tradeoff between + speed and quality, therefore you can safely stick to them if + the following section puzzles you. +</para> +</sect2> + +<sect2 id="menc-feat-xvid-encoding-options"> +<title>Encoding options of <systemitem class="library">XviD</systemitem></title> + +<itemizedlist> +<listitem><para> + <emphasis role="bold">vhq</emphasis> + This setting affects the macroblock decision algorithm, where the + higher the setting, the wiser the decision. + The default setting may be safely used for every encode, while + higher settings always help PSNR but are significantly slower. + Please note that a better PSNR does not necessarily mean + that the picture will look better, but tells you that it is + closer to the original. + Turning it off will noticeably speed up encoding; if speed is + critical for you, the tradeoff may be worth it. +</para></listitem> + +<listitem><para> + <emphasis role="bold">bvhq</emphasis> + This does the same job as vhq, but does it on B-frames. + It has a negligible impact on speed, and slightly improves quality + (around +0.1dB PSNR). +</para></listitem> + +<listitem><para> + <emphasis role="bold">max_bframes</emphasis> + A higher number of consecutive allowed B-frames usually improves + compressibility, although it may also lead to more blocking artifacts. + The default setting is a good tradeoff between compressibility and + quality, but you may increase it up to 3 if you are bitrate-starved. + You may also decrease it to 1 or 0 if you are aiming at perfect + quality, though in that case you should make sure your + target bitrate is high enough to ensure that the encoder does not + have to increase quantizers to reach it. +</para></listitem> + +<listitem><para> + <emphasis role="bold">bf_threshold</emphasis> + This controls the B-frame sensitivity of the encoder, where a higher + value leads to more B-frames being used (and vice versa). + This setting is to be used together with <option>max_bframes</option>; + if you are bitrate-starved, you should increase both + <option>max_bframes</option> and <option>bf_threshold</option>, + while you may increase <option>max_bframes</option> and reduce + <option>bf_threshold</option> so that the encoder may use more + B-frames in places that only <emphasis role="bold">really</emphasis> + need them. + A low number of <option>max_bframes</option> and a high value of + <option>bf_threshold</option> is probably not a wise choice as it + will force the encoder to put B-frames in places that would not + benefit from them, therefore reducing visual quality. + However, if you need to be compatible with standalone players that + only support old DivX profiles (which only supports up to 1 + consecutive B-frame), this would be your only way to + increase compressibility through using B-frames. +</para></listitem> + +<listitem><para> + <emphasis role="bold">trellis</emphasis> + Optimizes the quantization process to get an optimal tradeoff + between PSNR and bitrate, which allows significant bit saving. + These bits will in return be spent elsewhere on the video, + raising overall visual quality. + You should always leave it on as its impact on quality is huge. + Even if you are looking for speed, do not disable it until you + have turned down <option>vhq</option> and all other more + CPU-hungry options to the minimum. +</para></listitem> + +<listitem><para> + <emphasis role="bold">hq_ac</emphasis> + Activates a better coefficient cost estimation method, which slightly + reduces filesize by around 0.15 to 0.19%, while having a negligible + impact on speed. + It is therefore recommended to always leave it on. +</para></listitem> + +<listitem><para> + <emphasis role="bold">cartoon</emphasis> + Designed to better encode cartoon content, and has no impact on + speed as it just tunes the mode decision heuristics for this type + of content. +</para></listitem> + +<listitem><para> + <emphasis role="bold">me_quality</emphasis> + This setting is to control the precision of the motion estimation. + The higher <option>me_quality</option>, the more + precise the estimation of the original motion will be, and the + better the resulting clip will capture the original motion. + </para> + <para> + The default setting is best in all cases; + thus it is not recommended to turn it down unless you are + really looking for speed, as all the bits saved by a good motion + estimation would be spent elsewhere, raising overall quality. + Therefore, do not go any lower than 5, and even that only as a last + resort. +</para></listitem> + +<listitem><para> + <emphasis role="bold">chroma_me</emphasis> + Improves motion estimation by also taking the chroma (color) + information into account, whereas <option>me_quality</option> + alone only uses luma (grayscale). + This slows down encoding by 5-10% but improves visual quality + quite a bit by reducing blocking effects and reduces filesize by + around 1.3%. + If you are looking for speed, you should disable this option before + starting to consider reducing <option>me_quality</option>. +</para></listitem> + +<listitem><para> + <emphasis role="bold">chroma_opt</emphasis> + Is intended to increase chroma image quality around pure + white/black edges, rather than improving compression. + This can help to reduce the "red stairs" effect. +</para></listitem> + +<listitem><para> + <emphasis role="bold">lumi_mask</emphasis> + Tries to give less bitrate to part of the picture that the + human eye cannot see very well, which should allow the encoder + to spend the saved bits on more important parts of the picture. + The quality of the encode yielded by this option highly depends + on personal preferences and on the type and monitor settings + used to watch it (typically, it will not look as good if it is + bright or if it is a TFT monitor). +</para></listitem> + +<listitem><para> + <emphasis role="bold">qpel</emphasis> + Raise the number of candidate motion vectors by increasing + the precision of the motion estimation from halfpel to + quarterpel. + The idea is to find better motion vectors which will in return + reduce bitrate (hence increasing quality). + However, motion vectors with quarterpel precision require a + few extra bits to code, but the candidate vectors do not always + give (much) better results. + Quite often, the codec still spends bits on the extra precision, + but little or no extra quality is gained in return. + Unfortunately, there is no way to foresee the possible gains of + <option>qpel</option>, so you need to actually encode with and + without it to know for sure. + </para><para> + <option>qpel</option> can be almost double encoding time, and + requires as much as 25% more processing power to decode. + It is not supported by all standalone players. +</para></listitem> + +<listitem><para> + <emphasis role="bold">gmc</emphasis> + Tries to save bits on panning scenes by using a single motion + vector for the whole frame. + This almost always raises PSNR, but significantly slows down + encoding (as well as decoding). + Therefore, you should only use it when you have turned + <option>vhq</option> to the maximum. + <systemitem class="library">XviD</systemitem>'s GMC is more + sophisticated than DivX's, but is only supported by few + standalone players. +</para></listitem> + +</itemizedlist> +</sect2> +</sect1> + +<sect1 id="menc-feat-x264"> +<title>Encoding with the <systemitem class="library">x264</systemitem> codec</title> +<para> + <systemitem class="library">x264</systemitem> is a free library for + encoding H.264/AVC video streams. + Before starting to encode, you need to <link linkend="codec-x264-encode"> + set up <application>MEncoder</application> to support it</link>. +</para> + +<sect2 id="menc-feat-x264-encoding-options"> +<title>Encoding options of x264</title> + +<para> + Please begin by reviewing the + <systemitem class="library">x264</systemitem> section of + <application>MPlayer</application>'s man page. + This section is intended to be a supplement to the man page. + Here you will find quick hints about which options are most + likely to interest most people. The man page is more terse, + but also more exhaustive, and it sometimes offers much better + technical detail. +</para> + +<sect3 id="menc-feat-x264-encoding-options-intro"> +<title>Introduction</title> +<para>This guide considers two major categories of encoding options:</para> + +<orderedlist> + <listitem><para>Options which mainly trade off encoding time vs. quality + </para></listitem> + <listitem><para>Options which may be useful for fulfilling various personal + preferences and special requirements</para></listitem> +</orderedlist> + +<para> + Ultimately, only you can decide which options are best for your + purposes. The decision for the first class of options is the simplest: + you only have to decide whether you think the quality differences + justify the speed differences. For the second class of options, + preferences may be far more subjective, and more factors may be + involved. Note that some of the "personal preferences and special + requirements" options can still have large impacts on speed or quality, + but that is not what they are primarily useful for. A couple of the + "personal preference" options may even cause changes that look better + to some people, but look worse to others. +</para> + +<para> + Before continuing, you need to understand that this guide uses only one + quality metric: global PSNR. + For a brief explanation of what PSNR is, see + <ulink url="http://en.wikipedia.org/wiki/PSNR">the Wikipedia article on PSNR</ulink>. + Global PSNR is the last PSNR number reported when you include + the <option>psnr</option> option in <option>x264encopts</option>. + Any time you read a claim about PSNR, one of the assumptions + behind the claim is that equal bitrates are used. +</para> + +<para> + Nearly all of this guide's comments assume you are using + two pass. + When comparing options, there are two major reasons for using + two pass encoding. + First, using two pass often gains around 1dB PSNR, which is a + very big difference. + Secondly, testing options by doing direct quality comparisons + with one pass encodes introduces a major confounding + factor: bitrate often varies significantly with each encode. + It is not always easy to tell whether quality changes are due + mainly to changed options, or if they mostly reflect essentially + random differences in the achieved bitrate. +</para> + +</sect3> + +<sect3 id="menc-feat-x264-encoding-options-speedvquality"> +<title>Options which primarily affect speed and quality</title> + +<itemizedlist> +<listitem><para> + <emphasis role="bold">subq</emphasis>: + Of the options which allow you to trade off speed for quality, + <option>subq</option> and <option>frameref</option> (see below) are usually + by far the most important. + If you are interested in tweaking either speed or quality, these + are the first options you should consider. + On the speed dimension, the <option>frameref</option> and + <option>subq</option> options interact with each other fairly + strongly. + Experience shows that, with one reference frame, + <option>subq=5</option> (the default setting) takes about 35% more time than + <option>subq=1</option>. + With 6 reference frames, the penalty grows to over 60%. + <option>subq</option>'s effect on PSNR seems fairly constant + regardless of the number of reference frames. + Typically, <option>subq=5</option> achieves 0.2-0.5 dB higher global + PSNR in comparison <option>subq=1</option>. + This is usually enough to be visible. +</para> +<para> + <option>subq=6</option> is the slowest, highest quality mode. + In comparison to <option>subq=5</option>, it usually gains 0.1-0.4 dB + global PSNR with speed costs varying from 25%-100%. + Unlike other levels of <option>subq</option>, the behavior of + <option>subq=6</option> does not depend much on <option>frameref</option> + and <option>me</option>. Instead, the effectiveness of <option>subq=6 + </option> depends mostly upon the number of B-frames used. In normal + usage, this means <option>subq=6</option> has a large impact on both speed + and quality in complex, high motion scenes, but it may not have much effect + in low-motion scenes. Note that it is still recommended to always set + <option>bframes</option> to something other than zero (see below). +</para></listitem> +<listitem><para> + <emphasis role="bold">frameref</emphasis>: + <option>frameref</option> is set to 1 by default, but this + should not be taken to imply that it is reasonable to set it + to 1. + Merely raising <option>frameref</option> to 2 gains around + 0.15dB PSNR with a 5-10% speed penalty; this seems like a + good tradeoff. + <option>frameref=3</option> gains around 0.25dB PSNR over + <option>frameref=1</option>, which should be a visible + difference. + <option>frameref=3</option> is around 15% slower than + <option>frameref=1</option>. + Unfortunately, diminishing returns set in rapidly. + <option>frameref=6</option> can be expected to gain only + 0.05-0.1 dB over <option>frameref=3</option> at an additional + 15% speed penalty. + Above <option>frameref=6</option>, the quality gains are + usually very small (although you should keep in mind throughout + this whole discussion that it can vary quite a lot depending on + your source). + In a fairly typical case, <option>frameref=12</option> + will improve global PSNR by a tiny 0.02dB over + <option>frameref=6</option>, at a speed cost of 15%-20%. + At such high <option>frameref</option> values, the only really + good thing that can be said is that increasing it even further will + almost certainly never <emphasis role="bold">harm</emphasis> + PSNR, but the additional quality benefits are barely even + measurable, let alone perceptible. +</para> +<note><title>Note:</title> +<para> + Raising <option>frameref</option> to unnecessarily high values + <emphasis role="bold">can</emphasis> and + <emphasis role="bold">usually does</emphasis> + hurt coding efficiency if you turn CABAC off. + With CABAC on (the default behavior), the possibility of setting + <option>frameref</option> "too high" currently seems too remote + to even worry about, and in the future, optimizations may remove + the possibility altogether. +</para> +</note> +<para> + If you care about speed, a reasonable compromise is to use low + <option>subq</option> and <option>frameref</option> values on + the first pass, and then raise them on the second pass. + Typically, this has a negligible negative effect on the final + quality: You will probably lose well under 0.1dB PSNR, which + should be much too small of a difference to see. + However, different values of <option>frameref</option> can + occasionally affect frametype decision. + Most likely, these are rare outlying cases, but if you want to + be pretty sure, consider whether your video has either + fullscreen repetitive flashing patterns or very large temporary + occlusions which might force an I-frame. + Adjust the first-pass <option>frameref</option> so it is large + enough to contain the duration of the flashing cycle (or occlusion). + For example, if the scene flashes back and forth between two images + over a duration of three frames, set the first pass + <option>frameref</option> to 3 or higher. + This issue is probably extremely rare in live action video material, + but it does sometimes come up in video game captures. +</para></listitem> + +<listitem><para> + <emphasis role="bold">me</emphasis>: + This option is for choosing the motion estimation search method. + Altering this option provides a straightforward quality-vs-speed + tradeoff. <option>me=1</option> is only a few percent faster than + the default search, at a cost of under 0.1dB global PSNR. The + default setting (<option>me=2</option>) is a reasonable tradeoff + between speed and quality. <option>me=3</option> gains a little under + 0.1dB global PSNR, with a speed penalty that varies depending on + <option>frameref</option>. At high values of + <option>frameref</option> (e.g. 12 or so), <option>me=3</option> + is about 40% slower than the default <option> me=2</option>. With + <option>frameref=3</option>, the speed penalty incurred drops to + 25%-30%. +</para> +<para> + <option>me=4</option> uses an exhaustive search that is too slow for + practical use. +</para> +</listitem> + +<listitem><para> + <emphasis role="bold">4x4mv</emphasis>: + This option enables the use of 8x4, 4x8 and 4x4 subpartitions in + predicted macroblocks. Enabling it results in a fairly consistent + 10%-15% loss of speed. This option is rather useless in source + containing only low motion, however in some high-motion source, + particularly source with lots of small moving objects, gains of + about 0.1dB can be expected. +</para> +</listitem> + +<listitem><para> + <emphasis role="bold">bframes</emphasis>: + If you are used to encoding with other codecs, you may have found + that B-frames are not always useful. + In H.264, this has changed: there are new techniques and block + types that are possible in B-frames. + Usually, even a naive B-frame choice algorithm can have a + significant PSNR benefit. + It is interesting to note that using B-frames usually speeds up + the second pass somewhat, and may also speed up a single + pass encode if adaptive B-frame decision is turned off. +</para> +<para> + With adaptive B-frame decision turned off + (<option>x264encopts</option>'s <option>nob_adapt</option>), + the optimal value for this setting is usually no more than + <option>bframes=1</option>, or else high-motion scenes can suffer. + With adaptive B-frame decision on (the default behavior), it is + safe to use higher values; the encoder will reduce the use of + B-frames in scenes where they would hurt compression. + The encoder rarely chooses to use more than 3 or 4 B-frames; + setting this option any higher will have little effect. +</para></listitem> + +<listitem><para> + <emphasis role="bold">b_adapt</emphasis>: + Note: This is on by default. +</para> +<para> + With this option enabled, the encoder will use a reasonably fast + decision process to reduce the number of B-frames used in scenes that + might not benefit from them as much. + You can use <option>b_bias</option> to tweak how B-frame-happy + the encoder is. + The speed penalty of adaptive B-frames is currently rather modest, + but so is the potential quality gain. + It usually does not hurt, however. + Note that this only affects speed and frametype decision on the + first pass. + <option>b_adapt</option> and <option>b_bias</option> have no + effect on subsequent passes. +</para></listitem> + +<listitem><para> + <emphasis role="bold">b_pyramid</emphasis>: + You might as well enable this option if you are using >=2 B-frames; + as the man page says, you get a little quality improvement at no + speed cost. + Note that these videos cannot be read by libavcodec-based decoders + older than about March 5, 2005. +</para></listitem> + +<listitem><para> + <emphasis role="bold">weight_b</emphasis>: + In typical cases, there is not much gain with this option. + However, in crossfades or fade-to-black scenes, weighted + prediction gives rather large bitrate savings. + In MPEG-4 ASP, a fade-to-black is usually best coded as a series + of expensive I-frames; using weighted prediction in B-frames + makes it possible to turn at least some of these into much smaller + B-frames. + Encoding time cost is minimal, as no extra decisions need to be made. + Also, contrary to what some people seem to guess, the decoder + CPU requirements are not much affected by weighted prediction, + all else being equal. +</para> +<para> + Unfortunately, the current adaptive B-frame decision algorithm + has a strong tendency to avoid B-frames during fades. + Until this changes, it may be a good idea to add + <option>nob_adapt</option> to your x264encopts, if you expect + fades to have a large effect in your particular video + clip. +</para></listitem> +</itemizedlist> +</sect3> + +<sect3 id="menc-feat-x264-encoding-options-misc-preferences"> +<title>Options pertaining to miscellaneous preferences</title> +<itemizedlist> +<listitem><para> + <emphasis role="bold">Two pass encoding</emphasis>: + Above, it was suggested to always use two pass encoding, but there + are still reasons for not using it. For instance, if you are capturing + live TV and encoding in realtime, you are forced to use single-pass. + Also, one pass is obviously faster than two passes; if you use the + exact same set of options on both passes, two pass encoding is almost + twice as slow. +</para> +<para> + Still, there are very good reasons for using two pass encoding. For + one thing, single pass ratecontrol isn't psychic, and it often makes + unreasonable choices because it can't see the big picture. For example, + suppose you have a two minute long video consisting of two distinct + halves. The first half is a very high-motion scene lasting 60 seconds + which, in isolation, requires about 2500kbps in order to look decent. + Immediately following it is a much less demanding 60-second scene + that looks good at 300kbps. Suppose you ask for 1400kbps on the theory + that this is enough to accomodate both scenes. Single pass ratecontrol + will make a couple of "mistakes" in such a case. First of all, it + will target 1400kbps in both segments. The first segment may end up + heavily overquantized, causing it to look unacceptably and unreasonably + blocky. The second segment will be heavily underquantized; it may look + perfect, but the bitrate cost of that perfection will be completely + unreasonable. What's even harder to avoid is the problem at the + transition between the two scenes. The first seconds of the low motion + half will be hugely over-quantized, because the ratecontrol is still + expecting the kind of bitrate requirements it met in the first half + of the video. This "error period" of heavily over-quantized low motion + will look jarringly bad, and will actually use less than the 300kbps + it would have taken to make it look decent. There are ways to + mitigate the pitfalls of single-pass encoding, but they may tend to + increase bitrate misprediction. +</para> +<para> + Multipass ratecontrol can offer huge advantages over a single pass. + Using the statistics gathered from the first pass encode, the encoder + can estimate, with reasonable accuracy, the "cost" (in bits) of + encoding any given frame, at any given quantizer. This allows for + a much more rational, better planned allocation of bits between the + expensive (high-motion) and cheap (low-motion) scenes. See + <option>qcomp</option> below for some ideas on how to tweak this + allocation to your liking. +</para> +<para> + Moreover, two passes need not take twice as long as one pass. You can + tweak the options in the first pass for higher speed and lower quality. + If you choose your options well, you can get a very fast first pass. + The resulting quality in the second pass will be slightly lower because size + prediction is less accurate, but the quality difference is normally much + too small to be visible. Try, for example, adding + <option>subq=1:frameref=1</option> to the first pass + <option>x264encopts</option>. Then, on the second pass, use slower, + higher-quality options: + <option>subq=6:frameref=15:4x4mv:me=3</option> +</para></listitem> +<listitem><para> + <emphasis role="bold">Three pass encoding</emphasis>? + + x264 offers the ability to make an arbitrary number of consecutive + passes. If you specify <option>pass=1</option> on the first pass, + then use <option>pass=3</option> on a subsequent pass, the subsequent + pass will both read the statistics from the previous pass, and write + its own statistics. An additional pass following this one will have + a very good base from which to make highly accurate predictions of + framesizes at a chosen quantizer. In practice, the overall quality + gain from this is usually close to zero, and quite possibly a third + pass will result in slightly worse global PSNR than the pass before + it. In typical usage, three passes help if you get either bad bitrate + prediction or bad looking scene transitions when using only two passes. + This is somewhat likely to happen on extremely short clips. There are + also a few special cases in which three (or more) passes are handy + for advanced users, but for brevity, this guide omits discussing those + special cases. + +</para></listitem> +<listitem><para> + <emphasis role="bold">qcomp</emphasis>: + <option>qcomp</option> trades off the number of bits allocated + to "expensive" high-motion versus "cheap" low-motion frames. At + one extreme, <option>qcomp=0</option> aims for true constant + bitrate. Typically this would make high-motion scenes look completely + awful, while low-motion scenes would probably look absolutely + perfect, but would also use many times more bitrate than they + would need in order to look merely excellent. At the other extreme, + <option>qcomp=1</option> achieves nearly constant quantization parameter + (QP). Constant QP doesn't look bad, but most people think it's more + reasonable to shave some bitrate off of the extremely expensive scenes + (where the loss of quality isn't as noticeable) and reallocate it to + the scenes that are easier to encode at excellent quality. + <option>qcomp</option> is set to 0.6 by default, which may be slightly + low for many peoples' taste (0.7-0.8 are also commonly used). +</para></listitem> +<listitem><para> + <emphasis role="bold">keyint</emphasis>: + <option>keyint</option> is solely for trading off file seekability against + coding efficiency. By default, <option>keyint</option> is set to 250. In + 25fps material, this guarantees the ability to seek to within 10 seconds + precision. If you think it would be important and useful to be able to + seek within 5 seconds of precision, set <option>keyint=125</option>; + this will hurt quality/bitrate slightly. If you care only about quality + and not about seekability, you can set it to much higher values + (understanding that there are diminishing returns which may become + vanishingly low, or even zero). The video stream will still have seekable + points as long as there are some scene changes. +</para></listitem> +<listitem><para> + <emphasis role="bold">deblockalpha, deblockbeta</emphasis>: + This topic is going to be a bit controversial. +</para> +<para> + H.264 defines a simple deblocking procedure on I-blocks that uses + pre-set strengths and thresholds depending on the QP of the block + in question. + By default, high QP blocks are filtered heavily, and low QP blocks + are not deblocked at all. + The pre-set strengths defined by the standard are well-chosen and + the odds are very good that they are PSNR-optimal for whatever + video you are trying to encode. + The <option>deblockalpha</option> and <option>deblockbeta</option> + parameters allow you to specify offsets to the preset deblocking + thresholds. +</para> +<para> + Many people seem to think it is a good idea to lower the deblocking + filter strength by large amounts (say, -3). + This is however almost never a good idea, and in most cases, + people who are doing this do not understand very well how + deblocking works by default. +</para> +<para> + The first and most important thing to know about the in-loop + deblocking filter is that the default thresholds are almost always + PSNR-optimal. + In the rare cases that they are not optimal, the ideal offset is + plus or minus 1. + Adjusting deblocking parameters by a larger amount is almost + guaranteed to hurt PSNR. + Strengthening the filter will smear more details; weakening the + filter will increase the appearance of blockiness. +</para> +<para> + It is definitely a bad idea to lower the deblocking thresholds if + your source is mainly low in spacial complexity (i.e., not a lot + of detail or noise). + The in-loop filter does a rather excellent job of concealing + the artifacts that occur. + If the source is high in spacial complexity, however, artifacts + are less noticeable. + This is because the ringing tends to look like detail or noise. + Human visual perception easily notices when detail is removed, + but it does not so easily notice when the noise is wrongly + represented. + When it comes to subjective quality, noise and detail are somewhat + interchangeable. + By lowering the deblocking filter strength, you are most likely + increasing error by adding ringing artifacts, but the eye does + not notice because it confuses the artifacts with detail. +</para> + +<para> + This <emphasis role="bold">still</emphasis> does not justify + lowering the deblocking filter strength, however. + You can generally get better quality noise from postprocessing. + If your H.264 encodes look too blurry or smeared, try playing with + <option>-vf noise</option> when you play your encoded movie. + <option>-vf noise=8a:4a</option> should conceal most mild + artifacting. + It will almost certainly look better than the results you + would have gotten just by fiddling with the deblocking filter. +</para></listitem> +</itemizedlist> +</sect3> +</sect2> +</sect1> + +<sect1 id="menc-feat-vcd-dvd"> +<title>Using MEncoder to create VCD/SVCD/DVD-compliant files.</title> + +<sect2 id="menc-feat-vcd-dvd-constraints"> +<title>Format Constraints</title> +<para> + <application>MEncoder</application> is capable of creating VCD, SCVD + and DVD format MPEG files using the + <systemitem class="library">libavcodec</systemitem> library. + These files can then be used in conjunction with + <ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink> + or + <ulink url="http://dvdauthor.sourceforge.net/">dvdauthor</ulink> + to create discs that will play on a standard set-top player. +</para> + +<para> + The DVD, SVCD, and VCD formats are subject to heavy constraints. + Only a small selection of encoded picture sizes and aspect ratios are + available. + If your movie does not already meet these requirements, you may have + to scale,crop or add black borders to the picture to make it + compliant. +</para> + +<sect3 id="menc-feat-vcd-dvd-constraints-resolution"> +<title>Format Constraints</title> + +<informaltable frame="all"> +<tgroup cols="9"> +<thead> + <row> + <entry>Format</entry> + <entry>Resolution</entry> + <entry>V. Codec</entry> + <entry>V. Bitrate</entry> + <entry>Sample Rate</entry> + <entry>A. Codec</entry> + <entry>A. Bitrate</entry> + <entry>FPS</entry> + <entry>Aspect</entry> + </row> +</thead> +<tbody> + <row> + <entry>NTSC DVD</entry> + <entry>720x480, 704x480, 352x480, 352x240</entry> + <entry>MPEG-2</entry> + <entry>9800 kbps</entry> + <entry>48000 Hz</entry> + <entry>AC3,PCM</entry> + <entry>1536 kbps</entry> + <entry>23.976, 29.97</entry> + <entry>4:3, 16:9 (only for 720x480)</entry> + </row> + <row> + <entry>NTSC DVD</entry> + <entry>352x240<footnote id='fn-rare-resolutions'><para> + These resolutions are rarely used for DVDs because + they are fairly low quality.</para></footnote></entry> + <entry>MPEG-1</entry> + <entry>1856 kbps</entry> + <entry>48000 Hz</entry> + <entry>AC3,PCM</entry> + <entry>1536 kbps</entry> + <entry>23.976, 29.97</entry> + <entry>4:3, 16:9</entry> + </row> + <row> + <entry>NTSC SVCD</entry> + <entry>480x480</entry> + <entry>MPEG-2</entry> + <entry>2600 kbps</entry> + <entry>44100 Hz</entry> + <entry>MP2</entry> + <entry>384 kbps</entry> + <entry>29.97</entry> + <entry>4:3</entry> + </row> + <row> + <entry>NTSC VCD</entry> + <entry>352x240</entry> + <entry>MPEG-1</entry> + <entry>1150 kbps</entry> + <entry>44100 Hz</entry> + <entry>MP2</entry> + <entry>224 kbps</entry> + <entry>23.976, 29.97</entry> + <entry>4:3</entry> + </row> + <row> + <entry>PAL DVD</entry> + <entry>720x576, 704x576, 352x576, 352x288</entry> + <entry>MPEG-2</entry> + <entry>9800 kbps</entry> + <entry>48000 Hz</entry> + <entry>MP2,AC3,PCM</entry> + <entry>1536 kbps</entry> + <entry>25</entry> + <entry>4:3, 16:9 (only for 720x576)</entry> + </row> + <row> + <entry>PAL DVD</entry> + <entry>352x288<footnoteref linkend='fn-rare-resolutions'/></entry> + <entry>MPEG-1</entry> + <entry>1856 kbps</entry> + <entry>48000 Hz</entry> + <entry>MP2,AC3,PCM</entry> + <entry>1536 kbps</entry> + <entry>25</entry> + <entry>4:3, 16:9</entry> + </row> + <row> + <entry>PAL SVCD</entry> + <entry>480x576</entry> + <entry>MPEG-2</entry> + <entry>2600 kbps</entry> + <entry>44100 Hz</entry> + <entry>MP2</entry> + <entry>384 kbps</entry> + <entry>25</entry> + <entry>4:3</entry> + </row> + <row> + <entry>PAL VCD</entry> + <entry>352x288</entry> + <entry>MPEG-1</entry> + <entry>1150 kbps</entry> + <entry>44100 Hz</entry> + <entry>MP2</entry> + <entry>224 kbps</entry> + <entry>25</entry> + <entry>4:3</entry> + </row> +</tbody> +</tgroup> +</informaltable> + +<para> + If your movie has 2.35:1 aspect (most recent action movies), you will + have to add black borders or crop the movie down to 16:9 to make a DVD + or VCD. + If you add black borders, try to align them at 16-pixel boundaries in + order to minimize the impact on encoding performance. + Thankfully DVD has sufficiently excessive bitrate that you do not have + to worry too much about encoding efficiency, but SVCD and VCD are + highly bitrate-starved and require effort to obtain acceptable quality. +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-constraints-gop"> +<title>GOP Size Constraints</title> +<para> + DVD, VCD, and SVCD also constrain you to relatively low + GOP (Group of Pictures) sizes. + For 30 fps material the largest allowed GOP size is 18. + For 25 or 24 fps, the maximum is 15. + The GOP size is set using the <option>keyint</option> option. +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-constraints-bitrate"> +<title>Bitrate Constraints</title> +<para> + VCD video is required to be CBR at 1152 kbps. + This highly limiting constraint also comes along with an extremly low vbv + buffer size of 327 kilobits. + SVCD allows varying video bitrates up to 2500 kbps, and a somewhat less + restrictive vbv buffer size of 917 kilobits is allowed. + DVD video bitrates may range anywhere up to 9800 kbps (though typical + bitrates are about half that), and the vbv buffer size is 1835 kilobits. +</para> +</sect3> +</sect2> + +<sect2 id="menc-feat-vcd-dvd-output"> +<title>Output Options</title> +<para> + <application>MEncoder</application> has options to control the output + format. + Using these options we can instruct it to create the correct type of + file. +</para> + +<para> + The options for VCD and SVCD are called xvcd and xsvcd, because they + are extended formats. + They are not strictly compliant, mainly because the output does not + contain scan offsets. + If you need to generate an SVCD image, you should pass the output file + to + <ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink>. +</para> + +<para> + VCD: + <screen> + -of mpeg -mpegopts format=xvcd + </screen> +</para> + +<para> + SVCD: + <screen> + -of mpeg -mpegopts format=xsvcd + </screen> +</para> + +<para> + DVD: + <screen> + -of mpeg -mpegopts format=dvd + </screen> +</para> + +<sect3 id="menc-feat-vcd-dvd-output-aspect"> +<title>Aspect Ratio</title> +<para> + The aspect argument of <option>-lavcopts</option> is used to encode + the aspect ratio of the file. + During playback the aspect ratio is used to restore the video to the + correct size. +</para> + +<para> + 16:9 or "Widescreen" + <screen> + -lavcopts aspect=16/9 + </screen> +</para> + +<para> + 4:3 or "Fullscreen" + <screen> + -lavcopts aspect=4/3 + </screen> +</para> + +<para> + 2.35:1 or "Cinemascope" NTSC + <screen> + -vf scale=720:368,expand=720:480 -lavcopts aspect=16/9 + </screen> + To calculate the correct scaling size, use the expanded NTSC width of + 854/2.35 = 368 +</para> + +<para> + 2.35:1 or "Cinemascope" PAL + <screen> + -vf scale="720:432,expand=720:576 -lavcopts aspect=16/9 + </screen> + To calculate the correct scaling size, use the expanded PAL width of + 1024/2.35 = 432 +</para> + +</sect3> + +<sect3 id="menc-feat-vcd-dvd-output-srate"> +<title>Sample Rate Conversion</title> +<para> + If the audio sample rate in the original file is not the same as + required by the target format, sample rate conversion is required. + This is achieved using the <option>-srate</option> option and + the <option>-af lavcresample</option> audio filter together. + </para> + <para> + DVD: + <screen> + -srate 48000 -af lavcresample=48000 + </screen> +</para> +<para> + VCD and SVCD: + <screen> + -srate 44100 -af lavcresample=44100 + </screen> + </para> +</sect3> +</sect2> + +<sect2 id="menc-feat-vcd-dvd-lavc"> +<title>Using libavcodec for VCD/SVCD/DVD Encoding</title> + +<sect3 id="menc-feat-vcd-dvd-lavc-intro"> +<title>Introduction</title> +<para> + <systemitem class="library">libavcodec</systemitem> can be used to + create VCD/SVCD/DVD compliant video by using the appropriate options. +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-lavc-options"> +<title>lavcopts</title> +<para> + This is a list of fields in <option>-lavcopts</option> that you may + be required to change in order to make a complaint movie for VCD, SVCD, + or DVD: +</para> + +<itemizedlist> +<listitem><para> + <emphasis role="bold">acodec</emphasis>: + <option>mp2</option> for VCD, SVCD, or PAL DVD; + <option>ac3</option> is most commonly used for DVD. + PCM audio may also be used for DVD, but this is mostly a big waste of + space. + Note that MP3 audio is not compliant for any of these formats, but + players often have no problem playing it anyway. +</para></listitem> + +<listitem><para> + <emphasis role="bold">abitrate</emphasis>: + 224 for VCD; up to 384 for SVCD; up to 1536 for DVD, but commonly + used values range from 192 kbps for stereo to 384 kbps for 5.1 channel + sound. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vcodec</emphasis>: + <option>mpeg1video</option> for VCD; + <option>mpeg2video</option> for SVCD; + <option>mpeg2video</option> is usually used for DVD but you may also use + <option>mpeg1video</option> for CIF resolutions. +</para></listitem> + +<listitem><para> + <emphasis role="bold">keyint</emphasis>: + Used to set the GOP size. + 18 for 30fps material, or 15 for 25/24 fps material. + Commercial producers seem to prefer keyframe intervals of 12. + It is possible to make this much larger and still retain compatibility + with most players. + A <option>keyint</option> of 25 should never cause any problems. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vrc_buf_size</emphasis>: + 327 for VCD, 917 for SVCD, and 1835 for DVD. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vrc_minrate</emphasis>: + 1152, for VCD. May be left alone for SVCD and DVD. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vrc_maxrate</emphasis>: + 1152 for VCD; 2500 for SVCD; 9800 for DVD. + For SVCD and DVD, you might wish to use lower values depending on your + own personal preferences and requirements. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vbitrate</emphasis>: + 1152 for VCD; + up to 2500 for SVCD; + up to 9800 for DVD. + For the latter two formats, vbitrate should be set based on personal + preference. + For instance, if you insist on fitting 20 or so hours on a DVD, you + could use vbitrate=400. + The resulting video quality would probably be quite bad. + If you are trying to squeeze out the maximum possible quality on a DVD, + use vbitrate=9800, but be warned that this could constrain you to less + than an hour of video on a single-layer DVD. +</para></listitem> +</itemizedlist> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-lavc-examples"> +<title>Examples</title> +<para> + This is a typical minimum set of <option>-lavcopts</option> for + encoding video: +</para> +<para> + VCD: + <screen> + -lavcopts vcodec=mpeg1video:vrc_buf_size=327:vrc_minrate=1152:\ + vrc_maxrate=1152:vbitrate=1152:keyint=15:acodec=mp2 + </screen> +</para> + +<para> + SVCD: + <screen> + -lavcopts vcodec=mpeg2video:vrc_buf_size=917:vrc_maxrate=2500:vbitrate=1800:\ + keyint=15:acodec=mp2 + </screen> +</para> + +<para> + DVD: + <screen> + -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\ + keyint=15:acodec=ac3 + </screen> +</para> + +</sect3> + +<sect3 id="menc-feat-vcd-dvd-lavc-advanced"> +<title>Advanced Options</title> +<para> + For higher quality encoding, you may also wish to add quality-enhancing + options to lavcopts, such as <option>trell</option>, + <option>mbd=2</option>, and others. + Note that <option>qpel</option> and <option>v4mv</option>, while often + useful with MPEG-4, are not usable with MPEG-1 or MPEG-2. + Also, if you are trying to make a very high quality DVD encode, it may + be useful to add <option>dc=10</option> to lavcopts. + Doing so may help reduce the appearance of blocks in flat-colored areas. + Putting it all together, this is an example of a set of lavcopts for a + higher quality DVD: +</para> + +<para> + <screen> + -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=8000:\ + keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:\ + vqmin=1:lmin=1:dc=10 + </screen> +</para> + +</sect3> +</sect2> + +<sect2 id="menc-feat-vcd-dvd-audio"> +<title>Encoding Audio</title> +<para> + VCD and SVCD support MPEG-1 layer II audio, using one of + <systemitem class="library">toolame</systemitem>, + <systemitem class="library">twolame</systemitem>, + or <systemitem class="library">libavcodec</systemitem>'s MP2 encoder. + The libavcodec MP2 is far from being as good as the other two libraries, + however it should always be available to use. + VCD only supports constant bitrate audio (CBR) whereas SVCD supports + variable bitrate (VBR), too. + Be careful when using VBR because some bad standalone players might not + support it too well. +</para> + +<para> + For DVD audio, <systemitem class="library">libavcodec</systemitem>'s + AC3 codec is used. +</para> + +<sect3 id="menc-feat-vcd-dvd-audio-toolame"> +<title>toolame</title> +<para> + For VCD and SVCD: + <screen> + -oac toolame -toolameopts br=224 + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-audio-twolame"> +<title>twolame</title> +<para> + For VCD and SVCD: + <screen> + -oac twolame -twolameopts br=224 + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-audio-lavc"> +<title>libavcodec</title> +<para> + For DVD with 2 channel sound: + <screen> + -oac lavc -lavcopts acodec=ac3:abitrate=192 + </screen> +</para> +<para> + For DVD with 5.1 channel sound: + <screen> + -channels 6 -oac lavc -lavcopts acodec=ac3:abitrate=384 + </screen> +</para> +<para> + For VCD and SVCD: + <screen> + -oac lavc -lavcopts acodec=mp2:abitrate=224 + </screen> +</para> +</sect3> + +</sect2> + +<sect2 id="menc-feat-vcd-dvd-all"> +<title>Putting it all Together</title> +<para> + This section shows some complete commands for creating VCD/SVCD/DVD + compliant videos. +</para> + +<sect3 id="menc-feat-vcd-dvd-all-pal-dvd"> +<title>PAL DVD</title> +<para> + <screen> + mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\ + harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\ + vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:\ + abitrate=192:aspect=16/9 -ofps 25 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-all-ntsc-dvd"> +<title>NTSC DVD</title> +<para> + <screen> + mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,\ + harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\ + vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:\ + abitrate=192:aspect=16/9 -ofps 30000/1001 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-all-pal-ac3-copy"> +<title>PAL AVI Containing AC3 Audio to DVD</title> +<para> + If the source already has AC3 audio, use -oac copy instead of re-encoding it. + <screen> + mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\ + harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:\ + vbitrate=5000:keyint=15:aspect=16/9 -ofps 25 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-all-ntsc-ac3-copy"> +<title>NTSC AVI Containing AC3 Audio to DVD</title> +<para> + If the source already has AC3 audio, and is NTSC @ 23.976 fps: + <screen> + mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,\ + harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:\ + vbitrate=5000:keyint=15:aspect=16/9 -ofps 24000/1001 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-all-pal-svcd"> +<title>PAL SVCD</title> +<para> + <screen> + mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \ + scale=480:576,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ + vcodec=mpeg2video:mbd=2:keyint=15:vrc_buf_size=917:vrc_minrate=600:\ + vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 -ofps 25 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-all-ntsc-svcd"> +<title>NTSC SVCD</title> +<para> + <screen> + mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \ + scale=480:480,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ + vcodec=mpeg2video:mbd=2:keyint=18:vrc_buf_size=917:vrc_minrate=600:\ + vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 -ofps 30000/1001 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-all-pal-vcd"> +<title>PAL VCD</title> +<para> + <screen> + mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \ + scale=352:288,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ + vcodec=mpeg1video:keyint=15:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:\ + vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 25 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +<sect3 id="menc-feat-vcd-dvd-all-ntsc-vcd"> +<title>NTSC VCD</title> +<para> + <screen> + mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \ + scale=352:240,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ + vcodec=mpeg1video:keyint=18:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:\ + vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 30000/1001 \ + -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> + </screen> +</para> +</sect3> + +</sect2> + +</sect1> + +</chapter>
--- a/DOCS/xml/en/mencoder.xml Sun Jul 24 12:56:07 2005 +0000 +++ b/DOCS/xml/en/mencoder.xml Sun Jul 24 14:22:14 2005 +0000 @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="iso-8859-1"?> <!-- $Revision$ --> <chapter id="mencoder"> -<title>Encoding with <application>MEncoder</application></title> +<title>Basic usage of <application>MEncoder</application></title> <para> For the complete list of available <application>MEncoder</application> options @@ -83,7 +83,6 @@ </para> </sect1> - <sect1 id="menc-feat-rescale"> <title>Rescaling movies</title> @@ -140,86 +139,6 @@ </sect1> -<sect1 id="menc-feat-enc-libavcodec"> -<title>Encoding with the <systemitem class="library">libavcodec</systemitem> - codec family</title> - -<para> -<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link> -provides simple encoding to a lot of interesting video and audio formats. -You can encode to the following codecs (more or less up to date): - -<informaltable frame="all"> -<tgroup cols="2"> -<thead> -<row><entry>Codec name</entry><entry>Description</entry></row> -</thead> -<tbody> -<row><entry>mjpeg</entry><entry> - Motion JPEG - </entry></row> -<row><entry>ljpeg</entry><entry> - Lossless JPEG - </entry></row> -<row><entry>h263</entry><entry> - H.263 - </entry></row> -<row><entry>h263p</entry><entry> - H.263+ - </entry></row> -<row><entry>mpeg4</entry><entry> - ISO standard MPEG-4 (DivX 5, XVID compatible) - </entry></row> -<row><entry>msmpeg4</entry><entry> - pre-standard MPEG-4 variant by MS, v3 (AKA DivX3) - </entry></row> -<row><entry>msmpeg4v2</entry><entry> - pre-standard MPEG-4 by MS, v2 (used in old asf files) - </entry></row> -<row><entry>wmv1</entry><entry> - Windows Media Video, version 1 (AKA WMV7) - </entry></row> -<row><entry>wmv2</entry><entry> - Windows Media Video, version 2 (AKA WMV8) - </entry></row> -<row><entry>rv10</entry><entry> - an old RealVideo codec - </entry></row> -<row><entry>mpeg1video</entry><entry> - MPEG-1 video - </entry></row> -<row><entry>mpeg2video</entry><entry> - MPEG-2 video - </entry></row> -<row><entry>huffyuv</entry><entry> - lossless compression - </entry></row> -<row><entry>asv1</entry><entry> - ASUS Video v1 - </entry></row> -<row><entry>asv2</entry><entry> - ASUS Video v2 - </entry></row> -<row><entry>ffv1</entry><entry> - FFmpeg's lossless video codec - </entry></row> -</tbody> -</tgroup> -</informaltable> - -The first column contains the codec names that should be passed after the -<literal>vcodec</literal> config, like: <option>-lavcopts vcodec=msmpeg4</option> -</para> - -<informalexample> -<para> -An example, with MJPEG compression: -<screen>mencoder dvd://2 -o title2.avi -ovc lavc -lavcopts vcodec=mjpeg -oac copy</screen> -</para> -</informalexample> -</sect1> - - <sect1 id="menc-feat-enc-images"> <title>Encoding from multiple input image files (JPEG, PNG, TGA, SGI)</title> @@ -410,3565 +329,4 @@ </para> </sect1> -<sect1 id="custommatrices"><title>Custom inter/intra matrices</title> - -<para> -With this feature of -<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link> -you are able to set custom inter (I-frames/keyframes) and intra -(P-frames/predicted frames) matrices. It is supported by many of the codecs: -<systemitem>mpeg1video</systemitem> and <systemitem>mpeg2video</systemitem> -are reported as working. -</para> - -<para> -A typical usage of this feature is to set the matrices preferred by the -<ulink url="http://www.kvcd.net/">KVCD</ulink> specifications. -</para> - -<para> -The <emphasis role="bold">KVCD "Notch" Quantization Matrix:</emphasis> -</para> - -<para> -Intra: -<screen> - 8 9 12 22 26 27 29 34 - 9 10 14 26 27 29 34 37 -12 14 18 27 29 34 37 38 -22 26 27 31 36 37 38 40 -26 27 29 36 39 38 40 48 -27 29 34 37 38 40 48 58 -29 34 37 38 40 48 58 69 -34 37 38 40 48 58 69 79 -</screen> - -Inter: -<screen> -16 18 20 22 24 26 28 30 -18 20 22 24 26 28 30 32 -20 22 24 26 28 30 32 34 -22 24 26 30 32 32 34 36 -24 26 28 32 34 34 36 38 -26 28 30 32 34 36 38 40 -28 30 32 34 36 38 42 42 -30 32 34 36 38 40 42 44 -</screen> -</para> - -<para> -Usage: -<screen> -$ mencoder <replaceable>input.avi</replaceable> -o <replaceable>output.avi</replaceable> -oac copy -ovc lavc -lavcopts inter_matrix=...:intra_matrix=... -</screen> -</para> - -<para> -<screen> -$ mencoder <replaceable>input.avi</replaceable> -ovc lavc -lavcopts -vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37, -12,14,18,27,29,34,37,38,22,26,27,31,36,37,38,40,26,27,29,36,39,38,40,48,27, -29,34,37,38,40,48,58,29,34,37,38,40,48,58,69,34,37,38,40,48,58,69,79 -:inter_matrix=16,18,20,22,24,26,28,30,18,20,22,24,26,28,30,32,20,22,24,26, -28,30,32,34,22,24,26,30,32,32,34,36,24,26,28,32,34,34,36,38,26,28,30,32,34, -36,38,40,28,30,32,34,36,38,42,42,30,32,34,36,38,40,42,44 -oac copy -o svcd.mpg -</screen> -</para> -</sect1> - -<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://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> - <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> - <application>MPlayer</application> provides a crop detection filter that - will determine the crop rectangle (<option>-vf cropdetect</option>). - Run <application>MPlayer</application> with - <option>-vf cropdetect</option> and it will print out the crop - settings to remove the borders. - You should let the movie run long enough that the whole picture - area is used, in order to get accurate crop values. -</para> - -<para> - Then, test the values you get with <application>MPlayer</application>, - using the command line which was printed by - <option>cropdetect</option>, and adjust the rectangle as needed. - The <option>rectangle</option> filter can help by allowing you to - interactively position the crop rectangle over your movie. - Remember to follow the above divisibility guidelines so that you - do not misalign the chroma planes. -</para> - -<para> - In certain cases, scaling may be undesirable. - Scaling in the vertical direction is difficult with interlaced - video, and if you wish to preserve the interlacing, you should - usually refrain from scaling. - If you will not be scaling but you still want to use multiple-of-16 - dimensions, you will have to overcrop. - Do not undercrop, since black borders are very bad for encoding! -</para> - -<para> - Because MPEG-4 uses 16x16 macroblocks, you will want to make sure that each - dimension of the video you are encoding is a multiple of 16 or else you - will be degrading quality, especially at lower bitrates. You can do this - by rounding the width and height of the crop rectangle down to the nearest - multiple of 16. - As stated earlier, when cropping, you will want to increase the Y offset by - half the difference of the old and the new height so that the resulting - video is taken from the center of the frame. And because of the way DVD - video is sampled, make sure the offset is an even number. (In fact, as a - rule, never use odd values for any parameter when you are cropping and - scaling video.) If you are not comfortable throwing a few extra pixels - away, you might prefer instead to scale the video instead. We will look - at this in our example below. - You can actually let the <option>cropdetect</option> filter do all of the - above for you, as it has an optional <option>round</option> parameter that - is equal to 16 by default. -</para> - -<para> - Also, be careful about "half black" pixels at the edges. Make sure you - crop these out too, or else you will be wasting bits there that - are better spent elsewhere. -</para> - -<para> - After all is said and done, you will probably end up with video whose pixels - are not quite 1.85:1 or 2.35:1, but rather something close to that. You - could calculate the new aspect ratio manually, but - <application>MEncoder</application> offers an option for <systemitem - class="library">libavcodec</systemitem> called <option>autoaspect</option> - that will do this for you. Absolutely do not scale this video up in order to - square the pixels unless you like to waste your hard disk space. Scaling - should be done on playback, and the player will use the aspect stored in - the AVI to determine the correct resolution. - Unfortunately, not all players enforce this auto-scaling information, - therefore you may still want to rescale. -</para> - -<para> - First, you should compute the encoded aspect ratio: - <systemitem>ARc = (Wc x (ARa / PRdvd )) / Hc</systemitem> -<itemizedlist> -<title>where:</title> -<listitem><para> - Wc and Hc are the width and height of the cropped video, -</para></listitem> -<listitem><para> - ARa is the displayed aspect ratio, which usually is 4/3 or 16/9, -</para></listitem> -<listitem><para> - PRdvd is the pixel ratio of the DVD which is equal to 1.25=(720/576) for PAL - DVDs and 1.5=(720/480) for NTSC DVDs, -</para></listitem> -</itemizedlist> -</para> - -<para> - Then, you can compute the X and Y resolution, according to a certain - Compression Quality (CQ) factor: - <systemitem>ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16</systemitem> - and - <systemitem>ResX = INT( ResY * ARc / 16) * 16</systemitem> -</para> - -<para> - Okay, but what is the CQ? - The CQ represents the number of bits per pixel and per frame of the encode. - Roughly speaking, the greater the CQ, the less the likelihood to see - encoding artifacts. - However, if you have a target size for your movie (1 or 2 CDs for instance), - there is a limited total number of bits that you can spend; therefore it is - necessary to find a good tradeoff between compressibility and quality. -</para> - -<para> - The CQ depends both on the bitrate and the movie resolution. - In order to raise the CQ, typically you would downscale the movie given that the - bitrate is computed in function of the target size and the length of the - movie, which are constant. - A CQ below 0.18 usually ends up in a very blocky picture, because there - are not enough bits to code the information of each macroblock (MPEG4, like - many other codecs, groups pixels by blocks of several pixels to compress the - image; if there are not enough bits, the edges of those blocks are - visible). - It is therefore wise to take a CQ ranging from 0.20 to 0.22 for a 1 CD rip, - and 0.26-0.28 for 2 CDs. -</para> - -<para> - Please take note that the CQ is just an indicative figure, as depending on - the encoded content, a CQ of 0.18 may look just fine for a Bergman, contrary - to a movie such as The Matrix, which contains many high-motion scenes. - On the other hand, it is worthless to raise CQ higher than 0.30 as you would - be wasting bits without any noticeable quality gain. -</para> - -</sect2> - -<sect2 id="menc-feat-dvd-mpeg4-audio"> -<title>Audio</title> - -<para> - Audio is a much simpler problem to solve: if you care about quality, just - leave it as is. - Even AC3 5.1 streams are at most 448Kbit/s, and they are worth every bit. - You might be tempted to transcode the audio to high quality Vorbis, but - just because you do not have an A/V receiver for AC3 pass-through today - does not mean you will not have one tomorrow. Future-proof your DVD rips by - preserving the AC3 stream. - You can keep the AC3 stream either by copying it directly into the video - stream <link linkend="menc-feat-mpeg4">during the encoding</link>. - You can also extract the AC3 stream in order to mux it into containers such - as NUT or Matroska. - <screen>mplayer <replaceable>source_file.vob</replaceable> -aid 129 -dumpaudio -dumpfile <replaceable>sound.ac3</replaceable></screen> - will dump into the file <replaceable>sound.ac3</replaceable> the - audio track number 129 from the file - <replaceable>source_file.vob</replaceable> (NB: DVD VOB files - usually use a different audio numbering, - which means that the VOB audio track 129 is the 2nd audio track of the file). -</para> - -<para> - But sometimes you truly have no choice but to further compress the - sound so that more bits can be spent on the video. - Most people choose to compress audio with either MP3 or Vorbis audio - codecs. - While the latter is a very space-efficient codec, MP3 is better supported - by hardware players, although this trend is changing. -</para> - -<para> - First of all, you will have to convert the DVD sound into a WAV file that the - audio codec can use as input. - For example: - <screen>mplayer <replaceable>source_file.vob</replaceable> -ao pcm:file=<replaceable>destination_sound.wav</replaceable> -vc dummy -aid 1 -vo null</screen> - will dump the second audio track from the file - <replaceable>source_file.vob</replaceable> into the file - <replaceable>destination_sound.wav</replaceable>. - You may want to normalize the sound before encoding, as DVD audio tracks - are commonly recorded at low volumes. - You can use the tool <application>normalize</application> for instance, - which is available in most distributions. - If you are using Windows, a tool such as <application>BeSweet</application> - can do the same job. - You will compress in either Vorbis or MP3. - For example: - <screen>oggenc -q1 <replaceable>destination_sound.wav</replaceable></screen> - will encode <replaceable>destination_sound.wav</replaceable> with - the encoding quality 1, which is roughly equivalent to 80Kb/s, and - is the minimum quality at which you should encode if you care about - quality. - Please note that MEncoder currently cannot mux Vorbis audio tracks - into the output file because it only supports AVI and MPEG - containers as an output, each of which may lead to audio/video - playback synchronization problems with some players when the AVI file - contain VBR audio streams such as Vorbis. - Do not worry, this document will show you how you can do that with third - party programs. -</para> - -</sect2> - -<sect2 id="menc-feat-dvd-mpeg4-interlacing"> -<title>Interlacing and Telecine</title> - -<para> - Almost all movies are shot at 24 fps. Because NTSC is 30000/1001 fps, some - processing must be done to this 24 fps video to make it run at the correct - NTSC framerate. The process is called 3:2 pulldown, commonly referred to - as telecine (because pulldown is often applied during the telecine - process), and, naively described, it works by slowing the film down to - 24000/1001 fps, and repeating every fourth frame. -</para> - -<para> - No special processing, however, is done to the video for PAL DVDs, which - run at 25 fps. (Technically, PAL can be telecined, called 2:2 pulldown, - but this does not become an issue in practice.) The 24 fps film is simply - played back at 25 fps. The result is that the movie runs slightly faster, - but unless you are an alien, you probably will not notice the difference. - Most PAL DVDs have pitch-corrected audio, so when they are played back at - 25 fps things will sound right, even though the audio track (and hence the - whole movie) has a running time that is 4% less than NTSC DVDs. -</para> - -<para> - Because the video in a PAL DVD has not been altered, you needn't worry - much about framerate. The source is 25 fps, and your rip will be 25 - fps. However, if you are ripping an NTSC DVD movie, you may need to - apply inverse telecine. -</para> - -<para> - For movies shot at 24 fps, the video on the NTSC DVD is either telecined - 30000/1001, or else it is progressive 24000/1001 fps and intended to be telecined - on-the-fly by a DVD player. On the other hand, TV series are usually - only interlaced, not telecined. This is not a hard rule: some TV series - are interlaced (such as Buffy the Vampire Slayer) whereas some are a - mixture of progressive and interlaced (such as Angel, or 24). -</para> - -<para> - It is highly recommended that you read the section on - <link linkend="menc-feat-telecine">How to deal with telecine and interlacing in NTSC DVDs</link> - to learn how to handle the different possibilities. -</para> - -<para> - However, if you are mostly just ripping movies, likely you are either - dealing with 24 fps progressive or telecined video, in which case you can - use the <option>pullup</option> filter <option>-vf - pullup,softskip</option>. -</para> - -</sect2> - -<sect2 id="menc-feat-dvd-mpeg4-encoding-interlaced"> -<title>Encoding interlaced video</title> - -<para> - If the movie you want to encode is interlaced (NTSC video or - PAL video), you will need to choose whether you want to - deinterlace or not. - While deinterlacing will make your movie usable on progressive - scan displays such a computer monitors and projectors, it comes - at a cost: The fieldrate of 50 or 60000/1001 fields per second - is halved to 25 or 30000/1001 frames per second, and roughly half of - the information in your movie will be lost during scenes with - significant motion. -</para> - -<para> - Therefore, if you are encoding for high quality archival purposes, - it is recommended not to deinterlace. - You can always deinterlace the movie at playback time when - displaying it on progressive scan devices, and future players will - be able to deinterlace to full fieldrate, interpolating 50 or - 60000/1001 entire frames per second from the interlaced video. -</para> - -<para> -Special care must be taken when working with interlaced video: -</para> - -<orderedlist> -<listitem><para> - Crop height and y-offset must be multiples of 4. -</para></listitem> -<listitem><para> - Any vertical scaling must be performed in interlaced mode. -</para></listitem> -<listitem><para> - Postprocessing and denoising filters may not work as expected - unless you take special care to operate them a field at a time, - and they may damage the video if used incorrectly. -</para></listitem> -</orderedlist> - -<para> -With these things in mind, here is our first example: -</para> -<screen> - mencoder <replaceable>capture.avi</replaceable> -mc 0 -oac lavc -ovc lavc -lavcopts \ - vcodec=mpeg2video:vbitrate=6000:ilmv:ildct:acodec=mp2:abitrate=224 -</screen> -<para> -Note the <option>ilmv</option> and <option>ildct</option> options. -</para> -</sect2> - -<sect2 id="menc-feat-dvd-mpeg4-filtering"> -<title>Filtering</title> - -<para> - In general, you want to do as little filtering as possible to the movie - in order to remain close to the original DVD source. Cropping is often - necessary (as described above), but do not scale the video. Although - scaling down is sometimes preferred to using higher quantizers, we want - to avoid both these things: remember that we decided from the start to - trade bits for quality. -</para> - -<para> - Also, do not adjust gamma, contrast, brightness, etc. What looks good - on your display may not look good on others. These adjustments should - be done on playback only. -</para> - -<para> - One thing you might want to do, however, is pass the video through a - very light denoise filter, such as <option>-vf hqdn3d=2:1:2</option>. - Again, it is a matter of putting those bits to better use: why waste them - encoding noise when you can just add that noise back in during playback? - Increasing the parameters for <option>hqdn3d</option> will further - improve compressibility, but if you increase the values too much, you - risk degrading the image visibily. The suggested values above - (<option>2:1:2</option>) are quite conservative; you should feel free to - experiment with higher values and observe the results for yourself. -</para> - -</sect2> - -<sect2 id="menc-feat-dvd-mpeg4-lavc-encoding-options"> -<title>Encoding options of libavcodec</title> - -<para> - Ideally, you would probably want to be able to just tell the encoder to switch - into "high quality" mode and move on. - That would probably be nice, but unfortunately hard to implement as different - encoding options yield different quality results depending on the source material. - That is because compression depends on the visual properties of the video - in question. - For example, anime and live action have very different properties and - thus require different options to obtain optimum encoding. - The good news is that some options should never be left out, like - <option>mbd=2</option>, <option>trell</option>, and <option>v4mv</option>. - See below for a detailed description of common encoding options. -</para> - - -<itemizedlist> -<title>Options to adjust:</title> -<listitem><para> - <emphasis role="bold">vmax_b_frames</emphasis>: 1 or 2 is good, depending on - the movie. - Note that if you need to have your encode be decodable by DivX5, you - need to activate closed GOP support, using - <systemitem class="library">libavcodec</systemitem>'s <option>cgop</option> - option, but you need to deactivate scene detection, which - is not a good idea as it will hurt encode efficiency a bit. -</para></listitem> - -<listitem><para> - <emphasis role="bold">vb_strategy=1</emphasis>: helps in high-motion scenes. - Requires vmax_b_frames >= 2. - On some videos, vmax_b_frames may hurt quality, but vmax_b_frames=2 along - with vb_strategy=1 helps. -</para></listitem> - -<listitem><para> - <emphasis role="bold">dia</emphasis>: motion search range. Bigger is better - and slower. - Negative values are a completely different scale. - Good values are -1 for a fast encode, or 2-4 for slower. -</para></listitem> - -<listitem><para> - <emphasis role="bold">predia</emphasis>: motion search pre-pass. - Not as important as dia. Good values are 1 (default) to 4. Requires preme=2 - to really be useful. -</para></listitem> - -<listitem><para> - <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Comparison function for - motion estimation. - Experiment with values of 0 (default), 2 (hadamard), 3 (dct), and 6 (rate - distortion). - 0 is fastest, and sufficient for precmp. - For cmp and subcmp, 2 is good for anime, and 3 is good for live action. - 6 may or may not be slightly better, but is slow. -</para></listitem> - -<listitem><para> - <emphasis role="bold">last_pred</emphasis>: Number of motion predictors to - take from the previous frame. - 1-3 or so help at little speed cost. - Higher values are slow for no extra gain. -</para></listitem> - -<listitem><para> - <emphasis role="bold">cbp, mv0</emphasis>: Controls the selection of macroblocks. - Small speed cost for small quality gain. -</para></listitem> - -<listitem><para> - <emphasis role="bold">qprd</emphasis>: adaptive quantization based on the - macroblock's complexity. - May help or hurt depending on the video and other options. - This can cause artifacts unless you set vqmax to some reasonably small value - (6 is good, maybe as low as 4); vqmin=1 should also help. -</para></listitem> - -<listitem><para> - <emphasis role="bold">qns</emphasis>: very slow, especially when combined - with qprd. - This option will make the encoder minimize noise due to compression - artifacts instead of making the encoded video strictly match the source. - Do not use this unless you have already tweaked everything else as far as it - will go and the results still are not good enough. -</para></listitem> - -<listitem><para> - <emphasis role="bold">vqcomp</emphasis>: Tweak ratecontrol. - What values are good depends on the movie. - You can safely leave this alone if you want. - Reducing vqcomp puts more bits on low-complexity scenes, increasing it puts - them on high-complexity scenes (default: 0.5, range: 0-1. recommended range: - 0.5-0.7). -</para></listitem> - -<listitem><para> - <emphasis role="bold">vlelim, vcelim</emphasis>: Sets the single coefficient - elimination threshold for luminance and chroma planes. - These are encoded separately in all MPEG-like algorithms. - The idea behind these options is to use some good heuristics to determine - when the change in a block is less than the threshold you specify, and in - such a case, to just encode the block as "no change". - This saves bits and perhaps speeds up encoding. vlelim=-4 and vcelim=9 - seem to be good for live movies, but seem not to help with anime; - when encoding animation, you should probably leave them unchanged. -</para></listitem> - -<listitem><para> - <emphasis role="bold">qpel</emphasis>: Quarter pixel motion estimation. - MPEG-4 uses half pixel precision for its motion search by default, - therefore this option comes with an overhead as more information will be - stored in the encoded file. - The compression gain/loss depends on the movie, but it is usually not very - effective on anime. - qpel always incurs a significant cost in CPU decode time (+20% in - practice). -</para></listitem> - -<listitem><para> - <emphasis role="bold">psnr</emphasis>: does not affect the actual encoding, - but writes a log file giving the type/size/quality of each frame, and - prints a summary of PSNR (Peak Signal to Noise Ratio) at the end. -</para></listitem> - -</itemizedlist> - -<itemizedlist> -<title>Options not recommended to play with:</title> -<listitem><para> - <emphasis role="bold">vme</emphasis>: The default is best. -</para></listitem> - -<listitem><para> - <emphasis role="bold">lumi_mask, dark_mask</emphasis>: Psychovisual adaptive - quantization. - You do not want to play with those options if you care about quality. - Reasonable values may be effective in your case, but be warned this is very - subjective. -</para></listitem> - -<listitem><para> - <emphasis role="bold">scplx_mask</emphasis>: Tries to prevent blocky - artifacts, but postprocessing is better. -</para></listitem> -</itemizedlist> - -</sect2> - -<sect2 id="menc-feat-dvd-mpeg4-example"> -<title>Example</title> - -<para> - So, you have just bought your shiny new copy of Harry Potter and the Chamber - of Secrets (widescreen edition, of course), and you want to rip this DVD - so that you can add it to your Home Theatre PC. This is a region 1 DVD, - so it is NTSC. The example below will still apply to PAL, except you will - omit <option>-ofps 24000/1001</option> (because the output framerate is the - same as the input framerate), and of course the crop dimensions will be - different. -</para> - -<para> - After running <option>mplayer dvd://1</option>, we follow the process - detailed in the section <link linkend="menc-feat-telecine">How to deal - with telecine and interlacing in NTSC DVDs</link> and discover that it is - 24000/1001 fps progressive video, which means that we needn't use an inverse - telecine filter, such as <option>pullup</option> or - <option>filmdint</option>. -</para> - -<para> - Next, we want to determine the appropriate crop rectangle, so we use the - cropdetect filter: - - <screen>mplayer dvd://1 -vf cropdetect</screen> - - Make sure you seek to a fully filled frame (such as a bright scene), and - you will see in <application>MPlayer</application>'s console output: - - <screen>crop area: X: 0..719 Y: 57..419 (-vf crop=720:362:0:58)</screen> - - We then play the movie back with this filter to test its correctness: - - <screen>mplayer dvd://1 -vf crop=720:362:0:58</screen> - - And we see that it looks perfectly fine. Next, we ensure the width and - height are a multiple of 16. The width is fine, however the height is - not. Since we did not fail 7th grade math, we know that the nearest - multiple of 16 lower than 362 is 352. -</para> - -<para> - We could just use <option>crop=720:352:0:58</option>, but it would be nice - to take a little off the top and a little off the bottom so that we - retain the center. We have shrunk the height by 10 pixels, but we do not - want to increase the y-offset by 5-pixels since that is an odd number and - will adversely affect quality. Instead, we will increase the y-offset by - 4 pixels: - - <screen>mplayer dvd://1 -vf crop=720:352:0:62</screen> - - Another reason to shave pixels from both the top and the bottom is that we - ensure we have eliminated any half-black pixels if they exist. Note that if - your video is telecined, make sure the <option>pullup</option> filter (or - whichever inverse telecine filter you decide to use) appears in the filter - chain before you crop. If it is interlaced, deinterlace before cropping. - (If you choose to preserve the interlaced video, then make sure your - vertical crop offset is a multiple of 4.) -</para> - -<para> - If you are really concerned about losing those 10 pixels, you might - prefer instead to scale the dimensions down to the nearest multiple of 16. - The filter chain would look like: - - <screen>-vf crop=720:362:0:58,scale=720:352</screen> - - Scaling the video down like this will mean that some small amount of - detail is lost, though it probably will not be perceptible. Scaling up will - result in lower quality (unless you increase the bitrate). Cropping - discards those pixels altogether. It is a tradeoff that you will want to - consider for each circumstance. For example, if the DVD video was made - for television, you might want to avoid vertical scaling, since the line - sampling corresponds to the way the content was originally recorded. -</para> - -<para> - On inspection, we see that our movie has a fair bit of action and high - amounts of detail, so we pick 2400Kbit for our bitrate. -</para> - -<para> - We are now ready to do the two pass encode. Pass one: - - <screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \ --lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=1 \ --o Harry_Potter_2.avi</screen> - - And pass two is the same, except that we specify <option>vpass=2</option>: - - <screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \ --lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=2 \ --o Harry_Potter_2.avi</screen> -</para> - -<para> - The options <option>v4mv:mbd=2:trell</option> will greatly increase the - quality at the expense of encoding time. There is little reason to leave - these options out when the primary goal is quality. The options - <option>cmp=3:subcmp=3:mbcmp=3</option> select a comparison function that - yields higher quality than the defaults. You might try experimenting with - this parameter (refer to the man page for the possible values) as - different functions can have a large impact on quality depending on the - source material. For example, if you find - <systemitem class="library">libavcodec</systemitem> produces too much - blocky artifacting, you could try selecting the experimental NSSE as - comparison function via <option>*cmp=10</option>. -</para> - -<para> - For this movie, the resulting AVI will be 138 minutes long and nearly - 3GB. And because you said that file size does not matter, this is a - perfectly acceptable size. However, if you had wanted it smaller, you - could try a lower bitrate. Increasing bitrates have diminishing - returns, so while we might clearly see an improvement from 1800Kbit to - 2000Kbit, it might not be so noticeable above 2000Kbit. Feel - free to experiment until you are happy. -</para> - -<para> - Because we passed the source video through a denoise filter, you may want - to add some of it back during playback. This, along with the - <option>spp</option> post-processing filter, drastically improves the - perception of quality and helps eliminate blocky artifacts in the video. - With <application>MPlayer</application>'s <option>autoq</option> option, - you can vary the amount of post-processing done by the spp filter - depending on available CPU. Also, at this point, you may want to apply - gamma and/or color correction to best suit your display. For example: - - <screen>mplayer Harry_Potter_2.avi -vf spp,noise=9ah:5ah,eq2=1.2 -autoq 3</screen> - -</para> -</sect2> - -<sect2 id="menc-feat-dvd-mpeg4-muxing"> -<title>Muxing</title> -<para> - Now that you have encoded your video, you will most likely want - to mux it with one or more audio tracks into a movie container, such - as AVI, MPEG, Matroska or NUT. - <application>MEncoder</application> is currently only able to output - audio and video into MPEG and AVI container formats. - for example: - <screen>mencoder -oac copy -ovc copy -o <replaceable>output_movie.avi</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable></screen> - This would merge the video file <replaceable>input_video.avi</replaceable> - and the audio file <replaceable>input_audio.mp2</replaceable> - into the AVI file <replaceable>output_movie.avi</replaceable>. - This command works with MPEG-1 layer I, II and III (more commonly known - as MP3) audio, WAV and a few other audio formats too. -</para> - -<para> - MEncoder features experimental support for - <systemitem class="library">libavformat</systemitem>, which is a - library from the FFmpeg project that supports muxing and demuxing - a variety of containers. - For example: - <screen>mencoder -oac copy -ovc copy -o <replaceable>output_movie.asf</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable> -of lavf -lavfopts format=asf</screen> - This will do the same thing as the previous example, except that - the output container will be ASF. - Please note that this support is highly experimental (but getting - better every day), and will only work if you compiled - <application>MPlayer</application> with the support for - <systemitem class="library">libavformat</systemitem> enabled (which - means that a pre-packaged binary version will not work in most cases). -</para> - -<sect3 id="menc-feat-dvd-mpeg4-muxing-avi-limitations"> -<title>Limitations of the AVI container</title> -<para> - Although it is the most widely-supported container format after MPEG-1, - AVI also has some major drawbacks. - Perhaps the most obvious is the overhead. - For each chunk of the AVI file, 24 bytes are wasted on headers and - index. - This translates into a little over 5 MB per hour, or 1-2.5% - overhead for a 700 MB movie. This may not seem like much, but it could - mean the difference between being able to use 700 kbit/sec video or - 714 kbit/sec, and every bit of quality counts. -</para> - -<para> - In addition this gross inefficiency, AVI also has the following major - limitations: -</para> - -<orderedlist> -<listitem> -<para> - Only fixed-fps content can be stored. This is particularly limiting - if the original material you want to encode is mixed content, for - example a mix of NTSC video and film material. - Actually there are hacks that can be used to store mixed-framerate - content in AVI, but they increase the (already huge) overhead - fivefold or more and so are not practical. -</para> -</listitem> -<listitem> -<para> - Audio in AVI files must be either constant-bitrate (CBR) or - constant-framesize (i.e. all frames decode to the same number of - samples). - Unfortunately, the most efficient codec, Vorbis, does not meet - either of these requirements. - Therefore, if you plan to store your movie in AVI, you will have to - use a less efficient codec such as MP3 or AC3. -</para> -</listitem> -</orderedlist> - -<para> - Having said all that, <application>MEncoder</application> does not - currently support variable-fps output or Vorbis encoding. - Therefore, you may not see these as limitations if - <application>MEncoder</application> is the - only tool you will be using to produce your encodes. - However, it is possible to use <application>MEncoder</application> - only for video encoding, and then use external tools to encode - audio and mux it into another container format. -</para> -</sect3> - -<sect3 id="menc-feat-dvd-mpeg4-muxing-matroska"> -<title>Muxing into the Matroska container</title> -<para> - Matroska is a free, open standard container format, aiming - to offer a lot of advanced features, which older containers - like AVI cannot handle. - For example, Matroska supports variable bitrate audio content - (VBR), variable framerates (VFR), chapters, file attachments, - error detection code (EDC) and modern A/V Codecs like "Advanced Audio - Coding" (AAC), "Vorbis" or "MPEG-4 AVC" (H.264), next to nothing - handled by AVI. -</para> - -<para> - The tools required to create Matroska files are collectively called - <application>mkvtoolnix</application>, and are available for most - Unix platforms as well as <application>Windows</application>. - Because Matroska is an open standard you may find other - tools that suit you better, but since mkvtoolnix is the most - common, and is supported by the Matroska team itself, we will - only cover its usage. -</para> - -<para> - Probably the easiest way to get started with Matroska is to use - <application>MMG</application>, the graphical frontend shipped with - <application>mkvtoolnix</application>, and follow the - <ulink url="http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge-gui.html">guide to mkvmerge GUI (mmg)</ulink> -</para> - -<para> - You may also mux audio and video files using the command line: - <screen>mkvmerge -o <replaceable>output.mkv</replaceable> <replaceable>input_video.avi</replaceable> <replaceable>input_audio1.mp3</replaceable> <replaceable>input_audio2.ac3</replaceable></screen> - This would merge the video file <replaceable>input_video.avi</replaceable> - and the two audio files <replaceable>input_audio1.mp3</replaceable> - and <replaceable>input_audio2.ac3</replaceable> into the Matroska - file <replaceable>output.mkv</replaceable>. - Matroska, as mentioned earlier, is able to do much more than that, like - multiple audio tracks (including fine-tuning of audio/video - synchronization), chapters, subtitles, splitting, etc... - Please refer to the documentation of those applications for - more details. -</para> - -</sect3> - -</sect2> - -</sect1> - -<sect1 id="menc-feat-x264"> -<title>Encoding with the <systemitem class="library">x264</systemitem> codec</title> -<para> - <systemitem class="library">x264</systemitem> is a free library for - encoding H.264/AVC video streams. - Before starting to encode, you need to <link linkend="codec-x264-encode"> - set up <application>MEncoder</application> to support it</link>. -</para> - -<sect2 id="menc-feat-x264-encoding-options"> -<title>Encoding options of x264</title> - -<para> - Please begin by reviewing the - <systemitem class="library">x264</systemitem> section of - <application>MPlayer</application>'s man page. - This section is intended to be a supplement to the man page. - Here you will find quick hints about which options are most - likely to interest most people. The man page is more terse, - but also more exhaustive, and it sometimes offers much better - technical detail. -</para> - -<sect3 id="menc-feat-x264-encoding-options-intro"> -<title>Introduction</title> -<para>This guide considers two major categories of encoding options:</para> - -<orderedlist> - <listitem><para>Options which mainly trade off encoding time vs. quality - </para></listitem> - <listitem><para>Options which may be useful for fulfilling various personal - preferences and special requirements</para></listitem> -</orderedlist> - -<para> - Ultimately, only you can decide which options are best for your - purposes. The decision for the first class of options is the simplest: - you only have to decide whether you think the quality differences - justify the speed differences. For the second class of options, - preferences may be far more subjective, and more factors may be - involved. Note that some of the "personal preferences and special - requirements" options can still have large impacts on speed or quality, - but that is not what they are primarily useful for. A couple of the - "personal preference" options may even cause changes that look better - to some people, but look worse to others. -</para> - -<para> - Before continuing, you need to understand that this guide uses only one - quality metric: global PSNR. - For a brief explanation of what PSNR is, see - <ulink url="http://en.wikipedia.org/wiki/PSNR">the Wikipedia article on PSNR</ulink>. - Global PSNR is the last PSNR number reported when you include - the <option>psnr</option> option in <option>x264encopts</option>. - Any time you read a claim about PSNR, one of the assumptions - behind the claim is that equal bitrates are used. -</para> - -<para> - Nearly all of this guide's comments assume you are using - two pass. - When comparing options, there are two major reasons for using - two pass encoding. - First, using two pass often gains around 1dB PSNR, which is a - very big difference. - Secondly, testing options by doing direct quality comparisons - with one pass encodes introduces a major confounding - factor: bitrate often varies significantly with each encode. - It is not always easy to tell whether quality changes are due - mainly to changed options, or if they mostly reflect essentially - random differences in the achieved bitrate. -</para> - -</sect3> - -<sect3 id="menc-feat-x264-encoding-options-speedvquality"> -<title>Options which primarily affect speed and quality</title> - -<itemizedlist> -<listitem><para> - <emphasis role="bold">subq</emphasis>: - Of the options which allow you to trade off speed for quality, - <option>subq</option> and <option>frameref</option> (see below) are usually - by far the most important. - If you are interested in tweaking either speed or quality, these - are the first options you should consider. - On the speed dimension, the <option>frameref</option> and - <option>subq</option> options interact with each other fairly - strongly. - Experience shows that, with one reference frame, - <option>subq=5</option> (the default setting) takes about 35% more time than - <option>subq=1</option>. - With 6 reference frames, the penalty grows to over 60%. - <option>subq</option>'s effect on PSNR seems fairly constant - regardless of the number of reference frames. - Typically, <option>subq=5</option> achieves 0.2-0.5 dB higher global - PSNR in comparison <option>subq=1</option>. - This is usually enough to be visible. -</para> -<para> - <option>subq=6</option> is the slowest, highest quality mode. - In comparison to <option>subq=5</option>, it usually gains 0.1-0.4 dB - global PSNR with speed costs varying from 25%-100%. - Unlike other levels of <option>subq</option>, the behavior of - <option>subq=6</option> does not depend much on <option>frameref</option> - and <option>me</option>. Instead, the effectiveness of <option>subq=6 - </option> depends mostly upon the number of B-frames used. In normal - usage, this means <option>subq=6</option> has a large impact on both speed - and quality in complex, high motion scenes, but it may not have much effect - in low-motion scenes. Note that it is still recommended to always set - <option>bframes</option> to something other than zero (see below). -</para></listitem> -<listitem><para> - <emphasis role="bold">frameref</emphasis>: - <option>frameref</option> is set to 1 by default, but this - should not be taken to imply that it is reasonable to set it - to 1. - Merely raising <option>frameref</option> to 2 gains around - 0.15dB PSNR with a 5-10% speed penalty; this seems like a - good tradeoff. - <option>frameref=3</option> gains around 0.25dB PSNR over - <option>frameref=1</option>, which should be a visible - difference. - <option>frameref=3</option> is around 15% slower than - <option>frameref=1</option>. - Unfortunately, diminishing returns set in rapidly. - <option>frameref=6</option> can be expected to gain only - 0.05-0.1 dB over <option>frameref=3</option> at an additional - 15% speed penalty. - Above <option>frameref=6</option>, the quality gains are - usually very small (although you should keep in mind throughout - this whole discussion that it can vary quite a lot depending on - your source). - In a fairly typical case, <option>frameref=12</option> - will improve global PSNR by a tiny 0.02dB over - <option>frameref=6</option>, at a speed cost of 15%-20%. - At such high <option>frameref</option> values, the only really - good thing that can be said is that increasing it even further will - almost certainly never <emphasis role="bold">harm</emphasis> - PSNR, but the additional quality benefits are barely even - measurable, let alone perceptible. -</para> -<note><title>Note:</title> -<para> - Raising <option>frameref</option> to unnecessarily high values - <emphasis role="bold">can</emphasis> and - <emphasis role="bold">usually does</emphasis> - hurt coding efficiency if you turn CABAC off. - With CABAC on (the default behavior), the possibility of setting - <option>frameref</option> "too high" currently seems too remote - to even worry about, and in the future, optimizations may remove - the possibility altogether. -</para> -</note> -<para> - If you care about speed, a reasonable compromise is to use low - <option>subq</option> and <option>frameref</option> values on - the first pass, and then raise them on the second pass. - Typically, this has a negligible negative effect on the final - quality: You will probably lose well under 0.1dB PSNR, which - should be much too small of a difference to see. - However, different values of <option>frameref</option> can - occasionally affect frametype decision. - Most likely, these are rare outlying cases, but if you want to - be pretty sure, consider whether your video has either - fullscreen repetitive flashing patterns or very large temporary - occlusions which might force an I-frame. - Adjust the first-pass <option>frameref</option> so it is large - enough to contain the duration of the flashing cycle (or occlusion). - For example, if the scene flashes back and forth between two images - over a duration of three frames, set the first pass - <option>frameref</option> to 3 or higher. - This issue is probably extremely rare in live action video material, - but it does sometimes come up in video game captures. -</para></listitem> - -<listitem><para> - <emphasis role="bold">me</emphasis>: - This option is for choosing the motion estimation search method. - Altering this option provides a straightforward quality-vs-speed - tradeoff. <option>me=1</option> is only a few percent faster than - the default search, at a cost of under 0.1dB global PSNR. The - default setting (<option>me=2</option>) is a reasonable tradeoff - between speed and quality. <option>me=3</option> gains a little under - 0.1dB global PSNR, with a speed penalty that varies depending on - <option>frameref</option>. At high values of - <option>frameref</option> (e.g. 12 or so), <option>me=3</option> - is about 40% slower than the default <option> me=2</option>. With - <option>frameref=3</option>, the speed penalty incurred drops to - 25%-30%. -</para> -<para> - <option>me=4</option> uses an exhaustive search that is too slow for - practical use. -</para> -</listitem> - -<listitem><para> - <emphasis role="bold">4x4mv</emphasis>: - This option enables the use of 8x4, 4x8 and 4x4 subpartitions in - predicted macroblocks. Enabling it results in a fairly consistent - 10%-15% loss of speed. This option is rather useless in source - containing only low motion, however in some high-motion source, - particularly source with lots of small moving objects, gains of - about 0.1dB can be expected. -</para> -</listitem> - -<listitem><para> - <emphasis role="bold">bframes</emphasis>: - If you are used to encoding with other codecs, you may have found - that B-frames are not always useful. - In H.264, this has changed: there are new techniques and block - types that are possible in B-frames. - Usually, even a naive B-frame choice algorithm can have a - significant PSNR benefit. - It is interesting to note that using B-frames usually speeds up - the second pass somewhat, and may also speed up a single - pass encode if adaptive B-frame decision is turned off. -</para> -<para> - With adaptive B-frame decision turned off - (<option>x264encopts</option>'s <option>nob_adapt</option>), - the optimal value for this setting is usually no more than - <option>bframes=1</option>, or else high-motion scenes can suffer. - With adaptive B-frame decision on (the default behavior), it is - safe to use higher values; the encoder will reduce the use of - B-frames in scenes where they would hurt compression. - The encoder rarely chooses to use more than 3 or 4 B-frames; - setting this option any higher will have little effect. -</para></listitem> - -<listitem><para> - <emphasis role="bold">b_adapt</emphasis>: - Note: This is on by default. -</para> -<para> - With this option enabled, the encoder will use a reasonably fast - decision process to reduce the number of B-frames used in scenes that - might not benefit from them as much. - You can use <option>b_bias</option> to tweak how B-frame-happy - the encoder is. - The speed penalty of adaptive B-frames is currently rather modest, - but so is the potential quality gain. - It usually does not hurt, however. - Note that this only affects speed and frametype decision on the - first pass. - <option>b_adapt</option> and <option>b_bias</option> have no - effect on subsequent passes. -</para></listitem> - -<listitem><para> - <emphasis role="bold">b_pyramid</emphasis>: - You might as well enable this option if you are using >=2 B-frames; - as the man page says, you get a little quality improvement at no - speed cost. - Note that these videos cannot be read by libavcodec-based decoders - older than about March 5, 2005. -</para></listitem> - -<listitem><para> - <emphasis role="bold">weight_b</emphasis>: - In typical cases, there is not much gain with this option. - However, in crossfades or fade-to-black scenes, weighted - prediction gives rather large bitrate savings. - In MPEG-4 ASP, a fade-to-black is usually best coded as a series - of expensive I-frames; using weighted prediction in B-frames - makes it possible to turn at least some of these into much smaller - B-frames. - Encoding time cost is minimal, as no extra decisions need to be made. - Also, contrary to what some people seem to guess, the decoder - CPU requirements are not much affected by weighted prediction, - all else being equal. -</para> -<para> - Unfortunately, the current adaptive B-frame decision algorithm - has a strong tendency to avoid B-frames during fades. - Until this changes, it may be a good idea to add - <option>nob_adapt</option> to your x264encopts, if you expect - fades to have a large effect in your particular video - clip. -</para></listitem> -</itemizedlist> -</sect3> - -<sect3 id="menc-feat-x264-encoding-options-misc-preferences"> -<title>Options pertaining to miscellaneous preferences</title> -<itemizedlist> -<listitem><para> - <emphasis role="bold">Two pass encoding</emphasis>: - Above, it was suggested to always use two pass encoding, but there - are still reasons for not using it. For instance, if you are capturing - live TV and encoding in realtime, you are forced to use single-pass. - Also, one pass is obviously faster than two passes; if you use the - exact same set of options on both passes, two pass encoding is almost - twice as slow. -</para> -<para> - Still, there are very good reasons for using two pass encoding. For - one thing, single pass ratecontrol isn't psychic, and it often makes - unreasonable choices because it can't see the big picture. For example, - suppose you have a two minute long video consisting of two distinct - halves. The first half is a very high-motion scene lasting 60 seconds - which, in isolation, requires about 2500kbps in order to look decent. - Immediately following it is a much less demanding 60-second scene - that looks good at 300kbps. Suppose you ask for 1400kbps on the theory - that this is enough to accomodate both scenes. Single pass ratecontrol - will make a couple of "mistakes" in such a case. First of all, it - will target 1400kbps in both segments. The first segment may end up - heavily overquantized, causing it to look unacceptably and unreasonably - blocky. The second segment will be heavily underquantized; it may look - perfect, but the bitrate cost of that perfection will be completely - unreasonable. What's even harder to avoid is the problem at the - transition between the two scenes. The first seconds of the low motion - half will be hugely over-quantized, because the ratecontrol is still - expecting the kind of bitrate requirements it met in the first half - of the video. This "error period" of heavily over-quantized low motion - will look jarringly bad, and will actually use less than the 300kbps - it would have taken to make it look decent. There are ways to - mitigate the pitfalls of single-pass encoding, but they may tend to - increase bitrate misprediction. -</para> -<para> - Multipass ratecontrol can offer huge advantages over a single pass. - Using the statistics gathered from the first pass encode, the encoder - can estimate, with reasonable accuracy, the "cost" (in bits) of - encoding any given frame, at any given quantizer. This allows for - a much more rational, better planned allocation of bits between the - expensive (high-motion) and cheap (low-motion) scenes. See - <option>qcomp</option> below for some ideas on how to tweak this - allocation to your liking. -</para> -<para> - Moreover, two passes need not take twice as long as one pass. You can - tweak the options in the first pass for higher speed and lower quality. - If you choose your options well, you can get a very fast first pass. - The resulting quality in the second pass will be slightly lower because size - prediction is less accurate, but the quality difference is normally much - too small to be visible. Try, for example, adding - <option>subq=1:frameref=1</option> to the first pass - <option>x264encopts</option>. Then, on the second pass, use slower, - higher-quality options: - <option>subq=6:frameref=15:4x4mv:me=3</option> -</para></listitem> -<listitem><para> - <emphasis role="bold">Three pass encoding</emphasis>? - - x264 offers the ability to make an arbitrary number of consecutive - passes. If you specify <option>pass=1</option> on the first pass, - then use <option>pass=3</option> on a subsequent pass, the subsequent - pass will both read the statistics from the previous pass, and write - its own statistics. An additional pass following this one will have - a very good base from which to make highly accurate predictions of - framesizes at a chosen quantizer. In practice, the overall quality - gain from this is usually close to zero, and quite possibly a third - pass will result in slightly worse global PSNR than the pass before - it. In typical usage, three passes help if you get either bad bitrate - prediction or bad looking scene transitions when using only two passes. - This is somewhat likely to happen on extremely short clips. There are - also a few special cases in which three (or more) passes are handy - for advanced users, but for brevity, this guide omits discussing those - special cases. - -</para></listitem> -<listitem><para> - <emphasis role="bold">qcomp</emphasis>: - <option>qcomp</option> trades off the number of bits allocated - to "expensive" high-motion versus "cheap" low-motion frames. At - one extreme, <option>qcomp=0</option> aims for true constant - bitrate. Typically this would make high-motion scenes look completely - awful, while low-motion scenes would probably look absolutely - perfect, but would also use many times more bitrate than they - would need in order to look merely excellent. At the other extreme, - <option>qcomp=1</option> achieves nearly constant quantization parameter - (QP). Constant QP doesn't look bad, but most people think it's more - reasonable to shave some bitrate off of the extremely expensive scenes - (where the loss of quality isn't as noticeable) and reallocate it to - the scenes that are easier to encode at excellent quality. - <option>qcomp</option> is set to 0.6 by default, which may be slightly - low for many peoples' taste (0.7-0.8 are also commonly used). -</para></listitem> -<listitem><para> - <emphasis role="bold">keyint</emphasis>: - <option>keyint</option> is solely for trading off file seekability against - coding efficiency. By default, <option>keyint</option> is set to 250. In - 25fps material, this guarantees the ability to seek to within 10 seconds - precision. If you think it would be important and useful to be able to - seek within 5 seconds of precision, set <option>keyint=125</option>; - this will hurt quality/bitrate slightly. If you care only about quality - and not about seekability, you can set it to much higher values - (understanding that there are diminishing returns which may become - vanishingly low, or even zero). The video stream will still have seekable - points as long as there are some scene changes. -</para></listitem> -<listitem><para> - <emphasis role="bold">deblockalpha, deblockbeta</emphasis>: - This topic is going to be a bit controversial. -</para> -<para> - H.264 defines a simple deblocking procedure on I-blocks that uses - pre-set strengths and thresholds depending on the QP of the block - in question. - By default, high QP blocks are filtered heavily, and low QP blocks - are not deblocked at all. - The pre-set strengths defined by the standard are well-chosen and - the odds are very good that they are PSNR-optimal for whatever - video you are trying to encode. - The <option>deblockalpha</option> and <option>deblockbeta</option> - parameters allow you to specify offsets to the preset deblocking - thresholds. -</para> -<para> - Many people seem to think it is a good idea to lower the deblocking - filter strength by large amounts (say, -3). - This is however almost never a good idea, and in most cases, - people who are doing this do not understand very well how - deblocking works by default. -</para> -<para> - The first and most important thing to know about the in-loop - deblocking filter is that the default thresholds are almost always - PSNR-optimal. - In the rare cases that they are not optimal, the ideal offset is - plus or minus 1. - Adjusting deblocking parameters by a larger amount is almost - guaranteed to hurt PSNR. - Strengthening the filter will smear more details; weakening the - filter will increase the appearance of blockiness. -</para> -<para> - It is definitely a bad idea to lower the deblocking thresholds if - your source is mainly low in spacial complexity (i.e., not a lot - of detail or noise). - The in-loop filter does a rather excellent job of concealing - the artifacts that occur. - If the source is high in spacial complexity, however, artifacts - are less noticeable. - This is because the ringing tends to look like detail or noise. - Human visual perception easily notices when detail is removed, - but it does not so easily notice when the noise is wrongly - represented. - When it comes to subjective quality, noise and detail are somewhat - interchangeable. - By lowering the deblocking filter strength, you are most likely - increasing error by adding ringing artifacts, but the eye does - not notice because it confuses the artifacts with detail. -</para> - -<para> - This <emphasis role="bold">still</emphasis> does not justify - lowering the deblocking filter strength, however. - You can generally get better quality noise from postprocessing. - If your H.264 encodes look too blurry or smeared, try playing with - <option>-vf noise</option> when you play your encoded movie. - <option>-vf noise=8a:4a</option> should conceal most mild - artifacting. - It will almost certainly look better than the results you - would have gotten just by fiddling with the deblocking filter. -</para></listitem> -</itemizedlist> -</sect3> -</sect2> -</sect1> - -<sect1 id="menc-feat-xvid"> -<title>Encoding with the <systemitem class="library">XviD</systemitem> -codec</title> -<para> - <systemitem class="library">XviD</systemitem> is a free library for - encoding MPEG-4 ASP video streams. - Before starting to encode, you need to <link linkend="xvid"> - set up <application>MEncoder</application> to support it</link>. -</para> -<para> - This guide mainly aims at featuring the same kind of information - as x264's encoding guide. - Therefore, please begin by reading - <link linkend="menc-feat-x264-encoding-options-intro">the first part</link> - of that guide. -</para> - - -<sect2 id="menc-feat-xvid-intro"> -<title>What options should I use to get the best results?</title> - -<para> - Please begin by reviewing the - <systemitem class="library">XviD</systemitem> section of - <application>MPlayer</application>'s man page. - This section is intended to be a supplement to the man page. -</para> -<para> - The XviD default settings are already a good tradeoff between - speed and quality, therefore you can safely stick to them if - the following section puzzles you. -</para> -</sect2> - -<sect2 id="menc-feat-xvid-encoding-options"> -<title>Encoding options of <systemitem class="library">XviD</systemitem></title> - -<itemizedlist> -<listitem><para> - <emphasis role="bold">vhq</emphasis> - This setting affects the macroblock decision algorithm, where the - higher the setting, the wiser the decision. - The default setting may be safely used for every encode, while - higher settings always help PSNR but are significantly slower. - Please note that a better PSNR does not necessarily mean - that the picture will look better, but tells you that it is - closer to the original. - Turning it off will noticeably speed up encoding; if speed is - critical for you, the tradeoff may be worth it. -</para></listitem> - -<listitem><para> - <emphasis role="bold">bvhq</emphasis> - This does the same job as vhq, but does it on B-frames. - It has a negligible impact on speed, and slightly improves quality - (around +0.1dB PSNR). -</para></listitem> - -<listitem><para> - <emphasis role="bold">max_bframes</emphasis> - A higher number of consecutive allowed B-frames usually improves - compressibility, although it may also lead to more blocking artifacts. - The default setting is a good tradeoff between compressibility and - quality, but you may increase it up to 3 if you are bitrate-starved. - You may also decrease it to 1 or 0 if you are aiming at perfect - quality, though in that case you should make sure your - target bitrate is high enough to ensure that the encoder does not - have to increase quantizers to reach it. -</para></listitem> - -<listitem><para> - <emphasis role="bold">bf_threshold</emphasis> - This controls the B-frame sensitivity of the encoder, where a higher - value leads to more B-frames being used (and vice versa). - This setting is to be used together with <option>max_bframes</option>; - if you are bitrate-starved, you should increase both - <option>max_bframes</option> and <option>bf_threshold</option>, - while you may increase <option>max_bframes</option> and reduce - <option>bf_threshold</option> so that the encoder may use more - B-frames in places that only <emphasis role="bold">really</emphasis> - need them. - A low number of <option>max_bframes</option> and a high value of - <option>bf_threshold</option> is probably not a wise choice as it - will force the encoder to put B-frames in places that would not - benefit from them, therefore reducing visual quality. - However, if you need to be compatible with standalone players that - only support old DivX profiles (which only supports up to 1 - consecutive B-frame), this would be your only way to - increase compressibility through using B-frames. -</para></listitem> - -<listitem><para> - <emphasis role="bold">trellis</emphasis> - Optimizes the quantization process to get an optimal tradeoff - between PSNR and bitrate, which allows significant bit saving. - These bits will in return be spent elsewhere on the video, - raising overall visual quality. - You should always leave it on as its impact on quality is huge. - Even if you are looking for speed, do not disable it until you - have turned down <option>vhq</option> and all other more - CPU-hungry options to the minimum. -</para></listitem> - -<listitem><para> - <emphasis role="bold">hq_ac</emphasis> - Activates a better coefficient cost estimation method, which slightly - reduces filesize by around 0.15 to 0.19%, while having a negligible - impact on speed. - It is therefore recommended to always leave it on. -</para></listitem> - -<listitem><para> - <emphasis role="bold">cartoon</emphasis> - Designed to better encode cartoon content, and has no impact on - speed as it just tunes the mode decision heuristics for this type - of content. -</para></listitem> - -<listitem><para> - <emphasis role="bold">me_quality</emphasis> - This setting is to control the precision of the motion estimation. - The higher <option>me_quality</option>, the more - precise the estimation of the original motion will be, and the - better the resulting clip will capture the original motion. - </para> - <para> - The default setting is best in all cases; - thus it is not recommended to turn it down unless you are - really looking for speed, as all the bits saved by a good motion - estimation would be spent elsewhere, raising overall quality. - Therefore, do not go any lower than 5, and even that only as a last - resort. -</para></listitem> - -<listitem><para> - <emphasis role="bold">chroma_me</emphasis> - Improves motion estimation by also taking the chroma (color) - information into account, whereas <option>me_quality</option> - alone only uses luma (grayscale). - This slows down encoding by 5-10% but improves visual quality - quite a bit by reducing blocking effects and reduces filesize by - around 1.3%. - If you are looking for speed, you should disable this option before - starting to consider reducing <option>me_quality</option>. -</para></listitem> - -<listitem><para> - <emphasis role="bold">chroma_opt</emphasis> - Is intended to increase chroma image quality around pure - white/black edges, rather than improving compression. - This can help to reduce the "red stairs" effect. -</para></listitem> - -<listitem><para> - <emphasis role="bold">lumi_mask</emphasis> - Tries to give less bitrate to part of the picture that the - human eye cannot see very well, which should allow the encoder - to spend the saved bits on more important parts of the picture. - The quality of the encode yielded by this option highly depends - on personal preferences and on the type and monitor settings - used to watch it (typically, it will not look as good if it is - bright or if it is a TFT monitor). -</para></listitem> - -<listitem><para> - <emphasis role="bold">qpel</emphasis> - Raise the number of candidate motion vectors by increasing - the precision of the motion estimation from halfpel to - quarterpel. - The idea is to find better motion vectors which will in return - reduce bitrate (hence increasing quality). - However, motion vectors with quarterpel precision require a - few extra bits to code, but the candidate vectors do not always - give (much) better results. - Quite often, the codec still spends bits on the extra precision, - but little or no extra quality is gained in return. - Unfortunately, there is no way to foresee the possible gains of - <option>qpel</option>, so you need to actually encode with and - without it to know for sure. - </para><para> - <option>qpel</option> can be almost double encoding time, and - requires as much as 25% more processing power to decode. - It is not supported by all standalone players. -</para></listitem> - -<listitem><para> - <emphasis role="bold">gmc</emphasis> - Tries to save bits on panning scenes by using a single motion - vector for the whole frame. - This almost always raises PSNR, but significantly slows down - encoding (as well as decoding). - Therefore, you should only use it when you have turned - <option>vhq</option> to the maximum. - <systemitem class="library">XviD</systemitem>'s GMC is more - sophisticated than DivX's, but is only supported by few - standalone players. -</para></listitem> - -</itemizedlist> -</sect2> -</sect1> - -<sect1 id="menc-feat-vcd-dvd"> -<title>Using MEncoder to create VCD/SVCD/DVD-compliant files.</title> - -<sect2 id="menc-feat-vcd-dvd-constraints"> -<title>Format Constraints</title> -<para> - <application>MEncoder</application> is capable of creating VCD, SCVD - and DVD format MPEG files using the - <systemitem class="library">libavcodec</systemitem> library. - These files can then be used in conjunction with - <ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink> - or - <ulink url="http://dvdauthor.sourceforge.net/">dvdauthor</ulink> - to create discs that will play on a standard set-top player. -</para> - -<para> - The DVD, SVCD, and VCD formats are subject to heavy constraints. - Only a small selection of encoded picture sizes and aspect ratios are - available. - If your movie does not already meet these requirements, you may have - to scale,crop or add black borders to the picture to make it - compliant. -</para> - -<sect3 id="menc-feat-vcd-dvd-constraints-resolution"> -<title>Format Constraints</title> - -<informaltable frame="all"> -<tgroup cols="9"> -<thead> - <row> - <entry>Format</entry> - <entry>Resolution</entry> - <entry>V. Codec</entry> - <entry>V. Bitrate</entry> - <entry>Sample Rate</entry> - <entry>A. Codec</entry> - <entry>A. Bitrate</entry> - <entry>FPS</entry> - <entry>Aspect</entry> - </row> -</thead> -<tbody> - <row> - <entry>NTSC DVD</entry> - <entry>720x480, 704x480, 352x480, 352x240</entry> - <entry>MPEG-2</entry> - <entry>9800 kbps</entry> - <entry>48000 Hz</entry> - <entry>AC3,PCM</entry> - <entry>1536 kbps</entry> - <entry>23.976, 29.97</entry> - <entry>4:3, 16:9 (only for 720x480)</entry> - </row> - <row> - <entry>NTSC DVD</entry> - <entry>352x240<footnote id='fn-rare-resolutions'><para> - These resolutions are rarely used for DVDs because - they are fairly low quality.</para></footnote></entry> - <entry>MPEG-1</entry> - <entry>1856 kbps</entry> - <entry>48000 Hz</entry> - <entry>AC3,PCM</entry> - <entry>1536 kbps</entry> - <entry>23.976, 29.97</entry> - <entry>4:3, 16:9</entry> - </row> - <row> - <entry>NTSC SVCD</entry> - <entry>480x480</entry> - <entry>MPEG-2</entry> - <entry>2600 kbps</entry> - <entry>44100 Hz</entry> - <entry>MP2</entry> - <entry>384 kbps</entry> - <entry>29.97</entry> - <entry>4:3</entry> - </row> - <row> - <entry>NTSC VCD</entry> - <entry>352x240</entry> - <entry>MPEG-1</entry> - <entry>1150 kbps</entry> - <entry>44100 Hz</entry> - <entry>MP2</entry> - <entry>224 kbps</entry> - <entry>23.976, 29.97</entry> - <entry>4:3</entry> - </row> - <row> - <entry>PAL DVD</entry> - <entry>720x576, 704x576, 352x576, 352x288</entry> - <entry>MPEG-2</entry> - <entry>9800 kbps</entry> - <entry>48000 Hz</entry> - <entry>MP2,AC3,PCM</entry> - <entry>1536 kbps</entry> - <entry>25</entry> - <entry>4:3, 16:9 (only for 720x576)</entry> - </row> - <row> - <entry>PAL DVD</entry> - <entry>352x288<footnoteref linkend='fn-rare-resolutions'/></entry> - <entry>MPEG-1</entry> - <entry>1856 kbps</entry> - <entry>48000 Hz</entry> - <entry>MP2,AC3,PCM</entry> - <entry>1536 kbps</entry> - <entry>25</entry> - <entry>4:3, 16:9</entry> - </row> - <row> - <entry>PAL SVCD</entry> - <entry>480x576</entry> - <entry>MPEG-2</entry> - <entry>2600 kbps</entry> - <entry>44100 Hz</entry> - <entry>MP2</entry> - <entry>384 kbps</entry> - <entry>25</entry> - <entry>4:3</entry> - </row> - <row> - <entry>PAL VCD</entry> - <entry>352x288</entry> - <entry>MPEG-1</entry> - <entry>1150 kbps</entry> - <entry>44100 Hz</entry> - <entry>MP2</entry> - <entry>224 kbps</entry> - <entry>25</entry> - <entry>4:3</entry> - </row> -</tbody> -</tgroup> -</informaltable> - -<para> - If your movie has 2.35:1 aspect (most recent action movies), you will - have to add black borders or crop the movie down to 16:9 to make a DVD - or VCD. - If you add black borders, try to align them at 16-pixel boundaries in - order to minimize the impact on encoding performance. - Thankfully DVD has sufficiently excessive bitrate that you do not have - to worry too much about encoding efficiency, but SVCD and VCD are - highly bitrate-starved and require effort to obtain acceptable quality. -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-constraints-gop"> -<title>GOP Size Constraints</title> -<para> - DVD, VCD, and SVCD also constrain you to relatively low - GOP (Group of Pictures) sizes. - For 30 fps material the largest allowed GOP size is 18. - For 25 or 24 fps, the maximum is 15. - The GOP size is set using the <option>keyint</option> option. -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-constraints-bitrate"> -<title>Bitrate Constraints</title> -<para> - VCD video is required to be CBR at 1152 kbps. - This highly limiting constraint also comes along with an extremly low vbv - buffer size of 327 kilobits. - SVCD allows varying video bitrates up to 2500 kbps, and a somewhat less - restrictive vbv buffer size of 917 kilobits is allowed. - DVD video bitrates may range anywhere up to 9800 kbps (though typical - bitrates are about half that), and the vbv buffer size is 1835 kilobits. -</para> -</sect3> -</sect2> - -<sect2 id="menc-feat-vcd-dvd-output"> -<title>Output Options</title> -<para> - <application>MEncoder</application> has options to control the output - format. - Using these options we can instruct it to create the correct type of - file. -</para> - -<para> - The options for VCD and SVCD are called xvcd and xsvcd, because they - are extended formats. - They are not strictly compliant, mainly because the output does not - contain scan offsets. - If you need to generate an SVCD image, you should pass the output file - to - <ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink>. -</para> - -<para> - VCD: - <screen> - -of mpeg -mpegopts format=xvcd - </screen> -</para> - -<para> - SVCD: - <screen> - -of mpeg -mpegopts format=xsvcd - </screen> -</para> - -<para> - DVD: - <screen> - -of mpeg -mpegopts format=dvd - </screen> -</para> - -<sect3 id="menc-feat-vcd-dvd-output-aspect"> -<title>Aspect Ratio</title> -<para> - The aspect argument of <option>-lavcopts</option> is used to encode - the aspect ratio of the file. - During playback the aspect ratio is used to restore the video to the - correct size. -</para> - -<para> - 16:9 or "Widescreen" - <screen> - -lavcopts aspect=16/9 - </screen> -</para> - -<para> - 4:3 or "Fullscreen" - <screen> - -lavcopts aspect=4/3 - </screen> -</para> - -<para> - 2.35:1 or "Cinemascope" NTSC - <screen> - -vf scale=720:368,expand=720:480 -lavcopts aspect=16/9 - </screen> - To calculate the correct scaling size, use the expanded NTSC width of - 854/2.35 = 368 -</para> - -<para> - 2.35:1 or "Cinemascope" PAL - <screen> - -vf scale="720:432,expand=720:576 -lavcopts aspect=16/9 - </screen> - To calculate the correct scaling size, use the expanded PAL width of - 1024/2.35 = 432 -</para> - -</sect3> - -<sect3 id="menc-feat-vcd-dvd-output-srate"> -<title>Sample Rate Conversion</title> -<para> - If the audio sample rate in the original file is not the same as - required by the target format, sample rate conversion is required. - This is achieved using the <option>-srate</option> option and - the <option>-af lavcresample</option> audio filter together. - </para> - <para> - DVD: - <screen> - -srate 48000 -af lavcresample=48000 - </screen> -</para> -<para> - VCD and SVCD: - <screen> - -srate 44100 -af lavcresample=44100 - </screen> - </para> -</sect3> -</sect2> - -<sect2 id="menc-feat-vcd-dvd-lavc"> -<title>Using libavcodec for VCD/SVCD/DVD Encoding</title> - -<sect3 id="menc-feat-vcd-dvd-lavc-intro"> -<title>Introduction</title> -<para> - <systemitem class="library">libavcodec</systemitem> can be used to - create VCD/SVCD/DVD compliant video by using the appropriate options. -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-lavc-options"> -<title>lavcopts</title> -<para> - This is a list of fields in <option>-lavcopts</option> that you may - be required to change in order to make a complaint movie for VCD, SVCD, - or DVD: -</para> - -<itemizedlist> -<listitem><para> - <emphasis role="bold">acodec</emphasis>: - <option>mp2</option> for VCD, SVCD, or PAL DVD; - <option>ac3</option> is most commonly used for DVD. - PCM audio may also be used for DVD, but this is mostly a big waste of - space. - Note that MP3 audio is not compliant for any of these formats, but - players often have no problem playing it anyway. -</para></listitem> - -<listitem><para> - <emphasis role="bold">abitrate</emphasis>: - 224 for VCD; up to 384 for SVCD; up to 1536 for DVD, but commonly - used values range from 192 kbps for stereo to 384 kbps for 5.1 channel - sound. -</para></listitem> - -<listitem><para> - <emphasis role="bold">vcodec</emphasis>: - <option>mpeg1video</option> for VCD; - <option>mpeg2video</option> for SVCD; - <option>mpeg2video</option> is usually used for DVD but you may also use - <option>mpeg1video</option> for CIF resolutions. -</para></listitem> - -<listitem><para> - <emphasis role="bold">keyint</emphasis>: - Used to set the GOP size. - 18 for 30fps material, or 15 for 25/24 fps material. - Commercial producers seem to prefer keyframe intervals of 12. - It is possible to make this much larger and still retain compatibility - with most players. - A <option>keyint</option> of 25 should never cause any problems. -</para></listitem> - -<listitem><para> - <emphasis role="bold">vrc_buf_size</emphasis>: - 327 for VCD, 917 for SVCD, and 1835 for DVD. -</para></listitem> - -<listitem><para> - <emphasis role="bold">vrc_minrate</emphasis>: - 1152, for VCD. May be left alone for SVCD and DVD. -</para></listitem> - -<listitem><para> - <emphasis role="bold">vrc_maxrate</emphasis>: - 1152 for VCD; 2500 for SVCD; 9800 for DVD. - For SVCD and DVD, you might wish to use lower values depending on your - own personal preferences and requirements. -</para></listitem> - -<listitem><para> - <emphasis role="bold">vbitrate</emphasis>: - 1152 for VCD; - up to 2500 for SVCD; - up to 9800 for DVD. - For the latter two formats, vbitrate should be set based on personal - preference. - For instance, if you insist on fitting 20 or so hours on a DVD, you - could use vbitrate=400. - The resulting video quality would probably be quite bad. - If you are trying to squeeze out the maximum possible quality on a DVD, - use vbitrate=9800, but be warned that this could constrain you to less - than an hour of video on a single-layer DVD. -</para></listitem> -</itemizedlist> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-lavc-examples"> -<title>Examples</title> -<para> - This is a typical minimum set of <option>-lavcopts</option> for - encoding video: -</para> -<para> - VCD: - <screen> - -lavcopts vcodec=mpeg1video:vrc_buf_size=327:vrc_minrate=1152:\ - vrc_maxrate=1152:vbitrate=1152:keyint=15:acodec=mp2 - </screen> -</para> - -<para> - SVCD: - <screen> - -lavcopts vcodec=mpeg2video:vrc_buf_size=917:vrc_maxrate=2500:vbitrate=1800:\ - keyint=15:acodec=mp2 - </screen> -</para> - -<para> - DVD: - <screen> - -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\ - keyint=15:acodec=ac3 - </screen> -</para> - -</sect3> - -<sect3 id="menc-feat-vcd-dvd-lavc-advanced"> -<title>Advanced Options</title> -<para> - For higher quality encoding, you may also wish to add quality-enhancing - options to lavcopts, such as <option>trell</option>, - <option>mbd=2</option>, and others. - Note that <option>qpel</option> and <option>v4mv</option>, while often - useful with MPEG-4, are not usable with MPEG-1 or MPEG-2. - Also, if you are trying to make a very high quality DVD encode, it may - be useful to add <option>dc=10</option> to lavcopts. - Doing so may help reduce the appearance of blocks in flat-colored areas. - Putting it all together, this is an example of a set of lavcopts for a - higher quality DVD: -</para> - -<para> - <screen> - -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=8000:\ - keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:\ - vqmin=1:lmin=1:dc=10 - </screen> -</para> - -</sect3> -</sect2> - -<sect2 id="menc-feat-vcd-dvd-audio"> -<title>Encoding Audio</title> -<para> - VCD and SVCD support MPEG-1 layer II audio, using one of - <systemitem class="library">toolame</systemitem>, - <systemitem class="library">twolame</systemitem>, - or <systemitem class="library">libavcodec</systemitem>'s MP2 encoder. - The libavcodec MP2 is far from being as good as the other two libraries, - however it should always be available to use. - VCD only supports constant bitrate audio (CBR) whereas SVCD supports - variable bitrate (VBR), too. - Be careful when using VBR because some bad standalone players might not - support it too well. -</para> - -<para> - For DVD audio, <systemitem class="library">libavcodec</systemitem>'s - AC3 codec is used. -</para> - -<sect3 id="menc-feat-vcd-dvd-audio-toolame"> -<title>toolame</title> -<para> - For VCD and SVCD: - <screen> - -oac toolame -toolameopts br=224 - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-audio-twolame"> -<title>twolame</title> -<para> - For VCD and SVCD: - <screen> - -oac twolame -twolameopts br=224 - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-audio-lavc"> -<title>libavcodec</title> -<para> - For DVD with 2 channel sound: - <screen> - -oac lavc -lavcopts acodec=ac3:abitrate=192 - </screen> -</para> -<para> - For DVD with 5.1 channel sound: - <screen> - -channels 6 -oac lavc -lavcopts acodec=ac3:abitrate=384 - </screen> -</para> -<para> - For VCD and SVCD: - <screen> - -oac lavc -lavcopts acodec=mp2:abitrate=224 - </screen> -</para> -</sect3> - -</sect2> - -<sect2 id="menc-feat-vcd-dvd-all"> -<title>Putting it all Together</title> -<para> - This section shows some complete commands for creating VCD/SVCD/DVD - compliant videos. -</para> - -<sect3 id="menc-feat-vcd-dvd-all-pal-dvd"> -<title>PAL DVD</title> -<para> - <screen> - mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\ - harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\ - vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:\ - abitrate=192:aspect=16/9 -ofps 25 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-all-ntsc-dvd"> -<title>NTSC DVD</title> -<para> - <screen> - mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,\ - harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\ - vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:\ - abitrate=192:aspect=16/9 -ofps 30000/1001 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-all-pal-ac3-copy"> -<title>PAL AVI Containing AC3 Audio to DVD</title> -<para> - If the source already has AC3 audio, use -oac copy instead of re-encoding it. - <screen> - mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\ - harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:\ - vbitrate=5000:keyint=15:aspect=16/9 -ofps 25 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-all-ntsc-ac3-copy"> -<title>NTSC AVI Containing AC3 Audio to DVD</title> -<para> - If the source already has AC3 audio, and is NTSC @ 23.976 fps: - <screen> - mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,\ - harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:\ - vbitrate=5000:keyint=15:aspect=16/9 -ofps 24000/1001 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-all-pal-svcd"> -<title>PAL SVCD</title> -<para> - <screen> - mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \ - scale=480:576,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ - vcodec=mpeg2video:mbd=2:keyint=15:vrc_buf_size=917:vrc_minrate=600:\ - vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 -ofps 25 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-all-ntsc-svcd"> -<title>NTSC SVCD</title> -<para> - <screen> - mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \ - scale=480:480,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ - vcodec=mpeg2video:mbd=2:keyint=18:vrc_buf_size=917:vrc_minrate=600:\ - vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 -ofps 30000/1001 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-all-pal-vcd"> -<title>PAL VCD</title> -<para> - <screen> - mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \ - scale=352:288,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ - vcodec=mpeg1video:keyint=15:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:\ - vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 25 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -<sect3 id="menc-feat-vcd-dvd-all-ntsc-vcd"> -<title>NTSC VCD</title> -<para> - <screen> - mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \ - scale=352:240,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ - vcodec=mpeg1video:keyint=18:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:\ - vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 30000/1001 \ - -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable> - </screen> -</para> -</sect3> - -</sect2> - -</sect1> - -<sect1 id="menc-feat-telecine"> -<title>How to deal with telecine and interlacing within NTSC DVDs</title> - -<sect2 id="menc-feat-telecine-intro"> -<title>Introduction</title> -<formalpara> -<title>What is telecine?</title> -<para> - I suggest you visit this page if you do not understand much of what - is written in this document: - <ulink url="http://www.divx.com/support/guides/guide.php?gid=10">http://www.divx.com/support/guides/guide.php?gid=10</ulink> - This URL links to an understandable and reasonably comprehensive - description of what telecine is. -</para></formalpara> - -<formalpara> -<title>A note about the numbers.</title> -<para> - Many documents, including the guide linked above, refer to the fields - per second value of NTSC video as 59.94 and the corresponding frames - per second values as 29.97 (for telecined and interlaced) and 23.976 - (for progressive). For simplicity, some documents even round these - numbers to 60, 30, and 24. -</para></formalpara> - -<para> - Strictly speaking, all those numbers are approximations. Black and - white NTSC video was exactly 60 fields per second, but 60000/1001 - was later chosen to accomodate color data while remaining compatible - with contemporary black and white televisions. Digital NTSC video - (such as on a DVD) is also 60000/1001 fields per second. From this, - interlaced and telecined video are derived to be 30000/1001 frames - per second; progressive video is 24000/1001 frames per second. -</para> - -<para> - Older versions of the <application>MEncoder</application> documentation - and many archived mailing list posts refer to 59.94, 29.97, and 23.976. - All <application>MEncoder</application> documentation has been updated - to use the fractional values, and you should use them too. -</para> - -<para> - <option>-ofps 23.976</option> is incorrect. - <option>-ofps 24000/1001</option> should be used instead. -</para> - -<formalpara> -<title>How telecine is used.</title> -<para> - All video intended to be displayed on an NTSC - television set must be 60000/1001 fields per second. Made-for-TV movies - and shows are often filmed directly at 60000/1001 fields per second, but - the majority of cinema is filmed at 24 or 24000/1001 frames per - second. When cinematic movie DVDs are mastered, the video is then - converted for television using a process called telecine. -</para></formalpara> - -<para> - On a DVD, the video is never actually stored as 60000/1001 fields per - second. For video that was originally 60000/1001, each pair of fields is - combined to form a frame, resulting in 30000/1001 frames per - second. Hardware DVD players then read a flag embedded in the video - stream to determine whether the odd- or even-numbered lines should - form the first field. -</para> - -<para> - Usually, 24000/1001 frames per second content stays as it is when - encoded for a DVD, and the DVD player must perform telecining - on-the-fly. Sometimes, however, the video is telecined - <emphasis>before</emphasis> being stored on the DVD; even though it - was originally 24000/1001 frames per second, it becomes 60000/1001 fields per - second. When it is stored on the DVD, pairs of fields are combined to form - 30000/1001 frames per second. -</para> - -<para> - When looking at individual frames formed from 60000/10001 fields per - second video, telecined or otherwise, interlacing is clearly visible - wherever there is any motion, because one field (say, the - even-numbered lines) represents a moment in time 1/(60000/1001) - seconds later than the other. Playing interlaced video on a computer - looks ugly both because the monitor is higher resolution and because - the video is shown frame-after-frame instead of field-after-field. -</para> - -<itemizedlist> -<title>Notes:</title> -<listitem><para> - This section only applies to NTSC DVDs, and not PAL. - </para></listitem> -<listitem><para> - The example <application>MEncoder</application> lines throughout the - document are <emphasis role="bold">not</emphasis> intended for - actual use. They are simply the bare minimum required to encode the - pertaining video category. How to make good DVD rips or fine-tune - <systemitem class="library">libavcodec</systemitem> for maximal - quality is not within the scope of this document. - </para></listitem> -<listitem><para> - There are a couple footnotes specific to this guide, linked like this: - <link linkend="menc-feat-telecine-footnotes">[1]</link> - </para></listitem> -</itemizedlist> -</sect2> - -<sect2 id="menc-feat-telecine-ident"> -<title>How to tell what type of video you have</title> - -<sect3 id="menc-feat-telecine-ident-progressive"> -<title>Progressive</title> -<para> - Progressive video was originally filmed at 24000/1001 fps, and stored - on the DVD without alteration. -</para> - -<para> - When you play a progressive DVD in <application>MPlayer</application>, - <application>MPlayer</application> will print the following line as - soon as the movie begins to play: - - <screen> demux_mpg: 24000/1001 fps progressive NTSC content detected, switching framerate.</screen> - - From this point forward, demux_mpg should never say it finds - "30000/1001 fps NTSC content." -</para> - -<para> - When you watch progressive video, you should never see any - interlacing. Beware, however, because sometimes there is a tiny bit - of telecine mixed in where you would not expect. I have encountered TV - show DVDs that have one second of telecine at every scene change, or - at seemingly random places. I once watched a DVD that had a - progressive first half, and the second half was telecined. If you - want to be <emphasis>really</emphasis> thorough, you can scan the - entire movie: - - <screen>mplayer dvd://1 -nosound -vo null -benchmark</screen> - - Using <option>-benchmark</option> makes - <application>MPlayer</application> play the movie as quickly as it - possibly can; still, depending on your hardware, it can take a - while. Every time demux_mpg reports a framerate change, the line - immediately above will show you the time at which the change - occurred. -</para> - -<para> - Sometimes progressive video on DVDs is referred to as - "soft-telecine" because it is intended to - be telecined by the DVD player. -</para> -</sect3> - -<sect3 id="menc-feat-telecine-ident-telecined"> -<title>Telecined</title> -<para> - Telecined video was originally filmed at 24000/1001, but was telecined - <emphasis>before</emphasis> it was written to the DVD. -</para> - -<para> - <application>MPlayer</application> does not (ever) report any - framerate changes when it plays telecined video. -</para> - -<para> - Watching a telecined video, you will see interlacing artifacts that - seem to "blink": they repeatedly appear and disappear. - You can look closely at this by - <orderedlist> - <listitem> - <screen>mplayer dvd://1</screen> - </listitem> - <listitem><para> - Seek to a part with motion. - </para></listitem> - <listitem><para> - Use the <keycap>.</keycap> key to step forward one frame at a time. - </para></listitem> - <listitem><para> - Look at the pattern of interlaced-looking and progressive-looking - frames. If the pattern you see is PPPII,PPPII,PPPII,... then the - video is telecined. If you see some other pattern, then the video - may have been telecined using some non-standard method; - <application>MEncoder</application> cannot losslessly convert - non-standard telecine to progressive. If you do not see any - pattern at all, then it is most likely interlaced. - </para></listitem> - </orderedlist> -</para> - -<para> - Sometimes telecined video on DVDs is referred to as - "hard-telecine". Since hard-telecine is already 60000/1001 fields - per second, the DVD player plays the video without any manipulation. -</para> -</sect3> - -<sect3 id="menc-feat-telecine-ident-interlaced"> -<title>Interlaced</title> -<para> - Interlaced video was originally filmed at 60000/1001 fields per second, - and stored on the DVD as 30000/1001 frames per second. The interlacing effect - (often called "combing") is a result of combining pairs of - fields into frames. Each field is supposed to be 1/(60000/1001) seconds apart, - and when they are displayed simultaneously the difference is apparent. -</para> - -<para> - As with telecined video, <application>MPlayer</application> should - not ever report any framerate changes when playing interlaced content. -</para> - -<para> - When you view an interlaced video closely by frame-stepping with the - <keycap>.</keycap> key, you will see that every single frame is interlaced. -</para> -</sect3> - -<sect3 id="menc-feat-telecine-ident-mixedpt"> -<title>Mixed progressive and telecine</title> -<para> - All of a "mixed progressive and telecine" video was originally - 24000/1001 frames per second, but some parts of it ended up being telecined. -</para> - -<para> - When <application>MPlayer</application> plays this category, it will - (often repeatedly) switch back and forth between "30000/1001 fps NTSC" - and "24000/1001 fps progressive NTSC". Watch the bottom of - <application>MPlayer</application>'s output to see these messages. -</para> - -<para> - You should check the "30000/1001 fps NTSC" sections to make sure - they are actually telecine, and not just interlaced. -</para> -</sect3> - -<sect3 id="menc-feat-telecine-ident-mixedpi"> -<title>Mixed progressive and interlaced</title> -<para> - In "mixed progressive and interlaced" content, progressive - and interlaced video have been spliced together. -</para> - -<para> - This category looks just like "mixed progressive and telecine", - until you examine the 30000/1001 fps sections and see that they do not have the - telecine pattern. -</para> -</sect3> - -</sect2> - -<sect2 id="menc-feat-telecine-encode"> -<title>How to encode each category</title> -<para> - As I mentioned in the beginning, example <application>MEncoder</application> - lines below are <emphasis role="bold">not</emphasis> meant to actually be used; - they only demonstrate the minimum parameters to properly encode each category. -</para> - -<sect3 id="menc-feat-telecine-encode-progressive"> -<title>Progressive</title> -<para> - Progressive video requires no special filtering to encode. The only - parameter you need to be sure to use is - <option>-ofps 24000/1001</option>. Otherwise, <application>MEncoder</application> - will try to encode at 30000/1001 fps and will duplicate frames. -</para> - -<para> - <screen>mencoder dvd://1 -nosound -ovc lavc -ofps 24000/1001</screen> -</para> - -<para> - It is often the case, however, that a video that looks progressive - actually has very short parts of telecine mixed in. Unless you are - sure, it is safest to treat the video as - <link linkend="menc-feat-telecine-encode-mixedpt">mixed progressive and telecine</link>. - The performance loss is small - <link linkend="menc-feat-telecine-footnotes">[3]</link>. -</para> -</sect3> - -<sect3 id="menc-feat-telecine-encode-telecined"> -<title>Telecined</title> -<para> - Telecine can be reversed to retrieve the original 24000/1001 content, - using a process called inverse-telecine. - <application>MPlayer</application> contains several filters to - accomplish this; the best filter, <option>pullup</option>, is described - in the <link linkend="menc-feat-telecine-encode-mixedpt">mixed - progressive and telecine</link> section. -</para> -</sect3> - -<sect3 id="menc-feat-telecine-encode-interlaced"> -<title>Interlaced</title> -<para> - For most practical cases it is not possible to retrieve a complete - progressive video from interlaced content. The only way to do so - without losing half of the vertical resolution is to double the - framerate and try to "guess" what ought to make up the - corresponding lines for each field (this has drawbacks - see method - 3). -</para> - -<orderedlist> -<listitem><para> - - Encode the video in interlaced form. Normally, interlacing wreaks - havoc with the encoder's ability to compress well, but - <systemitem class="library">libavcodec</systemitem> has two - parameters specifically for dealing with storing interlaced video a - bit better: <option> ildct</option> and <option>ilme</option>. Also, - using <option>mbd=2</option> is strongly recommended - <link linkend="menc-feat-telecine-footnotes">[2] </link> because it - will encode macroblocks as non-interlaced in places where there is - no motion. Note that <option>-ofps</option> is NOT needed here. - - <screen>mencoder dvd://1 -nosound -ovc lavc -lavcopts ildct:ilme:mbd=2</screen> - </para></listitem> -<listitem><para> - Use a deinterlacing filter before encoding. There are several of - these filters available to choose from, each with its own advantages - and disadvantages. Consult <option>mplayer -pphelp</option> to see - what is available (grep for "deint"), and search the - <ulink url="http://www.mplayerhq.hu/homepage/design6/info.html#mailing_lists"> - MPlayer mailing lists</ulink> to find many discussions about the - various filters. Again, the framerate is not changing, so no - <option>-ofps</option>. Also, deinterlacing should be done after - cropping <link linkend="menc-feat-telecine-footnotes">[1]</link> and - before scaling. - - <screen>mencoder dvd://1 -nosound -vf pp=lb -ovc lavc</screen> - </para></listitem> -<listitem><para> - Unfortunately, this option is buggy with - <application>MEncoder</application>; it ought to work well with - <application>MEncoder G2</application>, but that is not here yet. You - might experience crahes. Anyway, the purpose of <option> -vf - tfields</option> is to create a full frame out of each field, which - makes the framerate 60000/1001. The advantage of this approach is that no - data is ever lost; however, since each frame comes from only one - field, the missing lines have to be interpolated somehow. There are - no very good methods of generating the missing data, and so the - result will look a bit similar to when using some deinterlacing - filters. Generating the missing lines creates other issues, as well, - simply because the amount of data doubles. So, higher encoding - bitrates are required to maintain quality, and more CPU power is - used for both encoding and decoding. tfields has several different - options for how to create the missing lines of each frame. If you - use this method, then Reference the manual, and chose whichever - option looks best for your material. Note that when using - <option>tfields</option> you - <emphasis role="bold">have to</emphasis> specify both - <option>-fps</option> and <option>-ofps</option> to be twice the - framerate of your original source. - - <screen>mencoder dvd://1 -nosound -vf tfields=2 -ovc lavc -fps 60000/1001 -ofps 60000/1001</screen> - </para></listitem> -<listitem><para> - If you plan on downscaling dramatically, you can extract and encode - only one of the two fields. Of course, you will lose half the vertical - resolution, but if you plan on downscaling to at most 1/2 of the - original, the loss will not matter much. The result will be a - progressive 30000/1001 frames per second file. The procedure is to use - <option>-vf field</option>, then crop - <link linkend="menc-feat-telecine-footnotes">[1]</link> and scale - appropriately. Remember that you will have to adjust the scale to - compensate for the vertical resolution being halved. - <screen>mencoder dvd://1 -nosound -vf field=0 -ovc lavc</screen> - </para></listitem> -</orderedlist> -</sect3> - -<sect3 id="menc-feat-telecine-encode-mixedpt"> -<title>Mixed progressive and telecine</title> -<para> - In order to turn mixed progressive and telecine video into entirely - progressive video, the telecined parts have to be - inverse-telecined. There are three ways to accomplish this, - described below. Note that you should - <emphasis role="bold">always</emphasis> inverse-telecine before any - rescaling; unless you really know what you are doing, - inverse-telecine before cropping, too - <link linkend="menc-feat-telecine-footnotes">[1]</link>. - <option>-ofps 24000/1001</option> is needed here because the output video - will be 24000/1001 frames per second. -</para> - -<itemizedlist> -<listitem><para> - <option>-vf pullup</option> is designed to inverse-telecine - telecined material while leaving progressive data alone. In order to - work properly, <option>pullup</option> <emphasis role="bold">must</emphasis> - be followed by the <option>softskip</option> filter or - else <application>MEncoder</application> will crash. - <option>pullup</option> is, however, the cleanest and most - accurate method available for encoding both telecine and - "mixed progressive and telecine". - - <screen>mencoder dvd://1 -nosound -vf pullup,softskip -ovc lavc -ofps 24000/1001</screen> - </para> - - - </listitem> - <listitem><para> - An older method - is to, rather than inverse-telecine the telecined parts, telecine - the non-telecined parts and then inverse-telecine the whole - video. Sound confusing? softpulldown is a filter that goes through - a video and makes the entire file telecined. If we follow - softpulldown with either <option>detc</option> or - <option>ivtc</option>, the final result will be entirely - progressive. <option>-ofps 24000/1001</option> is needed. - - <screen>mencoder dvd://1 -nosound -vf softpulldown,ivtc=1 -ovc lavc -ofps 24000/1001</screen> - </para> - </listitem> - -<listitem><para> - I have not used <option>-vf filmdint</option> myself, but here is what - D Richard Felker III has to say: - - <blockquote><para>It is OK, but IMO it tries to deinterlace rather - than doing inverse telecine too often (much like settop DVD - players & progressive TVs) which gives ugly flickering and - other artifacts. If you are going to use it, you at least need to - spend some time tuning the options and watching the output first - to make sure it is not messing up.</para></blockquote> - </para></listitem> -</itemizedlist> -</sect3> - -<sect3 id="menc-feat-telecine-encode-mixedpi"> -<title>Mixed progressive and interlaced</title> -<para> - There are two options for dealing with this category, each of - which is a compromise. You should decide based on the - duration/location of each type. -</para> - -<itemizedlist> -<listitem><para> - Treat it as progressive. The interlaced parts will look interlaced, - and some of the interlaced fields will have to be dropped, resulting - in a bit of uneven jumpiness. You can use a postprocessing filter if - you want to, but it may slightly degrade the progressive parts. - </para> - - <para> - This option should definitely not be used if you want to eventually - display the video on an interlaced device (with a TV card, for - example). If you have interlaced frames in a 24000/1001 frames per - second video, they will be telecined along with the progressive - frames. Half of the interlaced "frames" will be displayed for three - fields' duration (3/(60000/1001) seconds), resulting in a flicking - "jump back in time" effect that looks quite bad. If you - even attempt this, you <emphasis role="bold">must</emphasis> use a - deinterlacing filter like <option>lb</option> or - <option>l5</option>. - </para> - - <para> - It may also be a bad idea for progressive display, too. It will drop - pairs of consecutive interlaced fields, resulting in a discontinuity - that can be more visible than with the second method, which shows - some progressive frames twice. 30000/1001 frames per second interlaced - video is already a bit choppy because it really should be shown at - 60000/1001 fields per second, so the duplicate frames do not stand out as - much. - </para> - - <para> - Either way, it is best to consider your content and how you intend to - display it. If your video is 90% progressive and you never intend to - show it on a TV, you should favor a progressive approach. If it is - only half progressive, you probably want to encode it as if it is all - interlaced. - </para> - </listitem> - -<listitem><para> - Treat it as interlaced. Some frames of the progressive parts will - need to be duplicated, resulting in uneven jumpiness. Again, - deinterlacing filters may slightly degrade the progressive parts. - </para></listitem> - -</itemizedlist> -</sect3> - -</sect2> - -<sect2 id="menc-feat-telecine-footnotes"> -<title>Footnotes</title> -<orderedlist> -<listitem><formalpara> - <title>About cropping:</title> - <para> - Video data on DVDs are stored in a format called YUV 4:2:0. In YUV - video, luma ("brightness") and chroma ("color") - are stored separately. Because the human eye is somewhat less - sensitive to color than it is to brightness, in a YUV 4:2:0 picture - there is only one chroma pixel for every four luma pixels. In a - progressive picture, each square of four luma pixels (two on each - side) has one common chroma pixel. You must crop progressive YUV - 4:2:0 to even resolutions, and use even offsets. For example, - <option>crop=716:380:2:26</option> is OK but - <option>crop=716:380:3:26 </option> is not. - </para> - </formalpara> - - <para> - When you are dealing with interlaced YUV 4:2:0, the situation is a - bit more complicated. Instead of every four luma pixels in the - <emphasis>frame</emphasis> sharing a chroma pixel, every four luma - pixels in each <emphasis> field</emphasis> share a chroma - pixel. When fields are interlaced to form a frame, each scanline is - one pixel high. Now, instead of all four luma pixels being in a - square, there are two pixels side-by-side, and the other two pixels - are side-by-side two scanlines down. The two luma pixels in the - intermediate scanline are from the other field, and so share a - different chroma pixel with two luma pixels two scanlines away. All - this confusion makes it necessary to have vertical crop dimensions - and offsets be multiples of four. Horizontal can stay even. - </para> - - <para> - For telecined video, I recommend that cropping take place after - inverse telecining. Once the video is progressive you only need to - crop by even numbers. If you really want to gain the slight speedup - that cropping first may offer, you must crop vertically by multiples - of four or else the inverse-telecine filter will not have proper data. - </para> - - <para> - For interlaced (not telecined) video, you must always crop - vertically by multiples of four unless you use <option>-vf - field</option> before cropping. - </para> - </listitem> - -<listitem><formalpara> - <title>About encoding parameters and quality:</title> - <para> - Just because I recommend <option>mbd=2</option> here does not mean it - should not be used elsewhere. Along with <option>trell</option>, - <option>mbd=2</option> is one of the two - <systemitem class="library">libavcodec</systemitem> options that - increases quality the most, and you should always use at least those - two unless the drop in encoding speed is prohibitive (e.g. realtime - encoding). There are many other options to - <systemitem class="library">libavcodec</systemitem> that increase - encoding quality (and decrease encoding speed) but that is beyond - the scope of this document. - </para> - </formalpara> - </listitem> - -<listitem><formalpara> - <title>About the performance of pullup:</title> - <para> - It is safe to use <option>pullup</option> (along with <option>softskip - </option>) on progressive video, and is usually a good idea unless - the source has been definitively verified to be entirely progressive. - The performace loss is small for most cases. On a bare-minimum encode, - <option>pullup</option> causes <application>MEncoder</application> to - be 50% slower. Adding sound processing and advanced <option>lavcopts - </option> overshadows that difference, bringing the performance - decrease of using <option>pullup</option> down to 2%. - </para> - </formalpara> - </listitem> - -</orderedlist> - -</sect2> - -</sect1> - </chapter>