changeset 19025:45b8400e8e87

- incomplete but we probably need this (because we updated mencoder.xml already)

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/DOCS/xml/pl/encoding-guide.xml	Wed Jul 12 14:03:19 2006 +0000
@@ -0,0 +1,4418 @@
+<?xml version="1.0" encoding="iso-8859-2"?>
+<!-- synced with 1.32 -->
+<!-- Opiekun: Torinthiel -->
+<!-- INCOMPLETE!!!! -->
+<chapter id="encoding-guide">
+<title>Kodowanie przy użyciu <application>MEncodera</application></title>
+
+<sect1 id="menc-feat-dvd-mpeg4">
+<title>Rippowanie DVD do wysokiej jakości pliku MPEG-4 ("DivX")</title>
+
+<para>
+  Jednym z często zadawanych pytań jest "Jak zrobić rip najlepszej jakości
+  przy danej objętości?". Innym pytaniem jest "Jak zrobić najlepszy możliwy
+  rip? Nie ważne jaka będzie objętość, chcę najlepszej jakości."
+</para>
+
+<para>
+  To drugie pytanie jest przynajmniej źle postawione. W końcu, jeśli nie
+  przejmujesz się wielkością pliku, mógłbyć po prostu skopiować strumień
+  MPEG-2 z DVD. Pewnie, dostaniesz AVI wielkości około 5GB, ale jeśli chcesz
+  najlepszej jakości i nie przejmujesz się wielkością to jest to najlepsze
+  wyjście.
+</para>
+
+<para>
+  Tak na prawdę, powodem dla którego chcesz przekodować DVD na MPEG-4 jest to,
+  że <emphasis role="bold">przejmujesz</emphasis> się wielkością pliku.
+</para>
+
+<para>
+  Ciężko jest pokazać książkowy przepis na tworzenie ripu DVD bardzo wysokiej
+  jakości. Trzeba wziąć pod uwagę kilka czynników, i powinieneś rozumieć
+  szczegóły albo masz dużą szansę że nie będziesz zadowolony z wyników.
+  Poniżej zbadamy niektóre problemy i pokażemy przykład. Zakładamy że używasz
+  <systemitem class="library">libavcodec</systemitem> do kodowania obrazu,
+  chociaż ta sama teoria działą też przy innych kodekach.
+</para>
+
+<para>
+  Jeśli to wydaje Ci się za dużo, to pewnie powinieneś użyć jednej z wielu
+  nakładek dostępnych w
+  <ulink url="http://mplayerhq.hu/homepage/design7/projects.html#mencoder_frontends">sekcji MEncodera</ulink>
+  naszej strony z powiązanymi projektami.
+  W ten sposób, powinno się udać otrzymać ripy wysokiej jakości bez zbyt
+  myślenia za dużo, ponieważ te narzędzia są projektowane by podejmować za
+  Ciebie mądre decyzje.
+</para>
+
+<sect2 id="menc-feat-dvd-mpeg4-preparing-encode">
+<title>Przygotowanie do kodowania: Identyfikowanie materiału źródłowego
+i framerate</title>
+<para>
+  Zanim w ogóle zaczniesz myśleć o kodowaniu filmu, musisz podjąć kilka
+  początkowych kroków.
+</para>
+
+<para>
+  Pierwszym i najważniejszym krokiem przed kodowaniem powinno być
+  ustalenie jakim typem filmu się zajmujesz.
+  Jeśli Twój film jest z DVD albo telewizji (zwykłej, kablowej czy
+  satelitarnej), będzie w jednym z dwóch formatów: NTSC w Ameryce Północnej
+  i Japonii, PAL w Europie itp.
+  Trzeba sobie jednak zdawać sprawę z tego, że jest to tylko format do
+  prezentacji w telewizji, i często <emphasis role="bold">ne</emphasis> jest
+  oryginalnym formatem filmu.
+  Doświadczenie pokazuje że filmy NTSC są trudniejsze do kodowania, ponieważ
+  jest więcej elementów do zidentyfikowania w źródle.
+  Żeby zrobić odpowienie kodowanie musisz znać oryginalny format filmu.
+  Nieuwzględnienie tego skutkuje wieloma wadami wynikowego pliku, na przykład
+  brzydkie artefakty przeplotu i powtórzone albo zagubione klatki.
+  Poza tym że są pbrzydkie, artefakty są też szkodliwe dla kodowania:
+  Dostaniesz gorszą jakość na jednostkę bitrate.
+</para>
+
+<sect3 id="menc-feat-dvd-mpeg4-preparing-encode-fps">
+<title>Ustalanie źródłowego framerate</title>
+<para>
+  Poniżej jest lista popularnych typów materiału źródłowego, gdzie można je
+  najczęściej znaleźć i ich własności:
+</para>
+<itemizedlist>
+<listitem><para>
+  <emphasis role="bold">Typowy film</emphasis>: Tworzony do wyświetlania przy
+  24fps.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Film PAL</emphasis>: Nagrywany kamerą video PAL
+  z prędkością 50 pól na sekundę.
+  Pole składa się tylko z parzystych albo nieparzystych linii klatki.
+  Telewizja była projektowana by odświerzać je naprzemiennie, jako tania forma
+  analogowej kompresji.
+  Ludzkie oko podobno kompensuje ten efekt, ale jeśli zrozumiesz przeplot
+  nauczysz się go widzieć też w telewizji i nigdy już nie będziesz z niej
+  zadowolony.
+  Dwa pola <emphasis role="bold">nie</emphasis> dają pełnej klatki, ponieważ
+  są uchwycone co 1/50 sekundy, więc nie pasują do siebie, chyba że nie ma
+  ruchu.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Film NTSC</emphasis>: Nagrany kamerą NTSC z prędkością
+  6000/1001 pól na sekundę, albo 60 pól na sekundę w erze przedkolorowej.
+  Poza tym podobny do PAL.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Animacja</emphasis>: Zazwyczaj rysowana przy 24fps,
+  ale zdarzają się też z mieszanym framerate.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Grafika komputerowa (CG)</emphasis>: Może być dowolny
+  framerate, ale niektóre są częstsze niż inne; wartości 24 i 30 klatek na
+  sekundę są typowe dla NTSC, a 25fps jest typowe dla PAL. 
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Stary film</emphasis>: Rozmaite niższe framerate.
+</para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3 id="menc-feat-dvd-mpeg4-preparing-encode-material">
+<title>Identyfikowanie materiału źródłowego</title>
+<para>
+  Filmy składające się z klatek nazywa się progresywnymi,
+  podczas gdy te składające się z niezależnych pól nazywa się
+  z przeplotem, albo filmem - chociaż ten drugi termin jest niejasny.
+</para>
+<para>
+  Żeby nie było za łatwo, niektóre filmy są kombinacją kilku powyższych typów.
+</para>
+<para>
+  Najważniejszą różnicą między tymi formatami, jest to że niektóre są oparte
+  na klatkach a inne na polach.
+  <emphasis role="bold">Zawsze</emphasis> gdy film jest przygotowywany do
+  wyświetlania w telewizji jest przekształcany na format oparty na polach.
+  Rozliczne metody którymi się tego dokonuje są wspólnie nazywane "pulldown",
+  a niesławne "3:2 telecine" z NTSC jest jednym z jego rodzajów.
+  Jeżeli oryginał nie był też oparty na polach (z tą samą prędkością),
+  dostajesz film w innym formacie niż oryginał.
+</para>
+
+<itemizedlist>
+<title>Jest kilka popularnych typów pulldown:</title>
+<listitem><para>
+  <emphasis role="bold">pulldown PAL 2:2</emphasis>: Najprzyjemniejszy z nich
+  wszystkich.
+  Każda klatka jest pokazywana przez czas dwóch pól, poprzez wydobycie
+  parzystych i nieparzystych linii i pokazywanie ich na przemian.
+  Jeśli oryginalny materiał miał 24fps, ten proces przyspiesza film o 4%.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">pulldown PAL 2:2:2:2:2:2:2:2:2:2:2:3</emphasis>:
+  Każda 12ta klatka jest pokazywana przez czas trzech pól zamiast tylko dwóch.
+  Dzięki temu nie ma przyspieszenia o 4%, ale proces jest o wiele trudniejszy
+  do odtworzenia.
+  Zazwyczaj występuje w produkcjach muzycznych, gdzie zmiana prędkości o 4%
+  poważnie by uszkodziła muzykę.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">NTSC 3:2 telecine</emphasis>: Klatki są pokazywane na
+  przemian przez czas 3ch albo 2ch pól.
+  To daje częstotliwość pól 2.5 raza większą niż oryginalna częstotliwość
+  klatek. Rezultat jest też lekko zwolniony z 60 pól na sekundę do 60000/1001
+  pól na sekundę by utrzymać częstotliwość pól w NTSC.
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">NTSC 2:2 pulldown</emphasis>: Używane do pokazywania
+  materiałów 30fps na NTSC.
+  Przyjemne, dokładnie jak pulldown 2:2 PAL.
+</para></listitem>
+</itemizedlist>
+
+<para>
+  Są też metody konwersji między filmami PAL i NTSC, ale ten temat
+  wykracza poza zakres tego podręcznika.
+  Jeśli natkniesz się na taki film, i chcesz go zakodować, to największe
+  szanse masz odnajdując kopię w oryginalnym formacie.
+  Konwersja między tymi dwoma formatami jest wysoce destrukcyjna i nie może
+  zostać czysto odwrócona, więc kodowanie będzie o wiele gorszej jakości jeśli
+  jest robione z przekonwertowanego źródła.
+</para>
+<para>
+  Gdy film jest zapisywany na DVD, kolejne pary pól są zapisywane jako klatka,
+  pomimo tego że nie są przezaczone do wyświetlania razem.
+  Standard MPEG-2 używany na DVD i w cyfrowej TV pozwala na zakodowanie
+  oryginalnej progresywnej klatki i na przechowanie w nagłówku klatki ilości
+  pól przez które ta klatka powinna być pokazana.
+  Filmy zrobione przy użyciu tej metody są często określane mianem "miękkiego
+  telecine" (soft-telecine), ponieważ proces ten tylko informuje odtwarzacz że
+  ma on zastosować pulldown, a nie stosuje go samemu.
+  Tak jest o wiele lepiej, ponieważ może to zostać łatwo odwrócone (a tak na
+  prawdę zignorowane) przez koder i ponieważ zachowuje możliwie najwyższą
+  jakość.
+  Niestety, wielu producentów DVD i stacji nadawczych nie stosuje prawidłowych
+  technik kodowania ale w zamian produkuje filmy przy użyciu "twardego
+  telecine" (hard-telecine), gdzie pola są faktycznie powtórzone
+  w zakodowanym MPEG-2.
+</para>
+<para>
+  Procedury radzenia sobie z takimi przypadkami będą omówione
+  <link linkend="menc-feat-telecine">w dalszej części przewodnika</link>.
+  Teraz podamy tylko kilka wskazówek jak identyfikować z jakim typem materiału
+  mamy do czynienia.
+</para>
+
+<itemizedlist>
+<title>Regiony NTSC:</title>
+<listitem><para>
+  Jeśli <application>MPlayer</application> wyświetla w trakcie oglądania filmu
+  że framerate zostało zmienione na 24000/1001, i nigdy nie powraca, to jest
+  to prawie na pewno progresywny materiał na którym zastosowano "miękkie
+  telecine".
+</para></listitem>
+<listitem><para>
+  Jeśli <application>MPlayer</application> pokazuje że framerate zmienia się
+  między 24000/1001 i 30000/1001 i czasami widzisz "grzebienie" to jest kilka
+  możliwości.
+  <!-- Torinthiel: grzebienie mi najlepiej pasują, ale może jest oficjalne tłumaczenie -->
+  Kawałki 24000/1001fps są prawie na pewno progresywne, poddane "miękkiemu
+  telecine", ale fragmenty  30000/1001 fps mogą albo być 24000/1001 poddanym
+  "twardemu telecine" albo filmem NTCS o 60000/1001 polach na sekundę.
+  Używaj tych samych metod co w następnych dwóch przypadkach żeby je odróżnić.
+</para></listitem>
+<listitem><para>
+  Jeśli <application>MPlayer</application> nigdy nie pokazuje informacji
+  o zmianie framerate i każda klatka z ruchem wygląda jak grzebień, to masz
+  film NTSC z 60000/1001 polami na sekundę.
+</para></listitem>
+<listitem><para>
+  Jeśli <application>MPlayer</application> nigdy nie pokazuje informacji
+  o zmianie framerate i dwie klatki z każdych pięciu mają grzebienie, to film
+  jest 24000/1001 fps poddanym "twardemu telecine".
+</para></listitem>
+</itemizedlist>
+
+<itemizedlist>
+<title>Regiony PAL:</title>
+<listitem><para>
+  Jeśli nie widzisz grzebieni, to jest to 2:2 pulldown.
+</para></listitem>
+<listitem><para>
+  Jeśli na przemian przez pół sekundy widzisz grzebienie a potem nie, to masz
+  2:2:2:2:2:2:2:2:2:2:2:3 pulldown.
+</para></listitem>
+<listitem><para>
+  Jeśli zawsze widzisz grzebienie w trakcie ruchu, to film jest filmem PAL
+  wyświetlanym z 50 polami na sekundę.
+  <!-- Torinthiel: wyświetlanym czy nagranym? -->
+</para></listitem>
+</itemizedlist>
+
+<note><title>Podpowiedź:</title>
+<para>
+  <application>MPlayer</application> może zwolnić odtwarzanie filmu opcją
+  -speed albo odtwarzać klatka po klatce.
+  Spróbuj użyć opcji <option>-speed</option> 0.2 żeby oglądać film bardzo
+  wolno, albo naciskaj wielokrotnie klawisz "<keycap>.</keycap>" żeby
+  wyświetlać jedną klatkę na raz. Może to pomóc zidentyfikować wzorzec jeśli
+  nie możesz go dostrzec przy pełnej prędkości.
+</para>
+</note>
+</sect3>
+</sect2>
+
+<sect2 id="menc-feat-dvd-mpeg4-2pass">
+<title>Stały kwantyzator a tryb wieloprzebiegowy</title>
+
+<para>
+  Jest możliwe zakodowanie filmu z szeroką gamą jakości.
+  Z nowoczesnymi koderami i odrobiną kompresji przed kodekiem (zmniejszenie
+  rozdzielczości i usuwanie szumu), możliwe jest osiągnięcie bardzo dobrej
+  jakości przy 700 MB, dla 90-110 minutowego filmu kinowego.
+  Dodatkowo tylko najdłuższe filmy nie dają się zakodować na 1400 MB z prawie
+  doskonałą jakością.
+</para>
+
+<para>
+  Są trzy podejścia do kodowania video: stały bitrate (CBR),
+  stały kwantyzator i tryb wieloprzebiegowy (ABR, uśrednione bitrate).
+</para>
+
+<para>
+  Złożoność klatek filmu, a zatem i ilość bitów potrzebna na ich zakodowanie,
+  może się bardzo mocno zmieniać w zależności od sceny.
+  Nowoczesne kodery potrafią się dostosowywać do tych zmian i zmieniać
+  bitrate.
+  Jednak w prostych trybach, takich jak CBR, kodery nie znają zapotrzebowania
+  na bitrate w przyszłych scenach, więc nie mogą na długo przekraczać
+  wymaganego bitrate.
+  Bardziej zaawansowane tryby, takie jak kodowanie wieloprzebiegowe, potrafią
+  wziąć pod uwagę statystyki z poprzednich przebiegów; to naprawia wyżej
+  wymieniony problem.
+</para>
+
+<note><title>Uwaga:</title>
+<para>
+  Większość kodeków obsługujących kodowanie ABR obsługuje tylko kodowanie
+  dwuprzebiegowe, podczas gdy niektóre inne, na przykład
+  <systemitem class="library">x264</systemitem> albo
+  <systemitem class="library">XviD</systemitem> potrafią wykonywać wiele
+  przebiegów, z lekką poprawą jakości po każdym przebiegu. Jednak ta poprawa
+  nie jest zauważalna ani mierzalna po około 4tym przebiegu.
+  Dlatego też, w tej części, tryb dwuprzebiegowy i wieloprzebiegowy będą
+  używane zamiennie.
+</para>
+</note>
+
+<para>
+  W każdym z tych trybów, kodek video (na przykład
+  <systemitem class="library">libavcodec</systemitem>)
+  dzieli klatkę obrazu na makrobloki 16x16 pikseli i stosuje do każdego z nich
+  kwantyzator. Im niższy kwantyzator, tym lepsza jakość i tym wyższe bitrate.
+  Metody jakiej koder używa do ustalenia kwantyzatora są różne i można nimi
+  sterować. (Jest to straszliwe uproszczenie, ale wystarcza do zrozumienia
+  podstaw.)
+</para>
+
+<para>
+  Kiedy podajesz stałe bitrate, kodek koduje usuwając tyle szczegółów ile musi
+  i tak mało jak to tylko możliwe żeby pozostać poniżej podanego bitrate.
+  Jeśli na prawdę nie obchodzi cię wielkość pliku, możesz użyć CBR i podać
+  nieskończone bitrate (W praktyce oznacza to bitrate na tyle wysokie że nie
+  stanowi bariery, na przykład 10000Kbit.) Bez żadnego ograniczenia na bitrate
+  kodek użyje najniższego możliwego kwantyzatora do każdej klatki (ustalonego
+  dla <systemitem class="library">libavcodec</systemitem> opcją
+  <option>vqmin</option>, domyślnie 2).
+  Gdy tylko podasz bitrate na tyle niskie że kodek musi używać wyższego
+  kwantyzatora, to prawie na pewno niszczysz film.
+  Żeby tego uniknąć, powinieneś pewnie zmniejszyć rozdzielczość filmu, metodą
+  opisaną dalej.
+  Ogólnie, jeśli troszczysz się o jakość, powinieneś unikać CBR.
+</para>
+
+<para>
+  Przy stałym kwantyzatorze, kodek używa na każdym makrobloku tego samego
+  kwantyzatora, podanego opcją <option>vqscale</option>
+  (w przypadku <systemitem class="library">libavcodec</systemitem>).
+  Jeśli chcesz możliwie najlepszy efekt, znów ignorując bitrate, możesz użyć
+  <option>vqscale=2</option>. Da to ten sam bitrate i PSNR (peak
+  signal-to-noise ratio, szczytowa proporcja sygnału do szumu) co CBR
+  z <option>vbitrate</option>=nieskończoność i domyślnym
+  <option>vqmin</option>.
+</para>
+
+<para>
+  Problemem przy stałym kwantyzatorze jest to, że używa podanego kwantyzatora
+  niezależnie od tego czy makroblok tego wymaga czy nie. To znaczy że można by
+  było zastosować do makrobloku wyższy kwantyzator bez utraty postrzegalnej
+  jakości. Dlaczego marnować bity na niepotrzebnie niski kwantyzator?
+  Mikroprocesor ma tyle cykli ile jest czasu, ale jest tylko pewna ilość bitów
+  na twardym dysku.
+</para>
+
+<para>
+  Przy kodowaniu dwuprzebiegowym, pierwszy przebieg potraktuje film jak przu
+  ustawieniu CBR, ale zachowa informacje o własnościach każdej klatki. Te dane
+  są później używane przy drugim przebiegu do podejmowania słusznych decyzji
+  o używanym kwantyzatorze. Przy szybkich scenach albo niewielu szczegółach
+  pewnie użyje większego kwantyzatora, podczas gdy dla powolnych,
+  szczegółowych scen będzie niższy kwantyzator.
+</para>
+
+<para>
+  Jeśli używasz <option>vqscale=2</option> to marnujesz bity. Jeśli używasz
+  <option>vqscale=3</option> to nie dostajesz najlepszej możliwej jakości.
+  Załóżmy że zakodowałeś swoje DVD przy <option>vqscale=3</option>
+  i dostałeś bitrate 1800Kbit. Jeśli zrobisz dwa przebiegi
+  z <option>vbitrate=1800</option> ostateczny wynik będzie miał
+  <emphasis role="bold">wyższą jakość</emphasis> przy
+  <emphasis role="bold">tym samym bitrate</emphasis>.
+</para>
+
+<para>
+  Ponieważ jesteś już przekonany że prawidłowym wyborem są dwa przebiegi,
+  prawdziwym pytaniem jest jakiego bitrate użyć. Nie ma jednej odpowiedzi.
+  Idealnie chcesz wybrać bitrate będący najbliżej równowagi między jakością
+  a wielkością pliku. To się zmienia w zależności od filmu.
+</para>
+
+<para>
+  Jeśli wielkość nie ma znaczenia, dobrym punktem wyjściowym do bardzo
+  wysokiej jakości jest około 2000Kbit plus minus 200Kbit.
+  Jeśli jest dużo akcji albo szczegółów, albo po prostu masz bardzo wrażliwe
+  oko, możesz się zdecydować na 2400 albo 2600.
+  Przy niektórych DVD możesz nie zauważyć różnicy przy 1400Kbit. Dobrym
+  pomysłem jest poeksperymentowanie z kilkoma scenami i różnymi wartościami
+  bitrate żeby nabrać wyczucia.
+</para>
+
+<para>
+  Jeśli chcesz konkretnej wielkości, musisz jakoś obliczyć bitrare.
+  Ale zanim to zrobisz, musisz wiedzieć ile miejsca potrzebujesz na dźwięk,
+  więc powinieneś <link linkend="menc-feat-dvd-mpeg4-audio">ściągnąć go</link>
+  najpierw.
+  Możesz wyliczyć bitrate z następującego równania:
+  <systemitem>bitrate = (wielkość_docelowa_w_MBajtach - wielkość_dźwięku_w_MB)
+  * 1024 * 1024 / długość_w_sekundach * 8 / 1000</systemitem>
+  Na przykład by wcisność dwugodzinny film na płytkę 702MB, z 60MB ścieżki
+  dźwiękowej, bitrate video musi być:
+  <systemitem>(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000
+  = 740kbps</systemitem>
+</para>
+
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-constraints">
+<title>Constraints for efficient encoding</title>
+
+<para>
+  Due to the nature of MPEG-type compression, there are various
+  constraints you should follow for maximal quality.
+  MPEG splits the video up into 16x16 squares called macroblocks,
+  each composed of 4 8x8 blocks of luma (intensity) information and two
+  half-resolution 8x8 chroma (color) blocks (one for red-cyan axis and
+  the other for the blue-yellow axis).
+  Even if your movie width and height are not multiples of 16, the
+  encoder will use enough 16x16 macroblocks to cover the whole picture
+  area, and the extra space will go to waste.
+  So in the interests of maximizing quality at a fixed filesize, it is
+  a bad idea to use dimensions that are not multiples of 16.
+</para>
+
+<para>
+  Most DVDs also have some degree of black borders at the edges. Leaving
+  these in place can hurt quality in several ways.
+</para>
+
+<orderedlist>
+<listitem>
+<para>
+  MPEG-type compression is also highly dependent on frequency domain
+  transformations, in particular the Discrete Cosine Transform (DCT),
+  which is similar to the Fourier transform. This sort of encoding is
+  efficient for representing patterns and smooth transitions, but it
+  has a hard time with sharp edges. In order to encode them it must
+  use many more bits, or else an artifact known as ringing will
+  appear.
+</para>
+
+<para>
+  The frequency transform (DCT) takes place separately on each
+  macroblock (actually each block), so this problem only applies when
+  the sharp edge is inside a block. If your black borders begin
+  exactly at multiple-of-16 pixel boundaries, this is not a problem.
+  However, the black borders on DVDs rarely come nicely aligned, so
+  in practice you will always need to crop to avoid this penalty.
+</para>
+</listitem>
+</orderedlist>
+
+<para>
+  In addition to frequency domain transforms, MPEG-type compression uses
+  motion vectors to represent the change from one frame to the next.
+  Motion vectors naturally work much less efficiently for new content
+  coming in from the edges of the picture, because it is not present in
+  the previous frame. As long as the picture extends all the way to the
+  edge of the encoded region, motion vectors have no problem with
+  content moving out the edges of the picture. However, in the presence
+  of black borders, there can be trouble:
+</para>
+
+<orderedlist continuation="continues">
+<listitem>
+<para>
+  For each macroblock, MPEG-type compression stores a vector
+  identifying which part of the previous frame should be copied into
+  this macroblock as a base for predicting the next frame. Only the
+  remaining differences need to be encoded. If a macroblock spans the
+  edge of the picture and contains part of the black border, then
+  motion vectors from other parts of the picture will overwrite the
+  black border. This means that lots of bits must be spent either
+  re-blackening the border that was overwritten, or (more likely) a
+  motion vector will not be used at all and all the changes in this
+  macroblock will have to be coded explicitly. Either way, encoding
+  efficiency is greatly reduced.
+</para>
+
+<para>
+  Again, this problem only applies if black borders do not line up on
+  multiple-of-16 boundaries.
+</para>
+</listitem>
+
+<listitem>
+<para>
+  Finally, suppose we have a macroblock in the interior of the
+  picture, and an object is moving into this block from near the edge
+  of the image. MPEG-type coding cannot say "copy the part that is
+  inside the picture but not the black border." So the black border
+  will get copied inside too, and lots of bits will have to be spent
+  encoding the part of the picture that is supposed to be there.
+</para>
+
+<para>
+  If the picture runs all the way to the edge of the encoded area,
+  MPEG has special optimizations to repeatedly copy the pixels at the
+  edge of the picture when a motion vector comes from outside the
+  encoded area. This feature becomes useless when the movie has black
+  borders. Unlike problems 1 and 2, aligning the borders at multiples
+  of 16 does not help here.
+</para>
+</listitem>
+
+<listitem>
+<para>
+  Despite the borders being entirely black and never changing, there
+  is at least a minimal amount of overhead involved in having more
+  macroblocks.
+</para>
+</listitem>
+</orderedlist>
+
+<para>
+  For all of these reasons, it is recommended to fully crop black
+  borders. Further, if there is an area of noise/distortion at the edge
+  of the picture, cropping this will improve encoding efficiency as
+  well. Videophile purists who want to preserve the original as close as
+  possible may object to this cropping, but unless you plan to encode at
+  constant quantizer, the quality you gain from cropping will
+  considerably exceed the amount of information lost at the edges.
+</para>
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-crop">
+<title>Cropping and Scaling</title>
+
+<para>
+  Recall from the previous section that the final picture size you
+  encode should be a multiple of 16 (in both width and height).
+  This can be achieved by cropping, scaling, or a combination of both.
+</para>
+
+<para>
+  When cropping, there are a few guidelines that must be followed to
+  avoid damaging your movie.
+  The normal YUV format, 4:2:0, stores chroma (color) information
+  subsampled, i.e. chroma is only sampled half as often in each
+  direction as luma (intensity) information.
+  Observe this diagram, where L indicates luma sampling points and C
+  chroma.
+</para>
+
+<informaltable>
+<?dbhtml table-width="40%" ?>
+<?dbfo table-width="40%" ?>
+<tgroup cols="8" align="center">
+<colspec colnum="1" colname="col1"/>
+<colspec colnum="2" colname="col2"/>
+<colspec colnum="3" colname="col3"/>
+<colspec colnum="4" colname="col4"/>
+<colspec colnum="5" colname="col5"/>
+<colspec colnum="6" colname="col6"/>
+<colspec colnum="7" colname="col7"/>
+<colspec colnum="8" colname="col8"/>
+<spanspec spanname="spa1-2" namest="col1" nameend="col2"/>
+<spanspec spanname="spa3-4" namest="col3" nameend="col4"/>
+<spanspec spanname="spa5-6" namest="col5" nameend="col6"/>
+<spanspec spanname="spa7-8" namest="col7" nameend="col8"/>
+  <tbody>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+  </tbody>
+</tgroup>
+</informaltable>
+
+<para>
+  As you can see, rows and columns of the image naturally come in pairs.
+  Thus your crop offsets and dimensions <emphasis>must</emphasis> be
+  even numbers.
+  If they are not, the chroma will no longer line up correctly with the
+  luma.
+  In theory, it is possible to crop with odd offsets, but it requires
+  resampling the chroma which is potentially a lossy operation and not
+  supported by the crop filter.
+</para>
+
+<para>
+  Further, interlaced video is sampled as follows:
+</para>
+
+<informaltable>
+<?dbhtml table-width="80%" ?>
+<?dbfo table-width="80%" ?>
+<tgroup cols="16" align="center">
+<colspec colnum="1"  colname="col1"/>
+<colspec colnum="2"  colname="col2"/>
+<colspec colnum="3"  colname="col3"/>
+<colspec colnum="4"  colname="col4"/>
+<colspec colnum="5"  colname="col5"/>
+<colspec colnum="6"  colname="col6"/>
+<colspec colnum="7"  colname="col7"/>
+<colspec colnum="8"  colname="col8"/>
+<colspec colnum="9"  colname="col9"/>
+<colspec colnum="10" colname="col10"/>
+<colspec colnum="11" colname="col11"/>
+<colspec colnum="12" colname="col12"/>
+<colspec colnum="13" colname="col13"/>
+<colspec colnum="14" colname="col14"/>
+<colspec colnum="15" colname="col15"/>
+<colspec colnum="16" colname="col16"/>
+<spanspec spanname="spa1-2"   namest="col1" nameend="col2"/>
+<spanspec spanname="spa3-4"   namest="col3" nameend="col4"/>
+<spanspec spanname="spa5-6"   namest="col5" nameend="col6"/>
+<spanspec spanname="spa7-8"   namest="col7" nameend="col8"/>
+<spanspec spanname="spa9-10"  namest="col9" nameend="col10"/>
+<spanspec spanname="spa11-12" namest="col11" nameend="col12"/>
+<spanspec spanname="spa13-14" namest="col13" nameend="col14"/>
+<spanspec spanname="spa15-16" namest="col15" nameend="col16"/>
+  <tbody>
+    <row>
+      <entry namest="col1" nameend="col8">Top field</entry>
+      <entry namest="col9" nameend="col16">Bottom field</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry spanname="spa9-10">C</entry>
+      <entry spanname="spa11-12">C</entry>
+      <entry spanname="spa13-14">C</entry>
+      <entry spanname="spa15-16">C</entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry spanname="spa1-2">C</entry>
+      <entry spanname="spa3-4">C</entry>
+      <entry spanname="spa5-6">C</entry>
+      <entry spanname="spa7-8">C</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+    <row>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry spanname="spa9-10">C</entry>
+      <entry spanname="spa11-12">C</entry>
+      <entry spanname="spa13-14">C</entry>
+      <entry spanname="spa15-16">C</entry>
+    </row>
+    <row>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+      <entry>L</entry>
+    </row>
+  </tbody>
+</tgroup>
+</informaltable>
+
+<para>
+  As you can see, the pattern does not repeat until after 4 lines.
+  So for interlaced video, your y-offset and height for cropping must
+  be multiples of 4.
+</para>
+
+<para>
+  Native DVD resolution is 720x480 for NTSC, and 720x576 for PAL, but
+  there is an aspect flag that specifies whether it is full-screen (4:3) or
+  wide-screen (16:9). Many (if not most) widescreen DVDs are not strictly
+  16:9, and will be either 1.85:1 or 2.35:1 (cinescope). This means that
+  there will be black bands in the video that will need to be cropped out.
+</para>
+
+<para>
+  <application>MPlayer</application> provides a crop detection filter that
+  will determine the crop rectangle (<option>-vf cropdetect</option>).
+  Run <application>MPlayer</application> with
+  <option>-vf cropdetect</option> and it will print out the crop
+  settings to remove the borders.
+  You should let the movie run long enough that the whole picture
+  area is used, in order to get accurate crop values.
+</para>
+
+<para>
+  Then, test the values you get with <application>MPlayer</application>,
+  using the command line which was printed by
+  <option>cropdetect</option>, and adjust the rectangle as needed.
+  The <option>rectangle</option> filter can help by allowing you to
+  interactively position the crop rectangle over your movie.
+  Remember to follow the above divisibility guidelines so that you
+  do not misalign the chroma planes.
+</para>
+
+<para>
+  In certain cases, scaling may be undesirable.
+  Scaling in the vertical direction is difficult with interlaced
+  video, and if you wish to preserve the interlacing, you should
+  usually refrain from scaling.
+  If you will not be scaling but you still want to use multiple-of-16
+  dimensions, you will have to overcrop.
+  Do not undercrop, since black borders are very bad for encoding!
+</para>
+
+<para>
+  Because MPEG-4 uses 16x16 macroblocks, you will want to make sure that each
+  dimension of the video you are encoding is a multiple of 16 or else you
+  will be degrading quality, especially at lower bitrates. You can do this
+  by rounding the width and height of the crop rectangle down to the nearest
+  multiple of 16.
+  As stated earlier, when cropping, you will want to increase the Y offset by
+  half the difference of the old and the new height so that the resulting
+  video is taken from the center of the frame. And because of the way DVD
+  video is sampled, make sure the offset is an even number. (In fact, as a
+  rule, never use odd values for any parameter when you are cropping and
+  scaling video.) If you are not comfortable throwing a few extra pixels
+  away, you might prefer instead to scale the video instead. We will look
+  at this in our example below.
+  You can actually let the <option>cropdetect</option> filter do all of the
+  above for you, as it has an optional <option>round</option> parameter that
+  is equal to 16 by default.
+</para>
+
+<para>
+  Also, be careful about "half black" pixels at the edges. Make sure you
+  crop these out too, or else you will be wasting bits there that
+  are better spent elsewhere.
+</para>
+
+<para>
+  After all is said and done, you will probably end up with video whose pixels
+  are not quite 1.85:1 or 2.35:1, but rather something close to that. You
+  could calculate the new aspect ratio manually, but
+  <application>MEncoder</application> offers an option for <systemitem
+  class="library">libavcodec</systemitem> called <option>autoaspect</option>
+  that will do this for you. Absolutely do not scale this video up in order to
+  square the pixels unless you like to waste your hard disk space. Scaling
+  should be done on playback, and the player will use the aspect stored in
+  the AVI to determine the correct resolution.
+  Unfortunately, not all players enforce this auto-scaling information,
+  therefore you may still want to rescale.
+</para>
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-resolution-bitrate">
+<title>Choosing resolution and bitrate</title>
+
+<para>
+  If you will not be encoding in constant quantizer mode, you need to
+  select a bitrate.
+  The concept of bitrate is quite simple.
+  It is the (average) number of bits that will be consumed to store your
+  movie, per second.
+  Normally bitrate is measured in kilobits (1000 bits) per second.
+  The size of your movie on disk is the bitrate times the length of the
+  movie in time, plus a small amount of "overhead" (see the section on
+  <link linkend="menc-feat-dvd-mpeg4-muxing-avi-limitations">the AVI container</link>
+  for instance).
+  Other parameters such as scaling, cropping, etc. will
+  <emphasis role="bold">not</emphasis> alter the file size unless you
+  change the bitrate as well!.
+</para>
+<para>
+  Bitrate does <emphasis role="bold">not</emphasis> scale proportionally
+  to resolution.
+  That is to say, a 320x240 file at 200 kbit/sec will not be the same
+  quality as the same movie at 640x480 and 800 kbit/sec!
+  There are two reasons for this:
+<orderedlist>
+  <listitem><para>
+    <emphasis role="bold">Perceptual</emphasis>: You notice MPEG
+    artifacts more if they are scaled up bigger!
+    Artifacts appear on the scale of blocks (8x8).
+    Your eye will not see errors in 4800 small blocks as easily as it
+    sees errors in 1200 large blocks (assuming you will be scaling both
+    to fullscreen).
+  </para></listitem>
+  <listitem><para>
+    <emphasis role="bold">Theoretical</emphasis>: When you scale down
+    an image but still use the same size (8x8) blocks for the frequency
+    space transform, you move more data to the high frequency bands.
+    Roughly speaking, each pixel contains more of the detail than it
+    did before.
+    So even though your scaled-down picture contains 1/4 the information
+    in the spacial directions, it could still contain a large portion
+    of the information in the frequency domain (assuming that the high
+    frequencies were underutilized in the original 640x480 image).
+  </para></listitem>
+  </orderedlist>
+</para>
+<para>
+  Past guides have recommended choosing a bitrate and resolution based
+  on a "bits per pixel" approach, but this is usually not valid due to
+  the above reasons.
+  A better estimate seems to be that bitrates scale proportional to the
+  square root of resolution, so that 320x240 and 400 kbit/sec would be
+  comparable to 640x480 at 800 kbit/sec.
+  However this has not been verified with theoretical or empirical
+  rigor.
+  Further, given that movies vary greatly with regard to noise, detail,
+  degree of motion, etc., it is futile to make general recommendations
+  for bits per length-of-diagonal (the analog of bits per pixel,
+  using the square root).
+</para>
+<para>
+  So far we have discussed the difficulty of choosing a bitrate and
+  resolution.
+</para>
+
+
+<sect3 id="menc-feat-dvd-mpeg4-resolution-bitrate-compute">
+<title>Computing the resolution</title>
+<para>
+  First, you should compute the encoded aspect ratio:
+  <systemitem>ARc = (Wc x (ARa / PRdvd )) / Hc</systemitem>
+<itemizedlist>
+<title>where:</title>
+<listitem><para>
+  Wc and Hc are the width and height of the cropped video,
+</para></listitem>
+<listitem><para>
+  ARa is the displayed aspect ratio, which usually is 4/3 or 16/9,
+</para></listitem>
+<listitem><para>
+  PRdvd is the pixel ratio of the DVD which is equal to 1.25=(720/576) for PAL
+  DVDs and 1.5=(720/480) for NTSC DVDs,
+</para></listitem>
+</itemizedlist>
+</para>
+
+<para>
+  Then, you can compute the X and Y resolution, according to a certain
+  Compression Quality (CQ) factor:
+  <systemitem>ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16</systemitem>
+  and
+  <systemitem>ResX = INT( ResY * ARc / 16) * 16</systemitem>
+</para>
+
+<para>
+  Okay, but what is the CQ?
+  The CQ represents the number of bits per pixel and per frame of the encode.
+  Roughly speaking, the greater the CQ, the less the likelihood to see
+  encoding artifacts.
+  However, if you have a target size for your movie (1 or 2 CDs for instance),
+  there is a limited total number of bits that you can spend; therefore it is
+  necessary to find a good tradeoff between compressibility and quality.
+</para>
+
+<para>
+  The CQ depends both on the bitrate and the movie resolution.
+  In order to raise the CQ, typically you would downscale the movie given that the
+  bitrate is computed in function of the target size and the length of the
+  movie, which are constant.
+  A CQ below 0.18 usually ends up in a very blocky picture, because there
+  are not enough bits to code the information of each macroblock (MPEG4, like
+  many other codecs, groups pixels by blocks of several pixels to compress the
+  image; if there are not enough bits, the edges of those blocks are
+  visible).
+  It is therefore wise to take a CQ ranging from 0.20 to 0.22 for a 1 CD rip,
+  and 0.26-0.28 for 2 CDs.
+</para>
+
+<para>
+  Please take note that the CQ is just an indicative figure, as depending on
+  the encoded content, a CQ of 0.18 may look just fine for a Bergman, contrary
+  to a movie such as The Matrix, which contains many high-motion scenes.
+  On the other hand, it is worthless to raise CQ higher than 0.30 as you would
+  be wasting bits without any noticeable quality gain.
+</para>
+</sect3>
+
+</sect2>
+
+<sect2 id="menc-feat-dvd-mpeg4-filtering">
+<title>Filtering</title>
+
+<para>
+  Learning how to use <application>MEncoder</application>'s video filters
+  is essential to producing good encodes.
+  All video processing is performed through the filters -- cropping,
+  scaling, color adjustment, noise removal, sharpening, deinterlacing,
+  telecine, inverse telecine, and deblocking, just to name a few.
+  Along with the vast number of supported input formats, the variety of
+  filters available in <application>MEncoder</application> is one of its
+  main advantages over other similar programs.
+</para>
+
+<para>
+  Filters are loaded in a chain using the -vf option:
+
+  <screen>-vf filter1=options,filter2=options,...</screen>
+
+  Most filters take several numeric options separated by colons, but
+  the syntax for options varies from filter to filter, so read the man
+  page for details on the filters you wish to use.
+</para>
+
+<para>
+  Filters operate on the video in the order they are loaded.
+  For example, the following chain:
+
+  <screen>-vf crop=688:464:12:4,scale=640:464</screen>
+
+  will first crop the 688x464 region of the picture with upper-left
+  corner at (12,4), and then scale the result down to 640x464.
+</para>
+
+<para>
+  Certain filters need to be loaded at or near the beginning of the
+  filter chain, in order to take advantage of information from the
+  video decoder that will be lost or invalidated by other filters.
+  The principal examples are <option>pp</option> (postprocessing, only
+  when it is performing deblock or dering operations),
+  <option>spp</option> (another postprocessor to remove MPEG artifacts),
+  <option>pullup</option> (inverse telecine), and
+  <option>softpulldown</option> (for converting soft telecine to hard
+  telecine).
+</para>
+
+<para>
+  In general, you want to do as little filtering as possible to the movie
+  in order to remain close to the original DVD source. Cropping is often
+  necessary (as described above), but avoid to scale the video. Although
+  scaling down is sometimes preferred to using higher quantizers, we want
+  to avoid both these things: remember that we decided from the start to
+  trade bits for quality.
+</para>
+
+<para>
+  Also, do not adjust gamma, contrast, brightness, etc. What looks good
+  on your display may not look good on others. These adjustments should
+  be done on playback only.
+</para>
+
+<para>
+  One thing you might want to do, however, is pass the video through a
+  very light denoise filter, such as <option>-vf hqdn3d=2:1:2</option>.
+  Again, it is a matter of putting those bits to better use: why waste them
+  encoding noise when you can just add that noise back in during playback?
+  Increasing the parameters for <option>hqdn3d</option> will further
+  improve compressibility, but if you increase the values too much, you
+  risk degrading the image visibily. The suggested values above
+  (<option>2:1:2</option>) are quite conservative; you should feel free to
+  experiment with higher values and observe the results for yourself.
+</para>
+
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-interlacing">
+<title>Interlacing and Telecine</title>
+
+<para>
+  Almost all movies are shot at 24 fps. Because NTSC is 30000/1001 fps, some
+  processing must be done to this 24 fps video to make it run at the correct
+  NTSC framerate. The process is called 3:2 pulldown, commonly referred to
+  as telecine (because pulldown is often applied during the telecine
+  process), and, naively described, it works by slowing the film down to
+  24000/1001 fps, and repeating every fourth frame.
+</para>
+
+<para>
+  No special processing, however, is done to the video for PAL DVDs, which
+  run at 25 fps. (Technically, PAL can be telecined, called 2:2 pulldown,
+  but this does not become an issue in practice.) The 24 fps film is simply
+  played back at 25 fps. The result is that the movie runs slightly faster,
+  but unless you are an alien, you probably will not notice the difference.
+  Most PAL DVDs have pitch-corrected audio, so when they are played back at
+  25 fps things will sound right, even though the audio track (and hence the
+  whole movie) has a running time that is 4% less than NTSC DVDs.
+</para>
+
+<para>
+  Because the video in a PAL DVD has not been altered, you need not worry
+  much about framerate. The source is 25 fps, and your rip will be 25
+  fps. However, if you are ripping an NTSC DVD movie, you may need to
+  apply inverse telecine.
+</para>
+
+<para>
+  For movies shot at 24 fps, the video on the NTSC DVD is either telecined
+  30000/1001, or else it is progressive 24000/1001 fps and intended to be telecined
+  on-the-fly by a DVD player. On the other hand, TV series are usually
+  only interlaced, not telecined. This is not a hard rule: some TV series
+  are interlaced (such as Buffy the Vampire Slayer) whereas some are a
+  mixture of progressive and interlaced (such as Angel, or 24).
+</para>
+
+<para>
+  It is highly recommended that you read the section on
+  <link linkend="menc-feat-telecine">How to deal with telecine and interlacing in NTSC DVDs</link>
+  to learn how to handle the different possibilities.
+</para>
+
+<para>
+  However, if you are mostly just ripping movies, likely you are either
+  dealing with 24 fps progressive or telecined video, in which case you can
+  use the <option>pullup</option> filter <option>-vf
+  pullup,softskip</option>.
+</para>
+
+</sect2>
+
+<sect2 id="menc-feat-dvd-mpeg4-encoding-interlaced">
+<title>Encoding interlaced video</title>
+
+<para>
+  If the movie you want to encode is interlaced (NTSC video or
+  PAL video), you will need to choose whether you want to
+  deinterlace or not.
+  While deinterlacing will make your movie usable on progressive
+  scan displays such a computer monitors and projectors, it comes
+  at a cost: The fieldrate of 50 or 60000/1001 fields per second
+  is halved to 25 or 30000/1001 frames per second, and roughly half of
+  the information in your movie will be lost during scenes with
+  significant motion.
+</para>
+
+<para>
+  Therefore, if you are encoding for high quality archival purposes,
+  it is recommended not to deinterlace.
+  You can always deinterlace the movie at playback time when
+  displaying it on progressive scan devices, and future players will
+  be able to deinterlace to full fieldrate, interpolating 50 or
+  60000/1001 entire frames per second from the interlaced video.
+</para>
+
+<para>
+Special care must be taken when working with interlaced video:
+</para>
+
+<orderedlist>
+<listitem><para>
+  Crop height and y-offset must be multiples of 4.
+</para></listitem>
+<listitem><para>
+  Any vertical scaling must be performed in interlaced mode.
+</para></listitem>
+<listitem><para>
+  Postprocessing and denoising filters may not work as expected
+  unless you take special care to operate them a field at a time,
+  and they may damage the video if used incorrectly.
+</para></listitem>
+</orderedlist>
+
+<para>
+With these things in mind, here is our first example:
+</para>
+<screen>
+  mencoder <replaceable>capture.avi</replaceable> -mc 0 -oac lavc -ovc lavc -lavcopts \
+  vcodec=mpeg2video:vbitrate=6000:ilme:ildct:acodec=mp2:abitrate=224
+</screen>
+<para>
+Note the <option>ilme</option> and <option>ildct</option> options. 
+</para>
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-av-sync">
+<title>Notes on Audio/Video synchronization</title>
+<para>
+<application>MEncoder</application>'s audio/video synchronization
+algorithms were designed with the intention of recovering files with
+broken sync.
+However, in some cases they can cause unnecessary skipping and duplication of
+frames, and possibly slight A/V desync, when used with proper input
+(of course, A/V sync issues apply only if you process or copy the
+audio track while transcoding the video, which is strongly encouraged).
+Therefore, you may have to switch to basic A/V sync with
+the <option>-mc 0</option> option, or put this in your
+<systemitem>~/.mplayer/mencoder</systemitem> config file, as long as
+you are only working with good sources (DVD, TV capture, high quality
+MPEG-4 rips, etc) and not broken ASF/RM/MOV files.
+</para>
+<para>
+If you want to further guard against strange frame skips and
+duplication, you can use both <option>-mc 0</option> and
+<option>-noskip</option>.
+This will prevent <emphasis>all</emphasis> A/V sync, and copy frames
+one-to-one, so you cannot use it if you will be using any filters that
+unpredictably add or drop frames, or if your input file has variable
+framerate!
+Therefore, using <option>-noskip</option> is not in general recommended.
+</para>
+<para>
+The so-called "three-pass" audio encoding which <application>MEncoder</application>
+supports has been reported to cause A/V desync.
+This will definitely happen if it is used in conjunction with certain
+filters, therefore, it is now recommended <emphasis>not</emphasis> to
+use three-pass audio mode.
+This feature is only left for compatibility purposes and for expert
+users who understand when it is safe to use and when it is not.
+If you have never heard of three-pass mode before, forget that we
+even mentioned it!
+</para>
+<para>
+There have also been reports of A/V desync when encoding from stdin
+with <application>MEncoder</application>.
+Do not do this! Always use a file or CD/DVD/etc device as input.
+</para>
+</sect2>
+
+<sect2 id="menc-feat-dvd-mpeg4-audio">
+<title>Audio</title>
+
+<para>
+  Audio is a much simpler problem to solve: if you care about quality, just
+  leave it as is.
+  Even AC3 5.1 streams are at most 448Kbit/s, and they are worth every bit.
+  You might be tempted to transcode the audio to high quality Vorbis, but
+  just because you do not have an A/V receiver for AC3 pass-through today
+  does not mean you will not have one tomorrow. Future-proof your DVD rips by
+  preserving the AC3 stream.
+  You can keep the AC3 stream either by copying it directly into the video
+  stream <link linkend="menc-feat-mpeg4">during the encoding</link>.
+  You can also extract the AC3 stream in order to mux it into containers such
+  as NUT or Matroska.
+  <screen>mplayer <replaceable>source_file.vob</replaceable> -aid 129 -dumpaudio -dumpfile <replaceable>sound.ac3</replaceable></screen>
+  will dump into the file <replaceable>sound.ac3</replaceable> the
+  audio track number 129 from the file
+  <replaceable>source_file.vob</replaceable> (NB: DVD VOB files
+  usually use a different audio numbering,
+  which means that the VOB audio track 129 is the 2nd audio track of the file).
+</para>
+
+<para>
+  But sometimes you truly have no choice but to further compress the
+  sound so that more bits can be spent on the video.
+  Most people choose to compress audio with either MP3 or Vorbis audio
+  codecs.
+  While the latter is a very space-efficient codec, MP3 is better supported
+  by hardware players, although this trend is changing.
+</para>
+
+<para>
+  Do <emphasis>not</emphasis> use <option>-nosound</option> when encoding
+  a file with audio, even if you will be encoding and muxing audio
+  separately later.
+  Though it may work in ideal cases, using <option>-nosound</option> is
+  likely to hide some problems in your encoding command line setting.
+  In other words, having a soundtrack during your encode assures you that,
+  provided you do not see messages such as
+  <quote>Too many audio packets in the buffer</quote>, you will be able
+  to get proper sync.
+</para>
+
+<para>
+  You need to have <application>MEncoder</application> process the sound.
+  You can for example copy the orignal soundtrack during the encode with
+  <option>-oac copy</option> or convert it to a "light" 4 kHz mono WAV
+  PCM with <option>-oac pcm -channels 1 -srate 4000</option>.
+  Otherwise, in some cases, it will generate a video file that will not sync
+  with the audio.
+  Such cases are when the number of video frames in the source file does
+  not match up to the total length of audio frames or whenever there
+  are discontinuities/splices where there are missing or extra audio frames.
+  The correct way to handle this kind of problem is to insert silence or
+  cut audio at these points.
+  However <application>MPlayer</application> cannot do that, so if you
+  demux the AC3 audio and encode it with a separate app (or dump it to PCM with
+  <application>MPlayer</application>), the splices will be left incorrect
+  and the only way to correct them is to drop/dup video frames at the
+  splice.
+  As long as <application>MEncoder</application> sees the audio when it is
+  encoding the video, it can do this dropping/duping (which is usually OK
+  since it takes place at full black/scenechange, but if
+  <application>MEncoder</application> cannot see the audio, it will just
+  process all frames as-is and they will not fit the final audio stream when
+  you for example merge your audio and video track into a Matroska file.
+</para>
+
+<para>
+  First of all, you will have to convert the DVD sound into a WAV file that the
+  audio codec can use as input.
+  For example:
+  <screen>mplayer <replaceable>source_file.vob</replaceable> -ao pcm:file=<replaceable>destination_sound.wav</replaceable> -vc dummy -aid 1 -vo null</screen>
+  will dump the second audio track from the file
+  <replaceable>source_file.vob</replaceable> into the file
+  <replaceable>destination_sound.wav</replaceable>.
+  You may want to normalize the sound before encoding, as DVD audio tracks
+  are commonly recorded at low volumes.
+  You can use the tool <application>normalize</application> for instance,
+  which is available in most distributions.
+  If you are using Windows, a tool such as <application>BeSweet</application>
+  can do the same job.
+  You will compress in either Vorbis or MP3.
+  For example:
+  <screen>oggenc -q1 <replaceable>destination_sound.wav</replaceable></screen>
+  will encode <replaceable>destination_sound.wav</replaceable> with
+  the encoding quality 1, which is roughly equivalent to 80Kb/s, and
+  is the minimum quality at which you should encode if you care about
+  quality.
+  Please note that MEncoder currently cannot mux Vorbis audio tracks
+  into the output file because it only supports AVI and MPEG
+  containers as an output, each of which may lead to audio/video
+  playback synchronization problems with some players when the AVI file
+  contain VBR audio streams such as Vorbis.
+  Do not worry, this document will show you how you can do that with third
+  party programs.
+</para>
+
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-muxing">
+<title>Muxing</title>
+<para>
+  Now that you have encoded your video, you will most likely want
+  to mux it with one or more audio tracks into a movie container, such
+  as AVI, MPEG, Matroska or NUT.
+  <application>MEncoder</application> is currently only able to natively output
+  audio and video into MPEG and AVI container formats.
+  for example:
+  <screen>mencoder -oac copy -ovc copy  -o <replaceable>output_movie.avi</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable></screen>
+  This would merge the video file <replaceable>input_video.avi</replaceable>
+  and the audio file <replaceable>input_audio.mp2</replaceable>
+  into the AVI file <replaceable>output_movie.avi</replaceable>.
+  This command works with MPEG-1 layer I, II and III (more commonly known
+  as MP3) audio, WAV and a few other audio formats too.
+</para>
+
+<para>
+  MEncoder features experimental support for
+  <systemitem class="library">libavformat</systemitem>, which is a
+  library from the FFmpeg project that supports muxing and demuxing
+  a variety of containers.
+  For example:
+  <screen>mencoder -oac copy -ovc copy  -o <replaceable>output_movie.asf</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable> -of lavf -lavfopts format=asf</screen>
+  This will do the same thing as the previous example, except that
+  the output container will be ASF.
+  Please note that this support is highly experimental (but getting
+  better every day), and will only work if you compiled
+  <application>MPlayer</application> with the support for
+  <systemitem class="library">libavformat</systemitem> enabled (which
+  means that a pre-packaged binary version will not work in most cases).
+</para>
+
+
+<sect3 id="menc-feat-dvd-mpeg4-muxing-filter-issues">
+<title>Improving muxing and A/V sync reliability</title>
+<para>
+  You may experience some serious A/V sync problems while trying to mux
+  your video and some audio tracks, where no matter how you adjust the
+  audio delay, you will never get proper sync.
+  That may happen when you use some video filters that will drop or
+  duplicate some frames, like the inverse telecine filters.
+  It is strongly encouraged to append the <option>harddup</option> video
+  filter at the end of the filter chain to avoid this kind of problem.
+</para>
+
+<para>
+  Without <option>harddup</option>, if <application>MEncoder</application>
+  wants to duplicate a frame, it relies on the muxer to put a mark on the
+  container so that the last frame will be displayed again to maintain
+  sync while writing no actual frame.
+  With <option>harddup</option>, <application>MEncoder</application>
+  will instead just push the last frame displayed again into the filter
+  chain.
+  This means that the encoder receives the <emphasis>exact</emphasis>
+  same frame twice, and compresses it.
+  This will result in a slightly bigger file, but will not cause problems
+  when demuxing or remuxing into other container formats.
+</para>
+
+<para>
+  You may also have no choice but to use <option>harddup</option> with
+  container formats that are not too tightly linked with
+  <application>MEncoder</application> such as the ones supported through
+  <systemitem class="library">libavformat</systemitem>, which may not
+  support frame duplication at the container level.
+</para>
+</sect3>
+
+
+<sect3 id="menc-feat-dvd-mpeg4-muxing-avi-limitations">
+<title>Limitations of the AVI container</title>
+<para>
+  Although it is the most widely-supported container format after MPEG-1,
+  AVI also has some major drawbacks.
+  Perhaps the most obvious is the overhead.
+  For each chunk of the AVI file, 24 bytes are wasted on headers and
+  index.
+  This translates into a little over 5 MB per hour, or 1-2.5%
+  overhead for a 700 MB movie. This may not seem like much, but it could
+  mean the difference between being able to use 700 kbit/sec video or
+  714 kbit/sec, and every bit of quality counts.
+</para>
+
+<para>
+  In addition this gross inefficiency, AVI also has the following major
+  limitations:
+</para>
+
+<orderedlist>
+<listitem>
+<para>
+  Only fixed-fps content can be stored. This is particularly limiting
+  if the original material you want to encode is mixed content, for
+  example a mix of NTSC video and film material.
+  Actually there are hacks that can be used to store mixed-framerate
+  content in AVI, but they increase the (already huge) overhead
+  fivefold or more and so are not practical.
+</para>
+</listitem>
+<listitem>
+<para>
+  Audio in AVI files must be either constant-bitrate (CBR) or
+  constant-framesize (i.e. all frames decode to the same number of
+  samples).
+  Unfortunately, the most efficient codec, Vorbis, does not meet
+  either of these requirements.
+  Therefore, if you plan to store your movie in AVI, you will have to
+  use a less efficient codec such as MP3 or AC3.
+</para>
+</listitem>
+</orderedlist>
+
+<para>
+  Having said all that, <application>MEncoder</application> does not
+  currently support variable-fps output or Vorbis encoding.
+  Therefore, you may not see these as limitations if
+  <application>MEncoder</application> is the
+  only tool you will be using to produce your encodes.
+  However, it is possible to use <application>MEncoder</application>
+  only for video encoding, and then use external tools to encode
+  audio and mux it into another container format.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-dvd-mpeg4-muxing-matroska">
+<title>Muxing into the Matroska container</title>
+<para>
+  Matroska is a free, open standard container format, aiming
+  to offer a lot of advanced features, which older containers
+  like AVI cannot handle.
+  For example, Matroska supports variable bitrate audio content
+  (VBR), variable framerates (VFR), chapters, file attachments,
+  error detection code (EDC) and modern A/V Codecs like "Advanced Audio
+  Coding" (AAC), "Vorbis" or "MPEG-4 AVC" (H.264), next to nothing
+  handled by AVI.
+</para>
+
+<para>
+  The tools required to create Matroska files are collectively called
+  <application>mkvtoolnix</application>, and are available for most
+  Unix platforms as well as <application>Windows</application>.
+  Because Matroska is an open standard you may find other
+  tools that suit you better, but since mkvtoolnix is the most
+  common, and is supported by the Matroska team itself, we will
+  only cover its usage.
+</para>
+
+<para>
+  Probably the easiest way to get started with Matroska is to use 
+  <application>MMG</application>, the graphical frontend shipped with
+  <application>mkvtoolnix</application>, and follow the
+  <ulink url="http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge-gui.html">guide to mkvmerge GUI (mmg)</ulink>
+</para>
+
+<para>
+  You may also mux audio and video files using the command line:
+  <screen>mkvmerge -o <replaceable>output.mkv</replaceable> <replaceable>input_video.avi</replaceable> <replaceable>input_audio1.mp3</replaceable> <replaceable>input_audio2.ac3</replaceable></screen>
+  This would merge the video file <replaceable>input_video.avi</replaceable>
+  and the two audio files <replaceable>input_audio1.mp3</replaceable>
+  and <replaceable>input_audio2.ac3</replaceable> into the Matroska
+  file <replaceable>output.mkv</replaceable>.
+  Matroska, as mentioned earlier, is able to do much more than that, like
+  multiple audio tracks (including fine-tuning of audio/video
+  synchronization), chapters, subtitles, splitting, etc...
+  Please refer to the documentation of those applications for
+  more details.
+</para>
+
+</sect3>
+
+</sect2>
+
+</sect1>
+
+<sect1 id="menc-feat-telecine">
+<title>How to deal with telecine and interlacing within NTSC DVDs</title>
+
+<sect2 id="menc-feat-telecine-intro">
+<title>Introduction</title>
+<formalpara>
+<title>What is telecine?</title>
+<para>
+  I suggest you visit this page if you do not understand much of what
+  is written in this document:
+  <ulink url="http://www.divx.com/support/guides/guide.php?gid=10">http://www.divx.com/support/guides/guide.php?gid=10</ulink>
+  This URL links to an understandable and reasonably comprehensive
+  description of what telecine is.
+</para></formalpara>
+
+<formalpara>
+<title>A note about the numbers.</title>
+<para>
+  Many documents, including the guide linked above, refer to the fields
+  per second value of NTSC video as 59.94 and the corresponding frames
+  per second values as 29.97 (for telecined and interlaced) and 23.976
+  (for progressive). For simplicity, some documents even round these
+  numbers to 60, 30, and 24.
+</para></formalpara>
+
+<para>
+  Strictly speaking, all those numbers are approximations. Black and
+  white NTSC video was exactly 60 fields per second, but 60000/1001
+  was later chosen to accomodate color data while remaining compatible
+  with contemporary black and white televisions. Digital NTSC video
+  (such as on a DVD) is also 60000/1001 fields per second. From this,
+  interlaced and telecined video are derived to be 30000/1001 frames
+  per second; progressive video is 24000/1001 frames per second.
+</para>
+
+<para>
+  Older versions of the <application>MEncoder</application> documentation
+  and many archived mailing list posts refer to 59.94, 29.97, and 23.976.
+  All <application>MEncoder</application> documentation has been updated
+  to use the fractional values, and you should use them too.
+</para>
+
+<para>
+  <option>-ofps 23.976</option> is incorrect.
+  <option>-ofps 24000/1001</option> should be used instead.
+</para>
+
+<formalpara>
+<title>How telecine is used.</title>
+<para>
+  All video intended to be displayed on an NTSC
+  television set must be 60000/1001 fields per second. Made-for-TV movies
+4  and shows are often filmed directly at 60000/1001 fields per second, but
+  the majority of cinema is filmed at 24 or 24000/1001 frames per
+  second. When cinematic movie DVDs are mastered, the video is then
+  converted for television using a process called telecine.
+</para></formalpara>
+
+<para>
+  On a DVD, the video is never actually stored as 60000/1001 fields per
+  second. For video that was originally 60000/1001, each pair of fields is
+  combined to form a frame, resulting in 30000/1001 frames per
+  second. Hardware DVD players then read a flag embedded in the video
+  stream to determine whether the odd- or even-numbered lines should
+  form the first field.
+</para>
+
+<para>
+  Usually, 24000/1001 frames per second content stays as it is when
+  encoded for a DVD, and the DVD player must perform telecining
+  on-the-fly. Sometimes, however, the video is telecined
+  <emphasis>before</emphasis> being stored on the DVD; even though it
+  was originally 24000/1001 frames per second, it becomes 60000/1001 fields per
+  second. When it is stored on the DVD, pairs of fields are combined to form
+  30000/1001 frames per second.
+</para>
+
+<para>
+  When looking at individual frames formed from 60000/10001 fields per
+  second video, telecined or otherwise, interlacing is clearly visible
+  wherever there is any motion, because one field (say, the
+  even-numbered lines) represents a moment in time 1/(60000/1001)
+  seconds later than the other. Playing interlaced video on a computer
+  looks ugly both because the monitor is higher resolution and because
+  the video is shown frame-after-frame instead of field-after-field.
+</para>
+
+<itemizedlist>
+<title>Notes:</title>
+<listitem><para>
+  This section only applies to NTSC DVDs, and not PAL.
+  </para></listitem>
+<listitem><para>
+  The example <application>MEncoder</application> lines throughout the
+  document are <emphasis role="bold">not</emphasis> intended for
+  actual use. They are simply the bare minimum required to encode the
+  pertaining video category. How to make good DVD rips or fine-tune
+  <systemitem class="library">libavcodec</systemitem> for maximal
+  quality is not within the scope of this document.
+  </para></listitem>
+<listitem><para>
+  There are a couple footnotes specific to this guide, linked like this:
+  <link linkend="menc-feat-telecine-footnotes">[1]</link>
+  </para></listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="menc-feat-telecine-ident">
+<title>How to tell what type of video you have</title>
+
+<sect3 id="menc-feat-telecine-ident-progressive">
+<title>Progressive</title>
+<para>
+  Progressive video was originally filmed at 24000/1001 fps, and stored
+  on the DVD without alteration.
+</para>
+
+<para>
+  When you play a progressive DVD in <application>MPlayer</application>,
+  <application>MPlayer</application> will print the following line as
+  soon as the movie begins to play:
+
+  <screen> demux_mpg: 24000/1001 fps progressive NTSC content detected, switching framerate.</screen>
+
+  From this point forward, demux_mpg should never say it finds
+  &quot;30000/1001 fps NTSC content.&quot;
+</para>
+
+<para>
+  When you watch progressive video, you should never see any
+  interlacing. Beware, however, because sometimes there is a tiny bit
+  of telecine mixed in where you would not expect. I have encountered TV
+  show DVDs that have one second of telecine at every scene change, or
+  at seemingly random places. I once watched a DVD that had a
+  progressive first half, and the second half was telecined. If you
+  want to be <emphasis>really</emphasis> thorough, you can scan the
+  entire movie:
+
+  <screen>mplayer dvd://1 -nosound -vo null -benchmark</screen>
+
+  Using <option>-benchmark</option> makes
+  <application>MPlayer</application> play the movie as quickly as it
+  possibly can; still, depending on your hardware, it can take a
+  while. Every time demux_mpg reports a framerate change, the line
+  immediately above will show you the time at which the change
+  occurred.
+</para>
+
+<para>
+  Sometimes progressive video on DVDs is referred to as
+  &quot;soft-telecine&quot; because it is intended to
+  be telecined by the DVD player.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-ident-telecined">
+<title>Telecined</title>
+<para>
+  Telecined video was originally filmed at 24000/1001, but was telecined
+  <emphasis>before</emphasis> it was written to the DVD.
+</para>
+
+<para>
+  <application>MPlayer</application> does not (ever) report any
+  framerate changes when it plays telecined video.
+</para>
+
+<para>
+  Watching a telecined video, you will see interlacing artifacts that
+  seem to &quot;blink&quot;: they repeatedly appear and disappear.
+  You can look closely at this by
+  <orderedlist>
+  <listitem>
+    <screen>mplayer dvd://1</screen>
+    </listitem>
+  <listitem><para>
+    Seek to a part with motion.
+    </para></listitem>
+  <listitem><para>
+    Use the <keycap>.</keycap> key to step forward one frame at a time.
+    </para></listitem>
+  <listitem><para>
+    Look at the pattern of interlaced-looking and progressive-looking
+    frames. If the pattern you see is PPPII,PPPII,PPPII,... then the
+    video is telecined. If you see some other pattern, then the video
+    may have been telecined using some non-standard method;
+    <application>MEncoder</application> cannot losslessly convert
+    non-standard telecine to progressive. If you do not see any
+    pattern at all, then it is most likely interlaced.
+    </para></listitem>
+  </orderedlist>
+</para>
+
+<para>
+  Sometimes telecined video on DVDs is referred to as
+  &quot;hard-telecine&quot;. Since hard-telecine is already 60000/1001 fields
+  per second, the DVD player plays the video without any manipulation.
+</para>
+
+<para>
+  Another way to tell if your source is telecined or not is to play
+  the source with the <option>-vf pullup</option> and <option>-v</option>
+  command line options to see how <option>pullup</option> matches frames.
+  If the source is telecined, you should see on the console a 3:2 pattern
+  with <systemitem>0+.1.+2</systemitem> and <systemitem>0++1</systemitem>
+  alternating.
+  This technique has the advantage that you do not need to watch the
+  source to identify it, which could be useful if you wish to automate
+  the encoding procedure, or to carry out said procedure remotely via
+  a slow connection.
+</para>
+
+</sect3>
+
+<sect3 id="menc-feat-telecine-ident-interlaced">
+<title>Interlaced</title>
+<para>
+  Interlaced video was originally filmed at 60000/1001 fields per second,
+  and stored on the DVD as 30000/1001 frames per second. The interlacing effect
+  (often called &quot;combing&quot;) is a result of combining pairs of
+  fields into frames. Each field is supposed to be 1/(60000/1001) seconds apart,
+  and when they are displayed simultaneously the difference is apparent.
+</para>
+
+<para>
+  As with telecined video, <application>MPlayer</application> should
+  not ever report any framerate changes when playing interlaced content.
+</para>
+
+<para>
+  When you view an interlaced video closely by frame-stepping with the
+  <keycap>.</keycap> key, you will see that every single frame is interlaced.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-ident-mixedpt">
+<title>Mixed progressive and telecine</title>
+<para>
+  All of a &quot;mixed progressive and telecine&quot; video was originally
+  24000/1001 frames per second, but some parts of it ended up being telecined.
+</para>
+
+<para>
+  When <application>MPlayer</application> plays this category, it will
+  (often repeatedly) switch back and forth between &quot;30000/1001 fps NTSC&quot;
+  and &quot;24000/1001 fps progressive NTSC&quot;. Watch the bottom of
+  <application>MPlayer</application>'s output to see these messages.
+</para>
+
+<para>
+  You should check the &quot;30000/1001 fps NTSC&quot; sections to make sure
+  they are actually telecine, and not just interlaced.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-ident-mixedpi">
+<title>Mixed progressive and interlaced</title>
+<para>
+  In &quot;mixed progressive and interlaced&quot; content, progressive
+  and interlaced video have been spliced together.
+</para>
+
+<para>
+  This category looks just like &quot;mixed progressive and telecine&quot;,
+  until you examine the 30000/1001 fps sections and see that they do not have the
+  telecine pattern.
+</para>
+</sect3>
+
+</sect2>
+
+<sect2 id="menc-feat-telecine-encode">
+<title>How to encode each category</title>
+<para>
+  As I mentioned in the beginning, example <application>MEncoder</application>
+  lines below are <emphasis role="bold">not</emphasis> meant to actually be used;
+  they only demonstrate the minimum parameters to properly encode each category.
+</para>
+
+<sect3 id="menc-feat-telecine-encode-progressive">
+<title>Progressive</title>
+<para>
+  Progressive video requires no special filtering to encode. The only
+  parameter you need to be sure to use is
+  <option>-ofps 24000/1001</option>. Otherwise, <application>MEncoder</application>
+  will try to encode at 30000/1001 fps and will duplicate frames.
+</para>
+
+<para>
+  <screen>mencoder dvd://1 -oac copy -ovc lavc -ofps 24000/1001</screen>
+</para>
+
+<para>
+  It is often the case, however, that a video that looks progressive
+  actually has very short parts of telecine mixed in. Unless you are
+  sure, it is safest to treat the video as
+  <link linkend="menc-feat-telecine-encode-mixedpt">mixed progressive and telecine</link>.
+  The performance loss is small
+  <link linkend="menc-feat-telecine-footnotes">[3]</link>.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-encode-telecined">
+<title>Telecined</title>
+<para>
+  Telecine can be reversed to retrieve the original 24000/1001 content,
+  using a process called inverse-telecine.
+  <application>MPlayer</application> contains several filters to
+  accomplish this; the best filter, <option>pullup</option>, is described
+  in the <link linkend="menc-feat-telecine-encode-mixedpt">mixed
+  progressive and telecine</link> section.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-encode-interlaced">
+<title>Interlaced</title>
+<para>
+  For most practical cases it is not possible to retrieve a complete
+  progressive video from interlaced content. The only way to do so
+  without losing half of the vertical resolution is to double the
+  framerate and try to &quot;guess&quot; what ought to make up the
+  corresponding lines for each field (this has drawbacks - see method
+  3).
+</para>
+
+<orderedlist>
+<listitem><para>
+
+  Encode the video in interlaced form. Normally, interlacing wreaks
+  havoc with the encoder's ability to compress well, but
+  <systemitem class="library">libavcodec</systemitem> has two
+  parameters specifically for dealing with storing interlaced video a
+  bit better: <option> ildct</option> and <option>ilme</option>. Also,
+  using <option>mbd=2</option> is strongly recommended
+  <link linkend="menc-feat-telecine-footnotes">[2] </link> because it
+  will encode macroblocks as non-interlaced in places where there is
+  no motion. Note that <option>-ofps</option> is NOT needed here.
+
+  <screen>mencoder dvd://1 -oac copy -ovc lavc -lavcopts ildct:ilme:mbd=2</screen>
+  </para></listitem>
+<listitem><para>
+  Use a deinterlacing filter before encoding. There are several of
+  these filters available to choose from, each with its own advantages
+  and disadvantages. Consult <option>mplayer -pphelp</option> to see
+  what is available (grep for &quot;deint&quot;), and search the
+  <ulink url="http://www.mplayerhq.hu/homepage/design6/info.html#mailing_lists">
+  MPlayer mailing lists</ulink> to find many discussions about the
+  various filters. Again, the framerate is not changing, so no
+  <option>-ofps</option>. Also, deinterlacing should be done after
+  cropping <link linkend="menc-feat-telecine-footnotes">[1]</link> and
+  before scaling.
+
+  <screen>mencoder dvd://1 -oac copy -vf pp=lb -ovc lavc</screen>
+  </para></listitem>
+<listitem><para>
+  Unfortunately, this option is buggy with
+  <application>MEncoder</application>; it ought to work well with
+  <application>MEncoder G2</application>, but that is not here yet. You
+  might experience crahes. Anyway, the purpose of <option> -vf
+  tfields</option> is to create a full frame out of each field, which
+  makes the framerate 60000/1001. The advantage of this approach is that no
+  data is ever lost; however, since each frame comes from only one
+  field, the missing lines have to be interpolated somehow. There are
+  no very good methods of generating the missing data, and so the
+  result will look a bit similar to when using some deinterlacing
+  filters. Generating the missing lines creates other issues, as well,
+  simply because the amount of data doubles. So, higher encoding
+  bitrates are required to maintain quality, and more CPU power is
+  used for both encoding and decoding. tfields has several different
+  options for how to create the missing lines of each frame. If you
+  use this method, then Reference the manual, and chose whichever
+  option looks best for your material. Note that when using
+  <option>tfields</option> you
+  <emphasis role="bold">have to</emphasis> specify both
+  <option>-fps</option> and <option>-ofps</option> to be twice the
+  framerate of your original source.
+
+  <screen>mencoder dvd://1 -oac copy -vf tfields=2 -ovc lavc -fps 60000/1001 -ofps 60000/1001</screen>
+  </para></listitem>
+<listitem><para>
+  If you plan on downscaling dramatically, you can extract and encode
+  only one of the two fields. Of course, you will lose half the vertical
+  resolution, but if you plan on downscaling to at most 1/2 of the
+  original, the loss will not matter much. The result will be a
+  progressive 30000/1001 frames per second file. The procedure is to use
+  <option>-vf field</option>, then crop
+  <link linkend="menc-feat-telecine-footnotes">[1]</link> and scale
+  appropriately. Remember that you will have to adjust the scale to
+  compensate for the vertical resolution being halved.
+  <screen>mencoder dvd://1 -oac copy -vf field=0 -ovc lavc</screen>
+  </para></listitem>
+</orderedlist>
+</sect3>
+
+<sect3 id="menc-feat-telecine-encode-mixedpt">
+<title>Mixed progressive and telecine</title>
+<para>
+  In order to turn mixed progressive and telecine video into entirely
+  progressive video, the telecined parts have to be
+  inverse-telecined. There are three ways to accomplish this,
+  described below. Note that you should
+  <emphasis role="bold">always</emphasis> inverse-telecine before any
+  rescaling; unless you really know what you are doing,
+  inverse-telecine before cropping, too
+  <link linkend="menc-feat-telecine-footnotes">[1]</link>.
+  <option>-ofps 24000/1001</option> is needed here because the output video
+  will be 24000/1001 frames per second.
+</para>
+
+<itemizedlist>
+<listitem><para>
+  <option>-vf pullup</option> is designed to inverse-telecine
+  telecined material while leaving progressive data alone. In order to
+  work properly, <option>pullup</option> <emphasis role="bold">must</emphasis>
+  be followed by the <option>softskip</option> filter or
+  else <application>MEncoder</application> will crash.
+  <option>pullup</option> is, however, the cleanest and most
+  accurate method available for encoding both telecine and
+  &quot;mixed progressive and telecine&quot;.
+
+  <screen>mencoder dvd://1 -oac copy -vf pullup,softskip -ovc lavc -ofps 24000/1001</screen>
+  </para>
+
+
+  </listitem>
+  <listitem><para>
+  An older method
+  is to, rather than inverse-telecine the telecined parts, telecine
+  the non-telecined parts and then inverse-telecine the whole
+  video. Sound confusing? softpulldown is a filter that goes through
+  a video and makes the entire file telecined. If we follow
+  softpulldown with either <option>detc</option> or
+  <option>ivtc</option>, the final result will be entirely
+  progressive. <option>-ofps 24000/1001</option> is needed.
+
+  <screen>mencoder dvd://1 -oac copy -vf softpulldown,ivtc=1 -ovc lavc -ofps 24000/1001</screen>
+  </para>
+  </listitem>
+
+<listitem><para>
+  I have not used <option>-vf filmdint</option> myself, but here is what
+  D Richard Felker III has to say:
+
+  <blockquote><para>It is OK, but IMO it tries to deinterlace rather
+    than doing inverse telecine too often (much like settop DVD
+    players &amp; progressive TVs) which gives ugly flickering and
+    other artifacts. If you are going to use it, you at least need to
+    spend some time tuning the options and watching the output first
+    to make sure it is not messing up.</para></blockquote>
+  </para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3 id="menc-feat-telecine-encode-mixedpi">
+<title>Mixed progressive and interlaced</title>
+<para>
+  There are two options for dealing with this category, each of
+  which is a compromise. You should decide based on the
+  duration/location of each type.
+</para>
+
+<itemizedlist>
+<listitem><para>
+  Treat it as progressive. The interlaced parts will look interlaced,
+  and some of the interlaced fields will have to be dropped, resulting
+  in a bit of uneven jumpiness. You can use a postprocessing filter if
+  you want to, but it may slightly degrade the progressive parts.
+  </para>
+
+  <para>
+  This option should definitely not be used if you want to eventually
+  display the video on an interlaced device (with a TV card, for
+  example). If you have interlaced frames in a 24000/1001 frames per
+  second video, they will be telecined along with the progressive
+  frames. Half of the interlaced "frames" will be displayed for three
+  fields' duration (3/(60000/1001) seconds), resulting in a flicking
+  &quot;jump back in time&quot; effect that looks quite bad. If you
+  even attempt this, you <emphasis role="bold">must</emphasis> use a
+  deinterlacing filter like <option>lb</option> or
+  <option>l5</option>.
+  </para>
+
+  <para>
+  It may also be a bad idea for progressive display, too. It will drop
+  pairs of consecutive interlaced fields, resulting in a discontinuity
+  that can be more visible than with the second method, which shows
+  some progressive frames twice. 30000/1001 frames per second interlaced
+  video is already a bit choppy because it really should be shown at
+  60000/1001 fields per second, so the duplicate frames do not stand out as
+  much.
+  </para>
+
+  <para>
+  Either way, it is best to consider your content and how you intend to
+  display it. If your video is 90% progressive and you never intend to
+  show it on a TV, you should favor a progressive approach. If it is
+  only half progressive, you probably want to encode it as if it is all
+  interlaced.
+  </para>
+  </listitem>
+
+<listitem><para>
+  Treat it as interlaced. Some frames of the progressive parts will
+  need to be duplicated, resulting in uneven jumpiness. Again,
+  deinterlacing filters may slightly degrade the progressive parts.
+  </para></listitem>
+
+</itemizedlist>
+</sect3>
+
+</sect2>
+
+<sect2 id="menc-feat-telecine-footnotes">
+<title>Footnotes</title>
+<orderedlist>
+<listitem><formalpara>
+  <title>About cropping:</title>
+  <para>
+  Video data on DVDs are stored in a format called YUV 4:2:0. In YUV
+  video, luma (&quot;brightness&quot;) and chroma (&quot;color&quot;)
+  are stored separately. Because the human eye is somewhat less
+  sensitive to color than it is to brightness, in a YUV 4:2:0 picture
+  there is only one chroma pixel for every four luma pixels. In a
+  progressive picture, each square of four luma pixels (two on each
+  side) has one common chroma pixel. You must crop progressive YUV
+  4:2:0 to even resolutions, and use even offsets. For example,
+  <option>crop=716:380:2:26</option> is OK but
+  <option>crop=716:380:3:26 </option> is not.
+  </para>
+  </formalpara>
+
+  <para>
+  When you are dealing with interlaced YUV 4:2:0, the situation is a
+  bit more complicated. Instead of every four luma pixels in the
+  <emphasis>frame</emphasis> sharing a chroma pixel, every four luma
+  pixels in each <emphasis> field</emphasis> share a chroma
+  pixel. When fields are interlaced to form a frame, each scanline is
+  one pixel high. Now, instead of all four luma pixels being in a
+  square, there are two pixels side-by-side, and the other two pixels
+  are side-by-side two scanlines down. The two luma pixels in the
+  intermediate scanline are from the other field, and so share a
+  different chroma pixel with two luma pixels two scanlines away. All
+  this confusion makes it necessary to have vertical crop dimensions
+  and offsets be multiples of four. Horizontal can stay even.
+  </para>
+
+  <para>
+  For telecined video, I recommend that cropping take place after
+  inverse telecining. Once the video is progressive you only need to
+  crop by even numbers. If you really want to gain the slight speedup
+  that cropping first may offer, you must crop vertically by multiples
+  of four or else the inverse-telecine filter will not have proper data.
+  </para>
+
+  <para>
+  For interlaced (not telecined) video, you must always crop
+  vertically by multiples of four unless you use <option>-vf
+  field</option> before cropping.
+  </para>
+  </listitem>
+
+<listitem><formalpara>
+  <title>About encoding parameters and quality:</title>
+  <para>
+  Just because I recommend <option>mbd=2</option> here does not mean it
+  should not be used elsewhere. Along with <option>trell</option>,
+  <option>mbd=2</option> is one of the two
+   <systemitem class="library">libavcodec</systemitem> options that
+  increases quality the most, and you should always use at least those
+  two unless the drop in encoding speed is prohibitive (e.g. realtime
+  encoding). There are many other options to
+  <systemitem class="library">libavcodec</systemitem> that increase
+  encoding quality (and decrease encoding speed) but that is beyond
+  the scope of this document.
+  </para>
+  </formalpara>
+  </listitem>
+
+<listitem><formalpara>
+  <title>About the performance of pullup:</title>
+  <para>
+  It is safe to use <option>pullup</option> (along with <option>softskip
+  </option>) on progressive video, and is usually a good idea unless
+  the source has been definitively verified to be entirely progressive.
+  The performace loss is small for most cases. On a bare-minimum encode,
+  <option>pullup</option> causes <application>MEncoder</application> to
+  be 50% slower. Adding sound processing and advanced <option>lavcopts
+  </option> overshadows that difference, bringing the performance
+  decrease of using <option>pullup</option> down to 2%.
+  </para>
+  </formalpara>
+  </listitem>
+
+</orderedlist>
+
+</sect2>
+
+</sect1>
+
+
+<sect1 id="menc-feat-enc-libavcodec">
+<title>Encoding with the <systemitem class="library">libavcodec</systemitem>
+  codec family</title>
+
+<para>
+<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link>
+provides simple encoding to a lot of interesting video and audio formats.
+You can encode to the following codecs (more or less up to date):
+</para>
+
+<sect2 id="menc-feat-enc-libavcodec-video-codecs">
+<title><systemitem class="library">libavcodec</systemitem>'s video codecs</title>
+
+<para>
+<informaltable frame="all">
+<tgroup cols="2">
+<thead>
+<row><entry>Video codec name</entry><entry>Description</entry></row>
+</thead>
+<tbody>
+<row><entry>mjpeg</entry><entry>
+   Motion JPEG
+  </entry></row>
+<row><entry>ljpeg</entry><entry>
+   lossless JPEG
+  </entry></row>
+<row><entry>h261</entry><entry>
+  H.261
+  </entry></row>
+<row><entry>h263</entry><entry>
+  H.263
+  </entry></row>
+<row><entry>h263p</entry><entry>
+  H.263+
+  </entry></row>
+<row><entry>mpeg4</entry><entry>
+  ISO standard MPEG-4 (DivX 5, XviD compatible)
+  </entry></row>
+<row><entry>msmpeg4</entry><entry>
+  pre-standard MPEG-4 variant by MS, v3 (AKA DivX3)
+  </entry></row>
+<row><entry>msmpeg4v2</entry><entry>
+  pre-standard MPEG-4 by MS, v2 (used in old ASF files)
+  </entry></row>
+<row><entry>wmv1</entry><entry>
+  Windows Media Video, version 1 (AKA WMV7)
+  </entry></row>
+<row><entry>wmv2</entry><entry>
+  Windows Media Video, version 2 (AKA WMV8)
+  </entry></row>
+<row><entry>rv10</entry><entry>
+  RealVideo 1.0
+  </entry></row>
+<row><entry>rv20</entry><entry>
+  RealVideo 2.0
+  </entry></row>
+<row><entry>mpeg1video</entry><entry>
+  MPEG-1 video
+  </entry></row>
+<row><entry>mpeg2video</entry><entry>
+  MPEG-2 video
+  </entry></row>
+<row><entry>huffyuv</entry><entry>
+  lossless compression
+  </entry></row>
+<row><entry>asv1</entry><entry>
+  ASUS Video v1
+  </entry></row>
+<row><entry>asv2</entry><entry>
+  ASUS Video v2
+  </entry></row>
+<row><entry>ffv1</entry><entry>
+  FFmpeg's lossless video codec
+  </entry></row>
+<row><entry>svq1</entry><entry>
+  Sorenson video 1
+  </entry></row>
+<row><entry>flv</entry><entry>
+  Sorenson H.263 used in Flash Video
+  </entry></row>
+<row><entry>dvvideo</entry><entry>
+  Sony Digital Video
+  </entry></row>
+<row><entry>snow</entry><entry>
+  FFmpeg's experimental wavelet-based codec
+  </entry></row>
+</tbody>
+</tgroup>
+</informaltable>
+
+The first column contains the codec names that should be passed after the
+<literal>vcodec</literal> config, like: <option>-lavcopts vcodec=msmpeg4</option>
+</para>
+<informalexample>
+<para>
+An example with MJPEG compression:
+<screen>mencoder dvd://2 -o title2.avi -ovc lavc -lavcopts vcodec=mjpeg -oac copy</screen>
+</para>
+</informalexample>
+</sect2>
+
+<sect2 id="menc-feat-enc-libavcodec-audio-codecs">
+<title><systemitem class="library">libavcodec</systemitem>'s audio codecs</title>
+<para>
+<informaltable frame="all">
+<tgroup cols="2">
+<thead>
+<row><entry>Audio codec name</entry><entry>Description</entry></row>
+</thead>
+<tbody>
+  <row>
+    <entry>mp2</entry>
+    <entry>MPEG Layer 2</entry>
+  </row>
+  <row>
+    <entry>ac3</entry>
+    <entry>AC3, AKA Dolby Digital</entry>
+  </row>
+  <row>
+    <entry>adpcm_ima_wav</entry>
+    <entry>IMA adaptive PCM (4 bits per sample, 4:1 compression)</entry>
+  </row>
+  <row>
+    <entry>sonic</entry>
+    <entry>experimental lossy/lossless codec</entry>
+  </row>
+</tbody>
+</tgroup>
+</informaltable>
+
+The first column contains the codec names that should be passed after the
+<literal>acodec</literal> option, like: <option>-lavcopts acodec=ac3</option>
+</para>
+
+<informalexample>
+<para>
+An example with AC3 compression:
+<screen>mencoder dvd://2 -o title2.avi -oac lavc -lavcopts acodec=ac3 -ovc copy</screen>
+</para>
+</informalexample>
+
+<para>
+  Contrary to <systemitem class="library">libavcodec</systemitem>'s video
+  codecs, its audio codecs do not make a wise usage of the bits they are
+  given as they lack some minimal psychoacoustic model (if at all)
+  which most other codec implementations feature.
+  However, note that all these audio codecs are very fast and work
+  out-of-the-box everywhere <application>MEncoder</application> has been
+  compiled with <systemitem class="library">libavcodec</systemitem> (which
+  is the case most of time), and do not depend on external libraries.
+</para>
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-lavc-encoding-options">
+<title>Encoding options of libavcodec</title>
+
+<para>
+  Ideally, you would probably want to be able to just tell the encoder to switch
+  into "high quality" mode and move on.
+  That would probably be nice, but unfortunately hard to implement as different
+  encoding options yield different quality results depending on the source material.
+  That is because compression depends on the visual properties of the video
+  in question.
+  For example, anime and live action have very different properties and
+  thus require different options to obtain optimum encoding.
+  The good news is that some options should never be left out, like
+  <option>mbd=2</option>, <option>trell</option>, and <option>v4mv</option>.
+  See below for a detailed description of common encoding options.
+</para>
+
+
+<itemizedlist>
+<title>Options to adjust:</title>
+<listitem><para>
+  <emphasis role="bold">vmax_b_frames</emphasis>: 1 or 2 is good, depending on
+  the movie.
+  Note that if you need to have your encode be decodable by DivX5, you
+  need to activate closed GOP support, using
+  <systemitem class="library">libavcodec</systemitem>'s <option>cgop</option>
+  option, but you need to deactivate scene detection, which
+  is not a good idea as it will hurt encode efficiency a bit.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vb_strategy=1</emphasis>: helps in high-motion scenes.
+  On some videos, vmax_b_frames may hurt quality, but vmax_b_frames=2 along
+  with vb_strategy=1 helps.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">dia</emphasis>: motion search range. Bigger is better
+  and slower.
+  Negative values are a completely different scale.
+  Good values are -1 for a fast encode, or 2-4 for slower.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">predia</emphasis>: motion search pre-pass.
+  Not as important as dia. Good values are 1 (default) to 4. Requires preme=2
+  to really be useful.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Comparison function for
+  motion estimation.
+  Experiment with values of 0 (default), 2 (hadamard), 3 (dct), and 6 (rate
+  distortion).
+  0 is fastest, and sufficient for precmp.
+  For cmp and subcmp, 2 is good for anime, and 3 is good for live action.
+  6 may or may not be slightly better, but is slow.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">last_pred</emphasis>: Number of motion predictors to
+  take from the previous frame.
+  1-3 or so help at little speed cost.
+  Higher values are slow for no extra gain.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">cbp, mv0</emphasis>: Controls the selection of macroblocks.
+  Small speed cost for small quality gain.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">qprd</emphasis>: adaptive quantization based on the
+  macroblock's complexity.
+  May help or hurt depending on the video and other options.
+  This can cause artifacts unless you set vqmax to some reasonably small value
+  (6 is good, maybe as low as 4); vqmin=1 should also help.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">qns</emphasis>: very slow, especially when combined
+  with qprd.
+  This option will make the encoder minimize noise due to compression
+  artifacts instead of making the encoded video strictly match the source.
+  Do not use this unless you have already tweaked everything else as far as it
+  will go and the results still are not good enough.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vqcomp</emphasis>: Tweak ratecontrol.
+  What values are good depends on the movie.
+  You can safely leave this alone if you want.
+  Reducing vqcomp puts more bits on low-complexity scenes, increasing it puts
+  them on high-complexity scenes (default: 0.5, range: 0-1. recommended range:
+  0.5-0.7).
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vlelim, vcelim</emphasis>: Sets the single coefficient
+  elimination threshold for luminance and chroma planes.
+  These are encoded separately in all MPEG-like algorithms.
+  The idea behind these options is to use some good heuristics to determine
+  when the change in a block is less than the threshold you specify, and in
+  such a case, to just  encode the block as "no change".
+  This saves bits and perhaps speeds up encoding. vlelim=-4 and vcelim=9
+  seem to be good for live movies, but seem not to help with anime;
+  when encoding animation, you should probably leave them unchanged.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">qpel</emphasis>: Quarter pixel motion estimation.
+  MPEG-4 uses half pixel precision for its motion search by default,
+  therefore this option comes with an overhead as more information will be
+  stored in the encoded file.
+  The compression gain/loss depends on the movie, but it is usually not very
+  effective on anime.
+  qpel always incurs a significant cost in CPU decode time (+25% in
+  practice).
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">psnr</emphasis>: does not affect the actual encoding,
+  but writes a log file giving the type/size/quality of each frame, and
+  prints a summary of PSNR (Peak Signal to Noise Ratio) at the end.
+</para></listitem>
+
+</itemizedlist>
+
+<itemizedlist>
+<title>Options not recommended to play with:</title>
+<listitem><para>
+  <emphasis role="bold">vme</emphasis>: The default is best.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">lumi_mask, dark_mask</emphasis>: Psychovisual adaptive
+  quantization.
+  You do not want to play with those options if you care about quality.
+  Reasonable values may be effective in your case, but be warned this is very
+  subjective.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">scplx_mask</emphasis>: Tries to prevent blocky
+  artifacts, but postprocessing is better.
+</para></listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="menc-feat-mpeg4-lavc-example-settings">
+<title>Encoding setting examples</title>
+
+<para>
+  The following settings are examples of different encoding
+  option combinations that affect the speed vs quality tradeoff
+  at the same target bitrate.
+</para>
+
+<para>
+  All the encoding settings were tested on a 720x448 @30000/1001 fps
+  video sample, the target bitrate was 900kbps, and the machine was an
+  AMD-64 3400+ at 2400 Mhz in 64 bits mode.
+  Each encoding setting features the measured encoding speed (in
+  frames per second) and the PSNR loss (in dB) compared to the "very
+  high quality" setting.
+  Please understand that depending on your source, your machine type
+  and development advancements, you may get very different results.
+</para>
+
+<para>
+<informaltable frame="all">
+<tgroup cols="4">
+<thead>
+<row><entry>Description</entry><entry>Encoding options</entry><entry>speed (in fps)</entry><entry>Relative PSNR loss (in dB)</entry></row>
+</thead>
+<tbody>
+<row>
+  <entry>Very high quality</entry>
+  <entry><option>vcodec=mpeg4:mbd=2:mv0:trell:v4mv:cbp:last_pred=3:predia=2:dia=2:vmax_b_frames=2:vb_strategy=1:precmp=2:cmp=2:subcmp=2:preme=2:vme=5:naq:qns=2</option></entry>
+  <entry>6fps</entry>
+  <entry>0dB</entry>
+</row>
+<row>
+  <entry>High quality</entry>
+  <entry><option>vcodec=mpeg4:mbd=2:trell:v4mv:last_pred=2:dia=-1:vmax_b_frames=2:vb_strategy=1:cmp=3:subcmp=3:precmp=0:vqcomp=0.6:turbo</option></entry>
+  <entry>15fps</entry>
+  <entry>-0.5dB</entry>
+</row>
+<row>
+  <entry>Fast</entry>
+  <entry><option>vcodec=mpeg4:mbd=2:trell:v4mv:turbo</option></entry>
+  <entry>42fps</entry>
+  <entry>-0.74dB</entry>
+</row>
+<row>
+  <entry>Realtime</entry>
+  <entry><option>vcodec=mpeg4:mbd=2:turbo</option></entry>
+  <entry>54fps</entry>
+  <entry>-1.21dB</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+</para>
+</sect2>
+
+<sect2 id="custommatrices"><title>Custom inter/intra matrices</title>
+
+<para>
+With this feature of
+<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link>
+you are able to set custom inter (I-frames/keyframes) and intra
+(P-frames/predicted frames) matrices. It is supported by many of the codecs:
+<systemitem>mpeg1video</systemitem> and <systemitem>mpeg2video</systemitem>
+are reported as working.
+</para>
+
+<para>
+A typical usage of this feature is to set the matrices preferred by the
+<ulink url="http://www.kvcd.net/">KVCD</ulink> specifications.
+</para>
+
+<para>
+The <emphasis role="bold">KVCD &quot;Notch&quot; Quantization Matrix:</emphasis>
+</para>
+
+<para>
+Intra:
+<screen>
+ 8  9 12 22 26 27 29 34
+ 9 10 14 26 27 29 34 37
[phone] 38
[phone] 40
[phone] 48
[phone] 58
[phone] 69
[phone] 79
+</screen>
+
+Inter:
+<screen>
[phone] 30
[phone] 32
[phone] 34
[phone] 36
[phone] 38
[phone] 40
[phone] 42
[phone] 44
+</screen>
+</para>
+
+<para>
+Usage:
+<screen>
+$ mencoder <replaceable>input.avi</replaceable> -o <replaceable>output.avi</replaceable> -oac copy -ovc lavc -lavcopts inter_matrix=...:intra_matrix=...
+</screen>
+</para>
+
+<para>
+<screen>
+$ mencoder <replaceable>input.avi</replaceable> -ovc lavc -lavcopts
+vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,
+12,14,18,27,29,34,37,38,22,26,27,31,36,37,38,40,26,27,29,36,39,38,40,48,27,
+29,34,37,38,40,48,58,29,34,37,38,40,48,58,69,34,37,38,40,48,58,69,79
+:inter_matrix=16,18,20,22,24,26,28,30,18,20,22,24,26,28,30,32,20,22,24,26,
+28,30,32,34,22,24,26,30,32,32,34,36,24,26,28,32,34,34,36,38,26,28,30,32,34,
+36,38,40,28,30,32,34,36,38,42,42,30,32,34,36,38,40,42,44 -oac copy -o svcd.mpg
+</screen>
+</para>
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-example">
+<title>Example</title>
+
+<para>
+  So, you have just bought your shiny new copy of Harry Potter and the Chamber
+  of Secrets (widescreen edition, of course), and you want to rip this DVD
+  so that you can add it to your Home Theatre PC. This is a region 1 DVD,
+  so it is NTSC. The example below will still apply to PAL, except you will
+  omit <option>-ofps 24000/1001</option> (because the output framerate is the
+  same as the input framerate), and of course the crop dimensions will be
+  different.
+</para>
+
+<para>
+  After running <option>mplayer dvd://1</option>, we follow the process
+  detailed in the section <link linkend="menc-feat-telecine">How to deal
+  with telecine and interlacing in NTSC DVDs</link> and discover that it is
+  24000/1001 fps progressive video, which means that we need not use an inverse
+  telecine filter, such as <option>pullup</option> or
+  <option>filmdint</option>.
+</para>
+
+<para>
+  Next, we want to determine the appropriate crop rectangle, so we use the
+  cropdetect filter:
+
+  <screen>mplayer dvd://1 -vf cropdetect</screen>
+
+  Make sure you seek to a fully filled frame (such as a bright scene), and
+  you will see in <application>MPlayer</application>'s console output:
+
+  <screen>crop area: X: 0..719  Y: 57..419  (-vf crop=720:362:0:58)</screen>
+
+  We then play the movie back with this filter to test its correctness:
+
+  <screen>mplayer dvd://1 -vf crop=720:362:0:58</screen>
+
+  And we see that it looks perfectly fine. Next, we ensure the width and
+  height are a multiple of 16. The width is fine, however the height is
+  not. Since we did not fail 7th grade math, we know that the nearest
+  multiple of 16 lower than 362 is 352.
+</para>
+
+<para>
+  We could just use <option>crop=720:352:0:58</option>, but it would be nice
+  to take a little off the top and a little off the bottom so that we
+  retain the center. We have shrunk the height by 10 pixels, but we do not
+  want to increase the y-offset by 5-pixels since that is an odd number and
+  will adversely affect quality. Instead, we will increase the y-offset by
+  4 pixels:
+
+  <screen>mplayer dvd://1 -vf crop=720:352:0:62</screen>
+
+  Another reason to shave pixels from both the top and the bottom is that we
+  ensure we have eliminated any half-black pixels if they exist. Note that if
+  your video is telecined, make sure the <option>pullup</option> filter (or
+  whichever inverse telecine filter you decide to use) appears in the filter
+  chain before you crop. If it is interlaced, deinterlace before cropping.
+  (If you choose to preserve the interlaced video, then make sure your
+  vertical crop offset is a multiple of 4.)
+</para>
+
+<para>
+  If you are really concerned about losing those 10 pixels, you might
+  prefer instead to scale the dimensions down to the nearest multiple of 16.
+  The filter chain would look like:
+
+  <screen>-vf crop=720:362:0:58,scale=720:352</screen>
+
+  Scaling the video down like this will mean that some small amount of
+  detail is lost, though it probably will not be perceptible. Scaling up will
+  result in lower quality (unless you increase the bitrate). Cropping
+  discards those pixels altogether. It is a tradeoff that you will want to
+  consider for each circumstance. For example, if the DVD video was made
+  for television, you might want to avoid vertical scaling, since the line
+  sampling corresponds to the way the content was originally recorded.
+</para>
+
+<para>
+  On inspection, we see that our movie has a fair bit of action and high
+  amounts of detail, so we pick 2400Kbit for our bitrate.
+</para>
+
+<para>
+  We are now ready to do the two pass encode. Pass one:
+
+  <screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \
+-lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=1 \
+-o Harry_Potter_2.avi</screen>
+
+  And pass two is the same, except that we specify <option>vpass=2</option>:
+
+  <screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \
+-lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=2 \
+-o Harry_Potter_2.avi</screen>
+</para>
+
+<para>
+  The options <option>v4mv:mbd=2:trell</option> will greatly increase the
+  quality at the expense of encoding time. There is little reason to leave
+  these options out when the primary goal is quality. The options
+  <option>cmp=3:subcmp=3:mbcmp=3</option> select a comparison function that
+  yields higher quality than the defaults. You might try experimenting with
+  this parameter (refer to the man page for the possible values) as
+  different functions can have a large impact on quality depending on the
+  source material. For example, if you find
+  <systemitem class="library">libavcodec</systemitem> produces too much
+  blocky artifacting, you could try selecting the experimental NSSE as
+  comparison function via <option>*cmp=10</option>.
+</para>
+
+<para>
+  For this movie, the resulting AVI will be 138 minutes long and nearly
+  3GB. And because you said that file size does not matter, this is a
+  perfectly acceptable size. However, if you had wanted it smaller, you
+  could try a lower bitrate. Increasing bitrates have diminishing
+  returns, so while we might clearly see an improvement from 1800Kbit to
+  2000Kbit, it might not be so noticeable above 2000Kbit. Feel
+  free to experiment until you are happy.
+</para>
+
+<para>
+  Because we passed the source video through a denoise filter, you may want
+  to add some of it back during playback. This, along with the
+  <option>spp</option> post-processing filter, drastically improves the
+  perception of quality and helps eliminate blocky artifacts in the video.
+  With <application>MPlayer</application>'s <option>autoq</option> option,
+  you can vary the amount of post-processing done by the spp filter
+  depending on available CPU. Also, at this point, you may want to apply
+  gamma and/or color correction to best suit your display. For example:
+
+  <screen>mplayer Harry_Potter_2.avi -vf spp,noise=9ah:5ah,eq2=1.2 -autoq 3</screen>
+
+</para>
+</sect2>
+</sect1>
+
+
+<sect1 id="menc-feat-xvid">
+<title>Encoding with the <systemitem class="library">XviD</systemitem>
+codec</title>
+<para>
+ <systemitem class="library">XviD</systemitem> is a free library for
+ encoding MPEG-4 ASP video streams.
+ Before starting to encode, you need to <link linkend="xvid">
+ set up <application>MEncoder</application> to support it</link>.
+</para>
+<para>
+ This guide mainly aims at featuring the same kind of information
+ as x264's encoding guide.
+ Therefore, please begin by reading
+ <link linkend="menc-feat-x264-encoding-options-intro">the first part</link>
+ of that guide.
+</para>
+
+
+<sect2 id="menc-feat-xvid-intro">
+<title>What options should I use to get the best results?</title>
+
+<para>
+ Please begin by reviewing the
+ <systemitem class="library">XviD</systemitem> section of
+ <application>MPlayer</application>'s man page.
+ This section is intended to be a supplement to the man page.
+</para>
+<para>
+ The XviD default settings are already a good tradeoff between
+ speed and quality, therefore you can safely stick to them if
+ the following section puzzles you.
+</para>
+</sect2>
+
+<sect2 id="menc-feat-xvid-encoding-options">
+<title>Encoding options of <systemitem class="library">XviD</systemitem></title>
+
+<itemizedlist>
+<listitem><para>
+ <emphasis role="bold">vhq</emphasis>
+  This setting affects the macroblock decision algorithm, where the
+  higher the setting, the wiser the decision.
+  The default setting may be safely used for every encode, while
+  higher settings always help PSNR but are significantly slower.
+  Please note that a better PSNR does not necessarily mean
+  that the picture will look better, but tells you that it is
+  closer to the original.
+  Turning it off will noticeably speed up encoding; if speed is
+  critical for you, the tradeoff may be worth it.
+</para></listitem>
+
+<listitem><para>
+ <emphasis role="bold">bvhq</emphasis>
+  This does the same job as vhq, but does it on B-frames.
+  It has a negligible impact on speed, and slightly improves quality
+  (around +0.1dB PSNR).
+</para></listitem>
+
+<listitem><para>
+ <emphasis role="bold">max_bframes</emphasis>
+  A higher number of consecutive allowed B-frames usually improves
+  compressibility, although it may also lead to more blocking artifacts.
+  The default setting is a good tradeoff between compressibility and
+  quality, but you may increase it up to 3 if you are bitrate-starved.
+  You may also decrease it to 1 or 0 if you are aiming at perfect
+  quality, though in that case you should make sure your
+  target bitrate is high enough to ensure that the encoder does not
+  have to increase quantizers to reach it.
+</para></listitem>
+
+<listitem><para>
+ <emphasis role="bold">bf_threshold</emphasis>
+  This controls the B-frame sensitivity of the encoder, where a higher
+  value leads to more B-frames being used (and vice versa).
+  This setting is to be used together with <option>max_bframes</option>;
+  if you are bitrate-starved, you should increase both
+  <option>max_bframes</option> and <option>bf_threshold</option>,
+  while you may increase <option>max_bframes</option> and reduce
+  <option>bf_threshold</option> so that the encoder may use more
+  B-frames in places that only <emphasis role="bold">really</emphasis>
+  need them.
+  A low number of <option>max_bframes</option> and a high value of
+  <option>bf_threshold</option> is probably not a wise choice as it
+  will force the encoder to put B-frames in places that would not
+  benefit from them, therefore reducing visual quality.
+  However, if you need to be compatible with standalone players that
+  only support old DivX profiles (which only supports up to 1
+  consecutive B-frame), this would be your only way to
+  increase compressibility through using B-frames.
+</para></listitem>
+
+<listitem><para>
+ <emphasis role="bold">trellis</emphasis>
+  Optimizes the quantization process to get an optimal tradeoff
+  between PSNR and bitrate, which allows significant bit saving.
+  These bits will in return be spent elsewhere on the video,
+  raising overall visual quality.
+  You should always leave it on as its impact on quality is huge.
+  Even if you are looking for speed, do not disable it until you
+  have turned down <option>vhq</option> and all other more
+  CPU-hungry options to the minimum.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">hq_ac</emphasis>
+  Activates a better coefficient cost estimation method, which slightly
+  reduces filesize by around 0.15 to 0.19% (which corresponds to less
+  than 0.01dB PSNR increase), while having a negligible impact on speed.
+  It is therefore recommended to always leave it on.
+</para></listitem>
+
+<listitem><para>
+ <emphasis role="bold">cartoon</emphasis>
+  Designed to better encode cartoon content, and has no impact on
+  speed as it just tunes the mode decision heuristics for this type
+  of content.
+</para></listitem>
+
+<listitem><para>
+ <emphasis role="bold">me_quality</emphasis>
+  This setting is to control the precision of the motion estimation.
+  The higher <option>me_quality</option>, the more
+  precise the estimation of the original motion will be, and the
+  better the resulting clip will capture the original motion.
+ </para>
+ <para>
+  The default setting is best in all cases;
+  thus it is not recommended to turn it down unless you are
+  really looking for speed, as all the bits saved by a good motion
+  estimation would be spent elsewhere, raising overall quality.
+  Therefore, do not go any lower than 5, and even that only as a last
+  resort.
+</para></listitem>
+
+<listitem><para>
+ <emphasis role="bold">chroma_me</emphasis>
+  Improves motion estimation by also taking the chroma (color)
+  information into account, whereas <option>me_quality</option>
+  alone only uses luma (grayscale).
+  This slows down encoding by 5-10% but improves visual quality
+  quite a bit by reducing blocking effects and reduces filesize by
+  around 1.3%.
+  If you are looking for speed, you should disable this option before
+  starting to consider reducing <option>me_quality</option>.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">chroma_opt</emphasis>
+    Is intended to increase chroma image quality around pure
+    white/black edges, rather than improving compression.
+    This can help to reduce the "red stairs" effect.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">lumi_mask</emphasis>
+    Tries to give less bitrate to part of the picture that the
+    human eye cannot see very well, which should allow the encoder
+    to spend the saved bits on more important parts of the picture.
+    The quality of the encode yielded by this option highly depends
+    on personal preferences and on the type and monitor settings
+    used to watch it (typically, it will not look as good if it is
+    bright or if it is a TFT monitor).
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">qpel</emphasis>
+    Raise the number of candidate motion vectors by increasing
+    the precision of the motion estimation from halfpel to
+    quarterpel.
+    The idea is to find better motion vectors which will in return
+    reduce bitrate (hence increasing quality).
+    However, motion vectors with quarterpel precision require a
+    few extra bits to code, but the candidate vectors do not always
+    give (much) better results.
+    Quite often, the codec still spends bits on the extra precision,
+    but little or no extra quality is gained in return.
+    Unfortunately, there is no way to foresee the possible gains of
+    <option>qpel</option>, so you need to actually encode with and
+    without it to know for sure.
+  </para><para>
+    <option>qpel</option> can be almost double encoding time, and
+    requires as much as 25% more processing power to decode.
+    It is not supported by all standalone players.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">gmc</emphasis>
+    Tries to save bits on panning scenes by using a single motion
+    vector for the whole frame.
+    This almost always raises PSNR, but significantly slows down
+    encoding (as well as decoding).
+    Therefore, you should only use it when you have turned
+    <option>vhq</option> to the maximum.
+    <systemitem class="library">XviD</systemitem>'s GMC is more
+    sophisticated than DivX's, but is only supported by few
+    standalone players.
+</para></listitem>
+
+</itemizedlist>
+</sect2>
+
+<sect2 id="menc-feat-xvid-encoding-profiles">
+<title>Encoding profiles</title>
+<para>
+  XviD supports encoding profiles through the <option>profile</option> option,
+  which are used to impose restrictions on the properties of the XviD video
+  stream such that it will be playable on anything which supports the
+  chosen profile.
+  The restrictions relate to resolutions, bitrates and certain MPEG-4
+  features.
+  The following table shows what each profile supports.
+</para>
+<informaltable>
+<tgroup cols="16" align="center">
+<colspec colnum="1"  colname="col1"/>
+<colspec colnum="2"  colname="col2"/>
+<colspec colnum="3"  colname="col3"/>
+<colspec colnum="4"  colname="col4"/>
+<colspec colnum="5"  colname="col5"/>
+<colspec colnum="6"  colname="col6"/>
+<colspec colnum="7"  colname="col7"/>
+<colspec colnum="8"  colname="col8"/>
+<colspec colnum="9"  colname="col9"/>
+<colspec colnum="10" colname="col10"/>
+<colspec colnum="11" colname="col11"/>
+<colspec colnum="12" colname="col12"/>
+<colspec colnum="13" colname="col13"/>
+<colspec colnum="14" colname="col14"/>
+<colspec colnum="15" colname="col15"/>
+<colspec colnum="16" colname="col16"/>
+<colspec colnum="17" colname="col17"/>
+<spanspec spanname="spa2-5"   namest="col2" nameend="col5"/>
+<spanspec spanname="spa6-11"  namest="col6" nameend="col11"/>
+<spanspec spanname="spa12-17" namest="col12" nameend="col17"/>
+  <tbody>
+    <row>
+      <entry></entry>
+      <entry spanname="spa2-5">Simple</entry>
+      <entry spanname="spa6-11">Advanced Simple</entry>
+      <entry spanname="spa12-17">DivX</entry>
+    </row>
+    <row>
+      <entry>Profile name</entry>
+      <entry>0</entry>
+      <entry>1</entry>
+      <entry>2</entry>
+      <entry>3</entry>
+      <entry>0</entry>
+      <entry>1</entry>
+      <entry>2</entry>
+      <entry>3</entry>
+      <entry>4</entry>
+      <entry>5</entry>
+      <entry>Handheld</entry>
+      <entry>Portable NTSC</entry>
+      <entry>Portable PAL</entry>
+      <entry>Home Theater NTSC</entry>
+      <entry>Home Theater PAL</entry>
+      <entry>HDTV</entry>
+    </row>
+    <row>
+      <entry>Width [pixels]</entry>
+      <entry>176</entry>
+      <entry>176</entry>
+      <entry>352</entry>
+      <entry>352</entry>
+      <entry>176</entry>
+      <entry>176</entry>
+      <entry>352</entry>
+      <entry>352</entry>
+      <entry>352</entry>
+      <entry>720</entry>
+      <entry>176</entry>
+      <entry>352</entry>
+      <entry>352</entry>
+      <entry>720</entry>
+      <entry>720</entry>
+      <entry>1280</entry>
+    </row>
+    <row>
+      <entry>Height [pixels]</entry>
+      <entry>144</entry>
+      <entry>144</entry>
+      <entry>288</entry>
+      <entry>288</entry>
+      <entry>144</entry>
+      <entry>144</entry>
+      <entry>288</entry>
+      <entry>288</entry>
+      <entry>576</entry>
+      <entry>576</entry>
+      <entry>144</entry>
+      <entry>240</entry>
+      <entry>288</entry>
+      <entry>480</entry>
+      <entry>576</entry>
+      <entry>720</entry>
+    </row>
+    <row>
+      <entry>Frame rate [fps]</entry>
+      <entry>15</entry>
+      <entry>15</entry>
+      <entry>15</entry>
+      <entry>15</entry>
+      <entry>30</entry>
+      <entry>30</entry>
+      <entry>15</entry>
+      <entry>30</entry>
+      <entry>30</entry>
+      <entry>30</entry>
+      <entry>15</entry>
+      <entry>30</entry>
+      <entry>25</entry>
+      <entry>30</entry>
+      <entry>25</entry>
+      <entry>30</entry>
+    </row>
+    <row>
+      <entry>Max average bitrate [kbps]</entry>
+      <entry>64</entry>
+      <entry>64</entry>
+      <entry>128</entry>
+      <entry>384</entry>
+      <entry>128</entry>
+      <entry>128</entry>
+      <entry>384</entry>
+      <entry>768</entry>
+      <entry>3000</entry>
+      <entry>8000</entry>
+      <entry>537.6</entry>
+      <entry>4854</entry>
+      <entry>4854</entry>
+      <entry>4854</entry>
+      <entry>4854</entry>
+      <entry>9708.4</entry>
+    </row>
+    <row>
+      <entry>Peak average bitrate over 3 secs [kbps]</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>800</entry>
+      <entry>8000</entry>
+      <entry>8000</entry>
+      <entry>8000</entry>
+      <entry>8000</entry>
+      <entry>16000</entry>
+    </row>
+    <row>
+      <entry>Max. B-frames</entry>
+      <entry>0</entry>
+      <entry>0</entry>
+      <entry>0</entry>
+      <entry>0</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>0</entry>
+      <entry>1</entry>
+      <entry>1</entry>
+      <entry>1</entry>
+      <entry>1</entry>
+      <entry>2</entry>
+    </row>
+    <row>
+      <entry>MPEG quantization</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry>Adaptive quantization</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+    </row>
+    <row>
+      <entry>Interlaced encoding</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+    </row>
+    <row>
+      <entry>Quaterpixel</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+    <row>
+      <entry>Global motion compensation</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry>X</entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+      <entry></entry>
+    </row>
+  </tbody>
+</tgroup>
+</informaltable>
+</sect2>
+
+<sect2 id="menc-feat-xvid-example-settings">
+<title>Encoding setting examples</title>
+
+<para>
+  The following settings are examples of different encoding
+  option combinations that affect the speed vs quality tradeoff
+  at the same target bitrate.
+</para>
+
+<para>
+  All the encoding settings were tested on a 720x448 @30000/1001 fps
+  video sample, the target bitrate was 900kbps, and the machine was an
+  AMD-64 3400+ at 2400 Mhz in 64 bits mode.
+  Each encoding setting features the measured encoding speed (in
+  frames per second) and the PSNR loss (in dB) compared to the "very
+  high quality" setting.
+  Please understand that depending on your source, your machine type
+  and development advancements, you may get very different results.
+</para>
+
+<para>
+<informaltable frame="all">
+<tgroup cols="4">
+<thead>
+<row><entry>Description</entry><entry>Encoding options</entry><entry>speed (in fps)</entry><entry>Relative PSNR loss (in dB)</entry></row>
+</thead>
+<tbody>
+<row>
+  <entry>Very high quality</entry>
+  <entry><option>chroma_opt:vhq=4:bvhq=1:quant_type=mpeg</option></entry>
+  <entry>16fps</entry>
+  <entry>0dB</entry>
+</row>
+<row>
+  <entry>High quality</entry>
+  <entry><option>vhq=2:bvhq=1:chroma_opt:quant_type=mpeg</option></entry>
+  <entry>18fps</entry>
+  <entry>-0.1dB</entry>
+</row>
+<row>
+  <entry>Fast</entry>
+  <entry><option>turbo:vhq=0</option></entry>
+  <entry>28fps</entry>
+  <entry>-0.69dB</entry>
+</row>
+<row>
+  <entry>Realtime</entry>
+  <entry><option>turbo:nochroma_me:notrellis:max_bframes=0:vhq=0</option></entry>
+  <entry>38fps</entry>
+  <entry>-1.48dB</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+</para>
+</sect2>
+
+</sect1>
+
+<sect1 id="menc-feat-x264">
+<title>Encoding with the <systemitem class="library">x264</systemitem> codec</title>
+<para>
+  <systemitem class="library">x264</systemitem> is a free library for
+  encoding H.264/AVC video streams.
+  Before starting to encode, you need to <link linkend="codec-x264-encode">
+  set up <application>MEncoder</application> to support it</link>.
+</para>
+
+<sect2 id="menc-feat-x264-encoding-options">
+<title>Encoding options of x264</title>
+
+<para>
+  Please begin by reviewing the
+  <systemitem class="library">x264</systemitem> section of
+  <application>MPlayer</application>'s man page.
+  This section is intended to be a supplement to the man page.
+  Here you will find quick hints about which options are most
+  likely to interest most people. The man page is more terse,
+  but also more exhaustive, and it sometimes offers much better
+  technical detail.
+</para>
+
+<sect3 id="menc-feat-x264-encoding-options-intro">
+<title>Introduction</title>
+<para>This guide considers two major categories of encoding options:</para>
+
+<orderedlist>
+  <listitem><para>Options which mainly trade off encoding time vs. quality
+  </para></listitem>
+  <listitem><para>Options which may be useful for fulfilling various personal
+  preferences and special requirements</para></listitem>
+</orderedlist>
+
+<para>
+  Ultimately, only you can decide which options are best for your
+  purposes. The decision for the first class of options is the simplest:
+  you only have to decide whether you think the quality differences
+  justify the speed differences. For the second class of options,
+  preferences may be far more subjective, and more factors may be
+  involved. Note that some of the "personal preferences and special
+  requirements" options can still have large impacts on speed or quality,
+  but that is not what they are primarily useful for. A couple of the
+  "personal preference" options may even cause changes that look better
+  to some people, but look worse to others.
+</para>
+
+<para>
+  Before continuing, you need to understand that this guide uses only one
+  quality metric: global PSNR.
+  For a brief explanation of what PSNR is, see
+  <ulink url="http://en.wikipedia.org/wiki/PSNR">the Wikipedia article on PSNR</ulink>.
+  Global PSNR is the last PSNR number reported when you include
+  the <option>psnr</option> option in <option>x264encopts</option>.
+  Any time you read a claim about PSNR, one of the assumptions
+  behind the claim is that equal bitrates are used.
+</para>
+
+<para>
+  Nearly all of this guide's comments assume you are using
+  two pass.
+  When comparing options, there are two major reasons for using
+  two pass encoding.
+  First, using two pass often gains around 1dB PSNR, which is a
+  very big difference.
+  Secondly, testing options by doing direct quality comparisons
+  with one pass encodes introduces a major confounding
+  factor: bitrate often varies significantly with each encode.
+  It is not always easy to tell whether quality changes are due
+  mainly to changed options, or if they mostly reflect essentially
+  random differences in the achieved bitrate.
+</para>
+
+</sect3>
+
+<sect3 id="menc-feat-x264-encoding-options-speedvquality">
+<title>Options which primarily affect speed and quality</title>
+
+<itemizedlist>
+<listitem><para>
+  <emphasis role="bold">subq</emphasis>:
+  Of the options which allow you to trade off speed for quality,
+  <option>subq</option> and <option>frameref</option> (see below) are usually
+  by far the most important.
+  If you are interested in tweaking either speed or quality, these
+  are the first options you should consider.
+  On the speed dimension, the <option>frameref</option> and
+  <option>subq</option> options interact with each other fairly
+  strongly.
+  Experience shows that, with one reference frame,
+  <option>subq=5</option> (the default setting) takes about 35% more time than
+  <option>subq=1</option>.
+  With 6 reference frames, the penalty grows to over 60%.
+  <option>subq</option>'s effect on PSNR seems fairly constant
+  regardless of the number of reference frames.
+  Typically, <option>subq=5</option> achieves 0.2-0.5 dB higher global
+  PSNR in comparison <option>subq=1</option>.
+  This is usually enough to be visible.
+</para>
+<para>
+  <option>subq=6</option> is the slowest, highest quality mode.
+  In comparison to <option>subq=5</option>, it usually gains 0.1-0.4 dB
+  global PSNR with speed costs varying from 25%-100%.
+  Unlike other levels of <option>subq</option>, the behavior of
+  <option>subq=6</option> does not depend much on <option>frameref</option>
+  and <option>me</option>.  Instead, the effectiveness of <option>subq=6
+  </option> depends mostly upon the number of B-frames used. In normal
+  usage, this means <option>subq=6</option> has a large impact on both speed
+  and quality in complex, high motion scenes, but it may not have much effect
+  in low-motion scenes. Note that it is still recommended to always set
+  <option>bframes</option> to something other than zero (see below).
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">frameref</emphasis>:
+  <option>frameref</option> is set to 1 by default, but this
+  should not be taken to imply that it is reasonable to set it
+  to 1.
+  Merely raising <option>frameref</option> to 2 gains around
+  0.15dB PSNR with a 5-10% speed penalty; this seems like a
+  good tradeoff.
+  <option>frameref=3</option> gains around 0.25dB PSNR over
+  <option>frameref=1</option>, which should be a visible
+  difference.
+  <option>frameref=3</option> is around 15% slower than
+  <option>frameref=1</option>.
+  Unfortunately, diminishing returns set in rapidly.
+  <option>frameref=6</option> can be expected to gain only
+  0.05-0.1 dB over <option>frameref=3</option> at an additional
+  15% speed penalty.
+  Above <option>frameref=6</option>, the quality gains are
+  usually very small (although you should keep in mind throughout
+  this whole discussion that it can vary quite a lot depending on
+  your source).
+  In a fairly typical case, <option>frameref=12</option>
+  will improve global PSNR by a tiny 0.02dB over
+  <option>frameref=6</option>, at a speed cost of 15%-20%.
+  At such high <option>frameref</option> values, the only really
+  good thing that can be said is that increasing it even further will
+  almost certainly never <emphasis role="bold">harm</emphasis>
+  PSNR, but the additional quality benefits are barely even
+  measurable, let alone perceptible.
+</para>
+<note><title>Note:</title>
+<para>
+  Raising <option>frameref</option> to unnecessarily high values
+  <emphasis role="bold">can</emphasis> and
+  <emphasis role="bold">usually does</emphasis>
+  hurt coding efficiency if you turn CABAC off.
+  With CABAC on (the default behavior), the possibility of setting
+  <option>frameref</option> "too high" currently seems too remote
+  to even worry about, and in the future, optimizations may remove
+  the possibility altogether.
+</para>
+</note>
+<para>
+  If you care about speed, a reasonable compromise is to use low
+  <option>subq</option> and <option>frameref</option> values on
+  the first pass, and then raise them on the second pass.
+  Typically, this has a negligible negative effect on the final
+  quality: You will probably lose well under 0.1dB PSNR, which
+  should be much too small of a difference to see.
+  However, different values of <option>frameref</option> can
+  occasionally affect frametype decision.
+  Most likely, these are rare outlying cases, but if you want to
+  be pretty sure, consider whether your video has either
+  fullscreen repetitive flashing patterns or very large temporary
+  occlusions which might force an I-frame.
+  Adjust the first-pass <option>frameref</option> so it is large
+  enough to contain the duration of the flashing cycle (or occlusion).
+  For example, if the scene flashes back and forth between two images
+  over a duration of three frames, set the first pass
+  <option>frameref</option> to 3 or higher.
+  This issue is probably extremely rare in live action video material,
+  but it does sometimes come up in video game captures.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">me</emphasis>:
+  This option is for choosing the motion estimation search method.
+  Altering this option provides a straightforward quality-vs-speed
+  tradeoff. <option>me=1</option> is only a few percent faster than
+  the default search, at a cost of under 0.1dB global PSNR. The 
+  default setting (<option>me=2</option>) is a reasonable tradeoff
+  between speed and quality. <option>me=3</option> gains a little under
+  0.1dB global PSNR, with a speed penalty that varies depending on
+  <option>frameref</option>.  At high values of
+  <option>frameref</option> (e.g. 12 or so), <option>me=3</option>
+  is about 40% slower than the default <option> me=2</option>. With
+  <option>frameref=3</option>, the speed penalty incurred drops to
+  25%-30%.
+</para>
+<para>
+  <option>me=4</option> uses an exhaustive search that is too slow for
+  practical use.
+</para>
+</listitem>
+
+<listitem><para>
+  <emphasis role="bold">4x4mv</emphasis>:
+  This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
+  predicted macroblocks. Enabling it results in a fairly consistent
+  10%-15% loss of speed. This option is rather useless in source
+  containing only low motion, however in some high-motion source,
+  particularly source with lots of small moving objects, gains of
+  about 0.1dB can be expected.
+</para>
+</listitem>
+
+<listitem><para>
+  <emphasis role="bold">bframes</emphasis>:
+  If you are used to encoding with other codecs, you may have found
+  that B-frames are not always useful.
+  In H.264, this has changed: there are new techniques and block
+  types that are possible in B-frames.
+  Usually, even a naive B-frame choice algorithm can have a
+  significant PSNR benefit.
+  It is interesting to note that using B-frames usually speeds up
+  the second pass somewhat, and may also speed up a single
+  pass encode if adaptive B-frame decision is turned off.
+</para>
+<para>
+  With adaptive B-frame decision turned off
+  (<option>x264encopts</option>'s <option>nob_adapt</option>),
+  the optimal value for this setting is usually no more than
+  <option>bframes=1</option>, or else high-motion scenes can suffer.
+  With adaptive B-frame decision on (the default behavior), it is
+  safe to use higher values; the encoder will reduce the use of
+  B-frames in scenes where they would hurt compression.
+  The encoder rarely chooses to use more than 3 or 4 B-frames;
+  setting this option any higher will have little effect.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">b_adapt</emphasis>:
+  Note: This is on by default.
+</para>
+<para>
+  With this option enabled, the encoder will use a reasonably fast
+  decision process to reduce the number of B-frames used in scenes that
+  might not benefit from them as much.
+  You can use <option>b_bias</option> to tweak how B-frame-happy
+  the encoder is.
+  The speed penalty of adaptive B-frames is currently rather modest,
+  but so is the potential quality gain.
+  It usually does not hurt, however.
+  Note that this only affects speed and frametype decision on the
+  first pass.
+  <option>b_adapt</option> and <option>b_bias</option> have no
+  effect on subsequent passes.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">b_pyramid</emphasis>:
+  You might as well enable this option if you are using >=2 B-frames;
+  as the man page says, you get a little quality improvement at no
+  speed cost.
+  Note that these videos cannot be read by libavcodec-based decoders
+  older than about March 5, 2005.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">weight_b</emphasis>:
+  In typical cases, there is not much gain with this option.
+  However, in crossfades or fade-to-black scenes, weighted
+  prediction gives rather large bitrate savings.
+  In MPEG-4 ASP, a fade-to-black is usually best coded as a series
+  of expensive I-frames; using weighted prediction in B-frames
+  makes it possible to turn at least some of these into much smaller
+  B-frames.
+  Encoding time cost is minimal, as no extra decisions need to be made.
+  Also, contrary to what some people seem to guess, the decoder
+  CPU requirements are not much affected by weighted prediction,
+  all else being equal.
+</para>
+<para>
+  Unfortunately, the current adaptive B-frame decision algorithm
+  has a strong tendency to avoid B-frames during fades.
+  Until this changes, it may be a good idea to add
+  <option>nob_adapt</option> to your x264encopts, if you expect
+  fades to have a large effect in your particular video
+  clip.
+</para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3 id="menc-feat-x264-encoding-options-misc-preferences">
+<title>Options pertaining to miscellaneous preferences</title>
+<itemizedlist>
+<listitem><para>
+  <emphasis role="bold">Two pass encoding</emphasis>:
+  Above, it was suggested to always use two pass encoding, but there
+  are still reasons for not using it. For instance, if you are capturing
+  live TV and encoding in realtime, you are forced to use single-pass.
+  Also, one pass is obviously faster than two passes; if you use the
+  exact same set of options on both passes, two pass encoding is almost
+  twice as slow.
+</para>
+<para>
+  Still, there are very good reasons for using two pass encoding. For
+  one thing, single pass ratecontrol is not psychic, and it often makes
+  unreasonable choices because it cannot see the big picture. For example,
+  suppose you have a two minute long video consisting of two distinct
+  halves.  The first half is a very high-motion scene lasting 60 seconds
+  which, in isolation, requires about 2500kbps in order to look decent.
+  Immediately following it is a much less demanding 60-second scene
+  that looks good at 300kbps. Suppose you ask for 1400kbps on the theory
+  that this is enough to accomodate both scenes. Single pass ratecontrol
+  will make a couple of "mistakes" in such a case. First of all, it
+  will target 1400kbps in both segments. The first segment may end up
+  heavily overquantized, causing it to look unacceptably and unreasonably
+  blocky. The second segment will be heavily underquantized; it may look
+  perfect, but the bitrate cost of that perfection will be completely
+  unreasonable. What is even harder to avoid is the problem at the
+  transition between the two scenes. The first seconds of the low motion
+  half will be hugely over-quantized, because the ratecontrol is still
+  expecting the kind of bitrate requirements it met in the first half
+  of the video. This "error period" of heavily over-quantized low motion
+  will look jarringly bad, and will actually use less than the 300kbps
+  it would have taken to make it look decent. There are ways to
+  mitigate the pitfalls of single-pass encoding, but they may tend to
+  increase bitrate misprediction.
+</para>
+<para>
+  Multipass ratecontrol can offer huge advantages over a single pass.
+  Using the statistics gathered from the first pass encode, the encoder
+  can estimate, with reasonable accuracy, the "cost" (in bits) of
+  encoding any given frame, at any given quantizer. This allows for
+  a much more rational, better planned allocation of bits between the
+  expensive (high-motion) and cheap (low-motion) scenes. See
+  <option>qcomp</option> below for some ideas on how to tweak this
+  allocation to your liking.
+</para>
+<para>
+  Moreover, two passes need not take twice as long as one pass. You can
+  tweak the options in the first pass for higher speed and lower quality.
+  If you choose your options well, you can get a very fast first pass.
+  The resulting quality in the second pass will be slightly lower because size
+  prediction is less accurate, but the quality difference is normally much
+  too small to be visible. Try, for example, adding
+  <option>subq=1:frameref=1</option> to the first pass
+  <option>x264encopts</option>. Then, on the second pass, use slower,
+  higher-quality options:
+  <option>subq=6:frameref=15:4x4mv:me=3</option>
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">Three pass encoding</emphasis>?
+
+  x264 offers the ability to make an arbitrary number of consecutive
+  passes. If you specify <option>pass=1</option> on the first pass,
+  then use <option>pass=3</option> on a subsequent pass, the subsequent
+  pass will both read the statistics from the previous pass, and write
+  its own statistics. An additional pass following this one will have
+  a very good base from which to make highly accurate predictions of
+  framesizes at a chosen quantizer. In practice, the overall quality
+  gain from this is usually close to zero, and quite possibly a third
+  pass will result in slightly worse global PSNR than the pass before
+  it. In typical usage, three passes help if you get either bad bitrate
+  prediction or bad looking scene transitions when using only two passes.
+  This is somewhat likely to happen on extremely short clips. There are
+  also a few special cases in which three (or more) passes are handy
+  for advanced users, but for brevity, this guide omits discussing those
+  special cases.
+
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">qcomp</emphasis>:
+  <option>qcomp</option> trades off the number of bits allocated
+  to "expensive" high-motion versus "cheap" low-motion frames. At
+  one extreme, <option>qcomp=0</option> aims for true constant
+  bitrate. Typically this would make high-motion scenes look completely
+  awful, while low-motion scenes would probably look absolutely
+  perfect, but would also use many times more bitrate than they
+  would need in order to look merely excellent. At the other extreme,
+  <option>qcomp=1</option> achieves nearly constant quantization parameter
+  (QP). Constant QP does not look bad, but most people think it is more
+  reasonable to shave some bitrate off of the extremely expensive scenes
+  (where the loss of quality is not as noticeable) and reallocate it to
+  the scenes that are easier to encode at excellent quality.
+  <option>qcomp</option> is set to 0.6 by default, which may be slightly
+  low for many peoples' taste (0.7-0.8 are also commonly used).
+</para></listitem>
+<listitem><para>
+  <emphasis role="bold">keyint</emphasis>:
+  <option>keyint</option> is solely for trading off file seekability against
+  coding efficiency. By default, <option>keyint</option> is set to 250. In
+  25fps material, this guarantees the ability to seek to within 10 seconds
+  precision. If you think it would be important and useful to be able to
+  seek within 5 seconds of precision, set <option>keyint=125</option>;
+  this will hurt quality/bitrate slightly. If you care only about quality
+  and not about seekability, you can set it to much higher values
+  (understanding that there are diminishing returns which may become
+  vanishingly low, or even zero). The video stream will still have seekable
+  points as long as there are some scene changes.
+</para></listitem> 
+<listitem><para>
+  <emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
+  This topic is going to be a bit controversial.
+</para>
+<para>
+  H.264 defines a simple deblocking procedure on I-blocks that uses
+  pre-set strengths and thresholds depending on the QP of the block
+  in question.
+  By default, high QP blocks are filtered heavily, and low QP blocks
+  are not deblocked at all.
+  The pre-set strengths defined by the standard are well-chosen and
+  the odds are very good that they are PSNR-optimal for whatever
+  video you are trying to encode.
+  The <option>deblockalpha</option> and <option>deblockbeta</option>
+  parameters allow you to specify offsets to the preset deblocking
+  thresholds.
+</para>
+<para>
+  Many people seem to think it is a good idea to lower the deblocking
+  filter strength by large amounts (say, -3).
+  This is however almost never a good idea, and in most cases,
+  people who are doing this do not understand very well how
+  deblocking works by default.
+</para>
+<para>
+  The first and most important thing to know about the in-loop
+  deblocking filter is that the default thresholds are almost always
+  PSNR-optimal.
+  In the rare cases that they are not optimal, the ideal offset is
+  plus or minus 1.
+  Adjusting deblocking parameters by a larger amount is almost
+  guaranteed to hurt PSNR.
+  Strengthening the filter will smear more details; weakening the
+  filter will increase the appearance of blockiness.
+</para>
+<para>
+  It is definitely a bad idea to lower the deblocking thresholds if
+  your source is mainly low in spacial complexity (i.e., not a lot
+  of detail or noise).
+  The in-loop filter does a rather excellent job of concealing
+  the artifacts that occur.
+  If the source is high in spacial complexity, however, artifacts
+  are less noticeable.
+  This is because the ringing tends to look like detail or noise.
+  Human visual perception easily notices when detail is removed,
+  but it does not so easily notice when the noise is wrongly
+  represented.
+  When it comes to subjective quality, noise and detail are somewhat
+  interchangeable.
+  By lowering the deblocking filter strength, you are most likely
+  increasing error by adding ringing artifacts, but the eye does
+  not notice because it confuses the artifacts with detail.
+</para>
+
+<para>
+  This <emphasis role="bold">still</emphasis> does not justify
+  lowering the deblocking filter strength, however.
+  You can generally get better quality noise from postprocessing.
+  If your H.264 encodes look too blurry or smeared, try playing with
+  <option>-vf noise</option> when you play your encoded movie.
+  <option>-vf noise=8a:4a</option> should conceal most mild
+  artifacting.
+  It will almost certainly look better than the results you
+  would have gotten just by fiddling with the deblocking filter.
+</para></listitem>
+</itemizedlist>
+</sect3>
+</sect2>
+
+<sect2 id="menc-feat-x264-example-settings">
+<title>Encoding setting examples</title>
+
+<para>
+  The following settings are examples of different encoding
+  option combinations that affect the speed vs quality tradeoff
+  at the same target bitrate.
+</para>
+
+<para>
+  All the encoding settings were tested on a 720x448 @30000/1001 fps
+  video sample, the target bitrate was 900kbps, and the machine was an
+  AMD-64 3400+ at 2400 Mhz in 64 bits mode.
+  Each encoding setting features the measured encoding speed (in
+  frames per second) and the PSNR loss (in dB) compared to the "very
+  high quality" setting.
+  Please understand that depending on your source, your machine type
+  and development advancements, you may get very different results.
+</para>
+
+<para>
+<informaltable frame="all">
+<tgroup cols="4">
+<thead>
+<row><entry>Description</entry><entry>Encoding options</entry><entry>speed (in fps)</entry><entry>Relative PSNR loss (in dB)</entry></row>
+</thead>
+<tbody>
+<row>
+  <entry>Very high quality</entry>
+  <entry><option>subq=6:4x4mv:8x8dct:me=3:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
+  <entry>6fps</entry>
+  <entry>0dB</entry>
+</row>
+<row>
+  <entry>High quality</entry>
+  <entry><option>subq=5:4x4mv:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
+  <entry>13fps</entry>
+  <entry>-0.89dB</entry>
+</row>
+<row>
+  <entry>Fast</entry>
+  <entry><option>subq=4:bframes=2:b_pyramid:weight_b</option></entry>
+  <entry>17fps</entry>
+  <entry>-1.48dB</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+</para>
+</sect2>
+
+</sect1>
+
+<sect1 id="menc-feat-vcd-dvd">
+<title>Using MEncoder to create VCD/SVCD/DVD-compliant files.</title>
+
+<sect2 id="menc-feat-vcd-dvd-constraints">
+<title>Format Constraints</title>
+<para>
+  <application>MEncoder</application> is capable of creating VCD, SCVD
+  and DVD format MPEG files using the
+  <systemitem class="library">libavcodec</systemitem> library.
+  These files can then be used in conjunction with
+  <ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink>
+  or
+  <ulink url="http://dvdauthor.sourceforge.net/">dvdauthor</ulink>
+  to create discs that will play on a standard set-top player.
+</para>
+
+<para>
+  The DVD, SVCD, and VCD formats are subject to heavy constraints.
+  Only a small selection of encoded picture sizes and aspect ratios are
+  available.
+  If your movie does not already meet these requirements, you may have
+  to scale,crop or add black borders to the picture to make it
+  compliant.
+</para>
+
+<sect3 id="menc-feat-vcd-dvd-constraints-resolution">
+<title>Format Constraints</title>
+
+<informaltable frame="all">
+<tgroup cols="9">
+<thead>
+    <row>
+        <entry>Format</entry>
+        <entry>Resolution</entry>
+        <entry>V. Codec</entry>
+        <entry>V. Bitrate</entry>
+        <entry>Sample Rate</entry>
+        <entry>A. Codec</entry>
+        <entry>A. Bitrate</entry>
+        <entry>FPS</entry>
+        <entry>Aspect</entry>
+    </row>
+</thead>
+<tbody>
+    <row>
+        <entry>NTSC DVD</entry>
+        <entry>720x480, 704x480, 352x480, 352x240</entry> 
+        <entry>MPEG-2</entry>
+        <entry>9800 kbps</entry>
+        <entry>48000 Hz</entry>
+        <entry>AC3,PCM</entry>
+        <entry>1536 kbps (max)</entry>
+        <entry>30000/1001, 24000/1001</entry>
+        <entry>4:3, 16:9 (only for 720x480)</entry>
+    </row>
+    <row>
+        <entry>NTSC DVD</entry>
+        <entry>352x240<footnote id='fn-rare-resolutions'><para>
+	  These resolutions are rarely used for DVDs because
+	  they are fairly low quality.</para></footnote></entry> 
+        <entry>MPEG-1</entry>
+        <entry>1856 kbps</entry>
+        <entry>48000 Hz</entry>
+        <entry>AC3,PCM</entry>
+        <entry>1536 kbps (max)</entry>
+        <entry>30000/1001, 24000/1001</entry>
+        <entry>4:3, 16:9</entry>
+    </row>
+    <row>
+        <entry>NTSC SVCD</entry>
+        <entry>480x480</entry>
+        <entry>MPEG-2</entry>
+        <entry>2600 kbps</entry>
+        <entry>44100 Hz</entry>
+        <entry>MP2</entry>
+        <entry>384 kbps (max)</entry>
+        <entry>30000/1001</entry>
+        <entry>4:3</entry>
+    </row>
+    <row>
+        <entry>NTSC VCD</entry>
+        <entry>352x240</entry>
+        <entry>MPEG-1</entry>
+        <entry>1150 kbps</entry>
+        <entry>44100 Hz</entry>
+        <entry>MP2</entry>
+        <entry>224 kbps</entry>
+        <entry>24000/1001, 30000/1001</entry>
+        <entry>4:3</entry>
+    </row>
+    <row>
+        <entry>PAL DVD</entry>
+        <entry>720x576, 704x576, 352x576, 352x288</entry>
+        <entry>MPEG-2</entry>
+        <entry>9800 kbps</entry>
+        <entry>48000 Hz</entry>
+        <entry>MP2,AC3,PCM</entry>
+        <entry>1536 kbps (max)</entry>
+        <entry>25</entry>
+        <entry>4:3, 16:9 (only for 720x576)</entry>
+    </row>
+    <row>
+        <entry>PAL DVD</entry>
+        <entry>352x288<footnoteref linkend='fn-rare-resolutions'/></entry>
+        <entry>MPEG-1</entry>
+        <entry>1856 kbps</entry>
+        <entry>48000 Hz</entry>
+        <entry>MP2,AC3,PCM</entry>
+        <entry>1536 kbps (max)</entry>
+        <entry>25</entry>
+        <entry>4:3, 16:9</entry>
+    </row>
+    <row>
+        <entry>PAL SVCD</entry>
+        <entry>480x576</entry>
+        <entry>MPEG-2</entry>
+        <entry>2600 kbps</entry>
+        <entry>44100 Hz</entry>
+        <entry>MP2</entry>
+        <entry>384 kbps (max)</entry>
+        <entry>25</entry>
+        <entry>4:3</entry>
+    </row>
+    <row>
+        <entry>PAL VCD</entry>
+        <entry>352x288</entry>
+        <entry>MPEG-1</entry>
+        <entry>1152 kbps</entry>
+        <entry>44100 Hz</entry>
+        <entry>MP2</entry>
+        <entry>224 kbps</entry>
+        <entry>25</entry>
+        <entry>4:3</entry>
+    </row>
+</tbody>
+</tgroup>
+</informaltable>
+
+<para>
+  If your movie has 2.35:1 aspect (most recent action movies), you will
+  have to add black borders or crop the movie down to 16:9 to make a DVD
+  or VCD.
+  If you add black borders, try to align them at 16-pixel boundaries in
+  order to minimize the impact on encoding performance.
+  Thankfully DVD has sufficiently excessive bitrate that you do not have
+  to worry too much about encoding efficiency, but SVCD and VCD are
+  highly bitrate-starved and require effort to obtain acceptable quality.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-constraints-gop">
+<title>GOP Size Constraints</title>
+<para>
+  DVD, VCD, and SVCD also constrain you to relatively low 
+  GOP (Group of Pictures) sizes.
+  For 30 fps material the largest allowed GOP size is 18.
+  For 25 or 24 fps, the maximum is 15.
+  The GOP size is set using the <option>keyint</option> option.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-constraints-bitrate">
+<title>Bitrate Constraints</title>
+<para>
+  VCD video is required to be CBR at 1152 kbps.
+  This highly limiting constraint also comes along with an extremly low vbv
+  buffer size of 327 kilobits.
+  SVCD allows varying video bitrates up to 2500 kbps, and a somewhat less 
+  restrictive vbv buffer size of 917 kilobits is allowed.
+  DVD video bitrates may range anywhere up to 9800 kbps (though typical
+  bitrates are about half that), and the vbv buffer size is 1835 kilobits.
+</para>
+</sect3>
+</sect2>
+
+<sect2 id="menc-feat-vcd-dvd-output">
+<title>Output Options</title>
+<para>
+  <application>MEncoder</application> has options to control the output
+  format.
+  Using these options we can instruct it to create the correct type of
+  file.
+</para>
+
+<para>
+  The options for VCD and SVCD are called xvcd and xsvcd, because they
+  are extended formats.
+  They are not strictly compliant, mainly because the output does not
+  contain scan offsets.
+  If you need to generate an SVCD image, you  should pass the output file
+  to
+  <ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink>.
+</para>
+
+<para>
+  VCD:
+  <screen>
+  -of mpeg -mpegopts format=xvcd
+  </screen>
+</para>
+
+<para>
+  SVCD:
+  <screen>
+  -of mpeg -mpegopts format=xsvcd
+  </screen>
+</para>
+
+<para>
+  DVD:
+  <screen>
+  -of mpeg -mpegopts format=dvd
+  </screen>
+</para>
+
+<para>
+  DVD with NTSC Pullup:
+  <screen>
+  -of mpeg -mpegopts format=dvd:telecine -ofps 24000/1001
+  </screen>
+  This allows 24000/1001 fps progressive content to be encoded at 30000/1001 
+  fps whilst maintaing DVD-compliance.
+</para>
+
+<sect3 id="menc-feat-vcd-dvd-output-aspect">
+<title>Aspect Ratio</title>
+<para>
+  The aspect argument of <option>-lavcopts</option> is used to encode
+  the aspect ratio of the file.
+  During playback the aspect ratio is used to restore the video to the
+  correct size.
+</para>
+
+<para>
+  16:9 or "Widescreen"
+  <screen>
+  -lavcopts aspect=16/9
+  </screen>
+</para>
+
+<para>
+  4:3 or "Fullscreen"
+  <screen>
+  -lavcopts aspect=4/3
+  </screen>
+</para>
+
+<para>
+  2.35:1 or "Cinemascope" NTSC
+  <screen>
+  -vf scale=720:368,expand=720:480 -lavcopts aspect=16/9
+  </screen>
+  To calculate the correct scaling size, use the expanded NTSC width of
+  854/2.35 = 368
+</para>
+
+<para>
+  2.35:1 or "Cinemascope" PAL
+  <screen>
+  -vf scale="720:432,expand=720:576 -lavcopts aspect=16/9
+  </screen>
+  To calculate the correct scaling size, use the expanded PAL width of
+  1024/2.35 = 432
+</para>
+
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-output-srate">
+<title>Sample Rate Conversion</title>
+<para>
+  If the audio sample rate in the original file is not the same as
+  required by the target format, sample rate conversion is required.
+  This is achieved using the <option>-srate</option> option and 
+  the <option>-af lavcresample</option> audio filter together.
+  </para>
+  <para>
+  DVD:
+  <screen>
+  -srate 48000 -af lavcresample=48000
+  </screen>
+</para>
+<para>
+  VCD and SVCD:
+  <screen>
+  -srate 44100 -af lavcresample=44100
+  </screen>
+  </para>
+</sect3>
+</sect2>
+
+<sect2 id="menc-feat-vcd-dvd-lavc">
+<title>Using libavcodec for VCD/SVCD/DVD Encoding</title>
+
+<sect3 id="menc-feat-vcd-dvd-lavc-intro">
+<title>Introduction</title>
+<para>
+  <systemitem class="library">libavcodec</systemitem> can be used to
+  create VCD/SVCD/DVD compliant video by using the appropriate options.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-lavc-options">
+<title>lavcopts</title>
+<para>
+  This is a list of fields in <option>-lavcopts</option> that you may
+  be required to change in order to make a complaint movie for VCD, SVCD,
+  or DVD:
+</para>
+
+<itemizedlist>
+<listitem><para>
+  <emphasis role="bold">acodec</emphasis>:
+  <option>mp2</option> for VCD, SVCD, or PAL DVD;
+  <option>ac3</option> is most commonly used for DVD.
+  PCM audio may also be used for DVD, but this is mostly a big waste of
+  space.
+  Note that MP3 audio is not compliant for any of these formats, but
+  players often have no problem playing it anyway.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">abitrate</emphasis>:
+  224 for VCD; up to 384 for SVCD; up to 1536 for  DVD, but commonly
+  used values range from 192 kbps for stereo to 384 kbps for 5.1 channel
+  sound.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vcodec</emphasis>:
+  <option>mpeg1video</option> for VCD;
+  <option>mpeg2video</option> for SVCD;
+  <option>mpeg2video</option> is usually used for DVD but you may also use
+  <option>mpeg1video</option> for CIF resolutions.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">keyint</emphasis>:
+  Used to set the GOP size.
+  18 for 30fps material, or 15 for 25/24 fps material.
+  Commercial producers seem to prefer keyframe intervals of 12.
+  It is possible to make this much larger and still retain compatibility 
+  with most players.
+  A <option>keyint</option> of 25 should never cause any problems.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vrc_buf_size</emphasis>:
+  327 for VCD, 917 for SVCD, and 1835 for DVD.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vrc_minrate</emphasis>:
+  1152, for VCD. May be left alone for SVCD and DVD.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vrc_maxrate</emphasis>:
+  1152 for VCD; 2500 for SVCD; 9800 for DVD.
+  For SVCD and DVD, you might wish to use lower values depending on your
+  own personal preferences and requirements.
+</para></listitem>
+
+<listitem><para>
+  <emphasis role="bold">vbitrate</emphasis>:
+  1152 for VCD;
+  up to 2500 for SVCD;
+  up to 9800 for DVD.
+  For the latter two formats, vbitrate should be set based on personal
+  preference.
+  For instance, if you insist on fitting 20 or so hours on a DVD, you
+  could use vbitrate=400.
+  The resulting video quality would probably be quite bad.
+  If you are trying to squeeze out the maximum possible quality on a DVD,
+  use vbitrate=9800, but be warned that this could constrain you to less
+  than an hour of video on a single-layer DVD.
+</para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-lavc-examples">
+<title>Examples</title>
+<para>
+  This is a typical minimum set of <option>-lavcopts</option> for
+  encoding video:
+</para>
+<para>
+  VCD:
+  <screen>
+  -lavcopts vcodec=mpeg1video:vrc_buf_size=327:vrc_minrate=1152:\
+  vrc_maxrate=1152:vbitrate=1152:keyint=15:acodec=mp2
+  </screen>
+</para>
+
+<para>
+  SVCD:
+  <screen>
+  -lavcopts vcodec=mpeg2video:vrc_buf_size=917:vrc_maxrate=2500:vbitrate=1800:\
+  keyint=15:acodec=mp2
+  </screen>
+</para>
+
+<para>
+  DVD:
+  <screen>
+  -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\
+  keyint=15:acodec=ac3
+  </screen>
+</para>
+
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-lavc-advanced">
+<title>Advanced Options</title>
+<para>
+  For higher quality encoding, you may also wish to add quality-enhancing
+  options to lavcopts, such as <option>trell</option>,
+  <option>mbd=2</option>, and others.
+  Note that <option>qpel</option> and <option>v4mv</option>, while often
+  useful with MPEG-4, are not usable with MPEG-1 or MPEG-2.
+  Also, if you are trying to make a very high quality DVD encode, it may
+  be useful to add <option>dc=10</option> to lavcopts.
+  Doing so may help reduce the appearance of blocks in flat-colored areas.
+  Putting it all together, this is an example of a set of lavcopts for a
+  higher quality DVD:
+</para>
+
+<para>
+  <screen>
+  -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=8000:\
+  keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:\
+  vqmin=1:lmin=1:dc=10
+  </screen>
+</para>
+
+</sect3>
+</sect2>
+
+<sect2 id="menc-feat-vcd-dvd-audio">
+<title>Encoding Audio</title>
+<para>
+  VCD and SVCD support MPEG-1 layer II audio, using one of
+  <systemitem class="library">toolame</systemitem>,
+  <systemitem class="library">twolame</systemitem>,
+  or <systemitem class="library">libavcodec</systemitem>'s MP2 encoder.
+  The libavcodec MP2 is far from being as good as the other two libraries,
+  however it should always be available to use.
+  VCD only supports constant bitrate audio (CBR) whereas SVCD supports
+  variable bitrate (VBR), too.
+  Be careful when using VBR because some bad standalone players might not
+  support it too well.
+</para>
+
+<para>
+  For DVD audio, <systemitem class="library">libavcodec</systemitem>'s
+  AC3 codec is used.
+</para>
+
+<sect3 id="menc-feat-vcd-dvd-audio-toolame">
+<title>toolame</title>
+<para>
+  For VCD and SVCD:
+  <screen>
+  -oac toolame -toolameopts br=224
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-audio-twolame">
+<title>twolame</title>
+<para>
+  For VCD and SVCD:
+  <screen>
+  -oac twolame -twolameopts br=224
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-audio-lavc">
+<title>libavcodec</title>
+<para>
+  For DVD with 2 channel sound:
+  <screen>
+  -oac lavc -lavcopts acodec=ac3:abitrate=192
+  </screen>
+</para>
+<para>
+  For DVD with 5.1 channel sound:
+  <screen>
+  -channels 6 -oac lavc -lavcopts acodec=ac3:abitrate=384
+  </screen>
+</para>
+<para>
+  For VCD and SVCD:
+  <screen>
+  -oac lavc -lavcopts acodec=mp2:abitrate=224
+  </screen>
+</para>
+</sect3>
+
+</sect2>
+
+<sect2 id="menc-feat-vcd-dvd-all">
+<title>Putting it all Together</title>
+<para>
+  This section shows some complete commands for creating VCD/SVCD/DVD
+  compliant videos.
+</para>
+
+<sect3 id="menc-feat-vcd-dvd-all-pal-dvd">
+<title>PAL DVD</title>
+<para>
+  <screen>
+  mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\
+  harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
+  vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:\
+  abitrate=192:aspect=16/9 -ofps 25 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-all-ntsc-dvd">
+<title>NTSC DVD</title>
+<para>
+  <screen>
+  mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,\
+  harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
+  vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:\
+  abitrate=192:aspect=16/9 -ofps 30000/1001 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-all-pal-ac3-copy">
+<title>PAL AVI Containing AC3 Audio to DVD</title>
+<para>
+  If the source already has AC3 audio, use -oac copy instead of re-encoding it.
+  <screen>
+  mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\
+  harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:\
+  vbitrate=5000:keyint=15:aspect=16/9 -ofps 25 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-all-ntsc-ac3-copy">
+<title>NTSC AVI Containing AC3 Audio to DVD</title>
+<para>
+  If the source already has AC3 audio, and is NTSC @ 24000/1001 fps:
+  <screen>
+  mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd:telecine \
+  -vf scale=720:480,harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:\
+  vrc_maxrate=9800:vbitrate=5000:keyint=15:aspect=16/9 -ofps 24000/1001 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-all-pal-svcd">
+<title>PAL SVCD</title>
+<para>
+  <screen>
+  mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \
+  scale=480:576,harddup -srate 44100 -af lavcresample=44100 -lavcopts \
+  vcodec=mpeg2video:mbd=2:keyint=15:vrc_buf_size=917:vrc_minrate=600:\
+  vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 -ofps 25 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-all-ntsc-svcd">
+<title>NTSC SVCD</title>
+<para>
+  <screen>
+  mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd  -vf \
+  scale=480:480,harddup -srate 44100 -af lavcresample=44100 -lavcopts \
+  vcodec=mpeg2video:mbd=2:keyint=18:vrc_buf_size=917:vrc_minrate=600:\
+  vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 -ofps 30000/1001 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-all-pal-vcd">
+<title>PAL VCD</title>
+<para>
+  <screen>
+  mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \
+  scale=352:288,harddup -srate 44100 -af lavcresample=44100 -lavcopts \
+  vcodec=mpeg1video:keyint=15:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:\
+  vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 25 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+<sect3 id="menc-feat-vcd-dvd-all-ntsc-vcd">
+<title>NTSC VCD</title>
+<para>
+  <screen>
+  mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \
+  scale=352:240,harddup -srate 44100 -af lavcresample=44100 -lavcopts \
+  vcodec=mpeg1video:keyint=18:vrc_buf_size=327:vrc_minrate=1152:vbitrate=1152:\
+  vrc_maxrate=1152:acodec=mp2:abitrate=224 -ofps 30000/1001 \
+  -o <replaceable>movie.mpg</replaceable> <replaceable>movie.avi</replaceable>
+  </screen>
+</para>
+</sect3>
+
+</sect2>
+
+</sect1>
+
+</chapter>