[MPlayer-translations] r25307 - trunk/DOCS/xml/it/encoding-guide.xml
ptt
subversion at mplayerhq.hu
Wed Dec 5 20:06:12 CET 2007
Author: ptt
Date: Wed Dec 5 20:06:12 2007
New Revision: 25307
Log:
initial submit for revision... 24% synced with r22753
Added:
trunk/DOCS/xml/it/encoding-guide.xml
Added: trunk/DOCS/xml/it/encoding-guide.xml
==============================================================================
--- (empty file)
+++ trunk/DOCS/xml/it/encoding-guide.xml Wed Dec 5 20:06:12 2007
@@ -0,0 +1,5326 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- 24% synced with r22753 -->
+<chapter id="encoding-guide">
+<title>La codifica con <application>MEncoder</application></title>
+
+<sect1 id="menc-feat-dvd-mpeg4">
+<title>Produrre un rip di un film da DVD in un
+ MPEG-4 ("DivX") di alta qualità</title>
+
+<para>
+Una domanda frequente è "Come posso generare il rip con la migliore quallità
+per una dimensione data?". Un'altra domanda è "Come posso fare il rip da DVD
+migliore in assoluto? Non mi interessa la dimensione del file, voglio solo la
+più alta qualità."
+</para>
+
+<para>
+L'ultima domanda è perlomeno forse posta malamente. Dopo tutto, se non ti
+interessa la dimensione del file, perché non ti copi semplicemente l'intero
+flusso video MPEG-2 dal DVD? Certo, avrai un AVI di 5GB, prendere o lasciare,
+ma se vuoi la miglior qualità e non ti importa della dimensione, è
+sicuramente la scelta migliore.
+</para>
+
+<para>
+Invero, la ragione per cui vuoi codificare un DVD in MPEG-4 è proprio perché
+ti interessa <emphasis role="bold">davvero</emphasis> la dimensione del file.
+</para>
+
+<para>
+E' difficile offrire una ricetta da libro su come generare un rip da DVD in
+qualità molto alta. Bisogna considerare vari fattori, e dovresti comprendere
+questi dettagli, altrimenti alla fine probabilmente sarai insoddisfatto del
+risultato. Più sotto evidenziamo alcuni di questi argomenti e poi passiamo ad
+esaminare un esempio. Partiamo dal principio che per codificare il video tu
+stia usando <systemitem class="library">libavcodec</systemitem> anche se la
+teoria si applica allo stesso modo agli altri codec.
+</para>
+
+<para>
+Se questo ti sembra troppo, dovresti probabilmente usare una delle belle
+interfacce elencate nella
+<ulink url="http://www.mplayerhq.hu/design7/projects.html#mencoder_frontends">sezione su MEncoder</ulink>
+nella pagina dei progetti collegati (related projects).
+In tal modo riuscirai ad ottenere rip di alta qualità senza pensarci troppo,
+dato che la maggior parte di questi strumenti sono progettati per prendere
+decisioni sagge al tuo posto.
+</para>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-preparing-encode">
+<title>Prepararsi alla codifica: identificare il materiale sorgente e la frequenza fotogrammi (framerate)</title>
+
+<para>
+Prima ancora di pensare a codificare un film, devi fare alcuni passi
+preliminari.
+</para>
+
+<para>
+Il primo e più importante passo prima della codifica dovrebbe essere
+determinare il tipo di contenuto che stai trattando.
+Se il tuo materiale di partenza arriva da un DVD o da TV in
+broadcast/via cavo/satellite, sarà salvato in uno dei due formati: NTSC per
+il Nord America e il Giappone, PAL per l'Europa, etc...
+E' importante tuttavia comprendere che questo è solo il formato per la
+trasmissione in televisione, e spesso <emphasis role="bold">non</emphasis>
+corrisponde al formato originario del film.
+L'esperienza insegna che il materiale NTSC è molto più difficile da
+codificare, perché ci sono più elementi da identificare nel sorgente.
+Per generare una codifica adeguata, devi sapere il formato originario.
+Il non tenerne conto porterà a molti __flaws__ nella tua codifica, inclusi
+artefatti orrendi __combing__ (interlacing) e fotogrammi duplicati o addirittura
+perduti.
+Oltre ad essere brutti, gli artefatti influenzano negativamente l'efficenza
+della codifica: otterrai una peggior qualità a parità di bitrate.
+</para>
+
+
+<sect3 id="menc-feat-dvd-mpeg4-preparing-encode-fps">
+<title>Identificare la frequenza fotogrammi (framerate) del sorgente</title>
+
+<para>
+C'è qui un elenco di tipi comuni di materiale sorgente, dove facilmente si
+trovano e le loro proprietà:
+</para>
+
+<itemizedlist>
+<listitem><para>
+ <emphasis role="bold">Film standard</emphasis>: prodotti per la visione
+ su schermi da cinema a 24fps.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Video PAL</emphasis>: registrati con una videocamera
+ PAL a 50 campi al secondo.
+ Un campo è composto dalle sole linee pari o dispari di un fotogramma.
+ La televisione è stata progettata per aggiornarle alternativamente come un
+ metodo economico di compressione analogica.
+ L'occhio umano teoricamente compensa la cosa, ma una volta che capisci come
+ funziona l'interlacciatura imparerai a vederla anche in TV e non ti piacerà
+ più la TV.
+ Due campi <emphasis role="bold">non</emphasis> fanno un fotogramma intero,
+ poiché sono registrati a 1/50 di secondo di distanza nel tempo e quindi non
+ si allineano a meno che non ci sia movimento alcuno.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Video NTSC</emphasis>: registrati con una videocamera
+ NTSC a 60000/1001 campi al secondi, o 60 campi al secondo nell'era precedente
+ al colore.
+ Per il resto sono simili ai PAL.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Animazione</emphasis>: solitamente disegnati a 24fps,
+ ma se ne trovano anche in tipologie con frequenza di fotogrammi mista.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Computer Graphics (CG)</emphasis>: possono essere con
+ qualsiasi frequenza di fotogrammi, ma alcuni sono più comuni di altri;
+ sono tipici 24 e 30 fotogrammi al secondo per NTSC e 25fps per PAL.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Vecchi Film</emphasis>: varie e più basse frequenze di
+ fotogrammi.
+</para></listitem>
+</itemizedlist>
+</sect3>
+
+
+<sect3 id="menc-feat-dvd-mpeg4-preparing-encode-material">
+<title>Identificare il materiale sorgente</title>
+
+<para>
+I film composti da fotogrammi sono indicati come "progressivi", mentre quelli
+composti da campi indipendenti sono chiamati "interlacciati" o video - anche se
+quest'ultimo termine è ambiguo.
+</para>
+
+<para>
+Per complicare ulteriormente le cose, alcuni film possono essere un misto di
+molti dei suddetti.
+</para>
+
+<para>
+La più importante distinzione da farsi tra tutti questi formati è che alcuni
+sono basati su fotogrammi mentre gli altri sono basati su campi.
+<emphasis role="bold">Ogniqualvolta</emphasis> un film viene preparato per la
+visualizzazione in televisione (DVD inclusi), viene convertito in un formato
+basato su campi.
+I vari metodi con cui si può fare sono conosciuti nel loro insieme come
+"telecine", di cui il tristemente famoso "3:2 pulldown" NTSC è una tipologia.
+A meno che il materiale originale sia anch'esso basato su campi (e con la stessa
+frequenza di campi) otterrai un filmato in un formato diverso da quello che è
+in origine.
+</para>
+
+<itemizedlist>
+<title>Ci sono vari tipi usuali di "pulldown":</title>
+<listitem><para>
+ <emphasis role="bold">Pulldown PAL 2:2</emphasis>: il più bello di tutti.
+ Ciascun fotogramma viene mostrato per la durata di due campi, estraendo le
+ linee pari e dispari e mostrandole alternativamente.
+ Se il materiale di origine è a 24fps questo processo velocizza il filmato
+ del 4%.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Pulldown PAL 2:2:2:2:2:2:2:2:2:2:2:3</emphasis>:
+ Ogni dodicesimo fotogramma viene mostrato per la durata di tre campi, invece
+ che solamente per due.
+ Questo evita il problema dell'aumento del 4% di velocità, ma rende il
+ processo molto più difficile da __reversare__.
+ Solitamente viene usato nelle produzioni musicali, dove modificare del 4% la
+ velocità rovinerebbe pesantemente la colonna sonora.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Telecine NTSC 3:2</emphasis>: i fotogrammi vengono
+ mostrati alternativamente per la durata di 3 o 2 campi.
+ Questo porta ad una frequenza di campi di 2.5 volte la frequenza orginaria.
+ Il risultato viene anche leggermente rallentato da 60 campi al secondo fino a
+ 60000/1001 campi al secondo, per mantenere la frequenza dei campi di NTSC.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Pulldown NTSC 2:2</emphasis>: utilizzato per mostrare
+ materiale a 30fps su NTSC.
+ Carino, proprio come il pulldown PAL 2:2.
+</para></listitem>
+</itemizedlist>
+
+<para>
+Ci sono anche alcuni metodi per convertire tra video NTSC e PAL, ma gli
+arogmenti relativi non sono obiettivo di questa guida.
+Se ti trovi di fronte a un film di questo genere e lo vuoi codificare, la tua
+scelta migliore è cercarne una copia nel formato originale.
+La conversione tra questi due formati è altamente distruttiva e non può
+essere __reversed__ in maniera pulita, perciò la tua codifica __soffrirà__
+molto se eseguita da una sorgente convertita.
+</para>
+
+<para>
+Quando il video viene salvato du un DVD, coppie consecutive di campi sono
+raggruppati in un fotogramma, anche se non sono pensati per esser mostrati
+nello stesso momento.
+Lo standard MPEG-2 usato sui DVD e per la TV digitale fornisce un modo sia per
+codificare i fotogrammi progressivi originali, che uno per memorizzare
+nell'intestazione del fotogramma il numero dei campi per cui il fotogramma
+stesso debba essere mostrato.
+Se viene usato questo metodo il filmato verrà spesso indicato come
+"soft telecine", visto che il procedimento indica semplicemente al lettore DVD
+di applicare il pulldown al film, invece che modificare il film stesso.
+Questa situazione è decisamente preferibile, dato che può essere facilmente
+__reversed__ (__actually ignored__) dal condificatore, e dato che mantiene la
+massima qualità.
+Tuttavia, molti studi di produzione DVD e di trasmissione non usano tecniche di
+codifica appropriate, ma al contrario producono filmati con "hard telecine", in
+cui i campi sono sotanzialmente duplicati nell'MPEG-2 codificato.
+</para>
+
+<para>
+Le modalità per gestire questi casi verranno descritte
+<link linkend="menc-feat-telecine">più avanti in questa guida</link>.
+Per adesso ti lasciamo alcune indicazioni su come identificare il tipo di
+materiale che stai trattando:
+</para>
+
+<itemizedlist>
+<title>Regioni NTSC:</title>
+<listitem><para>
+ Se <application>MPlayer</application> dice che la frequenza fotogrammi passa
+ a 24000/1001 durante la visione del film e non ritorna come prima, è quasi
+ sicuramente un qualche contenuto progressivo che è stato modificato in
+ "soft telecine".
+</para></listitem>
+<listitem><para>
+ Se <application>MPlayer</application> dice che la frequenza fotogrammi va
+ avanti e indietro tra 24000/1001 e 30000/1001 e ogni tanto vedi delle "righe",
+ allora ci sono varie possibilità.
+ Le parti a 24000/1001 fps sono quasi certamente contenuto progressivo, in
+ "soft telecine", ma le parti a 30000/1001 fps possono essere sia contenuto in
+ "hard telecine" a 24000/1001 fps che video NTSC a 60000/1001 campi al secondo.
+ Usa le stesse linee guida dei due casi seguenti per determinare quale.
+</para></listitem>
+<listitem><para>
+ Se <application>MPlayer</application> non mostra mai una modifica alla
+ frequenza dei fotogrammi e ogni singolo fotogramma con del movimento appare
+ "rigato", il tuo filmato è video NTSC a 60000/1001 campi al secondo.
+</para></listitem>
+<listitem><para>
+ Se <application>MPlayer</application> non mostra mai una modifica alla
+ frequenza dei fotogrammi e due fotogrammi ogni cinque sono "rigati", il tuo
+ film è contenuto a 24000/1001fps in "hard telecine".
+</para></listitem>
+</itemizedlist>
+
+<itemizedlist>
+<title>Regioni PAL:</title>
+<listitem><para>
+ Se non vedi mai alcuna "riga", il tuo film è pulldown 2:2.
+</para></listitem>
+<listitem><para>
+ Se vedi delle "righe" che vanno e vengono ogni mezzo secondo,
+ allora il tuo film è pulldown 2:2:2:2:2:2:2:2:2:2:2:3.
+</para></listitem>
+<listitem><para>
+ Se vedi sempre "righe" durante il movimento, allora il tuo film è video
+ PAL a 50 campi al secondo.
+</para></listitem>
+</itemizedlist>
+
+<note><title>Consiglio:</title>
+<para>
+ <application>MPlayer</application> può rallentare la riproduzione del film
+ con l'opzione -speed o riprodurlo fotogramma per fotogramma.
+ Prova ad usare <option>-speed</option> 0.2 per guardare molto lentamente il
+ film o premi ripetutamente il tasto "<keycap>.</keycap>" per riprodurre un
+ fotogramma per volta ed identificare la sequenza, se non riesci a vederla a
+ velocità normale.
+</para>
+</note>
+</sect3>
+</sect2>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-2pass">
+<title>Quantizzatore costante vs. multipassaggio</title>
+
+<para>
+E' possibile codificare il filmato in un'ampia gamma di qualità.
+Con i codificatori video moderni e un pelo di compressione pre-codec
+(ridimensionando e ripulendo), è possibile raggiungere una qualità molto
+buona in 700 MB, per un film di 90-110 minuti in widescreen.
+Inoltre tutti i film tranne i più lunghi possono essere codificati con una
+qualità pressoché perfetta in 1400 MB.
+</para>
+
+<para>
+Ci sono tre approcci per codificare il video: bitrate costante (CBR),
+quantizzatore costante, e multipassaggio (ABR, o bitrate medio).
+</para>
+
+<para>
+La complessità dei fotogrammi di un filmato, e di conseguenza il numero di
+bit necessari per comprimerli, può variare molto da una scena ad un'altra.
+I codificatori video moderni possono adattarsi via via a queste necessità
+e cambiare il bitrate.
+In modalità semplici come CBR, tuttavia, i codificatori non sanno il bitrate
+necessario alle scene venture e perciò non possono stare sopra al bitrate
+richiesto per lunghi periodi di tempo.
+Modalità più avanzate, come la codifica in multipassaggio, possono tener
+conto delle statistiche del passo precedente; questo corregge il problema
+suddetto.
+</para>
+
+<note><title>Nota:</title>
+<para>
+La maggior parte dei codec che gestisce la codifica in ABR può usare solo la
+codifica a due passaggi mentre altri come
+<systemitem class="library">x264</systemitem>,
+<systemitem class="library">Xvid</systemitem> e
+<systemitem class="library">libavcodec</systemitem> gestiscono il
+multipassaggio, che migliora leggermente la qualità ad ogni passo, anche se
+tale moglioramento non è più misurabile né visibile veramente oltre il
+quarto passo o giù di lì.
+Perciò in questa sezione due passaggi e multipassaggio avranno lo stesso
+significato.
+</para>
+</note>
+
+<para>
+In ambedue i modi, il codec video (come
+<systemitem class="library">libavcodec</systemitem>) spezza il fotogramma video
+in macroblocchi da 16x16 pixel e poi applica un quantizzatore a ciascun
+macroblocco. Più basso è il quantizzatore, migliore sarà la qualità e
+più alto il bitrate.
+Il metodo usato dal codificatore del filmato per determinare quale quantizzatore
+utilizzare per un dato macroblocco varia ed è altamente configurabile.
+(Questa è una semplificazione estrema del vero processo, ma il concetto di base
+è comodo per capire.)
+</para>
+
+<para>
+Quando specifichi un bitrate constante, il codec video codificherà il video,
+scartando dettagli tanto quanto è necessario e il meno possibile, in modo da
+rimanere al di sotto del bitrate voluto. Se non ti interessa davvero la
+dimensione del file, potresti anche usare CBR e specificare un bitrate
+infinito. (In pratica, questo significa un valore abbastanza alto da non porre
+limiti, come 10000Kbit.) Con nessun limite sul bitrate, il risultato è che il
+codec userà il quantizzatore più basso possibile per ciascun macroblocco
+(come specificato da <option>vqmin</option> per
+<systemitem class="library">libavcodec</systemitem>, che è 2 di default).
+Appena specifichi un bitrate abbastanza basso tale che il codec venga forzato
+ad utilizzare un quantizzatore più alto, allora stai sicuramente diminuendo la
+qualità del tuo video.
+Per evitarlo, dovresti probabilmente ridurre la dimensione del tuo video,
+seguendo il metodo descritto più avanti in questa guida.
+In generale dovresti evitare del tutto CBR se ti interessa la qualità.
+</para>
+
+<para>
+Con il quantizzatore costante, il codec utilizza lo stesso quantizzatore per
+ogni macroblocco, come specificato dall'opzione <option>vqscale</option> (per
+<systemitem class="library">libavcodec</systemitem>).
+Se vuoi la più alta qualità possibile di rip, sempre ignorantdo il bitrate,
+puoi usare <option>vqscale=2</option>.
+Ciò porterà gli stessi bitrate e PSNR (peak signal-to-noise ratio) come CBR
+con <option>vbitrate</option>=infinito e <option>vqmin</option> di default a 2.
+</para>
+
+<para>
+Il problema con la quantizzazione costante è che usa il quantizzatore indicato
+sia che il macroblocco ne abbia bisogno o no. Perciò è possibile che venga
+usato un quantizzatore più alto su un macroblocco senza sacrificare la
+qualità visiva. Perché sprecare i bit di un quantizzatore basso che non
+serve? La tua CPU ha tanti cicli fin quando c'è tempo, ma c'è solo un certo
+numero di bit sul tuo disco rigido.
+</para>
+
+<para>
+Con una codifica a due passi, il primo codificherà il filmato come se fosse
+CBR, ma manterrà una registrazione delle caratteristiche di ogni fotogramma.
+Questi dati sono poi utilizzati durante il secondo passo in modo da effettuare
+scelte intelligenti su quale quantizzatore usare. Durante le scene con azione
+veloce o molti dettagliate, verrano usati più probabilmente quantizzatori più
+alti, e durante scene lente o con pochi dettagli, verranno usati quantizzatori
+più bassi. Solitamente è molto più importante la quantità di movimento
+che la quantità di dettagli.
+</para>
+
+<para>
+Se usi <option>vqscale=2</option>, allora stai sprecando dei bit. Se usi
+<option>vqscale=3</option>, allora non stai ottenendo la miglior qualità.
+Supponi di rippare un DVD a <option>vqscale=3</option> e che il risultato sia
+1800Kbit. Se fai una codifica a due passi con <option>vbitrate=1800</option> il
+video risultante avrà una <emphasis role="bold">qualità superiore</emphasis>
+a <emphasis role="bold">parità di bitrate</emphasis>.
+</para>
+
+<para>
+Dato che ora sei convinto che i due passaggi siano la strada da percorrere, la
+vera domanda adesso è quale bitrate usare? La risposta à che non c'è una
+risposta definitiva. Idealmente vuoi scegliere un bitrate che porti al miglior
+equilibrio tra qualità e dimensione del file. Tutto ciò varia in dipendenza
+del video di origine.
+</para>
+
+<para>
+Se la dimensione non è importante, un buon punto di partenza per un rip di
+qualità molto elevata è intorno a 2000Kbit più o meno 200Kbit.
+Per video con scene di azione veloce o con molti dettagli, oppure se
+semplicemente hai l'occhio critico, potresti scegliere 2400 o 2600.
+Per alcuni DVD potresti non notare alcuna differenza a 1400Kbit. Sperimentare
+con alcune scene a vari bitrate è una buona idea per farsi un'opinione.
+</para>
+
+<para>
+Se punti a una data dimensione, dovrai calcolare il bitrate in un qualche modo.
+Prima di farlo, però, devi sapere quanto spazio devi riservare per la traccia
+(le tracce) audio, per cui devi dapprima fare il
+<link linkend="menc-feat-dvd-mpeg4-audio">rip di queste</link>.
+Puoi calcolare il bitrate con l'equazione che segue:
+<systemitem>bitrate = (dimensione_voluta_in_Mbytes - dimensione_audio_in_Mbytes)
+* 1024 * 1024 / lunghezza_in_secondi * 8 / 1000</systemitem>
+Per esempio, per far stare un film di due ore su un CD da 702MB, con 60MB di
+traccia audio, il bitrate video diventerà:
+<systemitem>(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000
+= 740kbps</systemitem>
+</para>
+</sect2>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-constraints">
+<title>Vincoli per una codifica efficiente</title>
+
+<para>
+A causa della natura del tipo di compressione MPEG, ci sono alcuni vincoli da
+seguire per avere la massima qualità.
+L'MPEG divide il video in quadrati da 16x16 chiamati macroblocchi, ciascuno di
+essi composto da blocchi 4x4 con informazioni sulla luminanza (intensità) e
+due blocchi da 8x8 a metà risoluzione per la crominanza (colore) (uno per
+l'asse rosso-ciano e l'altro per l'asse blu-giallo).
+Anche se la larghezza e l'altezza del tuo filmato non sono multipli di 16 il
+codificatore userà tanti macroblocchi 16x16 in modo da coprire tutta la
+superficie dell'immagine, e lo spazio in esubero sarà sprecato.
+Indi, per migliorare la qualità a una dimensione prefissata è una brutta
+idea utilizzare dimensioni che non siano multiple di 16.
+</para>
+
+<para>
+La maggior parte dei DVD ha anche alcune con bordi neri sui lati. Lasciarli lì
+avrà un'influenza <emphasis role="bold">molto</emphasis> negativa sulla
+qualità in svariati modi.
+</para>
+
+<orderedlist>
+<listitem>
+ <para>
+ Il tipo di compressione MPEG è pesantemente dipendente dalle trasformazioni
+ di dominio frequenti, in particolare la "trasformazione discreta del coseno"
+ (Discrete Cosine Transform (DCT)), che xxièe' simile alla trasformazione di
+ Fourier. Quest'approccio di codifica è efficiente nella rappresentazione di
+ motivi e transizioni delicate, ma trova difficoltà con spigoli più
+ definiti. Per codificarli deve usare molti più bit oppure apparirà un
+ artefatto conosciuto come 'ringing'.
+ </para>
+
+ <para>
+ La trasformazione di frequenza (DCT) prende luogo separatemente in ogni
+ macroblocco (praticamente in ogni blocco) perciò questo problema si applica
+ solo quando lo spigolo definito è dentro a un blocco. Se il bordo nero inizia
+ esattamente sul lato di un multiplo di 16, questo non e' un problema.
+ Tuttavia i bordi neri sui DVD difficilmente sono ben allineati, perciò
+ nella realtà dovrai sempre tagliarli via per evitare questi problemi.
+ </para>
+</listitem>
+</orderedlist>
+
+<para>
+Oltre alle trasformazioni del dominio di frequenza, il tipo di compressione
+MPEG usa dei vettori di movimento per rappresetare le variazioni da un
+fotogramma al successivo. Naturalmente i vettori di movimento funzionano molto
+meno bene per i nuovi contenuti che arrivano dai bordi dell'immagine, dato che
+non erano presenti nel fotogramma precedente. Fintanto che l'immagine arriva
+fino al bordo dell'area codificata, i vettori di movimento non incontrano
+alcun problema con li contenuto che esce dall'immagine. Tuttavia ci possono
+esser problemi quando ci sono dei bordi neri:
+</para>
+
+<orderedlist continuation="continues">
+<listitem>
+ <para>
+ Per ogni macroblocco il tipo di compressione MPEG memorizza un vettore, che
+ identifica quale parte del fotogramma precedente debba essere copiata nel
+ macroblocco stesso, come base per predire il fotogramma successivo. Serve
+ codificare solo le differenze restanti. Se un macroblocco oltrepassa il
+ bordo dell'immagine e contiene parte del bordo nero, allora i vettori di
+ movimento provenienti da altre zone dell'immagine ricopriranno il bordo
+ nero. Questo significa che si devono utilizzare molti bit o per riannerire il
+ bordo che è stato ricoperto, oppure (più verosimilmente) un vettore di
+ movimento non sarà proprio usato e tutti i cambiamenti in questo
+ macroblocco dovranno venir esplicitamente codificate. In un modo o nell'altro
+ si ricuce di gran lunga l'efficienza della codifica.
+ </para>
+
+ <para>
+ Inoltre questo problema si applica solo se i bordi neri non sono allinati
+ su limiti di multipli di 16.
+ </para>
+</listitem>
+
+<listitem>
+ <para>
+ Immagina infine di avere un macroblocco all'interno dell'immagine, ed un
+ oggetto che passa da questo blocco verso il bordo dell'immagine. La
+ codifica MPEG non può dire "copia la parte che è dentro all'immagine, ma
+ non il bordo nero". Perciò anche il bordo nero vi verrà copiato
+ all'interno, e molti bit saranno sprecati codificando l'immagine che si
+ suppone stia lì.
+ </para>
+
+ <para>
+ Se l'immagine arriva al limite della superficie codificata, l'MPEG ha una
+ particolare ottimizzazione che consta nel copiare ripetutamente i pixel sul
+ bordo dell'immagine quando un vettore di movimento arriva dall'esterno della
+ superficie codificata. Questa funzionalità diventa inutile quando il film
+ ha dei bordi neri. Diversamente dai problemi 1 e 2, allineare i bordi a
+ multipli di 16 in questo caso non aiuta.
+ </para>
+</listitem>
+
+<listitem><para>
+ A dispetto del fatto che i bordi siano completamente neri e non cambino mai,
+ c'è perlomeno un piccolo spreco nell'avere più macroblocchi.
+</para></listitem>
+</orderedlist>
+
+<para>
+Per tutte queste ragioni si consiglia di tagliar via completamente i bordi neri.
+Inoltre, se c'è una zona di rumore/distorsione sui bordi dell'immagine,
+tagliarla migliorerà ancora l'efficienza di codifica. I puristi videofili che
+vogliono mantenere il più possibile l'originale potrebbero obiettare su questo
+taglio, ma a meno di non codificare a una quantizzazione costante, la qualità
+guadagnata tagliando sorpasserà di gran lunga la quantità di informazioni
+perse sui bordi.
+</para>
+</sect2>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-crop">
+<title>Tagliare e Ridimensionare</title>
+
+<para>
+Ricorda dalla sezione precedente che la dimensione finale dell'immagine che
+codifichi dovrebbe essere un multiplo di 16 (sia in larghezza che altezza).
+Si può ottenere ciò tagliando, ridimensionando o combinando le due cose.
+</para>
+
+<para>
+Quando tagli, ci sono alcune linee guida che si devono seguire per evitare di
+rovinare il tuo filmato.
+Il formato YUV abituale, 4:2:0, memorizza le informazioni sulla crominanza
+(colore) sottocampionate, per es. la crominanza viene campionata in ogni
+direzione solo la metà di quanto venga la luminanza (intensità).
+Osserva questo diagramma, dove L indica i punti di campionamente della
+luminanza e C quelli della crominanza.
+</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>
+Come puoi vedere, le righe e le colonne dell'immagine vengono sempre a coppie.
+Quindi i tuoi valori di spostamento e dimensione <emphasis>devono</emphasis>
+essere numeri pari.
+Se non lo sono la crominanza non sarà più allineata correttamente con la
+luminanza.
+In teoria è possibile tagliare con uno spostamento dispari, ma richiede che la
+crominanza venga ricampionata, il che potenzialmente è un'operazione in perdita
+e non è gestita dal filtro crop.
+</para>
+
+<para>
+Inoltre, il video interlacciato viene campionato come segue:
+</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">Campo superiore</entry>
+ <entry namest="col9" nameend="col16">Campo inferiore</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>
+Come puoi notare, il motivo non si ripete fino a dopo 4 linee.
+Quindi per il video interlacciato, il tuo spostamento sull'asse y e l'altezza
+devono essere multipli di 4.
+</para>
+
+<para>
+La risoluzione nativa DVD è 720x480 per NTSC e 720x576 per PAL, ma c'è un
+flag per l'aspetto che indica se è full-screen (4:3) o wide-screen (16:9).
+Molti (se non quasi tutti) i DVD in widescreen non sono esattamente 16:9 e
+possono essere sia 1.85:1 o 2.35:1 (cinescope). Questo significa che nel video
+ci saranno bordi neri che bisogna tagliare via.
+</para>
+
+<para>
+<application>MPlayer</application> fornisce un filtro che rileva i valori di
+taglio e fornisce il rettangolo per crop (<option>-vf cropdetect</option>).
+Esegui <application>MPlayer</application> con <option>-vf cropdetect</option> ed
+emetterà le impostazioni di taglio per crop al fine di rimuovere i bordi.
+Dovresti lasciare andare avanti il film abbastanza da ottenere valori di taglio
+precisi.
+</para>
+
+<para>
+Dopodiché prova con <application>MPlayer</application> i valori ottenuti usando
+la linea comando emessa da <option>cropdetect</option>, e correggi il
+rettangolo se e come serve.
+Il filtro <option>rectangle</option> può esserti di aiuto, dato che ti
+permette di impostare interattivamente la posizione del rettangolo di taglio
+sopra al filmato.
+Ricordati di seguire le linee guida sui multipli in modo da non disallineare
+i piani di crominanza.
+</para>
+
+<para>
+In talune occasioni, il ridimensionamento può essere indesiderabile.
+Il ridimensionamento sulla direzione verticale è difficoltoso con video
+interlacciato e se vuoi mantenere l'interlacciamento, dovresti evitare il
+ridimensionamento.
+Se non ridimensionerai, ma vuoi comunque usare dimensioni multiple di 16,
+dovrai tagliare di più.
+Evita di tagliare di meno, dato che i bordi neri sono un male per la codifica!
+</para>
+
+<para>
+Dato che MPEG-4 usa macroblocchi 16x16 vorrai esser sicuro che ambedue le
+dimensioni del video che stai per codificare siano multiple di 16, altrimenti
+perderai in qualità, soprattutto a bitrate più bassi. Puoi farlo abbassando
+la larghezza e l'altezza del rettangolo di taglio al multiplo di 16 più vicino.
+Come detto precedentemente, quando tagli, vorrai aumentare lo scostamento Y
+della metà della differenza tra la nuova e la vecchia altezza, in modo che il
+video risultante sia preso dal centro del fotogramma. Inoltre, a causa del modo
+in cui il video DVD viene campionato, assicurati che lo scostamento sia un
+numero pari. (Infatti, come regola, non utilizzare mai valori dispari per alcun
+parametro quando tagli e ridimensioni un video.) Se non ti va di scartare dei
+pixel in più, potresti piuttosto preferire il ridimensionamento del video.
+Prenderemo in esame questa situazione più avanti.
+Puoi in verità lasciare che tutte le considerazioni suddette vengano fatte
+dal filtro <option>cropdetect</option>, visto che ha un parametro
+<option>round</option> facoltativo, che è impostato a 16 di default.
+</para>
+
+<para>
+Fai anche attenzione ai pixel "mezzi neri" sui bordi. Assicurati di tagliare
+anch'essi, altrimenti sprecherai bit più utili altrove.
+</para>
+
+<para>
+Dopo aver detto e fatto tutto ciò, probabilmente avrei un vide i cui pixel
+non saranno proprio 1.85:1 o 2.35:1, ma piuttosto un valore vicino. Potresti
+calcolare a mano il nuovo rapporto di aspetto, ma
+<application>MEncoder</application> ha un'opzione per <systemitem
+class="library">libavcodec</systemitem> chiamata <option>autoaspect</option>
+che lo farà per te. Non aumentare assolutamente le dimensioni del video per
+avere i pixel quadrati, a meno che tu non voglia sprecare il tuo spazio disco.
+Il ridimensionamento dovrebbe essere eseguito in riproduzione, e per definire
+la risoluzione giusta il riproduttore userà l'aspetto memorizzato nell'AVI.
+Sfortunatamente non tutti i riproduttori verificano l'informazione sul rapporto
+perciò potresti voler comunque effettuare il ridimensionamento.
+</para>
+</sect2>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-resolution-bitrate">
+<title>Scegliere la risoluzione e il bitrate</title>
+
+<para>
+Other parameters such as scaling, cropping, etc. will
+<emphasis role="bold">not</emphasis> alter the file size unless you
+change the bitrate as well!.
+A meno che tu non stia per codificare con quantizzazione costante devi
+impostare un bitrate.
+La logica del bitrate è abbastanza semplice.
+Normalmente il bitrate viene misurato in kilobit (1000 bit) al secondo.
+La dimensione del filmato sul disco è il bitrate moltiplicato per la durata
+del filmato, più un piccolo quantitativo in "surplus" (vedi per esempio la
+sezione sul
+<link linkend="menc-feat-dvd-mpeg4-muxing-avi-limitations">contenitore AVI</link>).
+Altri parametri come ridimensionamento, taglio, etc...
+<emphasis role="bold">non</emphasis> influiscono sulla dimensione del file a
+meno che tu non cambi anche il bitrate!
+</para>
+
+<para>
+Il bitrate <emphasis role="bold">non</emphasis> è direttamente proporzionale
+alla risoluzione.
+Tanto per capirci, un file 320x240 a 200 kbit/sec non avrà la stessa qualità
+dello stesso filmato a 640x480 e 800 kbit/sec!
+Ci sono due ragioni per ciò:
+<orderedlist>
+<listitem><para>
+ <emphasis role="bold">Percettiva</emphasis>: noti di più gli artefatti MPEG
+ quando sono più grandi!
+ Gli artefatti appaiono a livello dei blocchi (8x8).
+ Il tuo occhio non noterà errori in 4800 piccoli blocchi tanti quanti ne
+ vedrà in 1200 grossi blocchi (assumendo che tu li stia ridimensionando tutti
+ e due a schermo intero).
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Teorica</emphasis> : quando rimpicciolisci un immagine
+ ma usi la stessa dimensione dei blocchi (8x8) per la trasformazione spaziale
+ della frequenza, hai più dati nelle bande ad alta frequenza. In parole
+ povere, ogni pixel contiene più dettagli di quanti ne contenesse prima.
+ Quindi anche se la tua immagine rimpicciolita contiene 1/4 delle informazioni
+ sulle direzioni spaziali, potrebbe ancora contenere una gran parte delle
+ informazioni nel dominio delal frequenza (assumendo che le alte frequenze
+ siano sotto-utilizzate nell'immagine di origine a 640x480).
+</para></listitem>
+</orderedlist>
+</para>
+
+<para>
+Guide precendenti hanno consigliato di scegliere un bitrate e una risoluzione
+in base ad un approccio "bit al secondo", ma di solito ciò non è valido a
+causa delle ragioni suddette.
+Una stima migliore pare essere che il bitrate è proporzionale alla radice
+quadrata della risoluzione, per cui 320x240 e 400 kbit/sec sarà
+paragonabile a 640x480 a 800 kbit/sec.
+Tuttavia ciò non è stato verificato con certezza empirica o teorica.
+Inoltre, dato che i filmati hanno diversi livelli di disturbo, dettaglio, angoli
+di movimento, etc..., è vano dare consigli generici su bit per lunghezza della
+diagonale (analogamente a bit per pixel, usando la radice quadrata).
+</para>
+<para>
+Finora abbiamo parlato della difficoltà nel scegliere un bitrate e una
+risoluzione.
+</para>
+
+
+<sect3 id="menc-feat-dvd-mpeg4-resolution-bitrate-compute">
+<title>Calcolare la risoluzione</title>
+
+<para>
+I passaggi seguenti ti guideranno nel calcolo della risoluzione per la tua
+codifica senza distorcere troppo il video, tenendo in considerazione vari tipo
+di informazioni riguardo la sorgente video.
+Per prima cosa dovresti calcolare il rapporto di aspetto codificato:
+<systemitem>ARc = (Wc x (ARa / PRdvd )) / Hc</systemitem>
+
+<itemizedlist>
+<title>dove:</title>
+<listitem><para>
+ Wc e Hc sono la larghezza e l'altezza del video tagliato,
+</para></listitem>
+<listitem><para>
+ ARa è il rapporto di aspetto mostrato, che di solito è 4/3 o 16/9,
+</para></listitem>
+<listitem><para>
+ PRdvd à il rapporto del pixel del DVD che è uguale a 1.25=(720/576) per DVD
+ PAL e 1.5=(720/480) per DVD NTSC.
+</para></listitem>
+</itemizedlist>
+</para>
+
+<para>
+Dopo puoi calcolare la risoluzione X e Y, basandoti su un dato fattore
+di qualità di compressione (Compression Quality, CQ):
+<systemitem>ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16</systemitem>
+and
+<systemitem>ResX = INT( ResY * ARc / 16) * 16</systemitem>
+</para>
+
+<para>
+Okay, ma cos'è la CQ?
+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.
+Il CQ rappresenta il numero di bit per pixel e per fotogramma in codifica.
+Parlando più semplicemente, più alto è la CQ, più difficilmente si vedranno
+codificati degli artefatti.
+</para>
+
+<para>
+La CQ dipende dal bitrate, dall'efficienza del codec video e dalla risoluzione
+del filmato.
+Per alzare la CQ, di solito dovrai rimpicciolire il filmato visto che il bitrate
+viene calcolato in funzione della dimensione voluta e della lunghezza del
+filmato, che sono delle costanti.
+Con codec MPEG-4 ASP come <systemitem class="library">Xvid</systemitem> e
+<systemitem class="library">libavcodec</systemitem>, una CQ inferiore a 0.18
+solitamente genera un'immagine abbastanza squadrettata, perché non ci sono
+abbastanza bit per codificare l'informazione di ogni macroblocco. (MPEG4, come
+molti altri codec, ragruppa i pixel in blocchi di pixel per comprimere
+l'immagine; se non ci sono abbastanza bit, si vedono i bordi dei blocchi.)
+E' saggio anche prendere una CQ compresa tra 0.20 e 0.22 per un rip a 1 CD,
+e 0.26-0.28 per un rip a 2 CD con impostazioni standard di codifica.
+Opzioni più evolute di codifica come quelle qui indicate per
+<link linkend="menc-feat-mpeg4-lavc-example-settings"><systemitem class="library">libavcodec</systemitem></link>
+e
+<link linkend="menc-feat-xvid-example-settings"><systemitem class="library">Xvid</systemitem></link>
+dovrebbero permetterti di ottenere la stessa qualità con CQ compresa tra
+0.18 e 0.20 per un rip da 1 CD, e da 0.24 a 0.26 per 2 CD.
+Con codec MPEG-4 AVC come <systemitem class="library">x264</systemitem>,
+puoi usare una CQ che varia da 0.14 a 0.16 con opzioni standard di codifica, e
+dovresti riuscire a scendere tra 0.10 e 0.12 con <link linkend="menc-feat-x264-example-settings">impostazioni avanzate di codifica
+<systemitem class="library">x264</systemitem></link>.
+</para>
+
+<para>
+Prendi per favore nota che CQ è solo un valore indicativo, dato che dipende dal
+contenuto che viene codificato, una CQ di 0.18 può andar bene per un Bergman,
+mentre per un film come Matrix, che contiene molte scene ad alta velocità, no.
+D'altro canto è inutile portare la CQ oltre 0.30 dato che sprecherai dei bit
+senza avere alcun guadagno visibile in qualità.
+Nota anche che come detto precedentemente in questa guida, per video a bassa
+risoluzione serve una CQ più alta (in rapporto, per esempio, alla risoluzione
+DVD) perché si vedano bene.
+</para>
+</sect3>
+</sect2>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-filtering">
+<title>Filtraggio</title>
+
+<para>
+Imparare come usare i filtri video di <application>MEncoder</application> è
+essenziale per produrre delle buone codfiche.
+Tutta l'elaborazione video è eseguita attraverso i filtri -- taglio,
+ridimensionamento, aggiustamento del colore, rimozione del disturbo, rilevamento
+margini, deinterlacciatura, telecine, telecine inverso, e deblocco, solo per
+nominarne qualcuno.
+Insieme con la vasta gamma di formati di entrata gestiti, la varietà dei
+filtri disponibili in <application>MEncoder</application> è uno dei suoi
+più grandi vantaggi sugli altri programmi similari.
+</para>
+
+<para>
+I filtri vengono caricati in catena usando l'opzione -vf:
+
+<screen>-vf filtro1=opzioni,filtro2=opzioni,...</screen>
+
+La maggior parte dei filtri riceve alcune opzioni numeriche separate da due
+punti, ma la sintassi per le opzioni cambia da filtro a filtro, indi leggiti la
+pagina man per i dettagli sul filtro che desideri usare.
+</para>
+
+<para>
+I filtri lavorano sul video nell'ordine in cui vengono caricati.
+Per esempio la catena seguente:
+
+<screen>-vf crop=688:464:12:4,scale=640:464</screen>
+
+dapprima taglia la zona 688x464 dell'immagine con uno scostamento dall'alto a
+sinistra di (12,4), e poi ridimensiona il risultato a 640x464.
+</para>
+
+<para>
+Taluni filtri devono essere caricati all'inizio o vicino all'inizio della
+catena di filtri, in modo da trarre vantaggio dalle informazioni che arrivano
+dal decoder video, che potrebbero essere perse o invalidate da altri filtri.
+Gli esempi principali sono <option>pp</option> (post elaborazione
+(postprocessing), solo quando esegue operazioni di deblock o dering),
+<option>spp</option> (un altra post elaborazione per eliminare artefatti MPEG),
+<option>pullup</option> (telecine inverso), e <option>softpulldown</option>
+(per passare da telecine soft a hard).
+</para>
+
+<para>
+In generale vorrai filtrare il meno possibile in modo da rimaner fedele alla
+sorgente DVD originale. Il taglio è spesso necessario (com detto sopra), ma
+evita di ridimensionare il video. Anche se alcune volte si preferisce
+rimpicciolire per poter usare quantizzatori più alti, vogliamo evitare ciò:
+ricorda che abbiamo sin dall'inizio deciso di investire bit in qualità.
+</para>
+
+<para>
+In più, non reimpostare la gamma, il contrasto, la luminosità, etc...
+Quello che si vede bene sul tuo schermo potrebbe non vedersi bene su altro.
+Queste modifiche dovrebbero esser fatte solo durante la riproduzione.
+</para>
+
+<para>
+Una cosa che voresti però fare è tuttavia far passare il video attraverso un
+leggero filtro di rimozione disturbo, come <option>-vf hqdn3d=2:1:2</option>.
+Ancora, è una questione di poter meglio utilizzare quei bit: perché sprecarli
+codificando disturbo mentre puoi semplicemente aggiungerlo di nuovo durante la
+riproduzione? Alzando i parametri per <option>hqdn3d</option> aumenterà
+ancora la compressione, ma se aumenti troppo i valori, rischi un degrado pesante
+dell'immagine. I valori sopra consigliati (<option>2:1:2</option>) sono
+abbastanza conservativi; sentiti libero di sperimentare con valori più alti e
+verificare da solo il risultato.
+</para>
+</sect2>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-interlacing">
+<title>Interlacciamento e Telecine</title>
+
+<para>
+Quasi tutti i film vengono ripresi a 24 fps. Dato che NTSC è 30000/1001 fps,
+si devono eseguire alcune elaborazioni affinché questo video a 24 fps sia
+letto al giusto framerate NTSC. Il processo è chiamato "3:2 pulldown", meglio
+conosciuto come "telecine" (poiché pulldown viene spesso applicato durante il
+processo di telecine), e descritto rozzamente, agisce rallentando il film a
+24000/1001 fps, e ripetendo ogni quarto fotogramma.
+</para>
+
+<para>
+Non viene invece eseguita alcuna elaborazione sul video per i DVD PAL, che
+girano a 25 fps. (Tecnicamente, PAL può subire il telecine, chiamato
+"2:2 pulldown", ma non è usanza abituale.) Il film a 24 fps viene
+semplicemente riprodotto a 25 fps. Il risultato è che il filmato è leggermente
+più veloce, ma a meno che tu non sia un alieno, probabilmente non noterai la
+differenza.
+La maggior parte dei DVD PAL hanno audio corretto ai picchi, in modo che quando
+siano riprodotti a 25 fps le cose suonino giuste, anche se la traccia audio
+(e quindi tutto il filmato) ha un tempo di riproduzione che è il 4% inferiore
+ai DVD NTSC.
+</para>
+
+<para>
+A causa del fatto che il video nei DVD PAL non è stato alterato, non dovrai
+preoccuperti molto della frequenza fotogrammi. La sorgente è 25 fps, e il tuo
+rip sarà a 25 fps. Tuttavia, se stai codificando un film da DVD NTSC,
+potresti dover applicare il telecine inverso.
+</para>
+
+<para>
+Per film ripresi a 24 fps, il video sul DVD NTSC è o con telecine a 30000/1001,
+oppure è progressivo a 24000/1001 fps e destinato a subire il telecine al volo
+da un lettore DVD. D'altro canto le serie TV sono solitamente solo
+interlacciate, senza telecine. Questa non è una regola ferrea: alcune serie TV
+sono interlacciate (come Buffy the Vampire Slayer) mentre alcune sono un misto
+di progressivo e interlacciato (come Angel, o 24).
+</para>
+
+<para>
+Si consiglia vivamente di leggere la sezione su
+<link linkend="menc-feat-telecine">Come trattare il telecine e l'interlacciamento nei DVD NTSC</link>
+per imparare come gestire le varie possibilità.
+</para>
+
+<para>
+Ciononostante, se stai principalmente rippando solo film, solitamente ti
+troverai di fronte a video a 24 fps progressivo o con telecine, nel qual caso
+puoi usare il filtro <option>pullup</option> <option>-vf
+pullup,softskip</option>.
+</para>
+</sect2>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-dvd-mpeg4-encoding-interlaced">
+<title>Codificare video interlacciato</title>
+
+<para>
+Se il film che vuoi codificare è interlacciato (video NTSC o PAL) dovrai
+scegliere se vuoi de-interlacciare o no.
+Se da un lato de-interlacciare renderà il tuo filmato utilizzabile su
+schermi a scansione progressiva come monitor di computer o proiettori, porta
+con sé un costo: la frequenza dei campi di 50 o 60000/1001 campi al secondo
+viene dimezzata a 25 o 30000/1001 fotogrammi al secondo, e circa la metà delle
+informazioni nel tuo film saranno perdute, in scene con movimento significativo.
+</para>
+
+<para>
+Per di più, se stai codificando puntando ad alta qualità di archiviazione.
+si consiglia di non de-interlacciare.
+Puoi sempre de-interlacciare il film durante la riproduzione attraverso
+dispositivi a scansione progressiva.
+La potenza dei computer attuali forza per i riproduttori l'utilizzo di un filtro
+di de-interlacciamento, che porta un leggero degrado dell'immagine.
+Ma i lettori del futuro saranno in grado di simulare lo schermo di una TV,
+de-interlacciando a piena frequenza di campi e interpolando 50 o 60000/1001
+fotogrammi interi al secondo dal video interlacciato
+</para>
+
+<para>
+Bisogna porre speciale attenzione quando si lavora con video interlacciato:
+</para>
+
+<orderedlist>
+<listitem><para>
+ Altezza e scostamento del taglio devono essere multipli di 4.
+</para></listitem>
+<listitem><para>
+ Qualsiasi ridimensionamento verticale va fatto in modalità interlacciata.
+</para></listitem>
+<listitem><para>
+ I filtri di post elaborazione e di rimozione disturbo potrebbero non
+ funzionare come ci si aspetta a meno che tu non ponga particolare attenzione
+ per farli lavorare su un campo per volta, e possono rovinare il video quando
+ usati in modo non corretto.
+</para></listitem>
+</orderedlist>
+
+<para>
+Tenendo a mente queste cose, ecco il nostro primo esempio:
+<screen>
+mencoder <replaceable>capture.avi</replaceable> -mc 0 -oac lavc -ovc lavc -lavcopts \
+ vcodec=mpeg2video:vbitrate=6000:ilme:ildct:acodec=mp2:abitrate=224
+</screen>
+Nota le opzioni <option>ilme</option> e <option>ildct</option>.
+</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-codec">
+<title>Choosing the video codec</title>
+
+<para>
+Which video codec is best to choose depends on several factors,
+like size, quality, streamability, usability and popularity, some of
+which widely depend on personal taste and technical constraints.
+</para>
+<itemizedlist>
+<listitem>
+ <para>
+ <emphasis role="bold">Compression efficiency</emphasis>:
+ It is quite easy to understand that most newer-generation codecs are
+ made to increase quality and compression.
+ Therefore, the authors of this guide and many other people suggest that
+ you cannot go wrong
+ <footnote id='fn-menc-feat-dvd-mpeg4-codec-cpu'><para>
+ Be careful, however: Decoding DVD-resolution MPEG-4 AVC videos
+ requires a fast machine (i.e. a Pentium 4 over 1.5GHz or a Pentium M
+ over 1GHz).
+ </para></footnote>
+ when choosing MPEG-4 AVC codecs like
+ <systemitem class="library">x264</systemitem> instead of MPEG-4 ASP codecs
+ such as <systemitem class="library">libavcodec</systemitem> MPEG-4 or
+ <systemitem class="library">Xvid</systemitem>.
+ (Advanced codec developers may be interested in reading Michael
+ Niedermayer's opinion on
+ "<ulink url="http://guru.multimedia.cx/?p=10">why MPEG4-ASP sucks</ulink>".)
+ Likewise, you should get better quality using MPEG-4 ASP than you
+ would with MPEG-2 codecs.
+ </para>
+
+ <para>
+ However, newer codecs which are in heavy development can suffer from
+ bugs which have not yet been noticed and which can ruin an encode.
+ This is simply the tradeoff for using bleeding-edge technology.
+ </para>
+
+ <para>
+ What is more, beginning to use a new codec requires that you spend some
+ time becoming familiar with its options, so that you know what
+ to adjust to achieve a desired picture quality.
+ </para>
+</listitem>
+
+<listitem><para>
+ <emphasis role="bold">Hardware compatibility</emphasis>:
+ It usually takes a long time for standalone video players to begin to
+ include support for the latest video codecs.
+ As a result, most only support MPEG-1 (like VCD, XVCD and KVCD), MPEG-2
+ (like DVD, SVCD and KVCD) and MPEG-4 ASP (like DivX,
+ <systemitem class="library">libavcodec</systemitem>'s LMP4 and
+ <systemitem class="library">Xvid</systemitem>)
+ (Beware: Usually, not all MPEG-4 ASP features are supported).
+ Please refer to the technical specs of your player (if they are available),
+ or google around for more information.
+</para></listitem>
+
+<listitem>
+ <para>
+ <emphasis role="bold">Best quality per encoding time</emphasis>:
+ Codecs that have been around for some time (such as
+ <systemitem class="library">libavcodec</systemitem> MPEG-4 and
+ <systemitem class="library">Xvid</systemitem>) are usually heavily
+ optimized with all kinds of smart algorithms and SIMD assembly code.
+ That is why they tend to yield the best quality per encoding time ratio.
+ However, they may have some very advanced options that, if enabled,
+ will make the encode really slow for marginal gains.
+ </para>
+
+ <para>
+ If you are after blazing speed you should stick around the default
+ settings of the video codec (although you should still try the other
+ options which are mentioned in other sections of this guide).
+ </para>
+
+ <para>
+ You may also consider choosing a codec which can do multi-threaded
+ processing, though this is only useful for users of machines with
+ several CPUs.
+ <systemitem class="library">libavcodec</systemitem> MPEG-4 does
+ allow that, but speed gains are limited, and there is a slight
+ negative effect on picture quality.
+ <systemitem class="library">Xvid</systemitem>'s multi-threaded encoding,
+ activated by the <option>threads</option> option, can be used to
+ boost encoding speed — by about 40-60% in typical cases —
+ with little if any picture degradation.
+ <systemitem class="library">x264</systemitem> also allows multi-threaded
+ encoding, which currently speeds up encoding by 94% per CPU core while
+ lowering PSNR between 0.005dB and 0.01dB on a typical setup.
+ </para>
+</listitem>
+
+<listitem>
+ <para>
+ <emphasis role="bold">Personal taste</emphasis>:
+ This is where it gets almost irrational: For the same reason that some
+ hung on to DivX 3 for years when newer codecs were already doing wonders,
+ some folks will prefer <systemitem class="library">Xvid</systemitem>
+ or <systemitem class="library">libavcodec</systemitem> MPEG-4 over
+ <systemitem class="library">x264</systemitem>.
+ </para>
+ <para>
+ You should make your own judgement; do not take advice from people who
+ swear by one codec.
+ Take a few sample clips from raw sources and compare different
+ encoding options and codecs to find one that suits you best.
+ The best codec is the one you master, and the one that looks
+ best to your eyes on your display
+ <footnote id='fn-menc-feat-dvd-mpeg4-codec-playback'><para>
+ The same encode may not look the same on someone else's monitor or
+ when played back by a different decoder, so future-proof your encodes by
+ playing them back on different setups.
+ </para></footnote>!
+ </para>
+</listitem>
+</itemizedlist>
+
+<para>
+Please refer to the section
+<link linkend="menc-feat-selecting-codec">selecting codecs and container formats</link>
+to get a list of supported codecs.
+</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 AC-3 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 AC-3 pass-through today
+does not mean you will not have one tomorrow. Future-proof your DVD rips by
+preserving the AC-3 stream.
+You can keep the AC-3 stream either by copying it directly into the video
+stream <link linkend="menc-feat-mpeg4">during the encoding</link>.
+You can also extract the AC-3 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 AC-3 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 <application>MEncoder</application> 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>
+<application>MEncoder</application> 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 AC-3.
+</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>
+If you do not understand much of what is written in this document, read the
+<ulink url="http://en.wikipedia.org/wiki/Telecine">Wikipedia entry on telecine</ulink>.
+It is an understandable and reasonably comprehensive
+description of what telecine is.
+</para></formalpara>
+
+<formalpara>
+<title>A note about the numbers.</title>
+<para>
+Many documents, including the guide linked above, refer to the fields
+per second value of NTSC video as 59.94 and the corresponding frames
+per second values as 29.97 (for telecined and interlaced) and 23.976
+(for progressive). For simplicity, some documents even round these
+numbers to 60, 30, and 24.
+</para></formalpara>
+
+<para>
+Strictly speaking, all those numbers are approximations. Black and
+white NTSC video was exactly 60 fields per second, but 60000/1001
+was later chosen to accomodate color data while remaining compatible
+with contemporary black and white televisions. Digital NTSC video
+(such as on a DVD) is also 60000/1001 fields per second. From this,
+interlaced and telecined video are derived to be 30000/1001 frames
+per second; progressive video is 24000/1001 frames per second.
+</para>
+
+<para>
+Older versions of the <application>MEncoder</application> documentation
+and many archived mailing list posts refer to 59.94, 29.97, and 23.976.
+All <application>MEncoder</application> documentation has been updated
+to use the fractional values, and you should use them too.
+</para>
+
+<para>
+<option>-ofps 23.976</option> is incorrect.
+<option>-ofps 24000/1001</option> should be used instead.
+</para>
+
+<formalpara>
+<title>How telecine is used.</title>
+<para>
+All video intended to be displayed on an NTSC
+television set must be 60000/1001 fields per second. Made-for-TV movies
+and shows are often filmed directly at 60000/1001 fields per second, but
+the majority of cinema is filmed at 24 or 24000/1001 frames per
+second. When cinematic movie DVDs are mastered, the video is then
+converted for television using a process called telecine.
+</para></formalpara>
+
+<para>
+On a DVD, the video is never actually stored as 60000/1001 fields per
+second. For video that was originally 60000/1001, each pair of fields is
+combined to form a frame, resulting in 30000/1001 frames per
+second. Hardware DVD players then read a flag embedded in the video
+stream to determine whether the odd- or even-numbered lines should
+form the first field.
+</para>
+
+<para>
+Usually, 24000/1001 frames per second content stays as it is when
+encoded for a DVD, and the DVD player must perform telecining
+on-the-fly. Sometimes, however, the video is telecined
+<emphasis>before</emphasis> being stored on the DVD; even though it
+was originally 24000/1001 frames per second, it becomes 60000/1001 fields per
+second. When it is stored on the DVD, pairs of fields are combined to form
+30000/1001 frames per second.
+</para>
+
+<para>
+When looking at individual frames formed from 60000/1001 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> and
+ <option>mplayer -vf help</option> to see what is available
+ (grep for "deint"), read Michael's Niedermayer
+ <ulink url="http://guru.multimedia.cx/deinterlacing-filters/">Deinterlacing filters comparison</ulink>,
+ and search the
+ <ulink url="http://www.mplayerhq.hu/design7/mailing_lists.html">
+ 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 yadif -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>jpegls</entry>
+ <entry>JPEG LS</entry>
+</row>
+<row>
+ <entry>targa</entry>
+ <entry>Targa image</entry>
+</row>
+<row>
+ <entry>gif</entry>
+ <entry>GIF image</entry>
+</row>
+<row>
+ <entry>bmp</entry>
+ <entry>BMP image</entry>
+</row>
+<row>
+ <entry>png</entry>
+ <entry>PNG image</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, 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>ffvhuff</entry>
+ <entry>FFmpeg modified huffyuv lossless</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>flashsv</entry>
+ <entry>Flash Screen 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>
+<row>
+ <entry>zbmv</entry>
+ <entry>Zip Blocks Motion Video</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 <replaceable>title2.avi</replaceable> -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>AC-3, 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 FFmpeg lossy codec</entry>
+</row>
+<row>
+ <entry>sonicls</entry>
+ <entry>experimental FFmpeg lossless codec</entry>
+</row>
+<row>
+ <entry>vorbis</entry>
+ <entry>Xiph Ogg Vorbis codec</entry>
+</row>
+<row>
+ <entry>wmav1</entry>
+ <entry>Windows Media Audio v1 codec</entry>
+</row>
+<row>
+ <entry>wmav2</entry>
+ <entry>Windows Media Audio v2 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 AC-3 compression:
+<screen>
+mencoder dvd://2 -o <replaceable>title2.avi</replaceable> -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: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 id="menc-feat-dvd-mpeg4-example-crop">
+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,
+past the opening credits and logos), 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 -o <replaceable>Harry_Potter_2.avi</replaceable> -ovc lavc \
+ -lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:autoaspect:vpass=1 \
+ -vf pullup,softskip,crop=720:352:0:62,hqdn3d=2:1:2
+</screen>
+And pass two is the same, except that we specify <option>vpass=2</option>:
+<screen>
+mencoder dvd://1 -ofps 24000/1001 -oac copy -o <replaceable>Harry_Potter_2.avi</replaceable> -ovc lavc \
+ -lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:autoaspect:vpass=2 \
+ -vf pullup,softskip,crop=720:352:0:62,hqdn3d=2:1:2
+</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</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 <replaceable>Harry_Potter_2.avi</replaceable> -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>
+
+<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>
+</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 slower and yields better quality at a reasonable
+ cost.
+ 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>
+ <para>
+ <option>subq=7</option> is the slowest, highest quality mode.
+ In comparison to <option>subq=6</option>, it usually gains 0.01-0.05 dB
+ global PSNR with speed costs varying from 15%-33%.
+ Since the tradeoff encoding time vs. quality is quite low, you should
+ only use it if you are after every bit saving and if encoding time is
+ not an issue.
+ </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=dia</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=hex</option>) is a reasonable tradeoff
+ between speed and quality. <option>me=umh</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=umh</option>
+ is about 40% slower than the default <option> me=hex</option>. With
+ <option>frameref=3</option>, the speed penalty incurred drops to
+ 25%-30%.
+ </para>
+ <para>
+ <option>me=esa</option> uses an exhaustive search that is too slow for
+ practical use.
+ </para>
+</listitem>
+<listitem><para>
+ <emphasis role="bold">partitions=all</emphasis>:
+ This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
+ predicted macroblocks (in addition to the default partitions).
+ 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>
+<listitem id="menc-feat-x264-encoding-options-speedvquality-threads">
+ <para>
+ <emphasis role="bold">threads</emphasis>:
+ This option allows to spawn threads to encode in parallel on multiple CPUs.
+ You can manually select the number of threads to be created or, better, set
+ <option>threads=auto</option> and let
+ <systemitem class="library">x264</systemitem> detect how many CPUs are
+ available and pick an appropriate number of threads.
+ If you have a multi-processor machine, you should really consider using it
+ as it can to increase encoding speed linearly with the number of CPU cores
+ (about 94% per CPU core), with very little quality reduction (about 0.005dB
+ for dual processor, about 0.01dB for a quad processor machine).
+ </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:partitions=all:me=umh</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">deblock</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>deblock</option> 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>
+
+<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:partitions=all:8x8dct:me=umh: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: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>
+</sect2>
+</sect1>
+
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+
+<sect1 id="menc-feat-video-for-windows">
+<title>
+ Encoding with the <systemitem class="library">Video For Windows</systemitem>
+ codec family
+</title>
+
+<para>
+Video for Windows provides simple encoding by means of binary video codecs.
+You can encode with the following codecs (if you have more, please tell us!)
+</para>
+
+<para>
+Note that support for this is very experimental and some codecs may not work
+correctly. Some codecs will only work in certain colorspaces, try
+<option>-vf format=bgr24</option> and <option>-vf format=yuy2</option>
+if a codec fails or gives wrong output.
+</para>
+
+<!-- ********** -->
+
+<sect2 id="menc-feat-enc-vfw-video-codecs">
+<title>Video for Windows supported codecs</title>
+
+<para>
+<informaltable frame="all">
+<tgroup cols="4">
+<thead>
+<row>
+ <entry>Video codec file name</entry>
+ <entry>Description (FourCC)</entry>
+ <entry>md5sum</entry>
+ <entry>Comment</entry>
+</row>
+</thead>
+<tbody>
+<row>
+ <entry>aslcodec_vfw.dll</entry>
+ <entry>Alparysoft lossless codec vfw (ASLC)</entry>
+ <entry>608af234a6ea4d90cdc7246af5f3f29a</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>avimszh.dll</entry>
+ <entry>AVImszh (MSZH)</entry>
+ <entry>253118fe1eedea04a95ed6e5f4c28878</entry>
+ <entry>needs <option>-vf format</option></entry>
+</row>
+<row>
+ <entry>avizlib.dll</entry>
+ <entry>AVIzlib (ZLIB)</entry>
+ <entry>2f1cc76bbcf6d77d40d0e23392fa8eda</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>divx.dll</entry>
+ <entry>DivX4Windows-VFW</entry>
+ <entry>acf35b2fc004a89c829531555d73f1e6</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>huffyuv.dll</entry>
+ <entry>HuffYUV (lossless) (HFYU)</entry>
+ <entry>b74695b50230be4a6ef2c4293a58ac3b</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>iccvid.dll</entry>
+ <entry>Cinepak Video (cvid)</entry>
+ <entry>cb3b7ee47ba7dbb3d23d34e274895133</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>icmw_32.dll</entry>
+ <entry>Motion Wavelets (MWV1)</entry>
+ <entry>c9618a8fc73ce219ba918e3e09e227f2</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>jp2avi.dll</entry>
+ <entry>ImagePower MJPEG2000 (IPJ2)</entry>
+ <entry>d860a11766da0d0ea064672c6833768b</entry>
+ <entry><option>-vf flip</option></entry>
+</row>
+<row>
+ <entry>m3jp2k32.dll</entry>
+ <entry>Morgan MJPEG2000 (MJ2C)</entry>
+ <entry>f3c174edcbaef7cb947d6357cdfde7ff</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>m3jpeg32.dll</entry>
+ <entry>Morgan Motion JPEG Codec (MJPG)</entry>
+ <entry>1cd13fff5960aa2aae43790242c323b1</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>mpg4c32.dll</entry>
+ <entry>Microsoft MPEG-4 v1/v2</entry>
+ <entry>b5791ea23f33010d37ab8314681f1256</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>tsccvid.dll</entry>
+ <entry>TechSmith Camtasia Screen Codec (TSCC)</entry>
+ <entry>8230d8560c41d444f249802a2700d1d5</entry>
+ <entry>shareware error on windows</entry>
+</row>
+<row>
+ <entry>vp31vfw.dll</entry>
+ <entry>On2 Open Source VP3 Codec (VP31)</entry>
+ <entry>845f3590ea489e2e45e876ab107ee7d2</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>vp4vfw.dll</entry>
+ <entry>On2 VP4 Personal Codec (VP40)</entry>
+ <entry>fc5480a482ccc594c2898dcc4188b58f</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>vp6vfw.dll</entry>
+ <entry>On2 VP6 Personal Codec (VP60)</entry>
+ <entry>04d635a364243013898fd09484f913fb</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>vp7vfw.dll</entry>
+ <entry>On2 VP7 Personal Codec (VP70)</entry>
+ <entry>cb4cc3d4ea7c94a35f1d81c3d750bc8d</entry>
+ <entry>wrong FourCC?</entry>
+</row>
+<row>
+ <entry>ViVD2.dll</entry>
+ <entry>SoftMedia ViVD V2 codec VfW (GXVE)</entry>
+ <entry>a7b4bf5cac630bb9262c3f80d8a773a1</entry>
+ <entry></entry>
+</row>
+<row>
+ <entry>msulvc06.DLL</entry>
+ <entry>MSU Lossless codec (MSUD)</entry>
+ <entry>294bf9288f2f127bb86f00bfcc9ccdda</entry>
+ <entry>
+ Decodable by <application>Window Media Player</application>,
+ not <application>MPlayer</application> (yet).
+ </entry>
+</row>
+<row>
+ <entry>camcodec.dll</entry>
+ <entry>CamStudio lossless video codec (CSCD)</entry>
+ <entry>0efe97ce08bb0e40162ab15ef3b45615</entry>
+ <entry>sf.net/projects/camstudio</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+
+The first column contains the codec names that should be passed after the
+<literal>codec</literal> parameter,
+like: <option>-xvfwopts codec=divx.dll</option>
+The FourCC code used by each codec is given in the parentheses.
+</para>
+
+<informalexample>
+<para>
+An example to convert an ISO DVD trailer to a VP6 flash video file
+using compdata bitrate settings:
+<screen>
+mencoder -dvd-device <replaceable>zeiram.iso</replaceable> dvd://7 -o <replaceable>trailer.flv</replaceable> \
+-ovc vfw -xvfwopts codec=vp6vfw.dll:compdata=onepass.mcf -oac mp3lame \
+-lameopts cbr:br=64 -af lavcresample=22050 -vf yadif,scale=320:240,flip \
+-of lavf -lavfopts i_certify_that_my_video_stream_does_not_use_b_frames
+</screen>
+</para>
+</informalexample>
+</sect2>
+
+<sect2 id="menc-feat-video-for-windows-bitrate-settings">
+<title>Using vfw2menc to create a codec settings file.</title>
+
+<para>
+To encode with the Video for Windows codecs, you will need to set bitrate
+and other options. This is known to work on x86 on both *NIX and Windows.
+</para>
+<para>
+First you must build the <application>vfw2menc</application> program.
+It is located in the <filename class="directory">TOOLS</filename> subdirectory
+of the MPlayer source tree.
+To build on Linux, this can be done using <application>Wine</application>:
+<screen>winegcc vfw2menc.c -o vfw2menc -lwinmm -lole32</screen>
+
+To build on Windows in <application>MinGW</application> or
+<application>Cygwin</application> use:
+<screen>gcc vfw2menc.c -o vfw2menc.exe -lwinmm -lole32</screen>
+
+To build on <application>MSVC</application> you will need getopt.
+Getopt can be found in the original <application>vfw2menc</application>
+archive available at:
+The <ulink url="http://oss.netfarm.it/mplayer-win32.php">MPlayer on win32</ulink> project.
+</para>
+<informalexample>
+<para>
+Below is an example with the VP6 codec.
+<screen>
+vfw2menc -f VP62 -d vp6vfw.dll -s firstpass.mcf
+</screen>
+This will open the VP6 codec dialog window.
+Repeat this step for the second pass
+and use <option>-s <replaceable>secondpass.mcf</replaceable></option>.
+</para>
+</informalexample>
+<para>
+Windows users can use
+<option>-xvfwopts codec=vp6vfw.dll:compdata=dialog</option> to have
+the codec dialog display before encoding starts.
+</para>
+</sect2>
+</sect1>
+
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+
+<sect1 id="menc-feat-quicktime-7">
+<title>Using <application>MEncoder</application> to create
+<application>QuickTime</application>-compatible files</title>
+
+
+<sect2 id="menc-feat-quicktime-7-why-use-it">
+<title>Why would one want to produce <application>QuickTime</application>-compatible Files?</title>
+
+<para>
+ There are several reasons why producing
+ <application>QuickTime</application>-compatible files can be desirable.
+</para>
+<itemizedlist>
+<listitem><para>
+ You want any computer illiterate to be able to watch your encode on
+ any major platform (Windows, Mac OS X, Unices …).
+</para></listitem>
+<listitem><para>
+ <application>QuickTime</application> is able to take advantage of more
+ hardware and software acceleration features of Mac OS X than
+ platform-independent players like <application>MPlayer</application>
+ or <application>VLC</application>.
+ That means that your encodes have a chance to be played smoothly by older
+ G4-powered machines.
+</para></listitem>
+<listitem><para>
+ <application>QuickTime</application> 7 supports the next-generation codec H.264,
+ which yields significantly better picture quality than previous codec
+ generations (MPEG-2, MPEG-4 …).
+</para></listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-constraints">
+<title><application>QuickTime</application> 7 limitations</title>
+
+<para>
+ <application>QuickTime</application> 7 supports H.264 video and AAC audio,
+ but it does not support them muxed in the AVI container format.
+ However, you can use <application>MEncoder</application> to encode
+ the video and audio, and then use an external program such as
+ <application>mp4creator</application> (part of the
+ <ulink url="http://mpeg4ip.sourceforge.net/">MPEG4IP suite</ulink>)
+ to remux the video and audio tracks into an MP4 container.
+</para>
+
+<para>
+ <application>QuickTime</application>'s support for H.264 is limited,
+ so you will need to drop some advanced features.
+ If you encode your video with features that
+ <application>QuickTime</application> 7 does not support,
+ <application>QuickTime</application>-based players will show you a pretty
+ white screen instead of your expected video.
+</para>
+
+<itemizedlist>
+<listitem><para>
+ <emphasis role="bold">B-frames</emphasis>:
+ <application>QuickTime</application> 7 supports a maximum of 1 B-frame, i.e.
+ <option>-x264encopts bframes=1</option>. This means that
+ <option>b_pyramid</option> and <option>weight_b</option> will have no
+ effect, since they require <option>bframes</option> to be greater than 1.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Macroblocks</emphasis>:
+ <application>QuickTime</application> 7 does not support 8x8 DCT macroblocks.
+ This option (<option>8x8dct</option>) is off by default, so just be sure
+ not to explicitly enable it. This also means that the <option>i8x8</option>
+ option will have no effect, since it requires <option>8x8dct</option>.
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Aspect ratio</emphasis>:
+ <application>QuickTime</application> 7 does not support SAR (sample
+ aspect ratio) information in MPEG-4 files; it assumes that SAR=1. Read
+ <link linkend="menc-feat-quicktime-7-scale">the section on scaling</link>
+ for a workaround.
+</para></listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-crop">
+<title>Cropping</title>
+<para>
+ Suppose you want to rip your freshly bought copy of "The Chronicles of
+ Narnia". Your DVD is region 1,
+ which means it is NTSC. The example below would still apply to PAL,
+ except you would omit <option>-ofps 24000/1001</option> and use slightly
+ different <option>crop</option> and <option>scale</option> dimensions.
+</para>
+
+<para>
+ After running <option>mplayer dvd://1</option>, you 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. This simplifies the process somewhat,
+ since you do not need to use an inverse telecine filter such as
+ <option>pullup</option> or a deinterlacing filter such as
+ <option>yadif</option>.
+</para>
+
+<para>
+ Next, you need to crop out the black bars from the top and bottom of the
+ video, as detailed in <link linkend="menc-feat-dvd-mpeg4-example-crop">this</link>
+ previous section.
+</para>
+
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-scale">
+<title>Scaling</title>
+
+<para>
+ The next step is truly heartbreaking.
+ <application>QuickTime</application> 7 does not support MPEG-4 videos
+ with a sample aspect ratio other than 1, so you will need to upscale
+ (which wastes a lot of disk space) or downscale (which loses some
+ details of the source) the video to square pixels.
+ Either way you do it, this is highly inefficient, but simply cannot
+ be avoided if you want your video to be playable by
+ <application>QuickTime</application> 7.
+ <application>MEncoder</application> can apply the appropriate upscaling
+ or downscaling by specifying respectively <option>-vf scale=-10:-1</option>
+ or <option>-vf scale=-1:-10</option>.
+ This will scale your video to the correct width for the cropped height,
+ rounded to the closest multiple of 16 for optimal compression.
+ Remember that if you are cropping, you should crop first, then scale:
+
+ <screen>-vf crop=720:352:0:62,scale=-10:-1</screen>
+</para>
+
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-avsync">
+<title>A/V sync</title>
+
+<para>
+ Because you will be remuxing into a different container, you should
+ always use the <option>harddup</option> option to ensure that duplicated
+ frames are actually duplicated in the video output. Without this option,
+ <application>MEncoder</application> will simply put a marker in the video
+ stream that a frame was duplicated, and rely on the client software to
+ show the same frame twice. Unfortunately, this "soft duplication" does
+ not survive remuxing, so the audio would slowly lose sync with the video.
+</para>
+
+<para>
+ The final filter chain looks like this:
+ <screen>-vf crop=720:352:0:62,scale=-10:-1,harddup</screen>
+</para>
+
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-bitrate">
+<title>Bitrate</title>
+
+<para>
+ As always, the selection of bitrate is a matter of the technical properties
+ of the source, as explained
+ <link linkend="menc-feat-dvd-mpeg4-resolution-bitrate">here</link>, as
+ well as a matter of taste.
+ This movie has a fair bit of action and lots of detail, but H.264 video
+ looks good at much lower bitrates than XviD or other MPEG-4 codecs.
+ After much experimentation, the author of this guide chose to encode
+ this movie at 900kbps, and thought that it looked very good.
+ You may decrease bitrate if you need to save more space, or increase
+ it if you need to improve quality.
+</para>
+
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-example">
+<title>Encoding example</title>
+
+<para>
+ You are now ready to encode the video. Since you care about
+ quality, of course you will be doing a two-pass encode. To shave off
+ some encoding time, you can specify the <option>turbo</option> option
+ on the first pass; this reduces <option>subq</option> and
+ <option>frameref</option> to 1. To save some disk space, you can
+ use the <option>ss</option> option to strip off the first few seconds
+ of the video. (I found that this particular movie has 32 seconds of
+ credits and logos.) <option>bframes</option> can be 0 or 1.
+ The other options are documented in <link
+ linkend="menc-feat-x264-encoding-options-speedvquality">Encoding with
+ the <systemitem class="library">x264</systemitem> codec</link> and
+ the man page.
+
+ <screen>mencoder dvd://1 -o /dev/null -ss 32 -ovc x264 \
+-x264encopts pass=1:turbo:bitrate=900:bframes=1:\
+me=umh:partitions=all:trellis=1:qp_step=4:qcomp=0.7:direct_pred=auto:keyint=300 \
+-vf crop=720:352:0:62,scale=-10:-1,harddup \
+-oac faac -faacopts br=192:mpeg=4:object=1 -channels 2 -srate 48000 \
+-ofps 24000/1001</screen>
+
+ If you have a multi-processor machine, don't miss the opportunity to
+ dramatically speed-up encoding by enabling
+ <link linkend="menc-feat-x264-encoding-options-speedvquality-threads">
+ <systemitem class="library">x264</systemitem>'s multi-threading mode</link>
+ by adding <option>threads=auto</option> to your <option>x264encopts</option>
+ command-line.
+</para>
+
+<para>
+ The second pass is the same, except that you specify the output file
+ and set <option>pass=2</option>.
+
+ <screen>mencoder dvd://1 <emphasis role="bold">-o narnia.avi</emphasis> -ss 32 -ovc x264 \
+-x264encopts <emphasis role="bold">pass=2</emphasis>:turbo:bitrate=900:frameref=5:bframes=1:\
+me=umh:partitions=all:trellis=1:qp_step=4:qcomp=0.7:direct_pred=auto:keyint=300 \
+-vf crop=720:352:0:62,scale=-10:-1,harddup \
+-oac faac -faacopts br=192:mpeg=4:object=1 -channels 2 -srate 48000 \
+-ofps 24000/1001</screen>
+</para>
+
+<para>
+ The resulting AVI should play perfectly in
+ <application>MPlayer</application>, but of course
+ <application>QuickTime</application> can not play it because it does
+ not support H.264 muxed in AVI.
+ So the next step is to remux the video into an MP4 container.
+</para>
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-remux">
+<title>Remuxing as MP4</title>
+
+<para>
+ There are several ways to remux AVI files to MP4. You can use
+ <application>mp4creator</application>, which is part of the
+ <ulink url="http://mpeg4ip.sourceforge.net/">MPEG4IP suite</ulink>.
+</para>
+
+<para>
+ First, demux the AVI into separate audio and video streams using
+ <application>MPlayer</application>.
+
+ <screen>mplayer narnia.avi -dumpaudio -dumpfile narnia.aac
+mplayer narnia.avi -dumpvideo -dumpfile narnia.h264</screen>
+
+ The filenames are important; <application>mp4creator</application>
+ requires that AAC audio streams be named <systemitem>.aac</systemitem>
+ and H.264 video streams be named <systemitem>.h264</systemitem>.
+</para>
+
+<para>
+ Now use <application>mp4creator</application> to create a new
+ MP4 file out of the audio and video streams.
+
+ <screen>mp4creator -create=narnia.aac narnia.mp4
+mp4creator -create=narnia.h264 -rate=23.976 narnia.mp4</screen>
+
+ Unlike the encoding step, you must specify the framerate as a
+ decimal (such as 23.976), not a fraction (such as 24000/1001).
+</para>
+
+<para>
+ This <systemitem>narnia.mp4</systemitem> file should now be playable
+ with any <application>QuickTime</application> 7 application, such as
+ <application>QuickTime Player</application> or
+ <application>iTunes</application>. If you are planning to view the
+ video in a web browser with the <application>QuickTime</application>
+ plugin, you should also hint the movie so that the
+ <application>QuickTime</application> plugin can start playing it
+ while it is still downloading. <application>mp4creator</application>
+ can create these hint tracks:
+
+ <screen>mp4creator -hint=1 narnia.mp4
+mp4creator -hint=2 narnia.mp4
+mp4creator -optimize narnia.mp4</screen>
+
+ You can check the final result to ensure that the hint tracks were
+ created successfully:
+
+ <screen>mp4creator -list narnia.mp4</screen>
+
+ You should see a list of tracks: 1 audio, 1 video, and 2 hint tracks.
+
+<screen>Track Type Info
+1 audio MPEG-4 AAC LC, 8548.714 secs, 190 kbps, 48000 Hz
+2 video H264 Main at 5.1, 8549.132 secs, 899 kbps, 848x352 @ 23.976001 fps
+3 hint Payload mpeg4-generic for track 1
+4 hint Payload H264 for track 2
+</screen>
+</para>
+
+</sect2>
+
+<sect2 id="menc-feat-quicktime-7-metadata">
+<title>Adding metadata tags</title>
+
+<para>
+ If you want to add tags to your video that show up in iTunes, you can use
+ <ulink url="http://atomicparsley.sourceforge.net/">AtomicParsley</ulink>.
+
+ <screen>AtomicParsley narnia.mp4 --metaEnema --title "The Chronicles of Narnia" --year 2005 --stik Movie --freefree --overWrite</screen>
+
+ The <option>--metaEnema</option> option removes any existing metadata
+ (<application>mp4creator</application> inserts its name in the
+ "encoding tool" tag), and <option>--freefree</option> reclaims the
+ space from the deleted metadata.
+ The <option>--stik</option> option sets the type of video (such as Movie
+ or TV Show), which iTunes uses to group related video files.
+ The <option>--overWrite</option> option overwrites the original file;
+ without it, <application>AtomicParsley</application> creates a new
+ auto-named file in the same directory and leaves the original file
+ untouched.
+</para>
+
+</sect2>
+
+</sect1>
+
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+
+<sect1 id="menc-feat-vcd-dvd">
+<title>Using <application>MEncoder</application>
+ 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>AC-3,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>AC-3,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,AC-3,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,AC-3,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 (with timestamps on every frame, if possible):
+<screen>-of mpeg -mpegopts format=dvd:tsaf</screen>
+</para>
+
+<para>
+DVD with NTSC Pullup:
+<screen>-of mpeg -mpegopts format=dvd:tsaf: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-a-v-sync">
+<title>Maintaining A/V sync</title>
+
+<para>
+In order to maintain audio/video synchronization throughout the encode,
+<application>MEncoder</application> has to drop or duplicate frames.
+This works rather well when muxing into an AVI file, but is almost
+guaranteed to fail to maintain A/V sync with other muxers such as MPEG.
+This is why it is necessary to append the
+<option>harddup</option> video filter at the end of the filter chain
+to avoid this kind of problem.
+You can find more technical information about <option>harddup</option>
+in the section
+<link linkend="menc-feat-dvd-mpeg4-muxing-filter-issues">Improving muxing and A/V sync reliability</link>
+or in the manual page.
+</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>
+<listitem><para>
+ <emphasis role="bold">vstrict</emphasis>:
+ <option>vstrict</option>=0 should be used to create DVDs.
+ Without this option, <application>MEncoder</application> creates a
+ stream that cannot be correctly decoded by some standalone DVD
+ players.
+</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:vstrict=0: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:vstrict=0
+</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
+AC-3 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:tsaf \
+ -vf scale=720:576,harddup -srate 48000 -af lavcresample=48000 \
+ -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\
+keyint=15:vstrict=0: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:tsaf \
+ -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000 \
+ -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\
+keyint=18:vstrict=0: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 AC-3 Audio to DVD</title>
+
+<para>
+If the source already has AC-3 audio, use -oac copy instead of re-encoding it.
+<screen>
+mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd:tsaf \
+ -vf scale=720:576,harddup -ofps 25 \
+ -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\
+keyint=15:vstrict=0:aspect=16/9 -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 AC-3 Audio to DVD</title>
+
+<para>
+If the source already has AC-3 audio, and is NTSC @ 24000/1001 fps:
+<screen>
+mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd:tsaf:telecine \
+ -vf scale=720:480,harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:\
+ vrc_maxrate=9800:vbitrate=5000:keyint=15:vstrict=0: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