[MPlayer-translations] r19030 - trunk/DOCS/xml/pl/encoding-guide.xml
boskicinek
subversion at mplayerhq.hu
Wed Jul 12 16:03:23 CEST 2006
Author: boskicinek
Date: Wed Jul 12 16:03:19 2006
New Revision: 19030
Added:
trunk/DOCS/xml/pl/encoding-guide.xml
Log:
- incomplete but we probably need this (because we updated mencoder.xml already)
Added: trunk/DOCS/xml/pl/encoding-guide.xml
==============================================================================
--- (empty file)
+++ trunk/DOCS/xml/pl/encoding-guide.xml Wed Jul 12 16:03:19 2006
@@ -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
+ "30000/1001 fps NTSC content."
+</para>
+
+<para>
+ When you watch progressive video, you should never see any
+ interlacing. Beware, however, because sometimes there is a tiny bit
+ of telecine mixed in where you would not expect. I have encountered TV
+ show DVDs that have one second of telecine at every scene change, or
+ at seemingly random places. I once watched a DVD that had a
+ progressive first half, and the second half was telecined. If you
+ want to be <emphasis>really</emphasis> thorough, you can scan the
+ entire movie:
+
+ <screen>mplayer dvd://1 -nosound -vo null -benchmark</screen>
+
+ Using <option>-benchmark</option> makes
+ <application>MPlayer</application> play the movie as quickly as it
+ possibly can; still, depending on your hardware, it can take a
+ while. Every time demux_mpg reports a framerate change, the line
+ immediately above will show you the time at which the change
+ occurred.
+</para>
+
+<para>
+ Sometimes progressive video on DVDs is referred to as
+ "soft-telecine" because it is intended to
+ be telecined by the DVD player.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-ident-telecined">
+<title>Telecined</title>
+<para>
+ Telecined video was originally filmed at 24000/1001, but was telecined
+ <emphasis>before</emphasis> it was written to the DVD.
+</para>
+
+<para>
+ <application>MPlayer</application> does not (ever) report any
+ framerate changes when it plays telecined video.
+</para>
+
+<para>
+ Watching a telecined video, you will see interlacing artifacts that
+ seem to "blink": they repeatedly appear and disappear.
+ You can look closely at this by
+ <orderedlist>
+ <listitem>
+ <screen>mplayer dvd://1</screen>
+ </listitem>
+ <listitem><para>
+ Seek to a part with motion.
+ </para></listitem>
+ <listitem><para>
+ Use the <keycap>.</keycap> key to step forward one frame at a time.
+ </para></listitem>
+ <listitem><para>
+ Look at the pattern of interlaced-looking and progressive-looking
+ frames. If the pattern you see is PPPII,PPPII,PPPII,... then the
+ video is telecined. If you see some other pattern, then the video
+ may have been telecined using some non-standard method;
+ <application>MEncoder</application> cannot losslessly convert
+ non-standard telecine to progressive. If you do not see any
+ pattern at all, then it is most likely interlaced.
+ </para></listitem>
+ </orderedlist>
+</para>
+
+<para>
+ Sometimes telecined video on DVDs is referred to as
+ "hard-telecine". Since hard-telecine is already 60000/1001 fields
+ per second, the DVD player plays the video without any manipulation.
+</para>
+
+<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 "combing") is a result of combining pairs of
+ fields into frames. Each field is supposed to be 1/(60000/1001) seconds apart,
+ and when they are displayed simultaneously the difference is apparent.
+</para>
+
+<para>
+ As with telecined video, <application>MPlayer</application> should
+ not ever report any framerate changes when playing interlaced content.
+</para>
+
+<para>
+ When you view an interlaced video closely by frame-stepping with the
+ <keycap>.</keycap> key, you will see that every single frame is interlaced.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-ident-mixedpt">
+<title>Mixed progressive and telecine</title>
+<para>
+ All of a "mixed progressive and telecine" video was originally
+ 24000/1001 frames per second, but some parts of it ended up being telecined.
+</para>
+
+<para>
+ When <application>MPlayer</application> plays this category, it will
+ (often repeatedly) switch back and forth between "30000/1001 fps NTSC"
+ and "24000/1001 fps progressive NTSC". Watch the bottom of
+ <application>MPlayer</application>'s output to see these messages.
+</para>
+
+<para>
+ You should check the "30000/1001 fps NTSC" sections to make sure
+ they are actually telecine, and not just interlaced.
+</para>
+</sect3>
+
+<sect3 id="menc-feat-telecine-ident-mixedpi">
+<title>Mixed progressive and interlaced</title>
+<para>
+ In "mixed progressive and interlaced" content, progressive
+ and interlaced video have been spliced together.
+</para>
+
+<para>
+ This category looks just like "mixed progressive and telecine",
+ until you examine the 30000/1001 fps sections and see that they do not have the
+ telecine pattern.
+</para>
+</sect3>
+
+</sect2>
+
+<sect2 id="menc-feat-telecine-encode">
+<title>How to encode each category</title>
+<para>
+ As I mentioned in the beginning, example <application>MEncoder</application>
+ lines below are <emphasis role="bold">not</emphasis> meant to actually be used;
+ they only demonstrate the minimum parameters to properly encode each category.
+</para>
+
+<sect3 id="menc-feat-telecine-encode-progressive">
+<title>Progressive</title>
+<para>
+ Progressive video requires no special filtering to encode. The only
+ parameter you need to be sure to use is
+ <option>-ofps 24000/1001</option>. Otherwise, <application>MEncoder</application>
+ will try to encode at 30000/1001 fps and will duplicate frames.
+</para>
+
+<para>
+ <screen>mencoder dvd://1 -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 "guess" what ought to make up the
+ corresponding lines for each field (this has drawbacks - see method
+ 3).
+</para>
+
+<orderedlist>
+<listitem><para>
+
+ Encode the video in interlaced form. Normally, interlacing wreaks
+ havoc with the encoder's ability to compress well, but
+ <systemitem class="library">libavcodec</systemitem> has two
+ parameters specifically for dealing with storing interlaced video a
+ bit better: <option> ildct</option> and <option>ilme</option>. Also,
+ using <option>mbd=2</option> is strongly recommended
+ <link linkend="menc-feat-telecine-footnotes">[2] </link> because it
+ will encode macroblocks as non-interlaced in places where there is
+ no motion. Note that <option>-ofps</option> is NOT needed here.
+
+ <screen>mencoder dvd://1 -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 "deint"), and search the
+ <ulink url="http://www.mplayerhq.hu/homepage/design6/info.html#mailing_lists">
+ MPlayer mailing lists</ulink> to find many discussions about the
+ various filters. Again, the framerate is not changing, so no
+ <option>-ofps</option>. Also, deinterlacing should be done after
+ cropping <link linkend="menc-feat-telecine-footnotes">[1]</link> and
+ before scaling.
+
+ <screen>mencoder dvd://1 -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
+ "mixed progressive and telecine".
+
+ <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 & progressive TVs) which gives ugly flickering and
+ other artifacts. If you are going to use it, you at least need to
+ spend some time tuning the options and watching the output first
+ to make sure it is not messing up.</para></blockquote>
+ </para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3 id="menc-feat-telecine-encode-mixedpi">
+<title>Mixed progressive and interlaced</title>
+<para>
+ There are two options for dealing with this category, each of
+ which is a compromise. You should decide based on the
+ duration/location of each type.
+</para>
+
+<itemizedlist>
+<listitem><para>
+ Treat it as progressive. The interlaced parts will look interlaced,
+ and some of the interlaced fields will have to be dropped, resulting
+ in a bit of uneven jumpiness. You can use a postprocessing filter if
+ you want to, but it may slightly degrade the progressive parts.
+ </para>
+
+ <para>
+ This option should definitely not be used if you want to eventually
+ display the video on an interlaced device (with a TV card, for
+ example). If you have interlaced frames in a 24000/1001 frames per
+ second video, they will be telecined along with the progressive
+ frames. Half of the interlaced "frames" will be displayed for three
+ fields' duration (3/(60000/1001) seconds), resulting in a flicking
+ "jump back in time" effect that looks quite bad. If you
+ even attempt this, you <emphasis role="bold">must</emphasis> use a
+ deinterlacing filter like <option>lb</option> or
+ <option>l5</option>.
+ </para>
+
+ <para>
+ It may also be a bad idea for progressive display, too. It will drop
+ pairs of consecutive interlaced fields, resulting in a discontinuity
+ that can be more visible than with the second method, which shows
+ some progressive frames twice. 30000/1001 frames per second interlaced
+ video is already a bit choppy because it really should be shown at
+ 60000/1001 fields per second, so the duplicate frames do not stand out as
+ much.
+ </para>
+
+ <para>
+ Either way, it is best to consider your content and how you intend to
+ display it. If your video is 90% progressive and you never intend to
+ show it on a TV, you should favor a progressive approach. If it is
+ only half progressive, you probably want to encode it as if it is all
+ interlaced.
+ </para>
+ </listitem>
+
+<listitem><para>
+ Treat it as interlaced. Some frames of the progressive parts will
+ need to be duplicated, resulting in uneven jumpiness. Again,
+ deinterlacing filters may slightly degrade the progressive parts.
+ </para></listitem>
+
+</itemizedlist>
+</sect3>
+
+</sect2>
+
+<sect2 id="menc-feat-telecine-footnotes">
+<title>Footnotes</title>
+<orderedlist>
+<listitem><formalpara>
+ <title>About cropping:</title>
+ <para>
+ Video data on DVDs are stored in a format called YUV 4:2:0. In YUV
+ video, luma ("brightness") and chroma ("color")
+ are stored separately. Because the human eye is somewhat less
+ sensitive to color than it is to brightness, in a YUV 4:2:0 picture
+ there is only one chroma pixel for every four luma pixels. In a
+ progressive picture, each square of four luma pixels (two on each
+ side) has one common chroma pixel. You must crop progressive YUV
+ 4:2:0 to even resolutions, and use even offsets. For example,
+ <option>crop=716:380:2:26</option> is OK but
+ <option>crop=716:380:3:26 </option> is not.
+ </para>
+ </formalpara>
+
+ <para>
+ When you are dealing with interlaced YUV 4:2:0, the situation is a
+ bit more complicated. Instead of every four luma pixels in the
+ <emphasis>frame</emphasis> sharing a chroma pixel, every four luma
+ pixels in each <emphasis> field</emphasis> share a chroma
+ pixel. When fields are interlaced to form a frame, each scanline is
+ one pixel high. Now, instead of all four luma pixels being in a
+ square, there are two pixels side-by-side, and the other two pixels
+ are side-by-side two scanlines down. The two luma pixels in the
+ intermediate scanline are from the other field, and so share a
+ different chroma pixel with two luma pixels two scanlines away. All
+ this confusion makes it necessary to have vertical crop dimensions
+ and offsets be multiples of four. Horizontal can stay even.
+ </para>
+
+ <para>
+ For telecined video, I recommend that cropping take place after
+ inverse telecining. Once the video is progressive you only need to
+ crop by even numbers. If you really want to gain the slight speedup
+ that cropping first may offer, you must crop vertically by multiples
+ of four or else the inverse-telecine filter will not have proper data.
+ </para>
+
+ <para>
+ For interlaced (not telecined) video, you must always crop
+ vertically by multiples of four unless you use <option>-vf
+ field</option> before cropping.
+ </para>
+ </listitem>
+
+<listitem><formalpara>
+ <title>About encoding parameters and quality:</title>
+ <para>
+ Just because I recommend <option>mbd=2</option> here does not mean it
+ should not be used elsewhere. Along with <option>trell</option>,
+ <option>mbd=2</option> is one of the two
+ <systemitem class="library">libavcodec</systemitem> options that
+ increases quality the most, and you should always use at least those
+ two unless the drop in encoding speed is prohibitive (e.g. realtime
+ encoding). There are many other options to
+ <systemitem class="library">libavcodec</systemitem> that increase
+ encoding quality (and decrease encoding speed) but that is beyond
+ the scope of this document.
+ </para>
+ </formalpara>
+ </listitem>
+
+<listitem><formalpara>
+ <title>About the performance of pullup:</title>
+ <para>
+ It is safe to use <option>pullup</option> (along with <option>softskip
+ </option>) on progressive video, and is usually a good idea unless
+ the source has been definitively verified to be entirely progressive.
+ The performace loss is small for most cases. On a bare-minimum encode,
+ <option>pullup</option> causes <application>MEncoder</application> to
+ be 50% slower. Adding sound processing and advanced <option>lavcopts
+ </option> overshadows that difference, bringing the performance
+ decrease of using <option>pullup</option> down to 2%.
+ </para>
+ </formalpara>
+ </listitem>
+
+</orderedlist>
+
+</sect2>
+
+</sect1>
+
+
+<sect1 id="menc-feat-enc-libavcodec">
+<title>Encoding with the <systemitem class="library">libavcodec</systemitem>
+ codec family</title>
+
+<para>
+<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link>
+provides simple encoding to a lot of interesting video and audio formats.
+You can encode to the following codecs (more or less up to date):
+</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 "Notch" Quantization Matrix:</emphasis>
+</para>
+
+<para>
+Intra:
+<screen>
+ 8 9 12 22 26 27 29 34
+ 9 10 14 26 27 29 34 37
+12 14 18 27 29 34 37 38
+22 26 27 31 36 37 38 40
+26 27 29 36 39 38 40 48
+27 29 34 37 38 40 48 58
+29 34 37 38 40 48 58 69
+34 37 38 40 48 58 69 79
+</screen>
+
+Inter:
+<screen>
+16 18 20 22 24 26 28 30
+18 20 22 24 26 28 30 32
+20 22 24 26 28 30 32 34
+22 24 26 30 32 32 34 36
+24 26 28 32 34 34 36 38
+26 28 30 32 34 36 38 40
+28 30 32 34 36 38 42 42
+30 32 34 36 38 40 42 44
+</screen>
+</para>
+
+<para>
+Usage:
+<screen>
+$ mencoder <replaceable>input.avi</replaceable> -o <replaceable>output.avi</replaceable> -oac copy -ovc lavc -lavcopts inter_matrix=...:intra_matrix=...
+</screen>
+</para>
+
+<para>
+<screen>
+$ mencoder <replaceable>input.avi</replaceable> -ovc lavc -lavcopts
+vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,
+12,14,18,27,29,34,37,38,22,26,27,31,36,37,38,40,26,27,29,36,39,38,40,48,27,
+29,34,37,38,40,48,58,29,34,37,38,40,48,58,69,34,37,38,40,48,58,69,79
+:inter_matrix=16,18,20,22,24,26,28,30,18,20,22,24,26,28,30,32,20,22,24,26,
+28,30,32,34,22,24,26,30,32,32,34,36,24,26,28,32,34,34,36,38,26,28,30,32,34,
+36,38,40,28,30,32,34,36,38,42,42,30,32,34,36,38,40,42,44 -oac copy -o svcd.mpg
+</screen>
+</para>
+</sect2>
+
+
+<sect2 id="menc-feat-dvd-mpeg4-example">
+<title>Example</title>
+
+<para>
+ So, you have just bought your shiny new copy of Harry Potter and the Chamber
+ of Secrets (widescreen edition, of course), and you want to rip this DVD
+ so that you can add it to your Home Theatre PC. This is a region 1 DVD,
+ so it is NTSC. The example below will still apply to PAL, except you will
+ omit <option>-ofps 24000/1001</option> (because the output framerate is the
+ same as the input framerate), and of course the crop dimensions will be
+ different.
+</para>
+
+<para>
+ After running <option>mplayer dvd://1</option>, we follow the process
+ detailed in the section <link linkend="menc-feat-telecine">How to deal
+ with telecine and interlacing in NTSC DVDs</link> and discover that it is
+ 24000/1001 fps progressive video, which means that we 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>
More information about the MPlayer-translations
mailing list