Update to MPlayer SVN rev 29473 and FFmpeg SVN rev 19572.
[vaapi:athaifas-mplayer.git] / DOCS / xml / en / .svn / text-base / encoding-guide.xml.svn-base
1 <?xml version="1.0" encoding="utf-8"?>
2 <!-- $Revision$ -->
3 <chapter id="encoding-guide">
4 <title>Encoding with <application>MEncoder</application></title>
5
6 <sect1 id="menc-feat-dvd-mpeg4">
7 <title>Making a high quality MPEG-4 ("DivX")
8   rip of a DVD movie</title>
9
10 <para>
11 One frequently asked question is "How do I make the highest quality rip
12 for a given size?". Another question is "How do I make the highest
13 quality DVD rip possible? I do not care about file size, I just want the best
14 quality."
15 </para>
16
17 <para>
18 The latter question is perhaps at least somewhat wrongly posed. After all, if
19 you do not care about file size, why not simply copy the entire MPEG-2 video
20 stream from the the DVD? Sure, your AVI will end up being 5GB, give
21 or take, but if you want the best quality and do not care about size,
22 this is certainly your best option.
23 </para>
24
25 <para>
26 In fact, the reason you want to transcode a DVD into MPEG-4 is
27 specifically because you <emphasis role="bold">do</emphasis> care about
28 file size.
29 </para>
30
31 <para>
32 It is difficult to offer a cookbook recipe on how to create a very high
33 quality DVD rip. There are several factors to consider, and you should
34 understand these details or else you are likely to end up disappointed
35 with your results. Below we will investigate some of these issues, and
36 then have a look at an example. We assume you are using
37 <systemitem class="library">libavcodec</systemitem> to encode the video,
38 although the theory applies to other codecs as well.
39 </para>
40
41 <para>
42 If this seems to be too much for you, you should probably use one of the
43 many fine frontends that are listed in the
44 <ulink url="http://www.mplayerhq.hu/design7/projects.html#mencoder_frontends">MEncoder section</ulink>
45 of our related projects page.
46 That way, you should be able to achieve high quality rips without too much
47 thinking, because most of those tools are designed to take clever decisions
48 for you.
49 </para>
50
51 <!-- ********** -->
52
53 <sect2 id="menc-feat-dvd-mpeg4-preparing-encode">
54 <title>Preparing to encode: Identifying source material and framerate</title>
55
56 <para>
57 Before you even think about encoding a movie, you need to take
58 several preliminary steps.
59 </para>
60
61 <para>
62 The first and most important step before you encode should be
63 determining what type of content you are dealing with.
64 If your source material comes from DVD or broadcast/cable/satellite
65 TV, it will be stored in one of two formats: NTSC for North
66 America and Japan, PAL for Europe, etc.
67 It is important to realize, however, that this is just the formatting for
68 presentation on a television, and often does
69 <emphasis role="bold">not</emphasis> correspond to the
70 original format of the movie.
71 Experience shows that NTSC material is a lot more difficult to encode,
72 because there more elements to identify in the source.
73 In order to produce a suitable encode, you need to know the original
74 format.
75 Failure to take this into account will result in various flaws in your
76 encode, including ugly combing (interlacing) artifacts and duplicated
77 or even lost frames.
78 Besides being ugly, the artifacts also harm coding efficiency:
79 You will get worse quality per unit bitrate.
80 </para>
81
82
83 <sect3 id="menc-feat-dvd-mpeg4-preparing-encode-fps">
84 <title>Identifying source framerate</title>
85
86 <para>
87 Here is a list of common types of source material, where you are
88 likely to find them, and their properties:
89 </para>
90
91 <itemizedlist>
92 <listitem><para>
93   <emphasis role="bold">Standard Film</emphasis>: Produced for
94   theatrical display at 24fps.
95 </para></listitem>
96 <listitem><para>
97   <emphasis role="bold">PAL video</emphasis>: Recorded with a PAL
98   video camera at 50 fields per second.
99   A field consists of just the odd- or even-numbered lines of a
100   frame.
101   Television was designed to refresh these in alternation as a
102   cheap form of analog compression.
103   The human eye supposedly compensates for this, but once you
104   understand interlacing you will learn to see it on TV too and
105   never enjoy TV again.
106   Two fields do <emphasis role="bold">not</emphasis> make a
107   complete frame, because they are captured 1/50 of a second apart
108   in time, and thus they do not line up unless there is no motion.
109 </para></listitem>
110 <listitem><para>
111   <emphasis role="bold">NTSC Video</emphasis>: Recorded with an
112   NTSC video camera at 60000/1001 fields per second, or 60 fields per
113   second in the pre-color era.
114   Otherwise similar to PAL.
115 </para></listitem>
116 <listitem><para>
117   <emphasis role="bold">Animation</emphasis>: Usually drawn at
118   24fps, but also comes in mixed-framerate varieties.
119 </para></listitem>
120 <listitem><para>
121   <emphasis role="bold">Computer Graphics (CG)</emphasis>: Can be
122   any framerate, but some are more common than others; 24 and
123   30 frames per second are typical for NTSC, and 25fps is typical
124   for PAL.
125 </para></listitem>
126 <listitem><para>
127   <emphasis role="bold">Old Film</emphasis>: Various lower
128   framerates.
129 </para></listitem>
130 </itemizedlist>
131 </sect3>
132
133
134 <sect3 id="menc-feat-dvd-mpeg4-preparing-encode-material">
135 <title>Identifying source material</title>
136
137 <para>
138 Movies consisting of frames are referred to as progressive,
139 while those consisting of independent fields are called
140 either interlaced or video - though this latter term is
141 ambiguous.
142 </para>
143
144 <para>
145 To further complicate matters, some movies will be a mix of
146 several of the above.
147 </para>
148
149 <para>
150 The most important distinction to make between all of these
151 formats is that some are frame-based, while others are
152 field-based.
153 <emphasis role="bold">Whenever</emphasis> a movie is prepared
154 for display on television (including DVD), it is converted to a
155 field-based format.
156 The various methods by which this can be done are collectively
157 referred to as "telecine", of which the infamous NTSC
158 "3:2 pulldown" is one variety.
159 Unless the original material was also field-based (and the same
160 fieldrate), you are getting the movie in a format other than the
161 original.
162 </para>
163
164 <itemizedlist>
165 <title>There are several common types of pulldown:</title>
166 <listitem><para>
167   <emphasis role="bold">PAL 2:2 pulldown</emphasis>: The nicest of
168   them all.
169   Each frame is shown for the duration of two fields, by extracting the
170   even and odd lines and showing them in alternation.
171   If the original material is 24fps, this process speeds up the
172   movie by 4%.
173 </para></listitem>
174 <listitem><para>
175   <emphasis role="bold">PAL 2:2:2:2:2:2:2:2:2:2:2:3 pulldown</emphasis>:
176   Every 12th frame is shown for the duration of three fields, instead of
177   just two.
178   This avoids the 4% speedup issue, but makes the process much
179   more difficult to reverse.
180   It is usually seen in musical productions where adjusting the
181   speed by 4% would seriously damage the musical score.
182 </para></listitem>
183 <listitem><para>
184   <emphasis role="bold">NTSC 3:2 telecine</emphasis>: Frames are
185   shown alternately for the duration of 3 fields or 2 fields.
186   This gives a fieldrate 2.5 times the original framerate.
187   The result is also slowed down very slightly from 60 fields per
188   second to 60000/1001 fields per second to maintain NTSC fieldrate.
189 </para></listitem>
190 <listitem><para>
191   <emphasis role="bold">NTSC 2:2 pulldown</emphasis>: Used for
192   showing 30fps material on NTSC.
193   Nice, just like 2:2 PAL pulldown.
194 </para></listitem>
195 </itemizedlist>
196
197 <para>
198 There are also methods for converting between NTSC and PAL video,
199 but such topics are beyond the scope of this guide.
200 If you encounter such a movie and want to encode it, your best
201 bet is to find a copy in the original format.
202 Conversion between these two formats is highly destructive and
203 cannot be reversed cleanly, so your encode will greatly suffer
204 if it is made from a converted source.
205 </para>
206
207 <para>
208 When video is stored on DVD, consecutive pairs of fields are
209 grouped as a frame, even though they are not intended to be shown
210 at the same moment in time.
211 The MPEG-2 standard used on DVD and digital TV provides a
212 way both to encode the original progressive frames and to store
213 the number of fields for which a frame should be shown in the
214 header of that frame.
215 If this method has been used, the movie will often be described
216 as "soft-telecined", since the process only directs the
217 DVD player to apply pulldown to the movie rather than altering
218 the movie itself.
219 This case is highly preferable since it can easily be reversed
220 (actually ignored) by the encoder, and since it preserves maximal
221 quality.
222 However, many DVD and broadcast production studios do not use
223 proper encoding techniques but instead produce movies with
224 "hard telecine", where fields are actually duplicated in the
225 encoded MPEG-2.
226 </para>
227
228 <para>
229 The procedures for dealing with these cases will be covered
230 <link linkend="menc-feat-telecine">later in this guide</link>.
231 For now, we leave you with some guides to identifying which type
232 of material you are dealing with:
233 </para>
234
235 <itemizedlist>
236 <title>NTSC regions:</title>
237 <listitem><para>
238   If <application>MPlayer</application> prints that the framerate
239   has changed to 24000/1001 when watching your movie, and never changes
240   back, it is almost certainly progressive content that has been
241   "soft telecined".
242 </para></listitem>
243 <listitem><para>
244   If <application>MPlayer</application> shows the framerate
245   switching back and forth between 24000/1001 and 30000/1001, and you see
246   "combing" at times, then there are several possibilities.
247   The 24000/1001 fps segments are almost certainly progressive
248   content, "soft telecined", but the 30000/1001 fps parts could be
249   either hard-telecined 24000/1001 fps content or 60000/1001 fields per second
250   NTSC video.
251   Use the same guidelines as the following two cases to determine which.
252 </para></listitem>
253 <listitem><para>
254   If <application>MPlayer</application> never shows the framerate
255   changing, and every single frame with motion appears combed, your
256   movie is NTSC video at 60000/1001 fields per second.
257 </para></listitem>
258 <listitem><para>
259   If <application>MPlayer</application> never shows the framerate
260   changing, and two frames out of every five appear combed, your
261   movie is "hard telecined" 24000/1001fps content.
262 </para></listitem>
263 </itemizedlist>
264
265 <itemizedlist>
266 <title>PAL regions:</title>
267 <listitem><para>
268   If you never see any combing, your movie is 2:2 pulldown.
269 </para></listitem>
270 <listitem><para>
271   If you see combing alternating in and out every half second,
272   then your movie is 2:2:2:2:2:2:2:2:2:2:2:3 pulldown.
273 </para></listitem>
274 <listitem><para>
275   If you always see combing during motion, then your movie is PAL
276   video at 50 fields per second.
277 </para></listitem>
278 </itemizedlist>
279
280 <note><title>Hint:</title>
281 <para>
282   <application>MPlayer</application> can slow down movie playback
283   with the -speed option or play it frame-by-frame.
284   Try using <option>-speed</option> 0.2 to watch the movie very
285   slowly or press the "<keycap>.</keycap>" key repeatedly to play one frame at
286   a time and identify the pattern, if you cannot see it at full speed.
287 </para>
288 </note>
289 </sect3>
290 </sect2>
291
292 <!-- ********** -->
293
294 <sect2 id="menc-feat-dvd-mpeg4-2pass">
295 <title>Constant quantizer vs. multipass</title>
296
297 <para>
298 It is possible to encode your movie at a wide range of qualities.
299 With modern video encoders and a bit of pre-codec compression
300 (downscaling and denoising), it is possible to achieve very good
301 quality at 700 MB, for a 90-110 minute widescreen movie.
302 Furthermore, all but the longest movies can be encoded with near-perfect
303 quality at 1400 MB.
304 </para>
305
306 <para>
307 There are three approaches to encoding the video: constant bitrate
308 (CBR), constant quantizer, and multipass (ABR, or average bitrate).
309 </para>
310
311 <para>
312 The complexity of the frames of a movie, and thus the number of bits
313 required to compress them, can vary greatly from one scene to another.
314 Modern video encoders can adjust to these needs as they go and vary
315 the bitrate.
316 In simple modes such as CBR, however, the encoders do not know the
317 bitrate needs of future scenes and so cannot exceed the requested
318 average bitrate for long stretches of time.
319 More advanced modes, such as multipass encode, can take into account
320 the statistics from previous passes; this fixes the problem mentioned
321 above.
322 </para>
323
324 <note><title>Note:</title>
325 <para>
326 Most codecs which support ABR encode only support two pass encode
327 while some others such as <systemitem class="library">x264</systemitem>,
328 <systemitem class="library">Xvid</systemitem>
329 and <systemitem class="library">libavcodec</systemitem> support
330 multipass, which slightly improves quality at each pass,
331 yet this improvement is no longer measurable nor noticeable after the
332 4th or so pass.
333 Therefore, in this section, two pass and multipass will be used
334 interchangeably.
335 </para>
336 </note>
337
338 <para>
339 In each of these modes, the video codec (such as
340 <systemitem class="library">libavcodec</systemitem>)
341 breaks the video frame into 16x16 pixel macroblocks and then applies a
342 quantizer to each macroblock. The lower the quantizer, the better the
343 quality and higher the bitrate.
344 The method the movie encoder uses to determine
345 which quantizer to use for a given macroblock varies and is highly
346 tunable. (This is an extreme over-simplification of the actual
347 process, but the basic concept is useful to understand.)
348 </para>
349
350 <para>
351 When you specify a constant bitrate, the video codec will encode the video,
352 discarding
353 detail as much as necessary and as little as possible in order to remain
354 lower than the given bitrate. If you truly do not care about file size,
355 you could as well use CBR and specify a bitrate of infinity. (In
356 practice, this means a value high enough so that it poses no limit, like
357 10000Kbit.) With no real restriction on bitrate, the result is that
358 the codec will use the lowest
359 possible quantizer for each macroblock (as specified by
360 <option>vqmin</option> for
361 <systemitem class="library">libavcodec</systemitem>, which is 2 by default).
362 As soon as you specify a
363 low enough bitrate that the codec
364 is forced to use a higher quantizer, then you are almost certainly ruining
365 the quality of your video.
366 In order to avoid that, you should probably downscale your video, according
367 to the method described later on in this guide.
368 In general, you should avoid CBR altogether if you care about quality.
369 </para>
370
371 <para>
372 With constant quantizer, the codec uses the same quantizer, as
373 specified by the <option>vqscale</option> option (for
374 <systemitem class="library">libavcodec</systemitem>), on every macroblock.
375 If you want the highest quality rip possible, again ignoring bitrate,
376 you can use <option>vqscale=2</option>.
377 This will yield the same bitrate and PSNR (peak signal-to-noise ratio)
378 as CBR with
379 <option>vbitrate</option>=infinity and the default <option>vqmin</option>
380 of 2.
381 </para>
382
383 <para>
384 The problem with constant quantizing is that it uses the given quantizer
385 whether the macroblock needs it or not. That is, it might be possible
386 to use a higher quantizer on a macroblock without sacrificing visual
387 quality. Why waste the bits on an unnecessarily low quantizer? Your
388 CPU has as many cycles as there is time, but there is only so many bits
389 on your hard disk.
390 </para>
391
392 <para>
393 With a two pass encode, the first pass will rip the movie as though it
394 were CBR, but it will keep a log of properties for each frame. This
395 data is then used during the second pass in order to make intelligent
396 decisions about which quantizers to use. During fast action or high
397 detail scenes, higher quantizers will likely be used, and during
398 slow moving or low detail scenes, lower quantizers will be used.
399 Normally, the amount of motion is much more important than the
400 amount of detail.
401 </para>
402
403 <para>
404 If you use <option>vqscale=2</option>, then you are wasting bits. If you
405 use <option>vqscale=3</option>, then you are not getting the highest
406 quality rip. Suppose you rip a DVD at <option>vqscale=3</option>, and
407 the result is 1800Kbit. If you do a two pass encode with
408 <option>vbitrate=1800</option>, the resulting video will have
409 <emphasis role="bold">higher quality</emphasis> for the
410 <emphasis role="bold">same bitrate</emphasis>.
411 </para>
412
413 <para>
414 Since you are now convinced that two pass is the way to go, the real
415 question now is what bitrate to use? The answer is that there is no
416 single answer. Ideally you want to choose a bitrate that yields the
417 best balance between quality and file size. This is going to vary
418 depending on the source video.
419 </para>
420
421 <para>
422 If size does not matter, a good starting point for a very high quality
423 rip is about 2000Kbit plus or minus 200Kbit.
424 For fast action or high detail source video, or if you just have a very
425 critical eye, you might decide on 2400 or 2600.
426 For some DVDs, you might not notice a difference at 1400Kbit. It is a
427 good idea to experiment with scenes at different bitrates to get a feel.
428 </para>
429
430 <para>
431 If you aim at a certain size, you will have to somehow calculate the bitrate.
432 But before that, you need to know how much space you should reserve for the
433 audio track(s), so you should
434 <link linkend="menc-feat-dvd-mpeg4-audio">rip those</link> first.
435 You can compute the bitrate with the following equation:
436 <systemitem>bitrate = (target_size_in_Mbytes - sound_size_in_Mbytes) *
437 1024 * 1024 / length_in_secs * 8 / 1000</systemitem>
438 For instance, to squeeze a two-hour movie onto a 702MB CD, with 60MB
439 of audio track, the video bitrate will have to be:
440 <systemitem>(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000
441 = 740kbps</systemitem>
442 </para>
443 </sect2>
444
445 <!-- ********** -->
446
447 <sect2 id="menc-feat-dvd-mpeg4-constraints">
448 <title>Constraints for efficient encoding</title>
449
450 <para>
451 Due to the nature of MPEG-type compression, there are various
452 constraints you should follow for maximal quality.
453 MPEG splits the video up into 16x16 squares called macroblocks,
454 each composed of 4 8x8 blocks of luma (intensity) information and two
455 half-resolution 8x8 chroma (color) blocks (one for red-cyan axis and
456 the other for the blue-yellow axis).
457 Even if your movie width and height are not multiples of 16, the
458 encoder will use enough 16x16 macroblocks to cover the whole picture
459 area, and the extra space will go to waste.
460 So in the interests of maximizing quality at a fixed file size, it is
461 a bad idea to use dimensions that are not multiples of 16.
462 </para>
463
464 <para>
465 Most DVDs also have some degree of black borders at the edges. Leaving
466 these in place will hurt quality <emphasis role="bold">a lot</emphasis>
467 in several ways.
468 </para>
469
470 <orderedlist>
471 <listitem>
472   <para>
473   MPEG-type compression is highly dependent on frequency domain
474   transformations, in particular the Discrete Cosine Transform (DCT),
475   which is similar to the Fourier transform. This sort of encoding is
476   efficient for representing patterns and smooth transitions, but it
477   has a hard time with sharp edges. In order to encode them it must
478   use many more bits, or else an artifact known as ringing will
479   appear.
480   </para>
481
482   <para>
483   The frequency transform (DCT) takes place separately on each
484   macroblock (actually each block), so this problem only applies when
485   the sharp edge is inside a block. If your black borders begin
486   exactly at multiple-of-16 pixel boundaries, this is not a problem.
487   However, the black borders on DVDs rarely come nicely aligned, so
488   in practice you will always need to crop to avoid this penalty.
489   </para>
490 </listitem>
491 </orderedlist>
492
493 <para>
494 In addition to frequency domain transforms, MPEG-type compression uses
495 motion vectors to represent the change from one frame to the next.
496 Motion vectors naturally work much less efficiently for new content
497 coming in from the edges of the picture, because it is not present in
498 the previous frame. As long as the picture extends all the way to the
499 edge of the encoded region, motion vectors have no problem with
500 content moving out the edges of the picture. However, in the presence
501 of black borders, there can be trouble:
502 </para>
503
504 <orderedlist continuation="continues">
505 <listitem>
506   <para>
507   For each macroblock, MPEG-type compression stores a vector
508   identifying which part of the previous frame should be copied into
509   this macroblock as a base for predicting the next frame. Only the
510   remaining differences need to be encoded. If a macroblock spans the
511   edge of the picture and contains part of the black border, then
512   motion vectors from other parts of the picture will overwrite the
513   black border. This means that lots of bits must be spent either
514   re-blackening the border that was overwritten, or (more likely) a
515   motion vector will not be used at all and all the changes in this
516   macroblock will have to be coded explicitly. Either way, encoding
517   efficiency is greatly reduced.
518   </para>
519
520   <para>
521   Again, this problem only applies if black borders do not line up on
522   multiple-of-16 boundaries.
523   </para>
524 </listitem>
525
526 <listitem>
527   <para>
528   Finally, suppose we have a macroblock in the interior of the
529   picture, and an object is moving into this block from near the edge
530   of the image. MPEG-type coding cannot say "copy the part that is
531   inside the picture but not the black border." So the black border
532   will get copied inside too, and lots of bits will have to be spent
533   encoding the part of the picture that is supposed to be there.
534   </para>
535
536   <para>
537   If the picture runs all the way to the edge of the encoded area,
538   MPEG has special optimizations to repeatedly copy the pixels at the
539   edge of the picture when a motion vector comes from outside the
540   encoded area. This feature becomes useless when the movie has black
541   borders. Unlike problems 1 and 2, aligning the borders at multiples
542   of 16 does not help here.
543   </para>
544 </listitem>
545
546 <listitem><para>
547   Despite the borders being entirely black and never changing, there
548   is at least a minimal amount of overhead involved in having more
549   macroblocks.
550 </para></listitem>
551 </orderedlist>
552
553 <para>
554 For all of these reasons, it is recommended to fully crop black
555 borders. Further, if there is an area of noise/distortion at the edge
556 of the picture, cropping this will improve encoding efficiency as
557 well. Videophile purists who want to preserve the original as close as
558 possible may object to this cropping, but unless you plan to encode at
559 constant quantizer, the quality you gain from cropping will
560 considerably exceed the amount of information lost at the edges.
561 </para>
562 </sect2>
563
564 <!-- ********** -->
565
566 <sect2 id="menc-feat-dvd-mpeg4-crop">
567 <title>Cropping and Scaling</title>
568
569 <para>
570 Recall from the previous section that the final picture size you
571 encode should be a multiple of 16 (in both width and height).
572 This can be achieved by cropping, scaling, or a combination of both.
573 </para>
574
575 <para>
576 When cropping, there are a few guidelines that must be followed to
577 avoid damaging your movie.
578 The normal YUV format, 4:2:0, stores chroma (color) information
579 subsampled, i.e. chroma is only sampled half as often in each
580 direction as luma (intensity) information.
581 Observe this diagram, where L indicates luma sampling points and C
582 chroma.
583 </para>
584
585 <informaltable>
586 <?dbhtml table-width="40%" ?>
587 <?dbfo table-width="40%" ?>
588 <tgroup cols="8" align="center">
589 <colspec colnum="1" colname="col1"/>
590 <colspec colnum="2" colname="col2"/>
591 <colspec colnum="3" colname="col3"/>
592 <colspec colnum="4" colname="col4"/>
593 <colspec colnum="5" colname="col5"/>
594 <colspec colnum="6" colname="col6"/>
595 <colspec colnum="7" colname="col7"/>
596 <colspec colnum="8" colname="col8"/>
597 <spanspec spanname="spa1-2" namest="col1" nameend="col2"/>
598 <spanspec spanname="spa3-4" namest="col3" nameend="col4"/>
599 <spanspec spanname="spa5-6" namest="col5" nameend="col6"/>
600 <spanspec spanname="spa7-8" namest="col7" nameend="col8"/>
601   <tbody>
602     <row>
603       <entry>L</entry>
604       <entry>L</entry>
605       <entry>L</entry>
606       <entry>L</entry>
607       <entry>L</entry>
608       <entry>L</entry>
609       <entry>L</entry>
610       <entry>L</entry>
611     </row>
612     <row>
613       <entry spanname="spa1-2">C</entry>
614       <entry spanname="spa3-4">C</entry>
615       <entry spanname="spa5-6">C</entry>
616       <entry spanname="spa7-8">C</entry>
617     </row>
618     <row>
619       <entry>L</entry>
620       <entry>L</entry>
621       <entry>L</entry>
622       <entry>L</entry>
623       <entry>L</entry>
624       <entry>L</entry>
625       <entry>L</entry>
626       <entry>L</entry>
627     </row>
628     <row>
629       <entry>L</entry>
630       <entry>L</entry>
631       <entry>L</entry>
632       <entry>L</entry>
633       <entry>L</entry>
634       <entry>L</entry>
635       <entry>L</entry>
636       <entry>L</entry>
637     </row>
638     <row>
639       <entry spanname="spa1-2">C</entry>
640       <entry spanname="spa3-4">C</entry>
641       <entry spanname="spa5-6">C</entry>
642       <entry spanname="spa7-8">C</entry>
643     </row>
644     <row>
645       <entry>L</entry>
646       <entry>L</entry>
647       <entry>L</entry>
648       <entry>L</entry>
649       <entry>L</entry>
650       <entry>L</entry>
651       <entry>L</entry>
652       <entry>L</entry>
653     </row>
654   </tbody>
655 </tgroup>
656 </informaltable>
657
658 <para>
659 As you can see, rows and columns of the image naturally come in pairs.
660 Thus your crop offsets and dimensions <emphasis>must</emphasis> be
661 even numbers.
662 If they are not, the chroma will no longer line up correctly with the
663 luma.
664 In theory, it is possible to crop with odd offsets, but it requires
665 resampling the chroma which is potentially a lossy operation and not
666 supported by the crop filter.
667 </para>
668
669 <para>
670 Further, interlaced video is sampled as follows:
671 </para>
672
673 <informaltable>
674 <?dbhtml table-width="80%" ?>
675 <?dbfo table-width="80%" ?>
676 <tgroup cols="16" align="center">
677 <colspec colnum="1"  colname="col1"/>
678 <colspec colnum="2"  colname="col2"/>
679 <colspec colnum="3"  colname="col3"/>
680 <colspec colnum="4"  colname="col4"/>
681 <colspec colnum="5"  colname="col5"/>
682 <colspec colnum="6"  colname="col6"/>
683 <colspec colnum="7"  colname="col7"/>
684 <colspec colnum="8"  colname="col8"/>
685 <colspec colnum="9"  colname="col9"/>
686 <colspec colnum="10" colname="col10"/>
687 <colspec colnum="11" colname="col11"/>
688 <colspec colnum="12" colname="col12"/>
689 <colspec colnum="13" colname="col13"/>
690 <colspec colnum="14" colname="col14"/>
691 <colspec colnum="15" colname="col15"/>
692 <colspec colnum="16" colname="col16"/>
693 <spanspec spanname="spa1-2"   namest="col1" nameend="col2"/>
694 <spanspec spanname="spa3-4"   namest="col3" nameend="col4"/>
695 <spanspec spanname="spa5-6"   namest="col5" nameend="col6"/>
696 <spanspec spanname="spa7-8"   namest="col7" nameend="col8"/>
697 <spanspec spanname="spa9-10"  namest="col9" nameend="col10"/>
698 <spanspec spanname="spa11-12" namest="col11" nameend="col12"/>
699 <spanspec spanname="spa13-14" namest="col13" nameend="col14"/>
700 <spanspec spanname="spa15-16" namest="col15" nameend="col16"/>
701   <tbody>
702     <row>
703       <entry namest="col1" nameend="col8">Top field</entry>
704       <entry namest="col9" nameend="col16">Bottom field</entry>
705     </row>
706     <row>
707       <entry>L</entry>
708       <entry>L</entry>
709       <entry>L</entry>
710       <entry>L</entry>
711       <entry>L</entry>
712       <entry>L</entry>
713       <entry>L</entry>
714       <entry>L</entry>
715       <entry></entry>
716       <entry></entry>
717       <entry></entry>
718       <entry></entry>
719       <entry></entry>
720       <entry></entry>
721       <entry></entry>
722       <entry></entry>
723     </row>
724     <row>
725       <entry spanname="spa1-2">C</entry>
726       <entry spanname="spa3-4">C</entry>
727       <entry spanname="spa5-6">C</entry>
728       <entry spanname="spa7-8">C</entry>
729       <entry></entry>
730       <entry></entry>
731       <entry></entry>
732       <entry></entry>
733       <entry></entry>
734       <entry></entry>
735       <entry></entry>
736       <entry></entry>
737     </row>
738     <row>
739       <entry></entry>
740       <entry></entry>
741       <entry></entry>
742       <entry></entry>
743       <entry></entry>
744       <entry></entry>
745       <entry></entry>
746       <entry></entry>
747       <entry>L</entry>
748       <entry>L</entry>
749       <entry>L</entry>
750       <entry>L</entry>
751       <entry>L</entry>
752       <entry>L</entry>
753       <entry>L</entry>
754       <entry>L</entry>
755     </row>
756     <row>
757       <entry>L</entry>
758       <entry>L</entry>
759       <entry>L</entry>
760       <entry>L</entry>
761       <entry>L</entry>
762       <entry>L</entry>
763       <entry>L</entry>
764       <entry>L</entry>
765       <entry></entry>
766       <entry></entry>
767       <entry></entry>
768       <entry></entry>
769       <entry></entry>
770       <entry></entry>
771       <entry></entry>
772       <entry></entry>
773     </row>
774     <row>
775       <entry></entry>
776       <entry></entry>
777       <entry></entry>
778       <entry></entry>
779       <entry></entry>
780       <entry></entry>
781       <entry></entry>
782       <entry></entry>
783       <entry spanname="spa9-10">C</entry>
784       <entry spanname="spa11-12">C</entry>
785       <entry spanname="spa13-14">C</entry>
786       <entry spanname="spa15-16">C</entry>
787     </row>
788     <row>
789       <entry></entry>
790       <entry></entry>
791       <entry></entry>
792       <entry></entry>
793       <entry></entry>
794       <entry></entry>
795       <entry></entry>
796       <entry></entry>
797       <entry>L</entry>
798       <entry>L</entry>
799       <entry>L</entry>
800       <entry>L</entry>
801       <entry>L</entry>
802       <entry>L</entry>
803       <entry>L</entry>
804       <entry>L</entry>
805     </row>
806     <row>
807       <entry>L</entry>
808       <entry>L</entry>
809       <entry>L</entry>
810       <entry>L</entry>
811       <entry>L</entry>
812       <entry>L</entry>
813       <entry>L</entry>
814       <entry>L</entry>
815       <entry></entry>
816       <entry></entry>
817       <entry></entry>
818       <entry></entry>
819       <entry></entry>
820       <entry></entry>
821       <entry></entry>
822       <entry></entry>
823     </row>
824     <row>
825       <entry spanname="spa1-2">C</entry>
826       <entry spanname="spa3-4">C</entry>
827       <entry spanname="spa5-6">C</entry>
828       <entry spanname="spa7-8">C</entry>
829       <entry></entry>
830       <entry></entry>
831       <entry></entry>
832       <entry></entry>
833       <entry></entry>
834       <entry></entry>
835       <entry></entry>
836       <entry></entry>
837     </row>
838     <row>
839       <entry></entry>
840       <entry></entry>
841       <entry></entry>
842       <entry></entry>
843       <entry></entry>
844       <entry></entry>
845       <entry></entry>
846       <entry></entry>
847       <entry>L</entry>
848       <entry>L</entry>
849       <entry>L</entry>
850       <entry>L</entry>
851       <entry>L</entry>
852       <entry>L</entry>
853       <entry>L</entry>
854       <entry>L</entry>
855     </row>
856     <row>
857       <entry>L</entry>
858       <entry>L</entry>
859       <entry>L</entry>
860       <entry>L</entry>
861       <entry>L</entry>
862       <entry>L</entry>
863       <entry>L</entry>
864       <entry>L</entry>
865       <entry></entry>
866       <entry></entry>
867       <entry></entry>
868       <entry></entry>
869       <entry></entry>
870       <entry></entry>
871       <entry></entry>
872       <entry></entry>
873     </row>
874     <row>
875       <entry></entry>
876       <entry></entry>
877       <entry></entry>
878       <entry></entry>
879       <entry></entry>
880       <entry></entry>
881       <entry></entry>
882       <entry></entry>
883       <entry spanname="spa9-10">C</entry>
884       <entry spanname="spa11-12">C</entry>
885       <entry spanname="spa13-14">C</entry>
886       <entry spanname="spa15-16">C</entry>
887     </row>
888     <row>
889       <entry></entry>
890       <entry></entry>
891       <entry></entry>
892       <entry></entry>
893       <entry></entry>
894       <entry></entry>
895       <entry></entry>
896       <entry></entry>
897       <entry>L</entry>
898       <entry>L</entry>
899       <entry>L</entry>
900       <entry>L</entry>
901       <entry>L</entry>
902       <entry>L</entry>
903       <entry>L</entry>
904       <entry>L</entry>
905     </row>
906   </tbody>
907 </tgroup>
908 </informaltable>
909
910 <para>
911 As you can see, the pattern does not repeat until after 4 lines.
912 So for interlaced video, your y-offset and height for cropping must
913 be multiples of 4.
914 </para>
915
916 <para>
917 Native DVD resolution is 720x480 for NTSC, and 720x576 for PAL, but
918 there is an aspect flag that specifies whether it is full-screen (4:3) or
919 wide-screen (16:9). Many (if not most) widescreen DVDs are not strictly
920 16:9, and will be either 1.85:1 or 2.35:1 (cinescope). This means that
921 there will be black bands in the video that will need to be cropped out.
922 </para>
923
924 <para>
925 <application>MPlayer</application> provides a crop detection filter that
926 will determine the crop rectangle (<option>-vf cropdetect</option>).
927 Run <application>MPlayer</application> with
928 <option>-vf cropdetect</option> and it will print out the crop
929 settings to remove the borders.
930 You should let the movie run long enough that the whole picture
931 area is used, in order to get accurate crop values.
932 </para>
933
934 <para>
935 Then, test the values you get with <application>MPlayer</application>,
936 using the command line which was printed by
937 <option>cropdetect</option>, and adjust the rectangle as needed.
938 The <option>rectangle</option> filter can help by allowing you to
939 interactively position the crop rectangle over your movie.
940 Remember to follow the above divisibility guidelines so that you
941 do not misalign the chroma planes.
942 </para>
943
944 <para>
945 In certain cases, scaling may be undesirable.
946 Scaling in the vertical direction is difficult with interlaced
947 video, and if you wish to preserve the interlacing, you should
948 usually refrain from scaling.
949 If you will not be scaling but you still want to use multiple-of-16
950 dimensions, you will have to overcrop.
951 Do not undercrop, since black borders are very bad for encoding!
952 </para>
953
954 <para>
955 Because MPEG-4 uses 16x16 macroblocks, you will want to make sure that each
956 dimension of the video you are encoding is a multiple of 16 or else you
957 will be degrading quality, especially at lower bitrates. You can do this
958 by rounding the width and height of the crop rectangle down to the nearest
959 multiple of 16.
960 As stated earlier, when cropping, you will want to increase the Y offset by
961 half the difference of the old and the new height so that the resulting
962 video is taken from the center of the frame. And because of the way DVD
963 video is sampled, make sure the offset is an even number. (In fact, as a
964 rule, never use odd values for any parameter when you are cropping and
965 scaling video.) If you are not comfortable throwing a few extra pixels
966 away, you might prefer to scale the video instead. We will look
967 at this in our example below.
968 You can actually let the <option>cropdetect</option> filter do all of the
969 above for you, as it has an optional <option>round</option> parameter that
970 is equal to 16 by default.
971 </para>
972
973 <para>
974 Also, be careful about "half black" pixels at the edges. Make sure you
975 crop these out too, or else you will be wasting bits there that
976 are better spent elsewhere.
977 </para>
978
979 <para>
980 After all is said and done, you will probably end up with video whose pixels
981 are not quite 1.85:1 or 2.35:1, but rather something close to that. You
982 could calculate the new aspect ratio manually, but
983 <application>MEncoder</application> offers an option for <systemitem
984 class="library">libavcodec</systemitem> called <option>autoaspect</option>
985 that will do this for you. Absolutely do not scale this video up in order to
986 square the pixels unless you like to waste your hard disk space. Scaling
987 should be done on playback, and the player will use the aspect stored in
988 the AVI to determine the correct resolution.
989 Unfortunately, not all players enforce this auto-scaling information,
990 therefore you may still want to rescale.
991 </para>
992 </sect2>
993
994 <!-- ********** -->
995
996 <sect2 id="menc-feat-dvd-mpeg4-resolution-bitrate">
997 <title>Choosing resolution and bitrate</title>
998
999 <para>
1000 If you will not be encoding in constant quantizer mode, you need to
1001 select a bitrate.
1002 The concept of bitrate is quite simple.
1003 It is the (average) number of bits that will be consumed to store your
1004 movie, per second.
1005 Normally bitrate is measured in kilobits (1000 bits) per second.
1006 The size of your movie on disk is the bitrate times the length of the
1007 movie in time, plus a small amount of "overhead" (see the section on
1008 <link linkend="menc-feat-dvd-mpeg4-muxing-avi-limitations">the AVI container</link>
1009 for instance).
1010 Other parameters such as scaling, cropping, etc. will
1011 <emphasis role="bold">not</emphasis> alter the file size unless you
1012 change the bitrate as well!
1013 </para>
1014
1015 <para>
1016 Bitrate does <emphasis role="bold">not</emphasis> scale proportionally
1017 to resolution.
1018 That is to say, a 320x240 file at 200 kbit/sec will not be the same
1019 quality as the same movie at 640x480 and 800 kbit/sec!
1020 There are two reasons for this:
1021 <orderedlist>
1022 <listitem><para>
1023   <emphasis role="bold">Perceptual</emphasis>: You notice MPEG
1024   artifacts more if they are scaled up bigger!
1025   Artifacts appear on the scale of blocks (8x8).
1026   Your eye will not see errors in 4800 small blocks as easily as it
1027   sees errors in 1200 large blocks (assuming you will be scaling both
1028   to fullscreen).
1029 </para></listitem>
1030 <listitem><para>
1031   <emphasis role="bold">Theoretical</emphasis>: When you scale down
1032   an image but still use the same size (8x8) blocks for the frequency
1033   space transform, you move more data to the high frequency bands.
1034   Roughly speaking, each pixel contains more of the detail than it
1035   did before.
1036   So even though your scaled-down picture contains 1/4 the information
1037   in the spacial directions, it could still contain a large portion
1038   of the information in the frequency domain (assuming that the high
1039   frequencies were underutilized in the original 640x480 image).
1040 </para></listitem>
1041 </orderedlist>
1042 </para>
1043
1044 <para>
1045 Past guides have recommended choosing a bitrate and resolution based
1046 on a "bits per pixel" approach, but this is usually not valid due to
1047 the above reasons.
1048 A better estimate seems to be that bitrates scale proportional to the
1049 square root of resolution, so that 320x240 and 400 kbit/sec would be
1050 comparable to 640x480 at 800 kbit/sec.
1051 However this has not been verified with theoretical or empirical
1052 rigor.
1053 Further, given that movies vary greatly with regard to noise, detail,
1054 degree of motion, etc., it is futile to make general recommendations
1055 for bits per length-of-diagonal (the analog of bits per pixel,
1056 using the square root).
1057 </para>
1058 <para>
1059 So far we have discussed the difficulty of choosing a bitrate and
1060 resolution.
1061 </para>
1062
1063
1064 <sect3 id="menc-feat-dvd-mpeg4-resolution-bitrate-compute">
1065 <title>Computing the resolution</title>
1066
1067 <para>
1068 The following steps will guide you in computing the resolution of your
1069 encode without distorting the video too much, by taking into account several
1070 types of information about the source video.
1071 First, you should compute the encoded aspect ratio:
1072 <systemitem>ARc = (Wc x (ARa / PRdvd )) / Hc</systemitem>
1073
1074 <itemizedlist>
1075 <title>where:</title>
1076 <listitem><para>
1077   Wc and Hc are the width and height of the cropped video,
1078 </para></listitem>
1079 <listitem><para>
1080   ARa is the displayed aspect ratio, which usually is 4/3 or 16/9,
1081 </para></listitem>
1082 <listitem><para>
1083   PRdvd is the pixel ratio of the DVD which is equal to 1.25=(720/576) for PAL
1084   DVDs and 1.5=(720/480) for NTSC DVDs.
1085 </para></listitem>
1086 </itemizedlist>
1087 </para>
1088
1089 <para>
1090 Then, you can compute the X and Y resolution, according to a certain
1091 Compression Quality (CQ) factor:
1092 <systemitem>ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16</systemitem>
1093 and
1094 <systemitem>ResX = INT( ResY * ARc / 16) * 16</systemitem>
1095 </para>
1096
1097 <para>
1098 Okay, but what is the CQ?
1099 The CQ represents the number of bits per pixel and per frame of the encode.
1100 Roughly speaking, the greater the CQ, the less the likelihood to see
1101 encoding artifacts.
1102 However, if you have a target size for your movie (1 or 2 CDs for instance),
1103 there is a limited total number of bits that you can spend; therefore it is
1104 necessary to find a good tradeoff between compressibility and quality.
1105 </para>
1106
1107 <para>
1108 The CQ depends on the bitrate, the video codec efficiency and the
1109 movie resolution.
1110 In order to raise the CQ, typically you would downscale the movie given that the
1111 bitrate is computed in function of the target size and the length of the
1112 movie, which are constant.
1113 With MPEG-4 ASP codecs such as <systemitem class="library">Xvid</systemitem>
1114 and <systemitem class="library">libavcodec</systemitem>, a CQ below 0.18
1115 usually results in a pretty blocky picture, because there
1116 are not enough bits to code the information of each macroblock. (MPEG4, like
1117 many other codecs, groups pixels by blocks of several pixels to compress the
1118 image; if there are not enough bits, the edges of those blocks are
1119 visible.)
1120 It is therefore wise to take a CQ ranging from 0.20 to 0.22 for a 1 CD rip,
1121 and 0.26-0.28 for 2 CDs rip with standard encoding options.
1122 More advanced encoding options such as those listed here for
1123 <link linkend="menc-feat-mpeg4-lavc-example-settings"><systemitem class="library">libavcodec</systemitem></link>
1124 and
1125 <link linkend="menc-feat-xvid-example-settings"><systemitem class="library">Xvid</systemitem></link>
1126 should make it possible to get the same quality with CQ ranging from
1127 0.18 to 0.20 for a 1 CD rip, and 0.24 to 0.26 for a 2 CD rip.
1128 With MPEG-4 AVC codecs such as <systemitem class="library">x264</systemitem>,
1129 you can use a CQ ranging from 0.14 to 0.16 with standard encoding options,
1130 and should be able to go as low as 0.10 to 0.12 with
1131 <link linkend="menc-feat-x264-example-settings"><systemitem class="library">x264</systemitem>'s advanced encoding settings</link>.
1132 </para>
1133
1134 <para>
1135 Please take note that the CQ is just an indicative figure, as depending on
1136 the encoded content, a CQ of 0.18 may look just fine for a Bergman, contrary
1137 to a movie such as The Matrix, which contains many high-motion scenes.
1138 On the other hand, it is worthless to raise CQ higher than 0.30 as you would
1139 be wasting bits without any noticeable quality gain.
1140 Also note that as mentioned earlier in this guide, low resolution videos
1141 need a bigger CQ (compared to, for instance, DVD resolution) to look good.
1142 </para>
1143 </sect3>
1144 </sect2>
1145
1146 <!-- ********** -->
1147
1148 <sect2 id="menc-feat-dvd-mpeg4-filtering">
1149 <title>Filtering</title>
1150
1151 <para>
1152 Learning how to use <application>MEncoder</application>'s video filters
1153 is essential to producing good encodes.
1154 All video processing is performed through the filters -- cropping,
1155 scaling, color adjustment, noise removal, sharpening, deinterlacing,
1156 telecine, inverse telecine, and deblocking, just to name a few.
1157 Along with the vast number of supported input formats, the variety of
1158 filters available in <application>MEncoder</application> is one of its
1159 main advantages over other similar programs.
1160 </para>
1161
1162 <para>
1163 Filters are loaded in a chain using the -vf option:
1164
1165 <screen>-vf filter1=options,filter2=options,...</screen>
1166
1167 Most filters take several numeric options separated by colons, but
1168 the syntax for options varies from filter to filter, so read the man
1169 page for details on the filters you wish to use.
1170 </para>
1171
1172 <para>
1173 Filters operate on the video in the order they are loaded.
1174 For example, the following chain:
1175
1176 <screen>-vf crop=688:464:12:4,scale=640:464</screen>
1177
1178 will first crop the 688x464 region of the picture with upper-left
1179 corner at (12,4), and then scale the result down to 640x464.
1180 </para>
1181
1182 <para>
1183 Certain filters need to be loaded at or near the beginning of the
1184 filter chain, in order to take advantage of information from the
1185 video decoder that will be lost or invalidated by other filters.
1186 The principal examples are <option>pp</option> (postprocessing, only
1187 when it is performing deblock or dering operations),
1188 <option>spp</option> (another postprocessor to remove MPEG artifacts),
1189 <option>pullup</option> (inverse telecine), and
1190 <option>softpulldown</option> (for converting soft telecine to hard telecine).
1191 </para>
1192
1193 <para>
1194 In general, you want to do as little filtering as possible to the movie
1195 in order to remain close to the original DVD source. Cropping is often
1196 necessary (as described above), but avoid to scale the video. Although
1197 scaling down is sometimes preferred to using higher quantizers, we want
1198 to avoid both these things: remember that we decided from the start to
1199 trade bits for quality.
1200 </para>
1201
1202 <para>
1203 Also, do not adjust gamma, contrast, brightness, etc. What looks good
1204 on your display may not look good on others. These adjustments should
1205 be done on playback only.
1206 </para>
1207
1208 <para>
1209 One thing you might want to do, however, is pass the video through a
1210 very light denoise filter, such as <option>-vf hqdn3d=2:1:2</option>.
1211 Again, it is a matter of putting those bits to better use: why waste them
1212 encoding noise when you can just add that noise back in during playback?
1213 Increasing the parameters for <option>hqdn3d</option> will further
1214 improve compressibility, but if you increase the values too much, you
1215 risk degrading the image visibly. The suggested values above
1216 (<option>2:1:2</option>) are quite conservative; you should feel free to
1217 experiment with higher values and observe the results for yourself.
1218 </para>
1219 </sect2>
1220
1221 <!-- ********** -->
1222
1223 <sect2 id="menc-feat-dvd-mpeg4-interlacing">
1224 <title>Interlacing and Telecine</title>
1225
1226 <para>
1227 Almost all movies are shot at 24 fps. Because NTSC is 30000/1001 fps, some
1228 processing must be done to this 24 fps video to make it run at the correct
1229 NTSC framerate. The process is called 3:2 pulldown, commonly referred to
1230 as telecine (because pulldown is often applied during the telecine
1231 process), and, naively described, it works by slowing the film down to
1232 24000/1001 fps, and repeating every fourth frame.
1233 </para>
1234
1235 <para>
1236 No special processing, however, is done to the video for PAL DVDs, which
1237 run at 25 fps. (Technically, PAL can be telecined, called 2:2 pulldown,
1238 but this does not become an issue in practice.) The 24 fps film is simply
1239 played back at 25 fps. The result is that the movie runs slightly faster,
1240 but unless you are an alien, you probably will not notice the difference.
1241 Most PAL DVDs have pitch-corrected audio, so when they are played back at
1242 25 fps things will sound right, even though the audio track (and hence the
1243 whole movie) has a running time that is 4% less than NTSC DVDs.
1244 </para>
1245
1246 <para>
1247 Because the video in a PAL DVD has not been altered, you need not worry
1248 much about framerate. The source is 25 fps, and your rip will be 25
1249 fps. However, if you are ripping an NTSC DVD movie, you may need to
1250 apply inverse telecine.
1251 </para>
1252
1253 <para>
1254 For movies shot at 24 fps, the video on the NTSC DVD is either telecined
1255 30000/1001, or else it is progressive 24000/1001 fps and intended to be
1256 telecined on-the-fly by a DVD player. On the other hand, TV series are usually
1257 only interlaced, not telecined. This is not a hard rule: some TV series
1258 are interlaced (such as Buffy the Vampire Slayer) whereas some are a
1259 mixture of progressive and interlaced (such as Angel, or 24).
1260 </para>
1261
1262 <para>
1263 It is highly recommended that you read the section on
1264 <link linkend="menc-feat-telecine">How to deal with telecine and interlacing in NTSC DVDs</link>
1265 to learn how to handle the different possibilities.
1266 </para>
1267
1268 <para>
1269 However, if you are mostly just ripping movies, likely you are either
1270 dealing with 24 fps progressive or telecined video, in which case you can
1271 use the <option>pullup</option> filter <option>-vf
1272 pullup,softskip</option>.
1273 </para>
1274 </sect2>
1275
1276 <!-- ********** -->
1277
1278 <sect2 id="menc-feat-dvd-mpeg4-encoding-interlaced">
1279 <title>Encoding interlaced video</title>
1280
1281 <para>
1282 If the movie you want to encode is interlaced (NTSC video or
1283 PAL video), you will need to choose whether you want to
1284 deinterlace or not.
1285 While deinterlacing will make your movie usable on progressive
1286 scan displays such a computer monitors and projectors, it comes
1287 at a cost: The fieldrate of 50 or 60000/1001 fields per second
1288 is halved to 25 or 30000/1001 frames per second, and roughly half of
1289 the information in your movie will be lost during scenes with
1290 significant motion.
1291 </para>
1292
1293 <para>
1294 Therefore, if you are encoding for high quality archival purposes,
1295 it is recommended not to deinterlace.
1296 You can always deinterlace the movie at playback time when
1297 displaying it on progressive scan devices.
1298 The power of currently available computers forces players to use a
1299 deinterlacing filter, which results in a slight degradation in
1300 image quality.
1301 But future players will be able to mimic the interlaced display of
1302 a TV, deinterlacing to full fieldrate and interpolating 50 or
1303 60000/1001 entire frames per second from the interlaced video.
1304 </para>
1305
1306 <para>
1307 Special care must be taken when working with interlaced video:
1308 </para>
1309
1310 <orderedlist>
1311 <listitem><para>
1312   Crop height and y-offset must be multiples of 4.
1313 </para></listitem>
1314 <listitem><para>
1315   Any vertical scaling must be performed in interlaced mode.
1316 </para></listitem>
1317 <listitem><para>
1318   Postprocessing and denoising filters may not work as expected
1319   unless you take special care to operate them a field at a time,
1320   and they may damage the video if used incorrectly.
1321 </para></listitem>
1322 </orderedlist>
1323
1324 <para>
1325 With these things in mind, here is our first example:
1326 <screen>
1327 mencoder <replaceable>capture.avi</replaceable> -mc 0 -oac lavc -ovc lavc -lavcopts \
1328     vcodec=mpeg2video:vbitrate=6000:ilme:ildct:acodec=mp2:abitrate=224
1329 </screen>
1330 Note the <option>ilme</option> and <option>ildct</option> options.
1331 </para>
1332 </sect2>
1333
1334 <!-- ********** -->
1335
1336 <sect2 id="menc-feat-dvd-mpeg4-av-sync">
1337 <title>Notes on Audio/Video synchronization</title>
1338
1339 <para>
1340 <application>MEncoder</application>'s audio/video synchronization
1341 algorithms were designed with the intention of recovering files with
1342 broken sync.
1343 However, in some cases they can cause unnecessary skipping and duplication of
1344 frames, and possibly slight A/V desync, when used with proper input
1345 (of course, A/V sync issues apply only if you process or copy the
1346 audio track while transcoding the video, which is strongly encouraged).
1347 Therefore, you may have to switch to basic A/V sync with
1348 the <option>-mc 0</option> option, or put this in your
1349 <systemitem>~/.mplayer/mencoder</systemitem> config file, as long as
1350 you are only working with good sources (DVD, TV capture, high quality
1351 MPEG-4 rips, etc) and not broken ASF/RM/MOV files.
1352 </para>
1353
1354 <para>
1355 If you want to further guard against strange frame skips and
1356 duplication, you can use both <option>-mc 0</option> and
1357 <option>-noskip</option>.
1358 This will prevent <emphasis>all</emphasis> A/V sync, and copy frames
1359 one-to-one, so you cannot use it if you will be using any filters that
1360 unpredictably add or drop frames, or if your input file has variable
1361 framerate!
1362 Therefore, using <option>-noskip</option> is not in general recommended.
1363 </para>
1364
1365 <para>
1366 The so-called "three-pass" audio encoding which
1367 <application>MEncoder</application> supports has been reported to cause A/V
1368 desync.
1369 This will definitely happen if it is used in conjunction with certain
1370 filters, therefore, it is now recommended <emphasis>not</emphasis> to
1371 use three-pass audio mode.
1372 This feature is only left for compatibility purposes and for expert
1373 users who understand when it is safe to use and when it is not.
1374 If you have never heard of three-pass mode before, forget that we
1375 even mentioned it!
1376 </para>
1377
1378 <para>
1379 There have also been reports of A/V desync when encoding from stdin
1380 with <application>MEncoder</application>.
1381 Do not do this! Always use a file or CD/DVD/etc device as input.
1382 </para>
1383 </sect2>
1384
1385 <!-- ********** -->
1386
1387 <sect2 id="menc-feat-dvd-mpeg4-codec">
1388 <title>Choosing the video codec</title>
1389
1390 <para>
1391 Which video codec is best to choose depends on several factors,
1392 like size, quality, streamability, usability and popularity, some of
1393 which widely depend on personal taste and technical constraints.
1394 </para>
1395 <itemizedlist>
1396 <listitem>
1397   <para>
1398   <emphasis role="bold">Compression efficiency</emphasis>:
1399   It is quite easy to understand that most newer-generation codecs are
1400   made to increase quality and compression.
1401   Therefore, the authors of this guide and many other people suggest that
1402   you cannot go wrong
1403   <footnote id='fn-menc-feat-dvd-mpeg4-codec-cpu'><para>
1404   Be careful, however: Decoding DVD-resolution MPEG-4 AVC videos
1405   requires a fast machine (i.e. a Pentium 4 over 1.5GHz or a Pentium M
1406   over 1GHz).
1407   </para></footnote>
1408   when choosing MPEG-4 AVC codecs like
1409   <systemitem class="library">x264</systemitem> instead of MPEG-4 ASP codecs
1410   such as <systemitem class="library">libavcodec</systemitem> MPEG-4 or
1411   <systemitem class="library">Xvid</systemitem>.
1412   (Advanced codec developers may be interested in reading Michael
1413   Niedermayer's opinion on
1414   "<ulink url="http://guru.multimedia.cx/?p=10">why MPEG4-ASP sucks</ulink>".)
1415   Likewise, you should get better quality using MPEG-4 ASP than you
1416   would with MPEG-2 codecs.
1417   </para>
1418
1419   <para>
1420   However, newer codecs which are in heavy development can suffer from
1421   bugs which have not yet been noticed and which can ruin an encode.
1422   This is simply the tradeoff for using bleeding-edge technology.
1423   </para>
1424
1425   <para>
1426   What is more, beginning to use a new codec requires that you spend some
1427   time becoming familiar with its options, so that you know what
1428   to adjust to achieve a desired picture quality.
1429   </para>
1430 </listitem>
1431
1432 <listitem><para>
1433   <emphasis role="bold">Hardware compatibility</emphasis>:
1434   It usually takes a long time for standalone video players to begin to
1435   include support for the latest video codecs.
1436   As a result, most only support MPEG-1 (like VCD, XVCD and KVCD), MPEG-2
1437   (like DVD, SVCD and KVCD) and MPEG-4 ASP (like DivX,
1438   <systemitem class="library">libavcodec</systemitem>'s LMP4 and
1439   <systemitem class="library">Xvid</systemitem>)
1440   (Beware: Usually, not all MPEG-4 ASP features are supported).
1441   Please refer to the technical specs of your player (if they are available),
1442   or google around for more information.
1443 </para></listitem>
1444
1445 <listitem>
1446   <para>
1447   <emphasis role="bold">Best quality per encoding time</emphasis>:
1448   Codecs that have been around for some time (such as
1449   <systemitem class="library">libavcodec</systemitem> MPEG-4 and
1450   <systemitem class="library">Xvid</systemitem>) are usually heavily
1451   optimized with all kinds of smart algorithms and SIMD assembly code.
1452   That is why they tend to yield the best quality per encoding time ratio.
1453   However, they may have some very advanced options that, if enabled,
1454   will make the encode really slow for marginal gains.
1455   </para>
1456
1457   <para>
1458   If you are after blazing speed you should stick around the default
1459   settings of the video codec (although you should still try the other
1460   options which are mentioned in other sections of this guide).
1461   </para>
1462
1463   <para>
1464   You may also consider choosing a codec which can do multi-threaded
1465   processing, though this is only useful for users of machines with
1466   several CPUs.
1467   <systemitem class="library">libavcodec</systemitem> MPEG-4 does
1468   allow that, but speed gains are limited, and there is a slight
1469   negative effect on picture quality.
1470   <systemitem class="library">Xvid</systemitem>'s multi-threaded encoding,
1471   activated by the <option>threads</option> option, can be used to
1472   boost encoding speed &mdash; by about 40-60% in typical cases &mdash;
1473   with little if any picture degradation.
1474   <systemitem class="library">x264</systemitem> also allows multi-threaded
1475   encoding, which currently speeds up encoding by 94% per CPU core while
1476   lowering PSNR between 0.005dB and 0.01dB on a typical setup.
1477   </para>
1478 </listitem>
1479
1480 <listitem>
1481   <para>
1482   <emphasis role="bold">Personal taste</emphasis>:
1483   This is where it gets almost irrational: For the same reason that some
1484   hung on to DivX&nbsp;3 for years when newer codecs were already doing wonders,
1485   some folks will prefer <systemitem class="library">Xvid</systemitem>
1486   or <systemitem class="library">libavcodec</systemitem> MPEG-4 over
1487   <systemitem class="library">x264</systemitem>.
1488   </para>
1489   <para>
1490   You should make your own judgement; do not take advice from people who
1491   swear by one codec.
1492   Take a few sample clips from raw sources and compare different
1493   encoding options and codecs to find one that suits you best.
1494   The best codec is the one you master, and the one that looks
1495   best to your eyes on your display
1496   <footnote id='fn-menc-feat-dvd-mpeg4-codec-playback'><para>
1497   The same encode may not look the same on someone else's monitor or
1498   when played back by a different decoder, so future-proof your encodes by
1499   playing them back on different setups.
1500   </para></footnote>!
1501   </para>
1502 </listitem>
1503 </itemizedlist>
1504
1505 <para>
1506 Please refer to the section
1507 <link linkend="menc-feat-selecting-codec">selecting codecs and container formats</link>
1508 to get a list of supported codecs.
1509 </para>
1510 </sect2>
1511
1512 <!-- ********** -->
1513
1514 <sect2 id="menc-feat-dvd-mpeg4-audio">
1515 <title>Audio</title>
1516
1517 <para>
1518 Audio is a much simpler problem to solve: if you care about quality, just
1519 leave it as is.
1520 Even AC-3 5.1 streams are at most 448Kbit/s, and they are worth every bit.
1521 You might be tempted to transcode the audio to high quality Vorbis, but
1522 just because you do not have an A/V receiver for AC-3 pass-through today
1523 does not mean you will not have one tomorrow. Future-proof your DVD rips by
1524 preserving the AC-3 stream.
1525 You can keep the AC-3 stream either by copying it directly into the video
1526 stream <link linkend="menc-feat-mpeg4">during the encoding</link>.
1527 You can also extract the AC-3 stream in order to mux it into containers such
1528 as NUT or Matroska.
1529 <screen>
1530 mplayer <replaceable>source_file.vob</replaceable> -aid 129 -dumpaudio -dumpfile <replaceable>sound.ac3</replaceable>
1531 </screen>
1532 will dump into the file <replaceable>sound.ac3</replaceable> the
1533 audio track number 129 from the file
1534 <replaceable>source_file.vob</replaceable> (NB: DVD VOB files
1535 usually use a different audio numbering,
1536 which means that the VOB audio track 129 is the 2nd audio track of the file).
1537 </para>
1538
1539 <para>
1540 But sometimes you truly have no choice but to further compress the
1541 sound so that more bits can be spent on the video.
1542 Most people choose to compress audio with either MP3 or Vorbis audio codecs.
1543 While the latter is a very space-efficient codec, MP3 is better supported
1544 by hardware players, although this trend is changing.
1545 </para>
1546
1547 <para>
1548 Do <emphasis>not</emphasis> use <option>-nosound</option> when encoding
1549 a file with audio, even if you will be encoding and muxing audio
1550 separately later.
1551 Though it may work in ideal cases, using <option>-nosound</option> is
1552 likely to hide some problems in your encoding command line setting.
1553 In other words, having a soundtrack during your encode assures you that,
1554 provided you do not see messages such as
1555 <quote>Too many audio packets in the buffer</quote>, you will be able
1556 to get proper sync.
1557 </para>
1558
1559 <para>
1560 You need to have <application>MEncoder</application> process the sound.
1561 You can for example copy the original soundtrack during the encode with
1562 <option>-oac copy</option> or convert it to a "light" 4 kHz mono WAV
1563 PCM with <option>-oac pcm -channels 1 -srate 4000</option>.
1564 Otherwise, in some cases, it will generate a video file that will not sync
1565 with the audio.
1566 Such cases are when the number of video frames in the source file does
1567 not match up to the total length of audio frames or whenever there
1568 are discontinuities/splices where there are missing or extra audio frames.
1569 The correct way to handle this kind of problem is to insert silence or
1570 cut audio at these points.
1571 However <application>MPlayer</application> cannot do that, so if you
1572 demux the AC-3 audio and encode it with a separate app (or dump it to PCM with
1573 <application>MPlayer</application>), the splices will be left incorrect
1574 and the only way to correct them is to drop/duplicate video frames at the
1575 splice.
1576 As long as <application>MEncoder</application> sees the audio when it is
1577 encoding the video, it can do this dropping/duping (which is usually OK
1578 since it takes place at full black/scene change), but if
1579 <application>MEncoder</application> cannot see the audio, it will just
1580 process all frames as-is and they will not fit the final audio stream when
1581 you for example merge your audio and video track into a Matroska file.
1582 </para>
1583
1584 <para>
1585 First of all, you will have to convert the DVD sound into a WAV file that the
1586 audio codec can use as input.
1587 For example:
1588 <screen>
1589 mplayer <replaceable>source_file.vob</replaceable> -ao pcm:file=<replaceable>destination_sound.wav</replaceable> \
1590     -vc dummy -aid 1 -vo null
1591 </screen>
1592 will dump the second audio track from the file
1593 <replaceable>source_file.vob</replaceable> into the file
1594 <replaceable>destination_sound.wav</replaceable>.
1595 You may want to normalize the sound before encoding, as DVD audio tracks
1596 are commonly recorded at low volumes.
1597 You can use the tool <application>normalize</application> for instance,
1598 which is available in most distributions.
1599 If you are using Windows, a tool such as <application>BeSweet</application>
1600 can do the same job.
1601 You will compress in either Vorbis or MP3.
1602 For example:
1603 <screen>oggenc -q1 <replaceable>destination_sound.wav</replaceable></screen>
1604 will encode <replaceable>destination_sound.wav</replaceable> with
1605 the encoding quality 1, which is roughly equivalent to 80Kb/s, and
1606 is the minimum quality at which you should encode if you care about
1607 quality.
1608 Please note that <application>MEncoder</application> currently cannot
1609 mux Vorbis audio tracks
1610 into the output file because it only supports AVI and MPEG
1611 containers as an output, each of which may lead to audio/video
1612 playback synchronization problems with some players when the AVI file
1613 contain VBR audio streams such as Vorbis.
1614 Do not worry, this document will show you how you can do that with third
1615 party programs.
1616 </para>
1617 </sect2>
1618
1619 <!-- ********** -->
1620
1621 <sect2 id="menc-feat-dvd-mpeg4-muxing">
1622 <title>Muxing</title>
1623
1624 <para>
1625 Now that you have encoded your video, you will most likely want
1626 to mux it with one or more audio tracks into a movie container, such
1627 as AVI, MPEG, Matroska or NUT.
1628 <application>MEncoder</application> is currently only able to natively output
1629 audio and video into MPEG and AVI container formats.
1630 for example:
1631 <screen>
1632 mencoder -oac copy -ovc copy  -o <replaceable>output_movie.avi</replaceable> \
1633     -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable>
1634 </screen>
1635 This would merge the video file <replaceable>input_video.avi</replaceable>
1636 and the audio file <replaceable>input_audio.mp2</replaceable>
1637 into the AVI file <replaceable>output_movie.avi</replaceable>.
1638 This command works with MPEG-1 layer I, II and III (more commonly known
1639 as MP3) audio, WAV and a few other audio formats too.
1640 </para>
1641
1642 <para>
1643 <application>MEncoder</application> features experimental support for
1644 <systemitem class="library">libavformat</systemitem>, which is a
1645 library from the FFmpeg project that supports muxing and demuxing
1646 a variety of containers.
1647 For example:
1648 <screen>
1649 mencoder -oac copy -ovc copy -o <replaceable>output_movie.asf</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> \
1650     <replaceable>input_video.avi</replaceable> -of lavf -lavfopts format=asf
1651 </screen>
1652 This will do the same thing as the previous example, except that
1653 the output container will be ASF.
1654 Please note that this support is highly experimental (but getting
1655 better every day), and will only work if you compiled
1656 <application>MPlayer</application> with the support for
1657 <systemitem class="library">libavformat</systemitem> enabled (which
1658 means that a pre-packaged binary version will not work in most cases).
1659 </para>
1660
1661
1662 <sect3 id="menc-feat-dvd-mpeg4-muxing-filter-issues">
1663 <title>Improving muxing and A/V sync reliability</title>
1664
1665 <para>
1666 You may experience some serious A/V sync problems while trying to mux
1667 your video and some audio tracks, where no matter how you adjust the
1668 audio delay, you will never get proper sync.
1669 That may happen when you use some video filters that will drop or
1670 duplicate some frames, like the inverse telecine filters.
1671 It is strongly encouraged to append the <option>harddup</option> video
1672 filter at the end of the filter chain to avoid this kind of problem.
1673 </para>
1674
1675 <para>
1676 Without <option>harddup</option>, if <application>MEncoder</application>
1677 wants to duplicate a frame, it relies on the muxer to put a mark on the
1678 container so that the last frame will be displayed again to maintain
1679 sync while writing no actual frame.
1680 With <option>harddup</option>, <application>MEncoder</application>
1681 will instead just push the last frame displayed again into the filter
1682 chain.
1683 This means that the encoder receives the <emphasis>exact</emphasis>
1684 same frame twice, and compresses it.
1685 This will result in a slightly bigger file, but will not cause problems
1686 when demuxing or remuxing into other container formats.
1687 </para>
1688
1689 <para>
1690 You may also have no choice but to use <option>harddup</option> with
1691 container formats that are not too tightly linked with
1692 <application>MEncoder</application> such as the ones supported through
1693 <systemitem class="library">libavformat</systemitem>, which may not
1694 support frame duplication at the container level.
1695 </para>
1696 </sect3>
1697
1698
1699 <sect3 id="menc-feat-dvd-mpeg4-muxing-avi-limitations">
1700 <title>Limitations of the AVI container</title>
1701
1702 <para>
1703 Although it is the most widely-supported container format after MPEG-1,
1704 AVI also has some major drawbacks.
1705 Perhaps the most obvious is the overhead.
1706 For each chunk of the AVI file, 24 bytes are wasted on headers and index.
1707 This translates into a little over 5 MB per hour, or 1-2.5%
1708 overhead for a 700 MB movie. This may not seem like much, but it could
1709 mean the difference between being able to use 700 kbit/sec video or
1710 714 kbit/sec, and every bit of quality counts.
1711 </para>
1712
1713 <para>
1714 In addition this gross inefficiency, AVI also has the following major
1715 limitations:
1716 </para>
1717
1718 <orderedlist>
1719 <listitem><para>
1720   Only fixed-fps content can be stored. This is particularly limiting
1721   if the original material you want to encode is mixed content, for
1722   example a mix of NTSC video and film material.
1723   Actually there are hacks that can be used to store mixed-framerate
1724   content in AVI, but they increase the (already huge) overhead
1725   fivefold or more and so are not practical.
1726 </para></listitem>
1727 <listitem><para>
1728   Audio in AVI files must be either constant-bitrate (CBR) or
1729   constant-framesize (i.e. all frames decode to the same number of
1730   samples).
1731   Unfortunately, the most efficient codec, Vorbis, does not meet
1732   either of these requirements.
1733   Therefore, if you plan to store your movie in AVI, you will have to
1734   use a less efficient codec such as MP3 or AC-3.
1735 </para></listitem>
1736 </orderedlist>
1737
1738 <para>
1739 Having said all that, <application>MEncoder</application> does not
1740 currently support variable-fps output or Vorbis encoding.
1741 Therefore, you may not see these as limitations if
1742 <application>MEncoder</application> is the
1743 only tool you will be using to produce your encodes.
1744 However, it is possible to use <application>MEncoder</application>
1745 only for video encoding, and then use external tools to encode
1746 audio and mux it into another container format.
1747 </para>
1748 </sect3>
1749
1750
1751 <sect3 id="menc-feat-dvd-mpeg4-muxing-matroska">
1752 <title>Muxing into the Matroska container</title>
1753
1754 <para>
1755 Matroska is a free, open standard container format, aiming
1756 to offer a lot of advanced features, which older containers
1757 like AVI cannot handle.
1758 For example, Matroska supports variable bitrate audio content
1759 (VBR), variable framerates (VFR), chapters, file attachments,
1760 error detection code (EDC) and modern A/V Codecs like "Advanced Audio
1761 Coding" (AAC), "Vorbis" or "MPEG-4 AVC" (H.264), next to nothing
1762 handled by AVI.
1763 </para>
1764
1765 <para>
1766 The tools required to create Matroska files are collectively called
1767 <application>mkvtoolnix</application>, and are available for most
1768 Unix platforms as well as <application>Windows</application>.
1769 Because Matroska is an open standard you may find other
1770 tools that suit you better, but since mkvtoolnix is the most
1771 common, and is supported by the Matroska team itself, we will
1772 only cover its usage.
1773 </para>
1774
1775 <para>
1776 Probably the easiest way to get started with Matroska is to use
1777 <application>MMG</application>, the graphical frontend shipped with
1778 <application>mkvtoolnix</application>, and follow the
1779 <ulink url="http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge-gui.html">guide to mkvmerge GUI (mmg)</ulink>
1780 </para>
1781
1782 <para>
1783 You may also mux audio and video files using the command line:
1784 <screen>
1785 mkvmerge -o <replaceable>output.mkv</replaceable> <replaceable>input_video.avi</replaceable> <replaceable>input_audio1.mp3</replaceable> <replaceable>input_audio2.ac3</replaceable>
1786 </screen>
1787 This would merge the video file <replaceable>input_video.avi</replaceable>
1788 and the two audio files <replaceable>input_audio1.mp3</replaceable>
1789 and <replaceable>input_audio2.ac3</replaceable> into the Matroska
1790 file <replaceable>output.mkv</replaceable>.
1791 Matroska, as mentioned earlier, is able to do much more than that, like
1792 multiple audio tracks (including fine-tuning of audio/video
1793 synchronization), chapters, subtitles, splitting, etc...
1794 Please refer to the documentation of those applications for
1795 more details.
1796 </para>
1797 </sect3>
1798 </sect2>
1799 </sect1>
1800
1801
1802 <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
1803
1804
1805 <sect1 id="menc-feat-telecine">
1806 <title>How to deal with telecine and interlacing within NTSC DVDs</title>
1807
1808 <sect2 id="menc-feat-telecine-intro">
1809 <title>Introduction</title>
1810
1811 <formalpara>
1812 <title>What is telecine?</title>
1813 <para>
1814 If you do not understand much of what is written in this document, read the
1815 <ulink url="http://en.wikipedia.org/wiki/Telecine">Wikipedia entry on telecine</ulink>.
1816 It is an understandable and reasonably comprehensive
1817 description of what telecine is.
1818 </para></formalpara>
1819
1820 <formalpara>
1821 <title>A note about the numbers.</title>
1822 <para>
1823 Many documents, including the article linked above, refer to the fields
1824 per second value of NTSC video as 59.94 and the corresponding frames
1825 per second values as 29.97 (for telecined and interlaced) and 23.976
1826 (for progressive). For simplicity, some documents even round these
1827 numbers to 60, 30, and 24.
1828 </para></formalpara>
1829
1830 <para>
1831 Strictly speaking, all those numbers are approximations. Black and
1832 white NTSC video was exactly 60 fields per second, but 60000/1001
1833 was later chosen to accommodate color data while remaining compatible
1834 with contemporary black and white televisions. Digital NTSC video
1835 (such as on a DVD) is also 60000/1001 fields per second. From this,
1836 interlaced and telecined video are derived to be 30000/1001 frames
1837 per second; progressive video is 24000/1001 frames per second.
1838 </para>
1839
1840 <para>
1841 Older versions of the <application>MEncoder</application> documentation
1842 and many archived mailing list posts refer to 59.94, 29.97, and 23.976.
1843 All <application>MEncoder</application> documentation has been updated
1844 to use the fractional values, and you should use them too.
1845 </para>
1846
1847 <para>
1848 <option>-ofps 23.976</option> is incorrect.
1849 <option>-ofps 24000/1001</option> should be used instead.
1850 </para>
1851
1852 <formalpara>
1853 <title>How telecine is used.</title>
1854 <para>
1855 All video intended to be displayed on an NTSC
1856 television set must be 60000/1001 fields per second. Made-for-TV movies
1857 and shows are often filmed directly at 60000/1001 fields per second, but
1858 the majority of cinema is filmed at 24 or 24000/1001 frames per
1859 second. When cinematic movie DVDs are mastered, the video is then
1860 converted for television using a process called telecine.
1861 </para></formalpara>
1862
1863 <para>
1864 On a DVD, the video is never actually stored as 60000/1001 fields per
1865 second. For video that was originally 60000/1001, each pair of fields is
1866 combined to form a frame, resulting in 30000/1001 frames per
1867 second. Hardware DVD players then read a flag embedded in the video
1868 stream to determine whether the odd- or even-numbered lines should
1869 form the first field.
1870 </para>
1871
1872 <para>
1873 Usually, 24000/1001 frames per second content stays as it is when
1874 encoded for a DVD, and the DVD player must perform telecining
1875 on-the-fly. Sometimes, however, the video is telecined
1876 <emphasis>before</emphasis> being stored on the DVD; even though it
1877 was originally 24000/1001 frames per second, it becomes 60000/1001 fields per
1878 second. When it is stored on the DVD, pairs of fields are combined to form
1879 30000/1001 frames per second.
1880 </para>
1881
1882 <para>
1883 When looking at individual frames formed from 60000/1001 fields per
1884 second video, telecined or otherwise, interlacing is clearly visible
1885 wherever there is any motion, because one field (say, the
1886 even-numbered lines) represents a moment in time 1/(60000/1001)
1887 seconds later than the other. Playing interlaced video on a computer
1888 looks ugly both because the monitor is higher resolution and because
1889 the video is shown frame-after-frame instead of field-after-field.
1890 </para>
1891
1892 <itemizedlist>
1893 <title>Notes:</title>
1894 <listitem><para>
1895   This section only applies to NTSC DVDs, and not PAL.
1896 </para></listitem>
1897 <listitem><para>
1898   The example <application>MEncoder</application> lines throughout the
1899   document are <emphasis role="bold">not</emphasis> intended for
1900   actual use. They are simply the bare minimum required to encode the
1901   pertaining video category. How to make good DVD rips or fine-tune
1902   <systemitem class="library">libavcodec</systemitem> for maximal
1903   quality is not within the scope of this section; refer to other
1904   sections within the <link linkend="encoding-guide">MEncoder encoding
1905   guide</link>.
1906 </para></listitem>
1907 <listitem><para>
1908   There are a couple footnotes specific to this guide, linked like this:
1909   <link linkend="menc-feat-telecine-footnotes">[1]</link>
1910 </para></listitem>
1911 </itemizedlist>
1912 </sect2>
1913
1914 <!-- ********** -->
1915
1916 <sect2 id="menc-feat-telecine-ident">
1917 <title>How to tell what type of video you have</title>
1918
1919 <sect3 id="menc-feat-telecine-ident-progressive">
1920 <title>Progressive</title>
1921
1922 <para>
1923 Progressive video was originally filmed at 24000/1001 fps, and stored
1924 on the DVD without alteration.
1925 </para>
1926
1927 <para>
1928 When you play a progressive DVD in <application>MPlayer</application>,
1929 <application>MPlayer</application> will print the following line as
1930 soon as the movie begins to play:
1931 <screen>
1932 demux_mpg: 24000/1001 fps progressive NTSC content detected, switching framerate.
1933 </screen>
1934 From this point forward, demux_mpg should never say it finds
1935 "30000/1001 fps NTSC content."
1936 </para>
1937
1938 <para>
1939 When you watch progressive video, you should never see any
1940 interlacing. Beware, however, because sometimes there is a tiny bit
1941 of telecine mixed in where you would not expect. I have encountered TV
1942 show DVDs that have one second of telecine at every scene change, or
1943 at seemingly random places. I once watched a DVD that had a
1944 progressive first half, and the second half was telecined. If you
1945 want to be <emphasis>really</emphasis> thorough, you can scan the
1946 entire movie:
1947 <screen>mplayer dvd://1 -nosound -vo null -benchmark</screen>
1948 Using <option>-benchmark</option> makes
1949 <application>MPlayer</application> play the movie as quickly as it
1950 possibly can; still, depending on your hardware, it can take a
1951 while. Every time demux_mpg reports a framerate change, the line
1952 immediately above will show you the time at which the change
1953 occurred.
1954 </para>
1955
1956 <para>
1957 Sometimes progressive video on DVDs is referred to as
1958 "soft-telecine" because it is intended to
1959 be telecined by the DVD player.
1960 </para>
1961 </sect3>
1962
1963
1964 <sect3 id="menc-feat-telecine-ident-telecined">
1965 <title>Telecined</title>
1966
1967 <para>
1968 Telecined video was originally filmed at 24000/1001, but was telecined
1969 <emphasis>before</emphasis> it was written to the DVD.
1970 </para>
1971
1972 <para>
1973 <application>MPlayer</application> does not (ever) report any
1974 framerate changes when it plays telecined video.
1975 </para>
1976
1977 <para>
1978 Watching a telecined video, you will see interlacing artifacts that
1979 seem to "blink": they repeatedly appear and disappear.
1980 You can look closely at this by
1981 <orderedlist>
1982 <listitem><screen>mplayer dvd://1</screen></listitem>
1983 <listitem><para>
1984   Seek to a part with motion.
1985 </para></listitem>
1986 <listitem><para>
1987   Use the <keycap>.</keycap> key to step forward one frame at a time.
1988 </para></listitem>
1989 <listitem><para>
1990   Look at the pattern of interlaced-looking and progressive-looking
1991   frames. If the pattern you see is PPPII,PPPII,PPPII,... then the
1992   video is telecined. If you see some other pattern, then the video
1993   may have been telecined using some non-standard method;
1994   <application>MEncoder</application> cannot losslessly convert
1995   non-standard telecine to progressive. If you do not see any
1996   pattern at all, then it is most likely interlaced.
1997 </para></listitem>
1998 </orderedlist>
1999 </para>
2000
2001 <para>
2002 Sometimes telecined video on DVDs is referred to as
2003 "hard-telecine". Since hard-telecine is already 60000/1001 fields
2004 per second, the DVD player plays the video without any manipulation.
2005 </para>
2006
2007 <para>
2008 Another way to tell if your source is telecined or not is to play
2009 the source with the <option>-vf pullup</option> and <option>-v</option>
2010 command line options to see how <option>pullup</option> matches frames.
2011 If the source is telecined, you should see on the console a 3:2 pattern
2012 with <systemitem>0+.1.+2</systemitem> and <systemitem>0++1</systemitem>
2013 alternating.
2014 This technique has the advantage that you do not need to watch the
2015 source to identify it, which could be useful if you wish to automate
2016 the encoding procedure, or to carry out said procedure remotely via
2017 a slow connection.
2018 </para>
2019 </sect3>
2020
2021
2022 <sect3 id="menc-feat-telecine-ident-interlaced">
2023 <title>Interlaced</title>
2024
2025 <para>
2026 Interlaced video was originally filmed at 60000/1001 fields per second,
2027 and stored on the DVD as 30000/1001 frames per second. The interlacing effect
2028 (often called "combing") is a result of combining pairs of
2029 fields into frames. Each field is supposed to be 1/(60000/1001) seconds apart,
2030 and when they are displayed simultaneously the difference is apparent.
2031 </para>
2032
2033 <para>
2034 As with telecined video, <application>MPlayer</application> should
2035 not ever report any framerate changes when playing interlaced content.
2036 </para>
2037
2038 <para>
2039 When you view an interlaced video closely by frame-stepping with the
2040 <keycap>.</keycap> key, you will see that every single frame is interlaced.
2041 </para>
2042 </sect3>
2043
2044
2045 <sect3 id="menc-feat-telecine-ident-mixedpt">
2046 <title>Mixed progressive and telecine</title>
2047
2048 <para>
2049 All of a "mixed progressive and telecine" video was originally
2050 24000/1001 frames per second, but some parts of it ended up being telecined.
2051 </para>
2052
2053 <para>
2054 When <application>MPlayer</application> plays this category, it will
2055 (often repeatedly) switch back and forth between "30000/1001 fps NTSC"
2056 and "24000/1001 fps progressive NTSC". Watch the bottom of
2057 <application>MPlayer</application>'s output to see these messages.
2058 </para>
2059
2060 <para>
2061 You should check the "30000/1001 fps NTSC" sections to make sure
2062 they are actually telecine, and not just interlaced.
2063 </para>
2064 </sect3>
2065
2066
2067 <sect3 id="menc-feat-telecine-ident-mixedpi">
2068 <title>Mixed progressive and interlaced</title>
2069
2070 <para>
2071 In "mixed progressive and interlaced" content, progressive
2072 and interlaced video have been spliced together.
2073 </para>
2074
2075 <para>
2076 This category looks just like "mixed progressive and telecine",
2077 until you examine the 30000/1001 fps sections and see that they do not have the
2078 telecine pattern.
2079 </para>
2080 </sect3>
2081 </sect2>
2082
2083 <!-- ********** -->
2084
2085 <sect2 id="menc-feat-telecine-encode">
2086 <title>How to encode each category</title>
2087 <para>
2088 As I mentioned in the beginning, example <application>MEncoder</application>
2089 lines below are <emphasis role="bold">not</emphasis> meant to actually be used;
2090 they only demonstrate the minimum parameters to properly encode each category.
2091 </para>
2092
2093
2094 <sect3 id="menc-feat-telecine-encode-progressive">
2095 <title>Progressive</title>
2096 <para>
2097 Progressive video requires no special filtering to encode. The only
2098 parameter you need to be sure to use is <option>-ofps 24000/1001</option>.
2099 Otherwise, <application>MEncoder</application>
2100 will try to encode at 30000/1001 fps and will duplicate frames.
2101 </para>
2102
2103 <para>
2104 <screen>mencoder dvd://1 -oac copy -ovc lavc -ofps 24000/1001</screen>
2105 </para>
2106
2107 <para>
2108 It is often the case, however, that a video that looks progressive
2109 actually has very short parts of telecine mixed in. Unless you are
2110 sure, it is safest to treat the video as
2111 <link linkend="menc-feat-telecine-encode-mixedpt">mixed progressive and telecine</link>.
2112 The performance loss is small
2113 <link linkend="menc-feat-telecine-footnotes">[3]</link>.
2114 </para>
2115 </sect3>
2116
2117
2118 <sect3 id="menc-feat-telecine-encode-telecined">
2119 <title>Telecined</title>
2120
2121 <para>
2122 Telecine can be reversed to retrieve the original 24000/1001 content,
2123 using a process called inverse-telecine.
2124 <application>MPlayer</application> contains several filters to
2125 accomplish this; the best filter, <option>pullup</option>, is described
2126 in the <link linkend="menc-feat-telecine-encode-mixedpt">mixed
2127 progressive and telecine</link> section.
2128 </para>
2129 </sect3>
2130
2131
2132 <sect3 id="menc-feat-telecine-encode-interlaced">
2133 <title>Interlaced</title>
2134
2135 <para>
2136 For most practical cases it is not possible to retrieve a complete
2137 progressive video from interlaced content. The only way to do so
2138 without losing half of the vertical resolution is to double the
2139 framerate and try to "guess" what ought to make up the
2140 corresponding lines for each field (this has drawbacks - see method 3).
2141 </para>
2142
2143 <orderedlist>
2144 <listitem><para>
2145   Encode the video in interlaced form. Normally, interlacing wreaks
2146   havoc with the encoder's ability to compress well, but
2147   <systemitem class="library">libavcodec</systemitem> has two
2148   parameters specifically for dealing with storing interlaced video a
2149   bit better: <option>ildct</option> and <option>ilme</option>. Also,
2150   using <option>mbd=2</option> is strongly recommended
2151   <link linkend="menc-feat-telecine-footnotes">[2] </link> because it
2152   will encode macroblocks as non-interlaced in places where there is
2153   no motion. Note that <option>-ofps</option> is NOT needed here.
2154   <screen>mencoder dvd://1 -oac copy -ovc lavc -lavcopts ildct:ilme:mbd=2</screen>
2155 </para></listitem>
2156 <listitem><para>
2157   Use a deinterlacing filter before encoding. There are several of
2158   these filters available to choose from, each with its own advantages
2159   and disadvantages. Consult <option>mplayer -pphelp</option> and
2160   <option>mplayer -vf help</option> to see what is available
2161   (grep for "deint"), read Michael Niedermayer's
2162   <ulink url="http://guru.multimedia.cx/deinterlacing-filters/">Deinterlacing filters comparison</ulink>,
2163   and search the
2164   <ulink url="http://www.mplayerhq.hu/design7/mailing_lists.html">
2165   MPlayer mailing lists</ulink> to find many discussions about the
2166   various filters.
2167   Again, the framerate is not changing, so no
2168   <option>-ofps</option>. Also, deinterlacing should be done after
2169   cropping <link linkend="menc-feat-telecine-footnotes">[1]</link> and
2170   before scaling.
2171   <screen>mencoder dvd://1 -oac copy -vf yadif -ovc lavc</screen>
2172 </para></listitem>
2173 <listitem><para>
2174   Unfortunately, this option is buggy with
2175   <application>MEncoder</application>; it ought to work well with
2176   <application>MEncoder G2</application>, but that is not here yet. You
2177   might experience crashes. Anyway, the purpose of <option> -vf
2178   tfields</option> is to create a full frame out of each field, which
2179   makes the framerate 60000/1001. The advantage of this approach is that no
2180   data is ever lost; however, since each frame comes from only one
2181   field, the missing lines have to be interpolated somehow. There are
2182   no very good methods of generating the missing data, and so the
2183   result will look a bit similar to when using some deinterlacing
2184   filters. Generating the missing lines creates other issues, as well,
2185   simply because the amount of data doubles. So, higher encoding
2186   bitrates are required to maintain quality, and more CPU power is
2187   used for both encoding and decoding. tfields has several different
2188   options for how to create the missing lines of each frame. If you
2189   use this method, then Reference the manual, and chose whichever
2190   option looks best for your material. Note that when using
2191   <option>tfields</option> you
2192   <emphasis role="bold">have to</emphasis> specify both
2193   <option>-fps</option> and <option>-ofps</option> to be twice the
2194   framerate of your original source.
2195   <screen>
2196 mencoder dvd://1 -oac copy -vf tfields=2 -ovc lavc \
2197     -fps 60000/1001 -ofps 60000/1001<!--
2198   --></screen>
2199 </para></listitem>
2200 <listitem><para>
2201   If you plan on downscaling dramatically, you can extract and encode
2202   only one of the two fields. Of course, you will lose half the vertical
2203   resolution, but if you plan on downscaling to at most 1/2 of the
2204   original, the loss will not matter much. The result will be a
2205   progressive 30000/1001 frames per second file. The procedure is to use
2206   <option>-vf field</option>, then crop
2207   <link linkend="menc-feat-telecine-footnotes">[1]</link> and scale
2208   appropriately. Remember that you will have to adjust the scale to
2209   compensate for the vertical resolution being halved.
2210   <screen>mencoder dvd://1 -oac copy -vf field=0 -ovc lavc</screen>
2211 </para></listitem>
2212 </orderedlist>
2213 </sect3>
2214
2215
2216 <sect3 id="menc-feat-telecine-encode-mixedpt">
2217 <title>Mixed progressive and telecine</title>
2218
2219 <para>
2220 In order to turn mixed progressive and telecine video into entirely
2221 progressive video, the telecined parts have to be
2222 inverse-telecined. There are three ways to accomplish this,
2223 described below. Note that you should
2224 <emphasis role="bold">always</emphasis> inverse-telecine before any
2225 rescaling; unless you really know what you are doing,
2226 inverse-telecine before cropping, too
2227 <link linkend="menc-feat-telecine-footnotes">[1]</link>.
2228 <option>-ofps 24000/1001</option> is needed here because the output video
2229 will be 24000/1001 frames per second.
2230 </para>
2231
2232 <itemizedlist>
2233 <listitem><para>
2234   <option>-vf pullup</option> is designed to inverse-telecine
2235   telecined material while leaving progressive data alone. In order to
2236   work properly, <option>pullup</option> <emphasis role="bold">must</emphasis>
2237   be followed by the <option>softskip</option> filter or
2238   else <application>MEncoder</application> will crash.
2239   <option>pullup</option> is, however, the cleanest and most
2240   accurate method available for encoding both telecine and
2241   "mixed progressive and telecine".
2242   <screen>
2243 mencoder dvd://1 -oac copy -vf pullup,softskip
2244     -ovc lavc -ofps 24000/1001<!--
2245   --></screen>
2246 </para></listitem>
2247 <listitem><para>
2248   <option>-vf filmdint</option> is similar to
2249   <option>-vf pullup</option>: both filters attempt to match a pair of
2250   fields to form a complete frame. <option>filmdint</option> will
2251   deinterlace individual fields that it cannot match, however, whereas
2252   <option>pullup</option> will simply drop them. Also, the two filters
2253   have separate detection code, and <option>filmdint</option> may tend to match fields a
2254   bit less often. Which filter works better may depend on the input
2255   video and personal taste; feel free to experiment with fine-tuning
2256   the filters' options if you encounter problems with either one (see
2257   the man page for details). For most well-mastered input video,
2258   however, both filters work quite well, so either one is a safe choice
2259   to start with.
2260   <screen>
2261 mencoder dvd://1 -oac copy -vf filmdint -ovc lavc -ofps 24000/1001<!--
2262   --></screen>
2263 </para></listitem>
2264 <listitem><para>
2265   An older method
2266   is to, rather than inverse-telecine the telecined parts, telecine
2267   the non-telecined parts and then inverse-telecine the whole
2268   video. Sound confusing? softpulldown is a filter that goes through
2269   a video and makes the entire file telecined. If we follow
2270   softpulldown with either <option>detc</option> or
2271   <option>ivtc</option>, the final result will be entirely
2272   progressive. <option>-ofps 24000/1001</option> is needed.
2273   <screen>
2274 mencoder dvd://1 -oac copy -vf softpulldown,ivtc=1 -ovc lavc -ofps 24000/1001
2275   </screen>
2276 </para></listitem>
2277
2278 </itemizedlist>
2279 </sect3>
2280
2281
2282 <sect3 id="menc-feat-telecine-encode-mixedpi">
2283 <title>Mixed progressive and interlaced</title>
2284
2285 <para>
2286 There are two options for dealing with this category, each of
2287 which is a compromise. You should decide based on the
2288 duration/location of each type.
2289 </para>
2290
2291 <itemizedlist>
2292 <listitem>
2293   <para>
2294   Treat it as progressive. The interlaced parts will look interlaced,
2295   and some of the interlaced fields will have to be dropped, resulting
2296   in a bit of uneven jumpiness. You can use a postprocessing filter if
2297   you want to, but it may slightly degrade the progressive parts.
2298   </para>
2299
2300   <para>
2301   This option should definitely not be used if you want to eventually
2302   display the video on an interlaced device (with a TV card, for
2303   example). If you have interlaced frames in a 24000/1001 frames per
2304   second video, they will be telecined along with the progressive
2305   frames. Half of the interlaced "frames" will be displayed for three
2306   fields' duration (3/(60000/1001) seconds), resulting in a flicking
2307   "jump back in time" effect that looks quite bad. If you
2308   even attempt this, you <emphasis role="bold">must</emphasis> use a
2309   deinterlacing filter like <option>lb</option> or
2310   <option>l5</option>.
2311   </para>
2312
2313   <para>
2314   It may also be a bad idea for progressive display, too. It will drop
2315   pairs of consecutive interlaced fields, resulting in a discontinuity
2316   that can be more visible than with the second method, which shows
2317   some progressive frames twice. 30000/1001 frames per second interlaced
2318   video is already a bit choppy because it really should be shown at
2319   60000/1001 fields per second, so the duplicate frames do not stand out as
2320   much.
2321   </para>
2322
2323   <para>
2324   Either way, it is best to consider your content and how you intend to
2325   display it. If your video is 90% progressive and you never intend to
2326   show it on a TV, you should favor a progressive approach. If it is
2327   only half progressive, you probably want to encode it as if it is all
2328   interlaced.
2329   </para>
2330 </listitem>
2331
2332 <listitem><para>
2333   Treat it as interlaced. Some frames of the progressive parts will
2334   need to be duplicated, resulting in uneven jumpiness. Again,
2335   deinterlacing filters may slightly degrade the progressive parts.
2336 </para></listitem>
2337 </itemizedlist>
2338 </sect3>
2339 </sect2>
2340
2341 <!-- ********** -->
2342
2343 <sect2 id="menc-feat-telecine-footnotes">
2344 <title>Footnotes</title>
2345
2346 <orderedlist>
2347 <listitem>
2348   <formalpara>
2349   <title>About cropping:</title>
2350   <para>
2351   Video data on DVDs are stored in a format called YUV 4:2:0. In YUV
2352   video, luma ("brightness") and chroma ("color")
2353   are stored separately. Because the human eye is somewhat less
2354   sensitive to color than it is to brightness, in a YUV 4:2:0 picture
2355   there is only one chroma pixel for every four luma pixels. In a
2356   progressive picture, each square of four luma pixels (two on each
2357   side) has one common chroma pixel. You must crop progressive YUV
2358   4:2:0 to even resolutions, and use even offsets. For example,
2359   <option>crop=716:380:2:26</option> is OK but
2360   <option>crop=716:380:3:26 </option> is not.
2361   </para>
2362   </formalpara>
2363
2364   <para>
2365   When you are dealing with interlaced YUV 4:2:0, the situation is a
2366   bit more complicated. Instead of every four luma pixels in the
2367   <emphasis>frame</emphasis> sharing a chroma pixel, every four luma
2368   pixels in each <emphasis> field</emphasis> share a chroma
2369   pixel. When fields are interlaced to form a frame, each scanline is
2370   one pixel high. Now, instead of all four luma pixels being in a
2371   square, there are two pixels side-by-side, and the other two pixels
2372   are side-by-side two scanlines down. The two luma pixels in the
2373   intermediate scanline are from the other field, and so share a
2374   different chroma pixel with two luma pixels two scanlines away. All
2375   this confusion makes it necessary to have vertical crop dimensions
2376   and offsets be multiples of four. Horizontal can stay even.
2377   </para>
2378
2379   <para>
2380   For telecined video, I recommend that cropping take place after
2381   inverse telecining. Once the video is progressive you only need to
2382   crop by even numbers. If you really want to gain the slight speedup
2383   that cropping first may offer, you must crop vertically by multiples
2384   of four or else the inverse-telecine filter will not have proper data.
2385   </para>
2386
2387   <para>
2388   For interlaced (not telecined) video, you must always crop
2389   vertically by multiples of four unless you use <option>-vf
2390   field</option> before cropping.
2391   </para>
2392 </listitem>
2393
2394 <listitem><formalpara>
2395   <title>About encoding parameters and quality:</title>
2396   <para>
2397   Just because I recommend <option>mbd=2</option> here does not mean it
2398   should not be used elsewhere. Along with <option>trell</option>,
2399   <option>mbd=2</option> is one of the two
2400    <systemitem class="library">libavcodec</systemitem> options that
2401   increases quality the most, and you should always use at least those
2402   two unless the drop in encoding speed is prohibitive (e.g. realtime
2403   encoding). There are many other options to
2404   <systemitem class="library">libavcodec</systemitem> that increase
2405   encoding quality (and decrease encoding speed) but that is beyond
2406   the scope of this document.
2407   </para>
2408 </formalpara></listitem>
2409
2410 <listitem><formalpara>
2411   <title>About the performance of pullup:</title>
2412   <para>
2413   It is safe to use <option>pullup</option> (along with <option>softskip
2414   </option>) on progressive video, and is usually a good idea unless
2415   the source has been definitively verified to be entirely progressive.
2416   The performance loss is small for most cases. On a bare-minimum encode,
2417   <option>pullup</option> causes <application>MEncoder</application> to
2418   be 50% slower. Adding sound processing and advanced <option>lavcopts
2419   </option> overshadows that difference, bringing the performance
2420   decrease of using <option>pullup</option> down to 2%.
2421   </para>
2422 </formalpara></listitem>
2423 </orderedlist>
2424 </sect2>
2425 </sect1>
2426
2427
2428 <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
2429
2430
2431 <sect1 id="menc-feat-enc-libavcodec">
2432 <title>Encoding with the <systemitem class="library">libavcodec</systemitem>
2433   codec family</title>
2434
2435 <para>
2436 <systemitem class="library">libavcodec</systemitem>
2437 provides simple encoding to a lot of interesting video and audio formats.
2438 You can encode to the following codecs (more or less up to date):
2439 </para>
2440
2441 <!-- ********** -->
2442
2443 <sect2 id="menc-feat-enc-libavcodec-video-codecs">
2444 <title><systemitem class="library">libavcodec</systemitem>'s
2445   video codecs</title>
2446
2447 <para>
2448 <informaltable frame="all">
2449 <tgroup cols="2">
2450 <thead>
2451   <row><entry>Video codec name</entry><entry>Description</entry></row>
2452 </thead>
2453 <tbody>
2454 <row>
2455   <entry>mjpeg</entry>
2456   <entry>Motion JPEG</entry>
2457 </row>
2458 <row>
2459   <entry>ljpeg</entry>
2460   <entry>lossless JPEG</entry>
2461 </row>
2462 <row>
2463   <entry>jpegls</entry>
2464   <entry>JPEG LS</entry>
2465 </row>
2466 <row>
2467   <entry>targa</entry>
2468   <entry>Targa image</entry>
2469 </row>
2470 <row>
2471   <entry>gif</entry>
2472   <entry>GIF image</entry>
2473 </row>
2474 <row>
2475   <entry>bmp</entry>
2476   <entry>BMP image</entry>
2477 </row>
2478 <row>
2479   <entry>png</entry>
2480   <entry>PNG image</entry>
2481 </row>
2482 <row>
2483   <entry>h261</entry>
2484   <entry>H.261</entry>
2485 </row>
2486 <row>
2487   <entry>h263</entry>
2488   <entry>H.263 </entry>
2489 </row>
2490 <row>
2491   <entry>h263p</entry>
2492   <entry>H.263+</entry>
2493 </row>
2494 <row>
2495   <entry>mpeg4</entry>
2496   <entry>ISO standard MPEG-4 (DivX, Xvid compatible)</entry>
2497 </row>
2498 <row>
2499   <entry>msmpeg4</entry>
2500   <entry>pre-standard MPEG-4 variant by MS, v3 (AKA DivX3)</entry>
2501 </row>
2502 <row>
2503   <entry>msmpeg4v2</entry>
2504   <entry>pre-standard MPEG-4 by MS, v2 (used in old ASF files)</entry>
2505 </row>
2506 <row>
2507   <entry>wmv1</entry>
2508   <entry>Windows Media Video, version 1 (AKA WMV7)</entry>
2509 </row>
2510 <row>
2511   <entry>wmv2</entry>
2512   <entry>Windows Media Video, version 2 (AKA WMV8)</entry>
2513 </row>
2514 <row>
2515   <entry>rv10</entry>
2516   <entry>RealVideo 1.0</entry>
2517 </row>
2518 <row>
2519   <entry>rv20</entry>
2520   <entry>RealVideo 2.0</entry>
2521 </row>
2522 <row>
2523   <entry>mpeg1video</entry>
2524   <entry>MPEG-1 video</entry>
2525 </row>
2526 <row>
2527   <entry>mpeg2video</entry>
2528   <entry>MPEG-2 video</entry>
2529 </row>
2530 <row>
2531   <entry>huffyuv</entry>
2532   <entry>lossless compression</entry>
2533 </row>
2534 <row>
2535   <entry>ffvhuff</entry>
2536   <entry>FFmpeg modified huffyuv lossless</entry>
2537 </row>
2538 <row>
2539   <entry>asv1</entry>
2540   <entry>ASUS Video v1</entry>
2541 </row>
2542 <row>
2543   <entry>asv2</entry>
2544   <entry>ASUS Video v2</entry>
2545 </row>
2546 <row>
2547   <entry>ffv1</entry>
2548   <entry>FFmpeg's lossless video codec</entry>
2549 </row>
2550 <row>
2551   <entry>svq1</entry>
2552   <entry>Sorenson video 1</entry>
2553 </row>
2554 <row>
2555   <entry>flv</entry>
2556   <entry>Sorenson H.263 used in Flash Video</entry>
2557 </row>
2558 <row>
2559   <entry>flashsv</entry>
2560   <entry>Flash Screen Video</entry>
2561 </row>
2562 <row>
2563   <entry>dvvideo</entry>
2564   <entry>Sony Digital Video</entry>
2565 </row>
2566 <row>
2567   <entry>snow</entry>
2568   <entry>FFmpeg's experimental wavelet-based codec</entry>
2569 </row>
2570 <row>
2571   <entry>zmbv</entry>
2572   <entry>Zip Motion Blocks Video</entry>
2573 </row>
2574 <row>
2575   <entry>dnxhd</entry>
2576   <entry>AVID DNxHD</entry>
2577 </row>
2578 </tbody>
2579 </tgroup>
2580 </informaltable>
2581
2582 The first column contains the codec names that should be passed after the
2583 <literal>vcodec</literal> config,
2584 like: <option>-lavcopts vcodec=msmpeg4</option>
2585 </para>
2586
2587 <informalexample><para>
2588 An example with MJPEG compression:
2589 <screen>
2590 mencoder dvd://2 -o <replaceable>title2.avi</replaceable> -ovc lavc -lavcopts vcodec=mjpeg -oac copy
2591 </screen>
2592 </para></informalexample>
2593 </sect2>
2594
2595 <!-- ********** -->
2596
2597 <sect2 id="menc-feat-enc-libavcodec-audio-codecs">
2598 <title><systemitem class="library">libavcodec</systemitem>'s
2599   audio codecs</title>
2600
2601 <para>
2602 <informaltable frame="all">
2603 <tgroup cols="2">
2604 <thead>
2605 <row><entry>Audio codec name</entry><entry>Description</entry></row>
2606 </thead>
2607 <tbody>
2608 <row>
2609   <entry>ac3</entry>
2610   <entry>Dolby Digital (AC-3)</entry>
2611 </row>
2612 <row>
2613   <entry>adpcm_*</entry>
2614   <entry>Adaptive PCM formats - see supplementary table</entry>
2615 </row>
2616 <row>
2617   <entry>flac</entry>
2618   <entry>Free Lossless Audio Codec (FLAC)</entry>
2619 </row>
2620 <row>
2621   <entry>g726</entry>
2622   <entry>G.726 ADPCM</entry>
2623 </row>
2624 <row>
2625   <entry>libfaac</entry>
2626   <entry>Advanced Audio Coding (AAC) - using FAAC</entry>
2627 </row>
2628 <row>
2629   <entry>libgsm</entry>
2630   <entry>ETSI GSM 06.10 full rate</entry>
2631 </row>
2632 <row>
2633   <entry>libgsm_ms</entry>
2634   <entry>Microsoft GSM</entry>
2635 </row>
2636 <row>