mpv/DOCS/xml/fr/encoding-guide.xml

4360 lines
179 KiB
XML
Raw Normal View History

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- synced with 1.47 -->
<chapter id="encoding-guide">
<title>L'encodage avec <application>MEncoder</application></title>
<sect1 id="menc-feat-dvd-mpeg4">
<title>Cr<EFBFBD>er un rip MPEG-4 (&quot;DivX&quot;) de haute qualit<69> <20> partir d'un DVD</title>
<para>
Une question fr<66>quemment pos<6F>e est "Comment faire le meilleur rip DVD possible ?
Une autre question est "Comment dois-je faire pour avoir un rip de la meilleure
qualit<69> possible ?" Peu importe la taille du fichier, je veux simplement la
meilleure qualit<69>."
</para>
<para>
Cette question est peut <20>tre un peu mal pos<6F>e. Apr<70>s tout, si vous ne vous
souciez pas de la taille du fichier, pourquoi ne pas simplement copier le
flux MPEG-2 du DVD entier ? Bien s<>r, votre AVI finira par faire 5Go, mais
si vous voulez la meilleure qualit<69> et ne vous souciez pas de la taille,
ceci est probablement votre meilleure option.
</para>
<para>
En fait, la raison pour laquelle vous voulez convertir un DVD en MPEG-4
est que vous tenez <emphasis role="bold">r<EFBFBD>ellement</emphasis> compte
de la taille du fichier.
</para>
<para>
Il est difficile de proposer une recette sur la fa<66>on de cr<63>er des rips DVD
de tr<74>s haute qualit<69>. Il y a de nombreux facteurs <20> prendre en compte, et vous
devriez comprendre ces d<>tails, ou vous serez d<><64>us par les r<>sultats. Ci-dessous
nous allons examiner quelques-uns de ces probl<62>mes, et voir un exemple. Nous
supposerons que vous utilisez <systemitem class="library">libavcodec</systemitem> pour encoder
la vid<69>o, bien que cet exemple th<74>orique s'applique <20>galement <20> d'autres codecs.
</para>
<para>
Si cela vous semble un peu trop pour vous, vous devriez utiliser une des
interfaces graphiques list<73>es dans <ulink url="http://mplayerhq.hu/homepage/design7/projects.html#mencoder_frontends">Section
MEncoder</ulink> sur la page de notre projet.
Avec ceci, vous serez suffisamment arm<72> pour produire des rips de bonne qualit<69> sans
trop r<>fl<66>chir car ces outils utilisent des r<>glages astucieux <20> votre place.
</para>
<sect2 id="menc-feat-dvd-mpeg4-preparing-encode">
<title>Pr<EFBFBD>paration <20> l'encodage : identification des sources, du mat<61>riel et du framerate</title>
<para>
Avant m<>me de penser <20> encoder un film, il est n<>cessaire de passer par quelques <20>tapes
pr<70>liminaires.
</para>
<para>
La premi<6D>re et plus importante <20>tape avant l'encodage sera la d<>termination du
type de contenu utilis<69>. Si la source physique provient d'un DVD ou bien d'un
m<>dia de diffusion comme la t<>l<EFBFBD> par c<>ble ou le satellite, elle sera stock<63>e
sous deux formats : NTSC pour l'Am<41>rique du nord et le Japon, et PAL pour
l'Europe et les autres pays...
C'est important de la prendre en compte ce param<61>tre: ceci est juste le format
de pr<70>sentation <20> la t<>l<EFBFBD>vision, ce n'est en <emphasis role="bold">aucun</emphasis>
cas le format original du film.
L'exp<78>rience montre que le NTSC est bien plus dur <20> encoder car il y a plus
d'<27>l<EFBFBD>ment d'identification dans la source.
Afin de produire l'encodage d<>sir<69>, vous devez conna<6E>tre le format original.
N<>gliger cette <20>tape aura pour cons<6E>quence des r<>sultats hasardeux, des artefacts
bizarro<72>des, des trames en double ou ignor<6F>es.
En plus d'avoir des r<>sultats bizarres, le rendu global risque d'en souffrir avec une
qualit<69> m<>diocre par unit<69> du bitrate.
</para>
<sect3 id="menc-feat-dvd-mpeg4-preparing-encode-fps">
<title>Identification du framerate de la source</title>
<para>
Voici une liste de types de sources mat<61>rielles, il est possible que vous
trouviez la v<>tre avec ces propri<72>t<EFBFBD>s :
</para>
<itemizedlist>
<listitem><para>
<emphasis role="bold">Film standard</emphasis>: produit pour une diffusion
cin<69>matographique avec 24 images par secondes (fps).
</para></listitem>
<listitem><para>
<emphasis role="bold">Vid<EFBFBD>o PAL</emphasis>: Enregistr<74> par une cam<61>ra <20> 50 trames
par secondes. Une trame est, par exemple, l'ensemble des lignes paires ou des lignes impaires d'une image.
La t<>l<EFBFBD>vision a <20>t<EFBFBD> cr<63><72>e pour afficher l'image de cette mani<6E>re (en fait une version bas de gamme
de compression analogique).
L'oeil humain est cens<6E> compenser cette alternance de trames mais d<>s lors que vous
comprenez ce fonctionnement, vous ne regarderez plus la t<>l<EFBFBD>vision de la m<>me fa<66>on.
Deux trames ne font <emphasis role="bold">pas</emphasis> une image compl<70>te, car elles
sont captur<75>es avec un d<>calage de 1/50e de seconde, et donc, elles ne s'alignent pas
parfaitement sauf s'il y a du mouvement
</para></listitem>
<listitem><para>
<emphasis role="bold">Vid<EFBFBD>o NTSC</emphasis> : Enregistr<74> par une cam<61>ra <20>
60000/1001 trames par secondes, ou 60 trames par secondes dans l'<27>re noir/blanc.
A part cela, c'est similaire au PAL.
</para></listitem>
<listitem><para>
<emphasis role="bold">Animation</emphasis>: Habituellement dessin<69> pour du 24fps,
mais on peut en trouver de toute sorte.
</para></listitem>
<listitem><para>
<emphasis role="bold">Animation Graphique, Effets Sp<53>ciaux</emphasis>: il est
possible d'en trouver avec n'importe quel framerate, mais en g<>n<EFBFBD>ral, le NTSC utilise 24fps et 30fps, le PAL utilise plut<75>t
25fps.
</para></listitem>
<listitem><para>
<emphasis role="bold">Vieux films</emphasis>: le framerate est g<>n<EFBFBD>ralement plus
bas.
</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="menc-feat-dvd-mpeg4-preparing-encode-material">
<title>Identification de la source mat<61>rielle</title>
<para>
(?)Les films compos<6F>s de trames sont dits 'progressive',
alors que ceux compos<6F>s de champs ind<6E>pendant sont appel<65>s
soit entrelac<61>s soit vid<69>o - ce dernier terme est plut<75>t ambigu.
</para>
<para>
Pour compliquer le tout, certains films utilisent un m<>lange de plusieurs des
techniques vues ci-dessus.
</para>
<para>
La distinction la plus importante qui doit <20>tre faire entre ces formats
est que certains utilisent les trames alors que d'autres, les champs.
<emphasis role="bold">M<EFBFBD>me si</emphasis> un film a <20>t<EFBFBD> pr<70>par<61> pour <20>tre projet<65>
sur une t<>l<EFBFBD>vision (DVDs inclus), il est converti dans un format bas<61> sur des champs.
Les nombreuses m<>thodes peuvent <20>tre rassembl<62>es sous le terme de redimensionnement comme
l'inf<6E>me NTSC "3:2 telecine" qui en est une vari<72>t<EFBFBD>.
Sauf si l'oeuvre originale est bas<61>e sur des champs (et avec le m<>me fieldrate),
le format d'image obtenu sera diff<66>rent de celui d'origine.
</para>
<itemizedlist>
<title>Plusieurs vari<72>t<EFBFBD>s communes de redimensionnement :</title>
<listitem><para>
<emphasis role="bold">Redimensionnement PAL 2:2 </emphasis>: Le meilleur de tous.
Chaque image est affich<63>e pendant la dur<75>e de deux trames, par extraction des lignes
paires et impaires, puis en les affichant par alternance.
Si l'original est <20> 24 images par secondes, ce redimensionnement augmentera la vitesse
du film de 4%.
</para></listitem>
<listitem><para>
<emphasis role="bold">Redimensionnement PAL 2:2:2:2:2:2:2:2:2:2:2:3</emphasis>:
La douzi<7A>me image est affich<63>e pendant la dur<75>e de 3 frames au lieu de deux. Cela
permet d'<27>viter le probl<62>me de l'acc<63>l<EFBFBD>ration de 4% mais rend le processus tr<74>s
difficile <20> inverser.
Cette technique est g<>n<EFBFBD>ralement utilis<69>e dans les productions musicales o<>
l'acc<63>l<EFBFBD>ration de 4% endommagerait s<>rieusement la qualit<69> musicale.
</para></listitem>
<listitem><para>
<emphasis role="bold">T<EFBFBD>l<EFBFBD>cine NTSC 3:2</emphasis>: Les images sont alternativement
affich<63>es pendant une dur<75>e de 3 ou 2 frames. Cela provoque un redimensionnement de 2,5 fois le
ratio original. Le r<>sultat est tr<74>s l<>g<EFBFBD>rement ralenti de 60 frames par secondes <20> 60000/1001
frames par seconde pour maintenir le fieldrate NTSC
</para></listitem>
<listitem><para>
<emphasis role="bold">Redimensionnement NTSC 2:2</emphasis>: Utilis<69> pour le NTSC avec une
source en 30fps. Le rendu est correct, similaire au redimensionnement PAL 2:2
</para></listitem>
</itemizedlist>
<para>
Il y aussi d'autres mani<6E>res de convertir des vid<69>os NTSC et PAL
mais ce sujet s'<27>loigne des limites de ce guide.
Si vous d<>sirez encoder un film par exemple, le mieux reste de trouver
une copie de l'original.
La conversion entre ces deux formats est hautement destructrice et il n'est
pas possible de l'inverser proprement, donc l'encodage sera d'autant plus
mauvais s'il est fait <20> partir d'une source d<>j<EFBFBD> convertie.
</para>
<para>
Quand des vid<69>os sont stock<63>es sur un DVD, des groupes de trames
cons<6E>cutives sont rassembl<62>es en une image, m<>me si elles ne sont pas cens<6E>es
<20>tre affich<63>es au m<>me moment.
Le standard MPEG-2 utilis<69> dans les DVDs et la t<>l<EFBFBD>vision num<75>rique fournit
un moyen d'encoder les images originales progressivement et de stocker le
nombre de trames pour chaque image qui devra <20>tre affich<63> avant cette
image.
Si cette m<>thode est utilis<69>e, on dit que le film est "soft-telecined"
("contenu progressif"), car le processus de rendu est
appliqu<71> directement par le lecteur DVD et non pas en d<>gradant le film.
Ce cas est de loin le mieux car il peut <20>tre tout aussi bien invers<72>
(en fait, non pris en compte) par l'encodeur puisqu'il pr<70>serve la qualit<69> maximale.
Malgr<67> cela, beaucoup de DVD et d'<27>missions studios diffus<75>es n'utilisent pas
des techniques d'encodage propres mais plut<75>t des films "hard telecine" ("contenu brut")
dans lesquels les trames sont dupliqu<71>es puis encod<6F>es en MPEG-2.
</para>
<para>
Les <20>tapes pour g<>rer correctement ce genre de cas seront <20>voqu<71>es <link
linkend="menc-feat-telecine">plus tard dans ce guide</link>.
Pour l'instant, nous allons vous donner quelques indices pour d<>finir <20> quelle
source vous avez <20> faire :
</para>
<itemizedlist>
<title>Domaine du NTSC:</title>
<listitem><para>
Si <application>MPlayer</application> affiche que le nombre d'image a changer pour
24000/1001 quand vous regardez votre film, et qu'il ne change plus du tout, il est
quasiment certain que c'est un contenu progressif qui a <20>t<EFBFBD> "soft telecin<69>".
</para></listitem>
<listitem><para>
Si <application>MPlayer</application> affiche un nombre d'images alternant
entre 24000/1001 et 30000/1001 et que les bords de l'image affichent des esp<73>ces de "peignes", alors
il y a plusieurs possibilit<69>s.
Les segments <20> 24000/1001 fps ont tr<74>s certainement un contenu progressif,
"soft telecin<69>" mais les parties 30000/1001 fps ont pu <20>tre "hard-telecin<69>es"
depuis un contenu 24000/1001 fps ou 60000/1001 frames par secondes d'une vid<69>o NTSC.
Utilisez les m<>mes conseils que ceux pour les deux cas qui suivent.
</para></listitem>
<listitem><para>
Si <application>MPlayer</application> montre un nombre d'images constant et que chacune
des images avec des mouvements semble avoir un "peigne" sur les cot<6F>s, alors votre film
est une vid<69>o NTSC <20> 60000/1001 images par seconde.
</para></listitem>
<listitem><para>
Si <application>MPlayer</application> montre un nombre d'images constant et que deux
images sur cinq apparaissent avec des "peignes", le film est "hard telecin<69>" avec un contenu
<20> 24000/1001fps.
</para></listitem>
</itemizedlist>
<itemizedlist>
<title>Domaine du PAL:</title>
<listitem><para>
Si vous ne voyez pas de "peigne" sur les cot<6F>s, le film a un redimensionnement 2:2.
</para></listitem>
<listitem><para>
Si vous voyez une alternance r<>guli<6C>re d'effet "peigne", de pseudo-entrelacement
toutes les demi-secondes, alors le film a subi une r<>duction 2:2:2:2:2:2:2:2:2:2:2:3.
</para></listitem>
<listitem><para>
Si vous voyez une sorte d'entrelacement constant dans les sc<73>nes en mouvement,
le film est en PAL avec 50 trames par secondes.
</para></listitem>
</itemizedlist>
<note><title>Astuce:</title>
<para>
<application>MPlayer</application> peut lire un film tr<74>s lentement en utilisant
l'option -speed ou en le jouant image par image.
Essayer d'utiliser l'option <option>-speed</option> <20> 0.2 afin de regarder le film
tr<74>s doucement ou presser la touche "<keycap>.</keycap>" pour avancer d'une frame
<20> l'autre et ainsi identifier la "signature" d'un type de redimensionnement si
celui-ci n'est pas visible <20> vitesse normale.
</para>
</note>
</sect3>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-2pass">
<title>Quantiseur constant contre deux passes</title>
<para>
Il est possible d'encoder votre film suivant une large gamme de qualit<69>s.
Les compresseurs vid<69>os modernes et quelques pre-codec de compression
(antibruit et redimensionnement) permettent d'obtenir un
tr<74>s bon rendu pour un film grand <20>cran de 90-110 minutes sur 700Mo.
De plus, la plupart des films longs peuvent approcher un r<>sultat parfait
avec un fichier d'un taille de 1400Mo.
</para>
<para>
Il y a trois approches possibles pour encoder une vid<69>o: d<>bit constant
(CBR), quantification constante, et deux passes (ABR, ou d<>bit moyen).
</para>
<para>
La complexit<69> des images d'un film et le nombre de bits utilis<69>s pour
cette compression fera varier grandement le r<>sultat d'une sc<73>ne <20> l'autre.
Les encodeurs vid<69>os modernes savent s'ajuster en fonction des besoins par
variation du d<>bit vid<69>o (bitrate).
Cependant, dans un mode simple comme le CBR, le compresseur ne conna<6E>t pas
le besoin en d<>bit vid<69>o pour les sc<73>nes <20> venir, donc il ne sait pas d<>finir
un bitrate moyen sur la longueur du film.
Les modes avanc<6E>s actuels, comme le mode 'multi-passes' (plusieurs passages), prennent
en compte les statistiques des passes pr<70>c<EFBFBD>dentes pour l'encodage, fixant le
probl<62>me ci-dessus.
</para>
<note><title>Note:</title>
<para>
La plupart des codecs qui supportent la compression ABR supportent seulement deux
passages alors que d'autres comme le <systemitem class="library">x264</systemitem>,
le <systemitem class="library">XviD</systemitem> et <systemitem class="library">libavcodec</systemitem> supportent des
passes multiples qui permettent d'affiner <20> chaque fois les statistiques (ces am<61>liorations seront cependant n<>gligeables
apr<70>s la quatri<72>me passe).
Dans cette section, deux passages ou plus peuvent <20>tre utilis<69>s indiff<66>remment.
</para>
</note>
<para>
Dans chacun de ces modes, <systemitem class="library">libavcodec</systemitem>
s<>pare les trames vid<69>os en macroblocs de 16x16 pixels et applique ensuite
un quantificateur sur chaque macrobloc. Plus le quantificateur est bas, plus
la qualit<69> est bonne et le d<>bit est gros. La m<>thode utilis<69>e par
<systemitem class="library">libavcodec</systemitem> pour d<>terminer quel
quantificateur utiliser varie et est configurable (ceci est une simplification
<20> l'extr<74>me du processus, mais il est utile de comprendre le principe de base).
</para>
<!-- FIXME -->
<para>
Lorsque vous sp<73>cifiez un d<>bit constant, le compresseur vid<69>o codera la vid<69>o
en laissant de c<>t<EFBFBD> les d<>tails, et ceci, d'autant plus
que le bitrate sera petit. Si la taille du fichier vous importe peu,
vous pouvez fixer un d<>bit contant et infini. (En pratique, cette
valeur aura une limite haute dans les 10000Kbit). Sans r<>elle
restriction de d<>bit,
<systemitem class="library">libavcodec</systemitem> utilisera le plus
bas quantificateur possible pour chaque macrobloc (tel que sp<73>cifi<66> par
<option>vqmin</option>, qui vaut 2 par d<>faut).
Si vous sp<73>cifiez un d<>bit si petit que <systemitem class="library">
libavcodec</systemitem> doit utiliser un quantificateur plus haut,
alors vous <20>tes certainement en train de massacrer la qualit<69> de votre
vid<69>o. En g<>n<EFBFBD>ral, vous devriez <20>viter le CBR si vous vous souciez de
la qualit<69>.
</para>
<para>
Avec un quantificateur constant <systemitem class="library">libavcodec</systemitem> utilise
le m<>me quantificateur, sp<73>cifi<66> par l'option <option>vqscale</option>, sur chaque macrobloc.
Si vous voulez un rip de la meilleure qualit<69> possible, cette fois encore en ignorant
le d<>bit, vous pouvez utiliser <option>vqscale=2</option>. Cela donnera le m<>me d<>bit
et le m<>me PSNR (Peak Signal-to-Noise Ratio, rapport signal sur bruit de cr<63>te)
que le CBR avec <option>vbitrate</option>=infini et la valeur de <option>vqmin</option> par
d<>faut (2).
</para>
<para>
Le probl<62>me de la quantification constante est, qu'elle utilise le quantificateur
demand<6E> m<>me si le macrobloc n'en a pas besoin. En fait, il doit <20>tre possible
d'utiliser un quantificateur plus haut sur un macrobloc sans sacrifier de la
qualit<69> visuelle. Pourquoi gaspiller des bits avec un quantificateur inutilement
bas ? Votre microprocesseur a assez de ressources car il a le temps, mais votre
disque lui a une taille fix<69>e.
</para>
<para>
Avec l'encodage deux passes, la premi<6D>re passe va ripper le film comme
en CBR, mais va garder un journal des propri<72>t<EFBFBD>s de chaque trame. Ces donn<6E>es
sont ensuite utilis<69>es pendant la seconde passe de fa<66>on <20> choisir intelligemment
quels quantificateurs utiliser. Lors des sc<73>nes d'action rapide ou celles ayant
beaucoup de d<>tails, des quantificateurs plus <20>lev<65>s seront utilis<69>s. Pendant les
sc<73>nes avec peu de mouvements ou avec peu de d<>tails, ce sera des quantificateurs
plus bas.
</para>
<para>
Si vous utilisez <option>vqscale=2</option>, alors vous gaspillerez des bits.
Si vous utilisez <option>vqscale=3</option>, vous n'aurez pas la meilleure
qualit<69> de rip. Supposez que vous ripiez un DVD avec <option>vqscale=3</option>,
et que le r<>sultat soit 1800Kbit. Si vous faites un encodage en deux passes avec
<option>vbitrate=1800</option>, la vid<69>o produite aura une
<emphasis role="bold">meilleure qualit<69></emphasis> pour le <emphasis role="bold">m<EFBFBD>me d<>bit</emphasis>.
</para>
<para>
Maintenant que vous <20>tes convaincu que l'encodage deux passes est la bonne m<>thode,
la vraie question est maintenant de savoir quel d<>bit utiliser. Il n'y a pas de r<>ponse
toute faite. Id<49>alement, vous devriez choisir un d<>bit offrant un compromis entre
qualit<69> et taille de fichier. Cette valeur varie selon la source vid<69>o.
</para>
<para>
Si la taille ne compte pas, un bon point de d<>part pour un rip de tr<74>s haute
qualit<69> est environ 2000kbps, plus ou moins 200kbps.
Pour les vid<69>os comportant beaucoup d'actions ou de d<>tails, et/ou si vous avez
de tr<74>s bon yeux, vous pouvez choisir 2400 ou 2600.
Pour certains DVDs, vous pourrez ne pas voir de diff<66>rence <20> 1400kbps. C'est une bonne
id<69>e que d'essayer sur des sc<73>nes avec diff<66>rents d<>bits pour se rendre compte.
</para>
<para>
Si vous avez fix<69> une taille limite, alors il faudra se livrer <20> un petit calcul
pour obtenir le d<>bit souhait<69>. Mais avant cela, il faudra d<>finir l'espace que
vous r<>serverez aux piste(s) audio et vous devrez <link linkend="menc-feat-dvd-mpeg4-audio">
les ripper</link> en premier.
Vous pourrez alors calculer le d<>bit souhait<69> avec l'<27>quation suivante :
<systemitem>D<EFBFBD>bit = (taille_fichier_final_en_Mo - taille_fichier_son_en_Mo) *
1024 * 1024 / dur<75>e_en_secondes * 8 / 1000</systemitem>
Par exemple, pour ramener deux heures de films sur un CD de 702Mo avec une piste
son de 60Mo, le d<>bit vid<69>o sera alors de :
<systemitem>(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000 = 740kbps</systemitem>
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-constraints">
<title>Contraintes pour une compression efficace</title>
<para>
De par la nature intrins<6E>que de la compression MPEG, de nombreux
param<61>tres entrent en jeu afin d'obtenir une qualit<69> maximale.
Le MPEG d<>coupe la vid<69>o en carr<72> de 16x16 appel<65> macroblocs. Chacun
d'entre eux est compos<6F> de 4 petits (8x8) blocs contenant des informations sur
la luminosit<69> (intensit<69>) ainsi que de 2 blocs (donc <20> r<>solution moiti<74>)
contenant des informations chromatiques (pour les teintes rouge-cyan et bleu-jaune).
M<>me si la longueur et la largeur du film ne sont pas des multiples de 16,
l'encodeur utilisera des macroblocs de 16x16 pour couvrir l'image enti<74>re,
l'espace restant sera alors perdu.
Si votre int<6E>r<EFBFBD>t est de conserver une tr<74>s bonne qualit<69>, utiliser des r<>solutions
non multiples de 16 n'est pas une bonne id<69>e.
</para>
<para>
La plupart des DVDs ont aussi des bandes noires sur les bords. N<>gliger
ces parties peut alt<6C>rer la qualit<69> de plusieurs mani<6E>res.
</para>
<orderedlist>
<listitem>
<para>
La compression MPEG est aussi d<>pendante du domaine de transformation des
fr<66>quences, en particulier du "Discrete Cosine Transform (DCT)" (une esp<73>ce de
transform<72>e de Fourier). Ce type d'encodage est efficace pour les
formes et les transitions douces, mais fonctionne moins bien avec les contours
ac<61>r<EFBFBD>s. Afin d'encoder correctement, il demandera plus de bits, sinon des
artefacts de compression appara<72>tront, aussi connus sous le nom de "ringing".
</para>
<para>
La transformation en fr<66>quence (DCT) prend place s<>par<61>ment dans chaque
macrobloc (en fait, dans chaque bloc), donc le probl<62>me n'appara<72>tra
que si un bord franc se situe dans ce bloc. Si vos bordures noires commencent
exactement sur un multiple de 16, ce ne sera pas un probl<62>me. En pratique,
les bordures ne sont jamais bien align<67>es, et il sera certainement
n<>cessaire de les couper pour <20>viter ces d<>fauts.
</para>
</listitem>
</orderedlist>
<para>
En plus des transformations au niveau des fr<66>quences, la compression MPEG
utilise des vecteurs de mouvements repr<70>sentant les changements d'une image
<20> la suivante. Ces vecteurs de mouvements voient leur utilit<69> grandement
r<>duite quand la prochaine image <20> un contenu totalement diff<66>rent. Quand
il y a un mouvement qui sort de la r<>gion encod<6F>e, cela ne pose pas de probl<62>me
aux vecteurs. En revanche, cela peut poser des probl<62>mes avec les bandes noires:
</para>
<orderedlist continuation="continues">
<listitem>
<para>
Pour chaque macrobloc, la compression MPEG stocke un vecteur identifiant
quelle partie de l'image pr<70>c<EFBFBD>dente devrait <20>tre copi<70>e dans les macroblocs
de l'image suivante. Seules les diff<66>rences devront alors <20>tre encod<6F>es.
Si le macrobloc s'<27>tend et prend en compte une des bordures noire de l'image,
alors le vecteur de mouvement <20>crasera la bordure noire. Cela veut dire que de
nombreux bits sont gaspill<6C>s pour re-noircir la bande noire ou alors (plus probable) que le vecteur
de mouvement ne sera pas du tout utilis<69> et que tout le macrobloc
devra alors <20>tre r<>-encod<6F>. Dans tous les cas, l'efficacit<69> de l'encodage en est
grandement am<61>lior<6F>e.
</para>
<para>
Une fois encore, ce probl<62>me n'existe que si les lignes des bordures noires
ne sont pas un multiple de 16.
</para>
</listitem>
<listitem>
<para>
Enfin, supposons que l'on ait un macrobloc <20> l'int<6E>rieur d'une image et qu'un
objet se d<>place dans ce bloc proche d'un bord de l'image. Malheureusement, le
MPEG ne sait pas faire "copier juste la partie qui dans l'image et laisser tomber
la partie noire". Donc la partie noire sera alors aussi copi<70>e, ce qui fait encore gaspiller
beaucoup de bits pour compresser un morceau d'image qui n'est pas sens<6E> <20>tre l<>.
</para>
<para>
Si l'objet en mouvement parcourt depuis le bord noir jusque dans la zone encod<6F>e,
le MPEG dispose d'optimisation sp<73>ciales pour copier en r<>p<EFBFBD>tition des pixels
depuis le bord de l'image lorsque celui vient de l'ext<78>rieur de la partie encod<6F>e.
Ces optimisations deviennent inutiles quand le film <20> des bandes noires. Contrairement
aux probl<62>mes 1 et 2, m<>me les bordures noires multiples de 16 n'aident pas dans ce cas.
</para>
</listitem>
<listitem>
<para>
Malgr<67> le fait que les bordures soient enti<74>rement noires et quelles ne changent jamais,
il y a toujours un minimum de macroblocs impliqu<71>s.
</para>
</listitem>
</orderedlist>
<para>
Pour toutes ces raisons, il est pr<70>f<EFBFBD>rable de couper enti<74>rement ces bandes
noires. Dans la m<>me optique, s'il y a une partie contenant du bruit ou de la
distorsion d'image pr<70>s d'une bordure, la coupure l'enl<6E>vera et permettra d'avoir
une am<61>lioration significative de la qualit<69> de l'encodage. Les puristes parmi les vid<69>ophiles
souhaiteront pr<70>server l'encodage le plus proche possible de
l'original, <20> moins qu'ils n'encodent avec un quantificateur constant, la qualit<69>
gagn<67>e apr<70>s la suppression des bandes noires am<61>liorera grandement la qualit<69>
finale de l'encodage au regard des quelques informations perdues.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-crop">
<title>D<EFBFBD>coupage et Redimensionnement</title>
<para>
Vous vous souvenez de la section pr<70>c<EFBFBD>dente que les dimensions (<28> la fois largeur et hauteur)
de l'image finale doivent <20>tre des
multiples de 16. Cela peut <20>tre r<>alis<69> par recadrage (d<>coupe),
redimensionnement ou une combinaison des deux.
</para>
<para>
Lors du recadrage, il y a quelques r<>gles qui doivent <20>tre respect<63>es pour <20>viter
d'endommager votre film.
Le format YUV normal, 4:2:0, stocke la chrominance (la couleur) de mani<6E>re
sous-<2D>chantillonn<6E>e, c'est <20> dire que la chrominance est <20>chantillon<6F>e moiti<74> moins
souvent que la luminance (intensit<69>). Sur le sch<63>ma suivant, L indique l'<27>chantillonage en luminance et C en chrominance.
</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>
Comme vous pouvez le voir, les lignes et colonnes de l'image viennent naturellement par deux.
Ainsi, les dimensions de votre recadrage ainsi que ses distances au bords d'origine
<emphasis>doivent</emphasis> <20>tre paires. Si elles ne
l'<27>taient pas, les chrominances et luminances ne seraient plus align<67>es.
En th<74>orie, il est possible d'avoir des dimensions impaires, mais cela
requi<75>re un nouvel <20>chantillonage de la chrominance, ce qui
engendre potentiellement des pertes d'information et n'est pas support<72> par
le filtre de recadrage.
</para>
<para>
Ensuite, la vid<69>o entrelac<61>e est <20>chantillon<6F>e de la fa<66>on suivante:
</para>
<informaltable>
<?dbhtml table-width="80%" ?>
<?dbfo table-width="80%" ?>
<tgroup cols="16" align="center">
<colspec colnum="1" colname="col1"/>
<colspec colnum="2" colname="col2"/>
<colspec colnum="3" colname="col3"/>
<colspec colnum="4" colname="col4"/>
<colspec colnum="5" colname="col5"/>
<colspec colnum="6" colname="col6"/>
<colspec colnum="7" colname="col7"/>
<colspec colnum="8" colname="col8"/>
<colspec colnum="9" colname="col9"/>
<colspec colnum="10" colname="col10"/>
<colspec colnum="11" colname="col11"/>
<colspec colnum="12" colname="col12"/>
<colspec colnum="13" colname="col13"/>
<colspec colnum="14" colname="col14"/>
<colspec colnum="15" colname="col15"/>
<colspec colnum="16" colname="col16"/>
<spanspec spanname="spa1-2" namest="col1" nameend="col2"/>
<spanspec spanname="spa3-4" namest="col3" nameend="col4"/>
<spanspec spanname="spa5-6" namest="col5" nameend="col6"/>
<spanspec spanname="spa7-8" namest="col7" nameend="col8"/>
<spanspec spanname="spa9-10" namest="col9" nameend="col10"/>
<spanspec spanname="spa11-12" namest="col11" nameend="col12"/>
<spanspec spanname="spa13-14" namest="col13" nameend="col14"/>
<spanspec spanname="spa15-16" namest="col15" nameend="col16"/>
<tbody>
<row>
<entry namest="col1" nameend="col8">Top field</entry>
<entry namest="col9" nameend="col16">Bottom field</entry>
</row>
<row>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry spanname="spa1-2">C</entry>
<entry spanname="spa3-4">C</entry>
<entry spanname="spa5-6">C</entry>
<entry spanname="spa7-8">C</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
</row>
<row>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry spanname="spa9-10">C</entry>
<entry spanname="spa11-12">C</entry>
<entry spanname="spa13-14">C</entry>
<entry spanname="spa15-16">C</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
</row>
<row>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry spanname="spa1-2">C</entry>
<entry spanname="spa3-4">C</entry>
<entry spanname="spa5-6">C</entry>
<entry spanname="spa7-8">C</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
</row>
<row>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry spanname="spa9-10">C</entry>
<entry spanname="spa11-12">C</entry>
<entry spanname="spa13-14">C</entry>
<entry spanname="spa15-16">C</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
<entry>L</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
Comme vous pouvez le voir, le plus petit motif <20> se r<>p<EFBFBD>ter est sur 4 lignes.
Donc, pour la vid<69>o entrelac<61>e, la hauteur de votre recadrage et sa distance
verticale aux bords doivent <20>tre des multiples de 4.
</para>
<para>
La r<>solution native pour un DVD NTSC est 720x480 et 720x576 pour un
PAL, mais il y a un indicateur d'aspect qui sp<73>cifie que le mode est
plein-<2D>cran (full-screen 4:3) ou bien <20>cran large (wide-screen 16:9).
Un grand nombre de DVDs (pas tous) en wide-screen ne respecte pas
strictement le format 16:9, mais est plut<75>t en 1,85:1 ou 2,35:1 (cin<69>mascope).
Ceci signifie qu'il y aura des bandes noires <20> enlever sur la vid<69>o.
</para>
<para>
<application>MPlayer</application> fournit un filtre de d<>tection
qui d<>termine le rectangle de recadrage (<option>-vf cropdetect</option>).
Lancer l'application <application>MPlayer</application> avec l'option
<option>-vf cropdetect</option> et il affichera les options de recadrage pour enlever les bandes.
Vous devez laisser tourner le film suffisamment longtemps pour que toute la zone de l'image soit vue
de fa<66>on <20> obtenir des valeurs pr<70>cises.
</para>
<para>
Ensuite, testez les valeurs obtenues avec <application>MPlayer</application> en utilisant
la ligne de commande fournie par <option>cropdetect</option>,
et <20>ventuellement ajustez le rectangle de recadrage.
Ce filtre <option>rectangle</option> offre la possibilit<69> de le positionner
de fa<66>on interactive pendant le film. N'oubliez pas de suivre les
recommandations pr<70>c<EFBFBD>dentes sur la divisibilit<69> des dimensions de l'image afin de ne pas
d<>saligner les plans de chrominance.
</para>
<para>
Dans certain cas, le redimensionnement n'est pas souhaitable. Il est d<>licat
dans le sens vertical avec des vid<69>os entrelac<61>es, si vous d<>sirez
conserver l'entrelacement, vous devrez vous abstenir de redimensionner.
Sans redimensionner, pour utiliser des dimensions multiples de 16,
il vous faudra recadrer plus petit que l'image. Ne pas recadrer plus grand que l'image
parce que car les bandes noires sont nuisibles <20> la compression.
</para>
<para>
Le MPEG-4 utilisant des macroblocs de 16x16, assurez-vous que les dimensions
de la vid<69>o que vous encodez sont des multiples de 16, sinon vous d<>graderez la
qualit<69>, surtout <20> de faibles d<>bits. Pour ce faire, vous pouvez
arrondir les dimensions du rectangle de recadrage au multiple de 16 inf<6E>rieur.
Comme expliqu<71> plus haut, durant le recadrage, vous devrez augmenter le
d<>calage en Y de la moiti<74> de la diff<66>rence entre l'ancienne et la nouvelle
hauteur pour que l'image r<>sultante se situe au milieu de l'ancienne. Et <20> cause
de la fa<66>on dont les vid<69>os DVD sont <20>chantillon<6F>es, assurez-vous que ce d<>calage en Y
est un nombre pair. (En fait, c'est une r<>gle: n'utilisez jamais une valeur impaire lors d'un recadrage ou
d'un redimensionnement de vid<69>o). Si vous ne vous faites pas <20> l'id<69>e de vous d<>barrasser de quelques
pixels, vous pr<70>f<EFBFBD>rerez sans doute redimensionner la vid<69>o. Nous allons voir cela
dans notre exemple ci-dessous.
En fait, vous pouvez laisser le filtre <option>cropdetect</option> faire
tout cela pour vous: il a un param<61>tre optionnel d'arrondi <option>round</option> qui vaut
16 par d<>faut.
</para>
<para>
Faites aussi attention aux pixels <20> "demi-noir" sur les bords. Assurez-vous qu'ils sont
en dehors de votre recadrage, autrement, vous g<>cherez des bits qui seraient mieux utilis<69>s ailleurs.
</para>
<para>
Apr<70>s tout ceci, vous obtiendrez une vid<69>o qui n'est pas tout <20> fait au format
1,85:1 ou 2,35:1, mais quelque chose d'assez proche. Vous pourriez alors
calculer le nouveau format <20> la main mais <application>MEncoder</application> propose
une option appel<65>e <option>autoaspect</option> pour <systemitem class="library">libavcodec</systemitem>
qui fera cela pour vous. N'agrandissez surtout pas cette vid<69>o pour
obtenir les dimensions standards <20> moins que vous n'aimiez g<>cher votre espace disque.
Ce changement d'<27>chelle se fait <20> la lecture, le lecteur utilisera les donn<6E>es
stock<63>es dans le fichier AVI pour effectuer le bon rendu.
Malheureusement, tous les lecteurs vid<69>os n'appliquent pas ce redimensionnement
automatique, c'est peut-<2D>tre pour cela que vous voudrez quand m<>me proc<6F>der <20> ce redimensionnement.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-resolution-bitrate">
<title>Choix de la r<>solution et du d<>bit</title>
<para>
Si vous n'encodez pas dans un mode <20> quantificateur constant, vous
devez s<>lectionner un d<>bit.
Le concept de d<>bit (bitrate) est assez simple.
C'est un nombre (moyen) de bits par seconde qui sera utilis<69> pour stocker votre film.
Normalement, le d<>bit est mesur<75> en kilobits (1000 bits) par seconde.
La taille de votre film sur le disque dur correspond au d<>bit multipli<6C> par sa
dur<75>e plus une petite quantit<69> pour l'"en-t<>te" (surco<63>t, voir par exemple la section sur
<link linkend="menc-feat-dvd-mpeg4-muxing-avi-limitations">les conteneurs AVI</link>).
D'autres param<61>tres comme le redimensionnement, le recadrage, etc. ne modifieront
<emphasis role="bold">pas</emphasis> la taille du fichier sauf si vous y
changez aussi le d<>bit.
</para>
<para>
Le d<>bit n'est <emphasis role="bold">pas</emphasis> proportionnel
<20> la r<>solution. Ce qui veut dire qu'un fichier en 320x240 <20> 200kbit/sec
n'aura pas la m<>me qualit<69> que le m<>me film en 640x480 <20> 800kbit/sec ! A cela, deux raisons:
<orderedlist>
<listitem><para>
<emphasis role="bold">Visuelle</emphasis> : Les artefacts de compression MPEG se
remarquent plus facilement <20> une plus grande <20>chelle. Les artefacts apparaissent
<20> l'<27>chelle des blocs (8x8). L'oeil humain ne voit pas les erreurs dans 4800 petits
blocs aussi facilement que qu'il les voit dans 1200 grands blocs (en supposant
une visualisation en plein <20>cran dans les deux cas).
</para></listitem>
<listitem><para>
<emphasis role="bold">Th<EFBFBD>orique</emphasis> : quand vous r<>duisez la taille d'une image
mais que vous continuez <20> utiliser les m<>mes tailles de bloc (8x8) pour la transformation
dans l'espace des fr<66>quences, vous d<>placez plus de donn<6E>es vers les hautes
fr<66>quences. Grossi<73>rement dit: chaque pixel contient plus de d<>tails qu'avant.
Donc, m<>me si votre image de taille r<>duite ne contient plus qu'un quart de l'information
dans le domaine spatial, elle peut toujours contenir une grande part de l'information dans
l'espace des fr<66>quences (en supposant que les hautes fr<66>quences <20>taient sous-utilis<69>es dans
votre originale en 640x480).
</para></listitem>
</orderedlist>
</para>
<para>
Les anciens guides recommandaient de choisir un d<>bit et une r<>solution bas<61>s
sur "1 bit par pixel", mais ce n'est que peu justifi<66> avec les raisons <20>voqu<71>es ci-dessus.
Une meilleure estimation reste que le d<>bit augmente proportionnellement <20> la
racine carr<72>e de la r<>solution, donc une image 320x240 <20> 400kbit/sec
sera comparable <20> une en 640x480 <20> 800 kbit/sec.
Cela n'a pas <20>t<EFBFBD> strictement v<>rifi<66> par la th<74>orie ou une quelconque m<>thode.
De plus, pour un film donn<6E>, le r<>sultat variera en fonction du bruit, des d<>tails,
du degr<67> de mouvement, etc.. Il est futile de donner des recommandations g<>n<EFBFBD>rales
du style: un nombre de bits par longueur de diagonale (similaire au bit par pixel,
en utilisant la racine carr<72>e).
</para>
<para>
Jusqu'<27> maintenant, nous avons discut<75> de la difficult<6C> de choisir le d<>bit et la r<>solution.
</para>
<sect3 id="menc-feat-dvd-mpeg4-resolution-bitrate-compute">
<title>Calcul de la r<>solution</title>
<para>
Les <20>tapes qui suivent vous guideront dans le calcul de la r<>solution de votre
encodage sans trop distordre la vid<69>o, en prenant en compte les diff<66>rents types
d'information sur la source vid<69>o.
En premier lieu, il faut calculer le format de l'encodage:
<systemitem>ARc = (Wc x (ARa / PRdvd )) / Hc</systemitem>
<itemizedlist>
<title>O<EFBFBD> :</title>
<listitem><para>
Wc et Hc sont la largeur et la hauteur de la vid<69>o recadr<64>e,
</para></listitem>
<listitem><para>
ARa est le format affich<63>, g<>n<EFBFBD>ralement 4/3 ou 16/9,
</para></listitem>
<listitem><para>
PRdvd est le ratio des pixels du DVD qui normalement est <20>gal <20> 1,25 (=720/576)
pour le PAL et 1,5(=720/480) pour le NTSC,
</para></listitem>
</itemizedlist>
</para>
<para>
Ensuite, vous pouvez calculer la r<>solution X et Y en tenant compte du facteur
de Qualit<69> de Compression (CQ):
<systemitem>ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16</systemitem>
et
<systemitem>ResX = INT( ResY * ARc / 16) * 16</systemitem>
</para>
<para>
D'accord, mais c'est quoi ce CQ ?
le CQ repr<70>sente le nombre de bit par pixel et par image encod<6F>e. Grosso modo,
plus le CQ est grand, moins il y aura de chances de voir appara<72>tre des artefacts
de compression. En tout cas, si vous avez une limite de taille pour votre film
(1 ou 2 CDs par exemple), il y a donc une limite au nombre de bits total que vous
pouvez lui allouer et il est donc n<>cessaire de trouver le bon compromis entre
compressibilit<69> et la qualit<69>.
</para>
<para>
Le CQ d<>pend du d<>bit, de l'efficacit<69> du codec vid<69>o et de la r<>solution
du film.
Une mani<6E>re d'augmenter le CQ, c'est de r<>duire la r<>solution du film puisque le
d<>bit est calcul<75> en fonction de la taille finale d<>sir<69>e et la longueur du film qui sont constant.
Avec les codecs ASP MPEG-4 comme le <systemitem class="library">XviD</systemitem> ou le
<systemitem class="library">libavcodec</systemitem>, un CQ en dessous de 0,18 donne
g<>n<EFBFBD>ralement une image type mosa<73>que car il n'y pas assez de bits pour coder
les informations de chaque macrobloc (le MPEG-4, comme les autres codecs, groupe
les pixels compress<73>s par blocs pour compresser l'image, s'il n'y a pas assez
de bits, les bords de ce macrobloc deviennent alors visibles).
Donc il est raisonnable de prendre un CQ entre 0,20 et 0,22 pour une copie tenant
sur 1 CD, et entre 0,26 et 0,28 pour une copie sur 2 CDs avec des options d'encodage
standard.
Des options d'encodage plus avanc<6E>es telles que celles list<73>es ici pour le
<link linkend="menc-feat-mpeg4-lavc-example-settings"><systemitem class="library">libavcodec</systemitem></link> et le
<link linkend="menc-feat-xvid-example-settings"><systemitem class="library">XviD</systemitem></link>
devraient permettre d'obtenir la m<>me qualit<69> avec un CQ se situant entre
0,18 et 0,20 pour une copie sur 1 CD et 0,24 <20> 0,26 pour une copie sur 2 CDs.
Avec les codecs ASP MPEG-4 comme le <systemitem class="library">x264</systemitem>,
vous pouvez utiliser un CQ se situant entre 0,14 et 0,16 avec des options standards
d'encodage, et m<>me descendre entre 0,10 et 0,12 avec des
<link linkend="menc-feat-x264-example-settings">options avanc<6E>es <systemitem class="library">x264</systemitem></link>.
</para>
<para>
Veuillez noter que le CQ n'est qu'un indicateur, il d<>pend directement
du contenu encod<6F>, un CQ de 0,18 pourrait sembler parfait pour un film de Bergman, mais
trop petit pour un film comme Matrix contenant beaucoup de sc<73>nes d'actions.
A l'oppos<6F>, il est inutile d'aller au del<65> de 0,30 pour le CQ, vous ne feriez que g<>cher
de l'espace disque sans gain notable en qualit<69>.
Notez aussi, comme cela a <20>t<EFBFBD> dit plus haut que les vid<69>os en
plus petites r<>solutions auront besoin d'un plus grand CQ (compar<61> <20> la r<>solution
d'un DVD par exemple) pour un rendu correct.
</para>
</sect3>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-filtering">
<title>Les filtres</title>
<para>
Apprendre <20> utiliser les filtres vid<69>os de <application>MEncoder</application>
est essentiel pour cr<63>er des fichiers bien encod<6F>s.
Toutes les transformations vid<69>os sont ex<65>cut<75>es au travers de filtres, comme le recadrage (d<>coupe),
le redimensionnement, l'ajustement de couleur, la suppression du bruit, l'ajustement
de la nettet<65>, le d<>s-entrelacement, le t<>l<EFBFBD>cin<69>, le t<>l<EFBFBD>cin<69> inverse, ou l'effacement
des macroblocs trop visible, pour n'en nommer que quelques un.
Avec le grand nombre de formats d'entr<74>e support<72>, la vari<72>t<EFBFBD> des
filtres disponibles dans <application>MEncoder</application> est l'un de ses principaux
avantages sur d'autres programmes similaires.
</para>
<para>
Les filtres sont charg<72>s dans la cha<68>ne gr<67>ce <20> l'option -vf :
<screen>-vf filtre1=options,filtre2=options,...</screen>
La plupart des filtres acceptent plusieurs options num<75>riques s<>par<61>es par des double-points (:), mais
la syntaxe varie d'un filtre <20> l'autre, aussi lisez la page manuel pour avoir les d<>tails sur les filtres
que vous souhaitez utiliser.
</para>
<para>
Les filtres agissent sur la vid<69>o dans l'ordre de leur chargement. Par exemple,
la cha<68>ne suivante :
<screen>-vf crop=688:464:12:4,scale=640:464</screen>
recadrera d'abord une zone de 688x464 depuis le bord haut gauche mais avec un
d<>calage de (12;4), puis redimensionnera la vid<69>o pour obtenir du 640x464.
</para>
<para>
Certains filtres ont besoin d'<27>tre charg<72>s au d<>but (ou proche du d<>but) de la cha<68>ne pour
profiter d'informations du d<>codeur vid<69>o qui seraient perdues ou invalid<69>es par d'autres filtres.
Les principaux exemples sont <option>pp</option> (postprocessing, seulement
dans le cas d'un estompage des macroblocs ou des enl<6E>vements des artefacts de
compression), le <option>spp</option> (un autre post processus pour enlever les
artefacts MPEG), le <option>pullup</option> (t<>l<EFBFBD>cin<69> inverse), et <option>
softpulldown</option> (conversion du soft t<>l<EFBFBD>cin<69> en hard
telecine).
</para>
<para>
En g<>n<EFBFBD>ral, il vaut mieux utiliser le moins de filtres possibles afin de conserver
l'encodage le plus proche possible du DVD source. Le recadrage est souvent
n<>cessaire (comme expliqu<71> plus haut), mais <20>vitez de redimensionner l'image.
Bien qu'il soit parfois pr<70>f<EFBFBD>rable de r<>duire la taille de l'image plut<75>t que d'utiliser
un quantificateur plus <20>lev<65>, nous voulons <20>viter tout ceci:souvenez-vous que
nous avons d<>cid<69> qu d<>part d'<27>changer des bits pour de la qualit<69>.
</para>
<para>
Aussi, n'ajustez pas le gamma, le contraste, la luminosit<69>, etc. Ces r<>glages
peuvent <20>tre bons chez vous mais pas sur un autre <20>cran. Ils doivent <20>tre
appliqu<71>s lors de la lecture uniquement.
</para>
<para>
Une chose que vous pouvez vouloir faire est de passer la vid<69>o <20> travers un filtre tr<74>s l<>ger
antibruit, comme par exemple <option>-vf hqdn3d=2:1:2</option>.
Il s'agit encore une fois d'optimiser l'utilisation de l'espace disque:
pourquoi le gaspiller <20> encoder du bruit alors qu'il sera l<> de toutes fa<66>ons <20> la lecture?
Augmenter les param<61>tres de <option>hqdn3d</option> am<61>liorera encore la compressibilit<69>, mais
si vous les augmentez trop, vous risquez de d<>grader l'image. Les valeurs sugg<67>r<EFBFBD>es
ci-dessus (<option>2:1:2</option>) sont plut<75>t conservatrices, n'h<>sitez pas <20>
les augmenter et <20> regarder le r<>sultat par vous-m<>me.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-interlacing">
<title>Entrelacmeent et T<>l<EFBFBD>cin<69></title>
<para>
Presque tous les films sont tourn<72>s en 24 images par seconde. Puisque le NTSC est en 30000/1001 images par seconde,
certains traitements doivent <20>tre appliqu<71>s pour l'adapter au d<>bit NTSC.
Ce proc<6F>d<EFBFBD> est appel<65> 3:2 pulldown, plus commun<75>ment appel<65> t<>l<EFBFBD>cin<69> (car
le pulldown est souvent appliqu<71> durant la phase de conversion en t<>l<EFBFBD>cin<69>),
et de fa<66>on simpliste, il fonctionne en ralentissant le film <20> 24000/1001 images par seconde,
et en r<>p<EFBFBD>tant une image sur 4.
</para>
<para>
Aucun traitement sp<73>cifique n'est cependant appliqu<71> <20> la vid<69>o des DVDs
PAL, qui fonctionnent <20> 25 images par seconde (techniquement, PAL peut <20>tre t<>l<EFBFBD>cin<69>, ce qui est
appel<65> 2:2 pulldown, mais ceci n'est pas un probl<62>me en pratique). Le film
en 24 images par seconde est simplement lu en 25 images par seconde. Le r<>sultat est que la vid<69>o tourne
l<>g<EFBFBD>rement plus vite, mais <20> moins d'<27>tre un extra-terrestre, vous ne verrez probablement pas la
diff<66>rence. Le son de la plupart des DVDs PAL a <20>t<EFBFBD> corrig<69> de fa<66>on <20> sonner correctement
quand il est lu <20> 25 images par seconde, m<>me si la piste
audio (et donc le film entier) a une dur<75>e 4% plus courte que les DVDs NTSC.
</para>
<para>
Puisque la vid<69>o d'un DVD PAL n'a pas <20>t<EFBFBD> modifi<66>e, vous n'avez pas <20> vous soucier
de la cadence de d<>filement des images. La source est en 25 images par seconde, et votre copie sera en 25 images par seconde. Cependant,
si vous recopier un film d'un DVD NTSC, vous pourrez avoir besoin d'appliquer
du t<>l<EFBFBD>cin<69> inverse.
</para>
<para>
Pour les films tourn<72>s en 24 images par seconde, la vid<69>o du DVD NTSC est soit en 30000/1001
t<>l<EFBFBD>cin<69>, soit en 24000/1001 progressif et pr<70>vu pour <20>tre t<>l<EFBFBD>cin<69> <20> la vol<6F>e
par le lecteur DVD. D'un autre cot<6F>, les s<>ries TV sont g<>n<EFBFBD>ralement
seulement entrelac<61>es, pas t<>l<EFBFBD>cin<69>es. Ce n'est pas une r<>gle absolue: certaines
s<>ries TV sont entrelac<61>es (comme 'Buffy contre les vampires') alors que d'autres
sont un m<>lange de progressif et d'entrelac<61> (comme 'Dark Angel', ou '24 heures
chrono').
</para>
<para>
Il est fortement recommand<6E> de lire la section <link linkend="menc-feat-telecine">
Comment g<>rer le t<>l<EFBFBD>cin<69> et le d<>s-entrelacement avec les DVDs NTSC</link>
pour apprendre <20> g<>rer les diff<66>rentes possibilit<69>s.
</para>
<para>
De toutes fa<66>ons, si vous copiez principalement des films, vous rencontrerez de
la vid<69>o 24 images par seconde progressive ou t<>l<EFBFBD>cin<69>e, et dans ce cas vous pouvez
utiliser le filtre <option>pullup</option> <option>-vf pullup,softskip</option>.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-encoding-interlaced">
<title>Encodage de vid<69>os entrelac<61>es</title>
<para>
Si la vid<69>o que vous d<>sirez encoder est entrelac<61>e (NTSC ou PAL), il vous faudra
alors choisir de la d<>s-entrelacer ou pas.
D'un cot<6F>, si vous la passez en d<>s-entrelac<61>, votre film sera utilisable en
progressive scan pour les <20>crans d'ordinateurs ou les projecteurs vid<69>os, mais
cela aura un prix : le fieldrate de 50 ou 60000/1001 trames par seconde passera <20>
25 ou 30000/1001 trames par seconde, et en gros, vous perdrez la moiti<74> des
informations durant les sc<73>nes avec beaucoup de mouvements.
</para>
<para>
Ainsi, si vous encodez pour avoir des archives de haute qualit<69>, il est recommand<6E>
de ne pas d<>s-entrelacer.
Vous pouvez toujours d<>s-entrelacer le film au moment de la lecture avec des
appareils en progressive scan, et les les futurs lecteurs pourront d<>s-entrelacer
toutes les trames, en interpolant les 50 ou 60000/1001 frames par seconde depuis
la vid<69>o entrelac<61>e.
</para>
<para>
Des pr<70>cautions sp<73>ciales doivent <20>tre prises lors d'un travail sur les vid<69>os entrelac<61>es:
</para>
<orderedlist>
<listitem><para>
Les d<>coupes sur la hauteur et l'offset sur Y doivent <20>tre des multiples de 4
</para></listitem>
<listitem><para>
Tout redimensionnement vertical doit <20>tre effectu<74> en mode entrelac<61>
</para></listitem>
<listitem><para>
Les filtres de post-traitement et d'antibruit ne marcheront pas comme pr<70>vu,
sauf si vous faites bien attention <20> ce qu'ils travaillent sur une frame <20> la fois, et
ils peuvent endommager la qualit<69> finale s'ils sont utilis<69>s de mani<6E>re incorrecte.
</para></listitem>
</orderedlist>
<para>
En tenant compte de ces recommandations, voici notre premier exemple :
</para>
<screen>
mencoder <replaceable>capture.avi</replaceable> -mc 0 -oac lavc -ovc lavc -lavcopts \
vcodec=mpeg2video:vbitrate=6000:ilme:ildct:acodec=mp2:abitrate=224
</screen>
<para>
Remarquez l'option <option>ilme</option> et <option>ildct</option>.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-av-sync">
<title>Commentaires sur le synchronisation Audio/Vid<69>o</title>
<para>
Le syst<73>me de synchronisation audio/vid<69>o de <application>MEncoder</application>
a <20>t<EFBFBD> cr<63><72> dans le but de pouvoir lire m<>me des fichiers dont la synchronisation
a <20>t<EFBFBD> mal faite ou des fichiers corrompus.
Il arrive que dans certain cas, il y ait des sauts ou des frames en double,
ce qui provoque une d<>synchronisation A/V, quand vous utilisez des entr<74>es propres
(bien s<>r, les probl<62>mes de synchronisation A/V ne s'appliquent que si vous avez copi<70> ou
ripp<70> le son en m<>me temps que l'encodage de la vid<69>o).
Vous pouvez ensuite activer l'option de synchronisation <option>-mc 0</option>,
ou la mettre dans votre fichier de configuration <systemitem>~/.mplayer/mencoder</systemitem>.
Elle ne sera utilis<69>e qu'avec les sources vid<69>os propres (DVD, capture T<>l<EFBFBD>,
bon rip MPEG-4, etc) mais pas pour des fichiers ASF/RM/MOV d<>t<EFBFBD>rior<6F>s.
</para>
<para>
Si vous d<>sirez une protection plus efficace contre les sauts ou multiplications
de frames, utilisez ces deux options : <option>-mc 0</option> et <option>-noskip</option>.
Cela emp<6D>chera <emphasis>toutes</emphasis> synchronisation A/V, ou la copie de
frames <20> frames, donc vous ne pouvez l'utiliser avec aucun autre filtre qui
pourrait produire al<61>atoirement des ajouts ou sauts de frames, ou si votre source
a un framerate variable!
C'est pour cela que l'option <option>-noskip</option> n'est en g<>n<EFBFBD>ral pas recommand<6E>e.
</para>
<para>
L'encodage audio nomm<6D> "3 passes" que <application>MEncoder</application>
supporte est connu pour provoquer des d<>synchronisations A/V
Ceci arrive g<>n<EFBFBD>ralement que lorsqu'il rentre en conjonction avec certains filtres,
donc il n'est pas recommand<6E> d'utiliser ce mode "3 passes".
Cette fonctionnalit<69> est conserv<72>e seulement pour une question de compatibilit<69>
et pour certains utilisateurs experts qui savent quand il est bon de l'utiliser
ou pas. Si vous n'avez jamais entendu parler de ce mode "3 passes", oubliez le
maintenant.
</para>
<para>
On a rapport<72> des d<>synchronisations A/V lors d'un encodage depuis stdin
avec <application>MEncoder</application>. Ne faites pas <20>a ! Utilisez toujours
un fichier ou bien une source telle qu'un CD/DVD/etc.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-audio">
<title>Audio</title>
<para>
L'audio est un probl<62>me bien plus simple <20> r<>soudre : si la qualit<69> importe,
laissez le flux audio tel quel.
M<>me les flux AC3 5.1 utilisent au plus 448Kbit/s, et tous ces bits sont utiles.
Vous pouvez <20>tre tent<6E> de convertir l'audio en Ogg Vorbis de haute qualit<69>,
mais ne pas avoir de d<>codeur AC3 aujourd'hui ne veut pas dire que vous n'en
n'aurez pas demain. Pr<50>parez le futur de vos rips DVDs en gardant le flux AC3.
Vous pouvez conserver le flux AC3 en le copiant directement dans le flux vid<69>o
<link linkend="menc-feat-mpeg4">pendant l'encodage</link>. On peut aussi extraire
le flux AC3 pour le mixer dans des conteneurs comme NUT ou Matroska.
<screen>mplayer <replaceable>fichier_source.vob</replaceable> -aid 129 -dumpaudio
-dumpfile <replaceable>son.ac3</replaceable></screen>
mettra dans ce fichier <replaceable>sond.ac3</replaceable> la piste audio num<75>ro
129 du fichier source <replaceable>fichier_source.vob</replaceable> (NB : les fichiers
VOB d'un DVD utilise normalement une autre syst<73>me de num<75>rotation pour l'audio,
ainsi la piste 129 est la seconde piste de ce fichier VOB).
</para>
<para>
Parfois, il arrivera que vous n'ayez pas d'autre choix que de compresser le son
pour laisser plus de place <20> la vid<69>o. La plupart des gens optent alors pour le
codec MP3 ou le Vorbis.
Bien que le codec MP3 soit moyennement efficace, il est de mieux en mieux
accept<70> par les lecteurs de salon, mais cette tendance <20>volue.
</para>
<para>
N'utilisez <emphasis>pas</emphasis> l'option <option>-nosound</option> quand vous
encodez un fichier avec de l'audio, m<>me si vous voulez encoder puis mixer l'audio
dans un deuxi<78>me temps.
Cela devrait pourtant marcher dans la plupart des cas, mais l'option <option>-nosound</option>
cache certains probl<62>mes dans les r<>glages en ligne de commande.
En d'autres mots, avoir une piste audio pendant l'encodage vous permettra de ne pas
avoir ce type de messages comme <quote>Trop de paquets audio dans la m<>moire tampon
</quote>, et vous aurez ainsi une synchronisation propre.
</para>
<para>
Vous aurez besoin de <application>MEncoder</application> pour traiter le son.
Vous pouvez copier la bande son originale pendant l'encodage avec l'option
<option>-oac copy</option> ou la convertir en un "petit" 4kHz mono WAV PCM
avec l'option <option>-oac pcm -channels 1 -srate 4000</option>.
Autrement, dans certains cas, cela g<>n<EFBFBD>rera un fichier vid<69>o qui ne se synchronisera pas avec l'audio.
Cela arrive quand le nombre de frames vid<69>os dans le fichier source ne correspond
pas exactement <20> la longueur totale des frames audio, ou bien lorsqu'il y a une
discontinuit<69> ou des frames audio en trop ou manquantes. La meilleure
fa<66>on de traiter ces soucis est d'ins<6E>rer un silence ou bien de couper l'audio
<20> ces points.
Cependant, <application>MPlayer</application> ne sait pas faire cela, si vous
avez d<>-multiplex<65> l'AC3, vous pourrez l'encoder avec une application externe
(ou le transformer en PCM avec <application>MPlayer</application>), les superpositions
de son seront mises de cot<6F>, et la seule mani<6E>re de corriger cela au niveau de
la vid<69>o, sera de la couper pendant des erreurs.
Du moment que <application>MEncoder</application> voit l'audio pendant qu'il
encode la vid<69>o, il peut faire ces d<>coupes (ce qui fonctionne habituellement
car elles se produisent lors d'un changement de sc<73>ne avec fondu au noir) mais si
<application>MEncoder</application> ne voit pas l'audio, il encodera toutes les frames telles quelles
et elles ne tiendront pas dans le fichier audio final, quand, par exemple,
vous m<>langerez la piste vid<69>o et sonore dans un fichier Matroska.
</para>
<para>
Dans un premier temps, il faudra convertir le son du DVD en fichier WAV que
le codec audio peut utiliser en entr<74>e.
Par exemple :
<screen>mplayer <replaceable>fichier_source.vob</replaceable> -ao pcm:file=<replaceable>fichier_destination_son.wav</replaceable>
-vc dummy -aid 1 -vo null</screen>
aura pour effet de prendre la seconde piste du fichier <replaceable>source_file.vob</replaceable>
pour la placer dans le fichier <replaceable>destination_sound.wav</replaceable>.
Vous devrez ensuite normaliser le son avec l'encodage, car les pistes
audio des DVDs sont g<>n<EFBFBD>ralement enregistr<74>s avec un volume bas.
Vous pouvez utiliser l'outil <application>normalize</application> qui est
normalement disponible dans toutes les distributions.
Si vous utilisez Windows, un outil comme <application>BeSweet</application>
donnera le m<>me r<>sultat.
Il faudra ensuite l'encoder en Vorbis ou MP3.
Par exemple :
<screen>oggenc -q1 <replaceable>fichier_destination_son.wav</replaceable></screen>
encodera <replaceable>fichier_destination_son.wav</replaceable> avec une qualit<69> de 1,
ce qui est <20>quivalent <20> environ 80Kb/s, soit le strict minimum en terme de qualit<69>.
Notez que <application>MEncoder</application> ne sait pas
encore multiplexer des pistes audio Vorbis car il ne supporte que des conteneurs
en sortie du type AVI ou MPEG, ce qui signifie qu'il y aura des probl<62>mes de
synchronisation lors de la lecture avec quelques lecteurs vid<69>o avec l'AVI
contenant un flux audio VBR en Vorbis.
Soyez sans crainte, ce document vous montrera comment y arriver avec un programme
tiers.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-muxing">
<title>Le multiplexage</title>
<para>
Maintenant que vous avez encod<6F> votre vid<69>o, vous d<>sirez tr<74>s certainement
la multiplexer avec une ou plusieurs pistes audio vers un conteneur comme l'AVI,
le MPEG, le Matroska ou le NUT.
<application>MEncoder</application> ne supporte nativement que des conteneurs
AVI ou MPEG.
Par exemple :
<screen>mencoder -oac copy -ovc copy -o <replaceable>sortie_film.avi</replaceable>
-audiofile <replaceable>entr<EFBFBD>e_audio.mp2</replaceable> <replaceable>entr<EFBFBD>e_video.avi</replaceable></screen>
Cela aura pour effet de fusionner le fichier vid<69>o <replaceable>entr<EFBFBD>e_video.avi</replaceable>
et le fichier audio <replaceable>entr<EFBFBD>e_audio.mp2</replaceable> vers un seul fichier AVI
<replaceable>sortie_film.avi</replaceable>.
Cette commande marche avec le MPEG-1 layer I, II, ou III (plus connu sous le nom
de MP3), WAV et quelques autres formats audio.
</para>
<para>
Une des caract<63>ristiques exp<78>rimentales de <application>MEncoder</application>
est le support de <systemitem class="library">libavformat</systemitem>, <20>tant
une librairie issue du projet FFmpeg, supportant le multiplexage et d<>-multiplexage
vers une grande vari<72>t<EFBFBD> de conteneurs.
Par exemple :
<screen>mencoder -oac copy -ovc copy -o <replaceable>sortie_film.avi</replaceable>
-audiofile <replaceable>entr<EFBFBD>e_audio.mp2</replaceable> <replaceable>entr<EFBFBD>e_video.avi</replaceable>
-of lavf -lavfopts format=asf</screen>
Cela fera strictement la m<>me chose que l'exemple d'avant, mais le conteneur
de sortie sera alors de l'ASF.
Prenez note : ce support est <20> l'<27>tat exp<78>rimental (mais s'am<61>liore de jour en jour),
et ne marchera que si vous compilez <application>MPlayer</application> avec l'option
activ<69>e <systemitem class="library">libavformat</systemitem> (ce qui veut dire que
les binaires en package ne marcheront certainement pas).
</para>
<sect3 id="menc-feat-dvd-mpeg4-muxing-filter-issues">
<title>Am<EFBFBD>lioration de la fiabilit<69> lors du multiplexage A/V</title>
<para>
Vous avez s<>rement pu exp<78>rimenter des probl<62>mes de d<>synchronisation A/V
quand vous multiplexiez des pistes vid<69>os et audio A/V, m<>me en ajustant
le d<>lai de d<>calage du son, il y avait toujours un d<>calage.
Ceci est d<> <20> l'utilisation de filtres qui dupliquent ou ajoutent des images,
comme le filtre t<>l<EFBFBD>cin<69> inverse. Il est vivement conseill<6C> d'utiliser le
filtre vid<69>o <option>harddup</option> <20> la fin des filtres pour <20>viter
ce probl<62>me.
</para>
<para>
Sans l'option <option>harddup</option>, si <application>MEncoder</application>
veut dupliquer une image, il va demander au multiplexeur de mettre en place
une marque sur le conteneur, ainsi la derni<6E>re image sera affich<63>e pour maintenir
la synchronisation sans avoir <20> <20>crire une nouvelle image.
Avec l'option <option>harddup</option>, <application>MEncoder</application>
affichera encore l'image dans le filtre au lieu de pousser la frame pr<70>c<EFBFBD>dente.
Ce qui veut dire que l'encodeur recevra <emphasis>exactement</emphasis> les m<>mes
frames plusieurs fois, puis les compressera.
Cela donnera un fichier l<>g<EFBFBD>rement plus grand, mais cela ne posera plus de
probl<62>mes quand vous d<>-multiplexerez ou multiplexerez vers un autre conteneur.
</para>
<para>
Vous n'aurez pas d'autre choix que d'utiliser <option>harddup</option> avec certains
formats de conteneur peu li<6C>s <20> <application>MEncoder</application> comme ceux
support<72>s par <systemitem class="library">libavformat</systemitem>, qui ne supportent
pas la duplication de frame au niveau du conteneur.
</para>
</sect3>
<sect3 id="menc-feat-dvd-mpeg4-muxing-avi-limitations">
<title>Limitations du conteneur AVI</title>
<para>
Bien que ce soit le format de conteneur le mieux support<72> apr<70>s le MPEG-1, l'AVI a
des inconv<6E>nients majeurs.
Peut-<2D>tre que plus <20>vident est le surco<63>t.
Pour chaque morceau du fichier AVI, 24 octets sont utilis<69>s dans les ent<6E>tes et dans l'index.
Ceci se traduit <20> environ 5Mo par heure, soit <20> peu pr<70>s 1-2,5% de surco<63>t
sur un fichier de 700Mo. Cela peut ne pas sembler <20>tre important, mais c'est ce qui
fait la diff<66>rence dans un fichier qui utilise 700 kbits/sec au lieu de 714 kbits/sec:
pour la qualit<69>, chaque bit compte.
</para>
<para>
En plus de cette grosse inefficacit<69>, l'AVI a aussi d'autres limitations importantes:
</para>
<orderedlist>
<listitem>
<para>
Seuls les contenus <20> fps constants peuvent <20>tre stock<63>s. Ceci est particuli<6C>rement
limitant si vous voulez stocker des fichiers aux contenus h<>t<EFBFBD>rog<6F>nes (par
exemple un m<>lange de vid<69>o NTSC et de films).
En fait, il y a des modifications qui permettent de stocker des contenus <20> fps
variables dans un AVI, mais ils multiplient par au moins 5 la taille des ent<6E>tes (d<>j<EFBFBD> grosses).
</para>
</listitem>
<listitem>
<para>
L'audio dans un fichier AVI doit aussi avoir un d<>bit constant (CBR) ou une
taille de 'frames' constante (par exemple : toutes les frames d<>codent le m<>me
nombre d'<27>chantillons).
Malheureusement, le meilleur codec, Vorbis, ne rentre pas dans ces crit<69>res.
Donc, si vous envisagez de stocker un fichier en AVI, vous devrez utiliser un
codec moins performant comme le MP3 ou l'AC3.
</para>
</listitem>
</orderedlist>
<para>
Ceci dit, <application>MEncoder</application> ne supporte pas actuellement
l'encodage avec des fps variables ou le Vorbis;
Donc vous n'allez pas voir de limitation de <application>MEncoder</application> si vous
n'utilisez que cet outil pour produire vos encodages.
Pourtant, il est possible d'utiliser <application>MEncoder</application> uniquement pour
l'encodage vid<69>o, utiliser des outils externes pour l'encodage de l'audio et
multiplexer le tout vers un conteneur diff<66>rent.
</para>
</sect3>
<sect3 id="menc-feat-dvd-mpeg4-muxing-matroska">
<title>Le multiplexage avec le conteneur Matroska</title>
<para>
Matroska est un conteneur libre, ouvert, qui offre de nombreuses options avanc<6E>es
que, par exemple, l'AVI ne peut pas supporter.
Par exemple, le Matroska supporte le d<>bit vid<69>o variable (VBR), un framerate
variable (VFR), chapitres, attachement de fichiers, code de d<>tection d'erreur
(EDC) et des codecs A/V modernes comme le "Advanced Audio Coding" (AAC), le
"Vorbis" ou le "MPEG-4 AVC" (H.264) et d'autres choses non support<72> par l'AVI.
</para>
<para>
Les outils n<>cessaires <20> la cr<63>ation de fichier Matroska sont appel<65>s <application>mkvtoolnix</application>,
et sont disponibles dans la plupart des syst<73>mes Unix mais aussi sous <application>Windows</application>.
Puisque Matroska est un standard ouvert, vous trouverez s<>rement d'autres outils
qui vous conviendront parfaitement, mais comme mkvtoolnix est le plus connu, et
qu'il est support<72> par Matroska lui m<>me, nous allons parler de son utilisation.
</para>
<para>
La fa<66>on la plus simple assur<75>ment de d<>marrer avec Matroska, est d'utiliser
<application>MMG</application>, une interface graphique livr<76>e avec <application>mkvtoolnix</application>,
et suivre le guide sur <ulink url="http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge-gui.html">l'interface mkvmerge (mmg)</ulink>.
</para>
<para>
Vous pouvez multiplexer des fichiers vid<69>os et audio en utilisant la commande :
<screen>mkvmerge -o <replaceable>sortie.mkv</replaceable> <replaceable>entree_video.avi</replaceable>
<replaceable>entre_son1.mp3</replaceable> <replaceable>entree_son2.ac3</replaceable></screen>
Ceci aura pour effet de multiplexer le fichier vid<69>o <replaceable>entree_video.avi</replaceable>
avec les deux fichiers audio <replaceable>entre_son1.mp3</replaceable> et <replaceable>entree_son2.ac3</replaceable>
dans un fichier Matroska <replaceable>sortie.mkv</replaceable>.
Matroska, comme mentionn<6E> plus t<>t, est capable de faire bien plus, comme plusieurs
pistes audio (avec un r<>glage pr<70>cis de la synchronisation audio/video), chapitres,
sous titres, coupures, etc... Merci de bien vouloir vous reporter <20> la documentation
de cette application pour plus d'informations.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="menc-feat-telecine">
<title>Comment g<>rer le t<>l<EFBFBD>cin<69> et l'entrelacement des DVDs NTSC</title>
<sect2 id="menc-feat-telecine-intro">
<title>Introduction</title>
<formalpara>
<title>Qu'est ce que le t<>l<EFBFBD>cin<69> ?</title>
<para>
Je vous sugg<67>re de visiter la page suivante sous peine de ne rien comprendre
au document suivant :
<ulink url="http://www.divx.com/support/guides/guide.php?gid=10">http://www.divx.com/support/guides/guide.php?gid=10</ulink>
Ce lien pointe vers une documentation relativement compr<70>hensible sur le format
t<>l<EFBFBD>cin<69>.
</para></formalpara>
<formalpara>
<title>Une note <20> propos des chiffres</title>
<para>
Beaucoup de documents, dont le guide propos<6F> ci-dessus, renvoient <20> un
nombre de trames par secondes pour la vid<69>o NTSC de 59.94 ce qui correspond <20>
29.97 images par secondes (pour le t<>l<EFBFBD>cine entrelac<61>) et <20> 23.976 fps pour
le progressive. Pour des raisons de simplicit<69>, certains documents utilisent les
valeurs arrondies de 60, 30 et 24.
</para></formalpara>
<para>
En toute rigueur, ces nombres sont des approximations. Les vid<69>os NTSC en noir et blanc
<20>taient exactement <20> 60 trames par secondes, mais 60000/1001 a <20>t<EFBFBD> choisi par la suite
pour la couleur tout en conservant la compatibilit<69> avec les t<>l<EFBFBD>viseurs noir et blanc.
La vid<69>o num<75>rique NTSC (comme celle d'un DVD) est aussi en 60000/1001 trames
par seconde. A partir de cela, la vid<69>o entrelac<61>e et t<>l<EFBFBD>cin<69>e est d<>riv<69>e vers
30000/1001 images par seconde ou, pour les vid<69>os progressives en 24000/1001
images par secondes.
</para>
<para>
De plus anciennes versions de la documentation <application>MEncoder</application>
et plusieurs e-mails archiv<69>s provenant de liste de diffusion font encore r<>f<EFBFBD>rence <20>
59.94, 29.97, et 23.976.
Toute la documentation de <application>MEncoder</application> a <20>t<EFBFBD> mise <20> jour
pour utiliser les valeurs fractionnelles, et vous devriez aussi les utiliser.
</para>
<para>
<option>-ofps 23.976</option> est incorrect.
<option>-ofps 24000/1001</option> doit <20>tre utilis<69> <20> la place.
</para>
<formalpara>
<title>Comment le t<>l<EFBFBD>cin<69> est-il utilis<69>?</title>
<para>
Toutes les vid<69>os qui sont cens<6E>es <20>tre affich<63>es sur des t<>l<EFBFBD>viseurs NTSC
doivent <20>tre en 60000/1001 trames par secondes. Les t<>l<EFBFBD>films sont souvent
film<6C>s directement <20> 60000/1001 trames par secondes, alors que la majorit<69> des
films pour le cin<69>ma est en 24000/1001 images par seconde. Quand les s<>quences
cin<69>ma pour le DVD sont masteris<69>s, la vid<69>o est alors convertie pour la
t<>l<EFBFBD>vision par un processus appel<65> le t<>l<EFBFBD>cin<69>.
</para></formalpara>
<para>
Sur un DVD, la vid<69>o n'est jamais vraiment stock<63>e <20> 60000/1001 trames par seconde.
Si la vid<69>o est d'origine en 60000/1001, chaque paire de trames est alors combin<69>e
pour former une image, ce qui donne 30000/1001 images par seconde. Les lecteurs de
DVD de salon lisent alors les drapeaux embarqu<71>s sur le flux vid<69>o pour d<>terminer
si la premi<6D>re ligne <20> afficher doit <20>tre paire ou impaire.
</para>
<para>
Normalement, les contenus <20> 24000/1001 images par seconde restent comme cela
lorsqu'ils sont encod<6F>s pour un DVD, et le lecteur DVD doit alors faire
la conversion du t<>l<EFBFBD>cin<69> <20> la vol<6F>e. Parfois, la vid<69>o est t<>l<EFBFBD>cin<69>e <emphasis>avant</emphasis>
d'<27>tre stock<63>e sur le DVD, m<>me si c'<27>tait originalement du 24000/1001 images
par seconde, cela devient 60000/1001 trames par seconde. Quand elles sont stock<63>es
sur le DVD, les trames sont combin<69>es par paires pour former 30000/1001 images
par seconde.
</para>
<para>
Quand on regarde les trames form<72>es individuellement <20> partir de la vid<69>o en
60000/10001 champs par seconde, t<>l<EFBFBD>cin<69> ou autre, l'entrelacement est
clairement visible et ce, qu'il y ait un mouvement ou non car l'un des champs (disons
les lignes impaires) repr<70>sente un moment dans le temps 1/(60000/1001) seconde
plus tard que les autres. Jouer une vid<69>o entrelac<61>e sur un ordinateur semble
dans les deux cas laid parce que l'<27>cran a une r<>solution plus <20>lev<65>e et
parce que la vid<69>o est affich<63>e trame apr<70>s trame <20> au lieu de champs apr<70>s champs.
</para>
<itemizedlist>
<title>Notes :</title>
<listitem><para>
Cette section est seulement destin<69>es aux DVDs NTSC, pas au PAL.
</para></listitem>
<listitem><para>
Les lignes d'exemple de <application>MEncoder</application> pr<70>sent<6E>es dans ce
document ne sont <emphasis role="bold">pas</emphasis> <20> utiliser tel quelles.
Elles sont juste l<> pour montrer le minimum <20> faire en relation avec ce chapitre.
Comment r<>aliser un bon rip DVD ou proc<6F>der <20> des r<>glages avanc<6E>s de
<systemitem class="library">libavcodec</systemitem> dont des questions qui
sortent du contexte de ce guide.
</para></listitem>
<listitem><para>
Quelques notes sp<73>cifiques <20> ce guide sont disponibles dans le pied de page,
et sont li<6C>es comme ceci : <link linkend="menc-feat-telecine-footnotes">[1]</link>
</para></listitem>
</itemizedlist>
</sect2>
<sect2 id="menc-feat-telecine-ident">
<title>Comment trouver le type de votre vid<69>o ?</title>
<sect3 id="menc-feat-telecine-ident-progressive">
<title>Progressive</title>
<para>
Les vid<69>os progressives sont film<6C>es initialement <20> 24000/1001 fps et stock<63>es
sur le DVD telles quelles.
</para>
<para>
Quand vous lisez un DVD progressive dans <application>MPlayer</application>,
il affiche la ligne suivante avant de commencer la lecture :
<screen> demux_mpg: 24000/1001 fps progressive NTSC content detected, switching framerate.</screen>
Dans l'<27>tat actuel des choses, demux_mpg ne devrait jamais <20>tre trouv<75> pour
&quot;une vid<69>o NTSC <20> 30000/1001 fps.&quot;
</para>
<para>
Quand vous regardez une vid<69>o progressive, vous ne devrez voir aucun entrelacement.
Mais soyez attentif, il arrive parfois que du t<>l<EFBFBD>cin<69> se glisse sans pr<70>venir.
Il m'est arriv<69> de tomber sur des <20>missions de t<>l<EFBFBD>visions en DVD avec une
seconde de t<>l<EFBFBD>cin<69> <20> chaque changement de sc<73>ne, voir de temps en temps <20> une
zone totalement al<61>atoire. Une autre fois, la moiti<74> du DVD <20>tait en progressif
et l'autre moiti<74> en t<>l<EFBFBD>cin<69>. Si vous n'<27>tes pas <emphasis>vraiment</emphasis> s<>r,
vous pouvez toujours scanner le film entier :
<screen>mplayer dvd://1 -nosound -vo null -benchmark</screen>
L'utilisation de l'option <option>-benchmark</option> fait lire <application>MPlayer</application>
aussi vite qu'il le peut - en fonction du mat<61>riel, cela peut prendre un certain
temps. Chaque fois que demux_mpg g<>n<EFBFBD>re une ligne, celle-ci vous donnera
imm<6D>diatement la valeur du changement.
</para>
<para>
Parfois, la vid<69>o progressive sur les DVDs consid<69>r<EFBFBD>s comme un &quot;soft-telecine&quot;
car il devrait <20>tre t<>l<EFBFBD>cin<69> par le lecteur DVD.
</para>
</sect3>
<sect3 id="menc-feat-telecine-ident-telecined">
<title>T<EFBFBD>l<EFBFBD>cin<EFBFBD></title>
<para>
Les vid<69>os t<>l<EFBFBD>cin<69>es sont d'abord film<6C>es <20> 24000/1001 et seront t<>l<EFBFBD>cin<69>es
<emphasis>avant</emphasis> d'<27>tre grav<61> sur DVD.
</para>
<para>
<application>MPlayer</application> ne doit (jamais) d<>tecter une changement de fps
quand une vid<69>o t<>l<EFBFBD>cin<69>e est lue.
</para>
<para>
Au visionnage d'une vid<69>o t<>l<EFBFBD>cin<69>e, vous verrez des artefacts d'entrelacement
donnant l'impression de &quot;clignotement&quot;: apparaissant et disparaissant
rapidement.
Vous pouvez le voir plus pr<70>cis<69>ment avec :
<orderedlist>
<listitem>
<screen>mplayer dvd://1</screen>
</listitem>
<listitem><para>
Chercher une partie en mouvement.
</para></listitem>
<listitem><para>
Utiliser la touche <keycap>.</keycap> pour avancer image par image.
</para></listitem>
<listitem><para>
Observer la forme donn<6E>e par l'entrelacement et les images progressives.
Si la forme que vous voyez ressemble <20> PPPII, PPPII, PPPII,... alors la vid<69>o est
t<>l<EFBFBD>cin<69>e. Si ce n'est pas le cas, la vid<69>o a peut-<2D>tre <20>t<EFBFBD> t<>l<EFBFBD>cin<69>e selon des r<>gles
non standard, <application>MEncoder</application> ne sait pas convertir un t<>l<EFBFBD>cin<69>
non-standard vers du progressive sans d<>gradation. Si aucune forme n'est visible, c'est
alors s<>rement une vid<69>o entrelac<61>e.
</para></listitem>
</orderedlist>
</para>
<para>
Parfois, les vid<69>os t<>l<EFBFBD>cin<69>es sur les DVD sont &quot;hard-telecin<69>&quot;. Le hard-telecin<69>
<20>tant <20> 60000/1001 images par seconde, les lecteurs de DVD liront la vid<69>o sans modification.
</para>
<para>
Une autre fa<66>on de savoir si la source est t<>l<EFBFBD>cin<69>e ou non, est de la lire avec
l'option <option>-vf pullup</option> et <option>-v</option> depuis une ligne de commande
et de voir comment l'option <option>pullup</option> voit d'images.
Si la source est t<>l<EFBFBD>cin<69>e, vous devriez voir sur la console une forme 3:2 avec des
alternances de <systemitem>0+.1.+2</systemitem> et <systemitem>0++1</systemitem>.
L'avantage de cette technique et que vous n'avez pas besoin de visionner la
source pour l'identifier, donc utile pour automatiser l'encodage de vid<69>os, ou
bien effectuer ces proc<6F>dures <20> distance m<>me <20> travers une connexion internet lente.
</para>
</sect3>
<sect3 id="menc-feat-telecine-ident-interlaced">
<title>Entrelac<EFBFBD>e</title>
<para>
Les vid<69>os entrelac<61>es sont d'abord film<6C>es en 60000/1001 frames par seconde,
puis stock<63>es sur le DVD <20> 30000/1001 frames par secondes. L'effet d'entrelacement
(souvent appel<65> &quot;combing&quot; = comme les dents d'un peigne) est le r<>sultat d'une combinaison de paires
de trames dans chaque frames. Chaque frame est suppos<6F>e <20>tre cach<63>e 1/(60000/1001)
d'une seconde, quand elles sont affich<63>es en m<>me temps, la diff<66>rence devient
visible.
</para>
<para>
Comme pour la vid<69>o t<>l<EFBFBD>cin<69>e, <application>MPlayer</application> ne devrait
jamais signaler un changement de framerate <20> la lecture de la vid<69>o entrelac<61>e.
</para>
<para>
Si vous regardez une vid<69>o entrelac<61>e de plus pr<70>s, image par image avec la
touche <keycap>.</keycap>, vous pourrez voir l'entrelacement de chaque frame.
</para>
</sect3>
<sect3 id="menc-feat-telecine-ident-mixedpt">
<title>M<EFBFBD>lange de vid<69>o progressive et t<>l<EFBFBD>cin<69>e</title>
<para>
Toutes les vid<69>os qui &quot;m<EFBFBD>langent mode progressif et t<>l<EFBFBD>cin<69>&quot; ont <20>t<EFBFBD> au
d<>part en 24000/1001 frames par seconde, puis certaines parties ont <20>t<EFBFBD> converties en t<>l<EFBFBD>cin<69>.
</para>
<para>
Quand <application>MPlayer</application> joue ce type de fichier, il doit jongler
(souvent rapidement) entre &quot;30000/1001 fps NTSC&quot; et &quot;24000/1001 fps
NTSC progressif&quot;. Regardez la sortie des messages de <application>MPlayer</application>.
</para>
<para>
Vous devriez aller voir la section &quot;30000/1001 fps NTSC&quot; afin d'<27>tre
s<>r que c'est vraiment du t<>l<EFBFBD>cin<69>, et pas seulement de l'entrelac<61>.
</para>
</sect3>
<sect3 id="menc-feat-telecine-ident-mixedpi">
<title>M<EFBFBD>lange de progressif et d'entrelacement</title>
<para>
Dans les vid<69>os qui &quot;m<EFBFBD>langent modes progressif et t<>l<EFBFBD>cin<69>&quot;, les flux vid<69>os
progressifs et entrelac<61>s sont r<>unis ensemble.
</para>
<para>
Cette cat<61>gorie ressemble <20> du &quot;m<EFBFBD>lange progressif et t<>l<EFBFBD>cin<69>&quot; jusqu'<27>
ce que vous examiniez la partie 30000/1001 fps et que vous vous aperceviez
qu'il n'y a pas de trace de t<>l<EFBFBD>cin<69>.
</para>
</sect3>
</sect2>
<sect2 id="menc-feat-telecine-encode">
<title>Comment encoder chaque cat<61>gorie ?</title>
<para>
Comme <20>voqu<71> au d<>part, ces prochaines lignes de &quot;HowTo&quot;
<application>MEncoder</application> ne sont <emphasis role="bold">pas</emphasis> l<> pour <20>tre strictement
utilis<69>es telles quelles, mais pour fournir des param<61>tres minimum d'encodages pour
chaque cat<61>gorie.
</para>
<sect3 id="menc-feat-telecine-encode-progressive">
<title>Le progressif</title>
<para>
La vid<69>o progressive ne n<>cessite pas de filtre particulier pour l'encodage.
Pourtant, un param<61>tre ne doit pas <20>tre omis : <option>-ofps 24000/1001</option>. Sinon,
<application>MEncoder</application> essayera d'encoder <20> 30000/1001 fps et produira des
images en double.
</para>
<para>
<screen>mencoder dvd://1 -oac copy -ovc lavc -ofps 24000/1001</screen>
</para>
<para>
Il n'est pas rare de se trouver avec une vid<69>o qui semble progressive mais qui
contient en fait quelques petites parties en t<>l<EFBFBD>cin<69>. A moins d'<27>tre vraiment
s<>r l'<27>tat de la vid<69>o, il sera pr<70>f<EFBFBD>rable de traiter la vid<69>o comme
<link linkend="menc-feat-telecine-encode-mixedpt"> du progressif et t<>l<EFBFBD>cin<69> m<>lang<6E>s</link>.
La perte de qualit<69> est n<>gligeable <link linkend="menc-feat-telecine-footnotes">[3]</link>.
</para>
</sect3>
<sect3 id="menc-feat-telecine-encode-telecined">
<title>T<EFBFBD>l<EFBFBD>cin<EFBFBD></title>
<para>
Les vid<69>os en t<>l<EFBFBD>cin<69> peuvent redonner le contenu original <20> 24000/1001 avec
un processus appel<65> inverse-t<>l<EFBFBD>cin<69>.
<application>MPlayer</application> a plusieurs filtres disponibles pour ceci,
mais le meilleur, <option>pullup</option>, est abord<72> <20> la section
<link linkend="menc-feat-telecine-encode-mixedpt">m<EFBFBD>lange de progressif et t<>l<EFBFBD>cin<69></link>.
</para>
</sect3>
<sect3 id="menc-feat-telecine-encode-interlaced">
<title>L'entrelac<61></title>
<para>
Pour des raisons pratiques, il n'est pas possible de retrouver enti<74>rement une
vid<69>o progressive depuis une entrelac<61>e. La seule mani<6E>re de faire cela sans
perdre la moiti<74> de la r<>solution verticale est de doubler le framerate et
d'essayer de &quot;trouver&quot; les lignes correspondantes pour chaque frame
(cela a des inconv<6E>nients, voir la m<>thode 3).
</para>
<orderedlist>
<listitem><para>
Encodez la vid<69>o sous une forme entrelac<61>e. Normalement, l'entrelacement
d<>t<EFBFBD>riore la capacit<69> de l'encodeur <20> bien compresser, mais <systemitem class="library">libavcodec</systemitem>
poss<73>de deux param<61>tres sp<73>cifiquement faits pour stocker la vid<69>o entrelac<61>e de mani<6E>re
plus satisfaisante: <option> ildct</option> et <option>ilme</option>. Aussi,
l'utilisation de <option>mbd=2</option> est-elle fortement recommand<6E>e <link linkend="menc-feat-telecine-footnotes">[2] </link>
car cela encodera les macroblocs non-entrelac<61>s <20> des endroits o<> il n'y
a pas de mouvements. Notez que <option>-ofps</option> n'est <emphasis>pas</emphasis> n<>cessaire ici.
<screen>mencoder dvd://1 -oac copy -ovc lavc -lavcopts ildct:ilme:mbd=2</screen>
</para></listitem>
<listitem><para>
Utilisez un filtre de d<>s-entrelacement avant l'encodage. Il y a plusieurs de
ces filtres disponibles aux choix, chacun avec ces propres avantages et
d<>savantages. Consultez <option>mplayer -pphelp</option> pour voir quels sont
ceux disponibles (grep pour &quot;deint&quot;), et cherchez les
<ulink url="http://www.mplayerhq.hu/homepage/design6/info.html#mailing_lists">
listes de diffusion MPlayer</ulink> pour trouver plusieurs discussions sur les
diff<66>rents filtres. Encore une fois, le framerate ne change pas, donc pas de
<option>-ofps</option>. Aussi, le d<>s-entrelacement devra <20>tre fait apr<70>s
d<>coupage <link linkend="menc-feat-telecine-footnotes">[1]</link> et
avant dimensionnement.
<screen>mencoder dvd://1 -oac copy -vf pp=lb -ovc lavc</screen>
</para></listitem>
<listitem><para>
Malheureusement, cette option est un bogu<67>e dans
<application>MEncoder</application> : cela devrait bien marcher avec
<application>MEncoder G2</application>, mais on n'en est pas encore l<>. Vous
risquez d'avoir des plantages. Cela importe peu car le but de <option> -vf tfields</option>
est de cr<63>er une frame compl<70>te <20> partir de chaque champs, ce qui
donne le framerate 60000/1001. L'avantage de cette approche est qu'aucune
donn<6E>e n'est jamais perdue. Cependant, vu que chaque frame vient avec seulement
un champ, les lignes manquantes doivent <20>tre interpol<6F>es d'une fa<66>on ou d'une autre.
Il n'y a pas de tr<74>s bonne m<>thode g<>n<EFBFBD>rant les donn<6E>es manquantes, et donc le
r<>sultat sera un peu similaire <20> celui obtenu quand on utilise certains filtres de d<>s-entrelacement.
G<>n<EFBFBD>rer les lignes manquantes cr<63>e aussi d'autres probl<62>mes,
simplement parce que la quantit<69> de donn<6E>es double. Ainsi, de plus haut bitrates
d'encodage sont n<>cessaires pour conserver la qualit<69>, et plus de puissance CPU est
utilis<69>e pour l'encodage et le d<>codage. 'tfields' a plusieurs
options pour g<>rer la cr<63>ation des lignes manquantes de chaque frame. Si vous
utilisez cette m<>thode, alors regardez le manuel, et prenez n'importe quelle
option qui semble la meilleure pour votre mat<61>riel. Notez que lors de l'utilisation de
<option>tfields</option> vous
<emphasis role="bold">devez</emphasis> sp<73>cifier les deux options <option>-fps</option>
et <option>-ofps</option> <20> deux fois le framerate de votre source originale.
<screen>mencoder dvd://1 -oac copy -vf tfields=2 -ovc lavc -fps 60000/1001 -ofps 60000/1001</screen>
</para></listitem>
<listitem><para>
Si vous avez d<>cid<69> de r<>duire la taille de fa<66>on dramatique, vous pouvez
extraire et encoder seulement un des deux champs. Bien s<>r, vous perdrez la
moiti<74> de la r<>solution verticale, mais si vous pensez la r<>duire au plus de
moiti<74> par rapport <20> l'original, la perte ne sera pas trop grande. Le r<>sultat
sera un fichier progressif <20> 30000/1001 frames par seconde. La proc<6F>dure est
d'utiliser <option>-vf field</option>, puis de d<>couper
<link linkend="menc-feat-telecine-footnotes">[1]</link> et de dimensionner
de mani<6E>re appropri<72>e. Souvenez-vous que vous devrez ajuster la dimension pour
compenser la r<>solution verticale ayant <20>t<EFBFBD> r<>duite de moiti<74>.
<screen>mencoder dvd://1 -oac copy -vf field=0 -ovc lavc</screen>
</para></listitem>
</orderedlist>
</sect3>
<sect3 id="menc-feat-telecine-encode-mixedpt">
<title>Progressif et t<>l<EFBFBD>cin<69> m<>lang<6E></title>
<para>
Afin de convertir une vid<69>o compos<6F>e de progressive et de t<>l<EFBFBD>cin<69> en vid<69>o enti<74>rement
progressive, les parties en t<>l<EFBFBD>cin<69> doivent <20>tre inverse-t<>l<EFBFBD>cin<69>es. Il y a trois
moyens d'accomplir cela, comme d<>crit ci-dessous. Notez que vous devrez
<emphasis role="bold">toujours</emphasis> inverse-t<>l<EFBFBD>cin<69> avant tout
redimensionnement. Sauf si vous savez vraiment ce que vous faites, il faudra
inverse-t<>l<EFBFBD>cin<69> avant tout d<>coupage <link linkend="menc-feat-telecine-footnotes">[1]</link>.
<option>-ofps 24000/1001</option> est n<>cessaire ici parce que la sortie vid<69>o
sera de 24000/1001 frames par seconde.
</para>
<itemizedlist>
<listitem><para>
<option>-vf pullup</option> est faite pour inverse-t<>l<EFBFBD>cin<69> le mat<61>riel
t<>l<EFBFBD>cin<69> tandis que les donn<6E>es progressives sont laiss<73>es intactes. Afin
de bien fonctionner, <option>pullup</option> <emphasis role="bold">doit</emphasis>
<20>tre suivi par le filtre <option>softskip</option> ou sinon <application>MEncoder</application> plantera.
<option>pullup</option> est, cependant, la m<>thode la plus propre et la plus pr<70>cise
disponible pour encoder le t<>l<EFBFBD>cin<69> et le &quot;progressif et t<>l<EFBFBD>cin<69> m<>lang<6E>s&quot;.
<screen>mencoder dvd://1 -oac copy -vf pullup,softskip -ovc lavc -ofps 24000/1001</screen>
</para>
</listitem>
<listitem><para>
Une m<>thode plus ancienne consiste <20> t<>l<EFBFBD>ciner les parties non-t<>l<EFBFBD>cin<69>es
et ensuite inverse-t<>l<EFBFBD>ciner la vid<69>o tout enti<74>re, au lieu de
n'inverse-t<>l<EFBFBD>ciner que les parties en t<>l<EFBFBD>cin<69>.
Cela semble confus? softpulldown est un filtre qui parcours une vid<69>o
et rend t<>l<EFBFBD>cin<69> le fichier entier. Si nous faisons suivre softpulldown avec
soit <option>detc</option> ou soit <option>ivtc</option>, le r<>sultat final
sera enti<74>rement progressif. <option>-ofps 24000/1001</option> est n<>cessaire.
<screen>mencoder dvd://1 -oac copy -vf softpulldown,ivtc=1 -ovc lavc -ofps 24000/1001</screen>
</para>
</listitem>
<listitem><para>
Je n'ai pas moi-m<>me utilis<69> <option>-vf filmdint</option>, mais voil<69> ce que
D Richard Felker III en dit:
<blockquote><para>Il est correct, mais AMA il essaie de d<>s-entrelacer plut<75>t
que de faire l'inverse-t<>l<EFBFBD>cin<69> trop souvent (tout comme les lecteurs DVD de salon
&amp; les TVs progressive) ce qui donne des clignotements affreux et d'autre
artefacts. Si vous penser l'employer, vous devez commencer par passer un peu de temps
pour affiner les options et observer la sortie pour <20>tre s<>r que cela
casse pas tout.</para></blockquote>
</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="menc-feat-telecine-encode-mixedpi">
<title>Progressif et entrelac<61> m<>lang<6E>s</title>
<para>
Il y a deux options pour s'occuper de cette cat<61>gorie, chacune <20>tant un
compromis. Vous devez prendre une d<>cision bas<61>e sur la dur<75>e/localisation
de chaque type.
</para>
<itemizedlist>
<listitem><para>
Traitez-la comme progressive. Les parties entrelac<61>es sembleront entrelac<61>es,
et certains des champs entrelac<61>s devront <20>tre jet<65>s, ayant pour r<>sultat un
peu de sautillement in<69>gal. Vous pouvez utiliser un filtre post-traitement si
vous le voulez, mais cela peut sensiblement d<>grader les parties progressives.
</para>
<para>
Cette option ne devrait vraiment pas <20>tre utilis<69>e si vous voulez
<20>ventuellement afficher la vid<69>o sur un appareil entrelac<61> (avec une carte TV,
par exemple). Si vous avez entrelac<61> les frames dans une vid<69>o <20> 24000/1001
frames par seconde, ils seront t<>l<EFBFBD>cin<69>s en m<>me temps que les frames progressive.
La moiti<74> des "frames" entrelac<61>es sera affich<63>e pour une dur<75>e de trois champs
(3/(60000/1001) secondes), ce qui a pour r<>sultat un effet pichenette de
&quot;retour en arri<72>re&quot; ce qui semble tout <20> fait mauvais. Si vous tentez
quand m<>me ceci, vous <emphasis role="bold">devez</emphasis> utiliser un filtre
d<>s-entrela<6C>ant comme <option>lb</option> ou <option>l5</option>.
</para>
<para>
Cela peut tout aussi bien <20>tre une mauvaise id<69>e pour l'affichage progressive.
Cela laissera tomber les paires cons<6E>cutives de champs entrelac<61>s, ayant pour
r<>sultat une discontinuit<69> qui peut <20>tre plus visible qu'avec la seconde m<>thode,
ce qui montre certaines frames progressive en double. Une vid<69>o entrelac<61>e <20>
30000/1001 frames par seconde est d<>j<EFBFBD> un peu variable parce que cela devrait
vraiment <20>tre montr<74> <20> 60000/1001 champs par seconde, donc les frames dupliqu<71>es
ne tiennent pas.
</para>
<para>
Qu'importe la fa<66>on, il est recommand<6E> de consid<69>rer votre contenu et comment
vous voulez l'afficher. Si votre vid<69>o est <20> 90% progressive et que vous ne
pensez pas la regarder sur une TV, vous devriez favoriser une approche progressive.
Si elle est seulement <20> moiti<74> progressive, vous voudrez probablement l'encoder
comme si elle <20>tait enti<74>rement entrelac<61>e.
</para>
</listitem>
<listitem><para>
Traitez-la comme entrelac<61>e. Certaines frames des parties progressive auront
besoin d'<27>tre dupliqu<71>es, ce qui entra<72>nera en un sautillement in<69>gal. Encore une
fois, les filtres d<>s-entrela<6C>ant peuvent passablement d<>grader les parties
progressives.
</para></listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2 id="menc-feat-telecine-footnotes">
<title>Notes de pied</title>
<orderedlist>
<listitem><formalpara>
<title>A propos de d<>coupage:</title>
<para>
Les donn<6E>es vid<69>o d'un DVD sont stock<63>es dans un format appel<65> YUV 4:2:0. Dans
la vid<69>o YUV, la luma (&quot;luminosit<EFBFBD>&quot;) et le chroma (&quot;couleur&quot;)
sont stock<63>s s<>par<61>ment. Parce que l'oeil humain est somme toute moins sensible
<20> la couleur qu'il ne l'est <20> la luminosit<69>, dans une image YUV 4:2:0 il y a
seulement un pixel de chroma pour 4 pixels de luma. Dans une image progressive,
chaque carr<72> de quatre pixels de luma (deux sur chaque cot<6F>) ont un pixel de
chroma commun. Vous devez d<>couper un YUV 4:2:0 progressif <20> des r<>solutions paires,
et utiliser un d<>calage pair. Par exemple,
<option>crop=716:380:2:26</option> est correct mais
<option>crop=716:380:3:26 </option> ne l'est pas.
</para>
</formalpara>
<para>
Quand vous avez <20> faire <20> un YUV 4:2:0 entrelac<61>, la situation devient un peu plus
compliqu<71>e. Au lieu que chaque s<>rie de quatre pixels de luma partage un pixel
de chroma dans une <emphasis>frame</emphasis>, chaque groupe de quatre pixels de luma
dans chaque <emphasis>champs</emphasis> partage un pixel de chroma. Quand les
champs sont entrelac<61>s pour former une frame, chaque ligne de scan est un
pixel de haut. Maintenant, au lieu que tout les quatre pixels de luma soient
dans un carr<72>, ils sont deux pixels c<>te <20> c<>te, et les deux autres pixels
sont c<>te <20> c<>te deux lignes de scan plus bas. Les deux pixels de luma dans la
ligne de scan interm<72>diaire sont <20> partir de l'autre champ, et donc partage un
pixel de chroma diff<66>rent avec deux pixels de luma deux lignes de scan plus loin.
Toute cette confusion rend n<>cessaire d'avoir des dimensions de d<>coupe verticales
et des d<>calages en multiple de quatre. Le d<>calage horizontal peut rester <20>gal.
</para>
<para>
Pour la vid<69>o t<>l<EFBFBD>cin<69>e, je recommande que le d<>coupage prenne place apr<70>s l'inverse
t<>l<EFBFBD>cin<69>. Une fois la vid<69>o progressive vous avez seulement besoin de d<>couper par
nombres pairs. Si vous voulez vraiment gagner la l<>g<EFBFBD>re acc<63>l<EFBFBD>ration que la d<>coupe
peut offrir, vous devez d<>couper verticalement par multiples de quatre
ou bien le filtre inverse-t<>l<EFBFBD>cin<69> n'aura pas les bonnes donn<6E>es.
</para>
<para>
Pour la vid<69>o entrelac<61>e (pas t<>l<EFBFBD>cin<69>e), vous devez toujours d<>couper verticalement
par multiples de quatre <20> moins que vous n'utilisiez <option>-vf field</option> avant de d<>couper.
</para>
</listitem>
<listitem><formalpara>
<title>A propos des param<61>tres d'encodage et de la qualit<69>:</title>
<para>
Juste parce que je recommande <option>mbd=2</option> ici ne veut pas dire
que cela ne devrait pas <20>tre utilis<69> autre part. Avec <option>trell</option>,
<option>mbd=2</option> est l'une des deux options de <systemitem class="library">libavcodec</systemitem>
qui augmente le mieux la qualit<69>, et vous devriez toujours utiliser au moins
une des deux <20> moins que la baisse de vitesse d'encodage ne soit prohibitive
(e.g. encodage temps r<>el). Il y a plusieurs autres options <systemitem class="library">libavcodec</systemitem>
qui augmentent la qualit<69> d'encodage (et r<>duisent la vitesse d'encodage) mais ceci est au del<65>
de la port<72>e de ce document.
</para>
</formalpara>
</listitem>
<listitem><formalpara>
<title>A propos de la performance de pullup:</title>
<para>
Employer <option>pullup</option> (avec <option>softskip</option>)
sur une vid<69>o progressive est s<>r, et est habituellement une bonne id<69>e <20> moins qu'il
ait <20>t<EFBFBD> v<>rifi<66> que la source est enti<74>rement progressive.
La perte de performance est petite pour la plupart des cas. Sur un encodage minimal,
<option>pullup</option> ralentit <application>MEncoder</application> de 50%.
L'ajout du traitement du son et d'options avanc<6E>es pour <option>lavcopts</option> masquent cette
diff<66>rence, en limitant la perte de performance due <20> l'utilisation de <option>pullup</option> <20> 2%.
</para>
</formalpara>
</listitem>
</orderedlist>
</sect2>
</sect1>
<sect1 id="menc-feat-enc-libavcodec">
<title>Encodage avec la famille de codec <systemitem class="library">libavcodec</systemitem></title>
<para>
<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link>
fournit un encodage simple pour plusieurs formats vid<69>os et audio int<6E>ressants.
Vous pouvez encoder vers les codecs suivant (la liste suivante est plus ou moins <20> jour):
</para>
<sect2 id="menc-feat-enc-libavcodec-video-codecs">
<title>codecs vid<69>o de <systemitem class="library">libavcodec</systemitem></title>
<para>
<informaltable frame="all">
<tgroup cols="2">
<thead>
<row><entry>Nom du codec vid<69>o</entry><entry>Description</entry></row>
</thead>
<tbody>
<row><entry>mjpeg</entry><entry>
Motion JPEG
</entry></row>
<row><entry>ljpeg</entry><entry>
JPEG sans perte
</entry></row>
<row><entry>h261</entry><entry>
H.261
</entry></row>
<row><entry>h263</entry><entry>
H.263
</entry></row>
<row><entry>h263p</entry><entry>
H.263+
</entry></row>
<row><entry>mpeg4</entry><entry>
ISO standard MPEG-4 (DivX 5, compatible XviD)
</entry></row>
<row><entry>msmpeg4</entry><entry>
pre-standard MPEG-4 variant par MS, v3 (AKA DivX3)
</entry></row>
<row><entry>msmpeg4v2</entry><entry>
pre-standard MPEG-4 by MS, v2 (utilis<69> dans les vieux fichiers ASF)
</entry></row>
<row><entry>wmv1</entry><entry>
Windows Media Vid<69>o, version 1 (AKA WMV7)
</entry></row>
<row><entry>wmv2</entry><entry>
Windows Media Vid<69>o, version 2 (AKA WMV8)
</entry></row>
<row><entry>rv10</entry><entry>
RealVid<69>o 1.0
</entry></row>
<row><entry>rv20</entry><entry>
RealVid<69>o 2.0
</entry></row>
<row><entry>mpeg1vid<EFBFBD>o</entry><entry>
MPEG-1 vid<69>o
</entry></row>
<row><entry>mpeg2vid<EFBFBD>o</entry><entry>
MPEG-2 vid<69>o
</entry></row>
<row><entry>huffyuv</entry><entry>
compression sans perte
</entry></row>
<row><entry>asv1</entry><entry>
ASUS Vid<69>o v1
</entry></row>
<row><entry>asv2</entry><entry>
ASUS Vid<69>o v2
</entry></row>
<row><entry>ffv1</entry><entry>
codec vid<69>o sans perte de FFmpeg
</entry></row>
<row><entry>svq1</entry><entry>
Sorenson vid<69>o 1
</entry></row>
<row><entry>flv</entry><entry>
Sorenson H.263 utilis<69> dans Vid<69>o Flash
</entry></row>
<row><entry>dvvideo</entry><entry>
Vid<69>o Num<75>rique Sony
</entry></row>
<row><entry>snow</entry><entry>
codec bas<61> sur l'ondelette exp<78>rimentale de FFmpeg
</entry></row>
</tbody>
</tgroup>
</informaltable>
La premi<6D>re colonne contient les noms de codec qui doivent <20>tre pass<73>s apr<70>s la
configuration de <literal>vcodec</literal>, comme ceci: <option>-lavcopts vcodec=msmpeg4</option>
</para>
<informalexample>
<para>
Un exemple avec la compression MJPEG:
<screen>mencoder dvd://2 -o title2.avi -ovc lavc -lavcopts vcodec=mjpeg -oac copy</screen>
</para>
</informalexample>
</sect2>
<sect2 id="menc-feat-enc-libavcodec-audio-codecs">
<title>Codecs audio de <systemitem class="library">libavcodec</systemitem>=</title>
<para>
<informaltable frame="all">
<tgroup cols="2">
<thead>
<row><entry>Nom de codec audio</entry><entry>Description</entry></row>
</thead>
<tbody>
<row>
<entry>mp2</entry>
<entry>MPEG Layer 2</entry>
</row>
<row>
<entry>ac3</entry>
<entry>AC3, AKA Dolby Digital</entry>
</row>
<row>
<entry>adpcm_ima_wav</entry>
<entry>IMA adaptatif PCM (4 bits par <20>chantillon, compression 4:1)</entry>
</row>
<row>
<entry>sonic</entry>
<entry>codec avec/sans perte exp<78>rimental</entry>
</row>
</tbody>
</tgroup>
</informaltable>
La premi<6D>re colonne contient les noms du codec qui devra <20>tre pass<73>e apr<70>s l'option
<literal>acodec</literal>, comme ceci: <option>-lavcopts acodec=ac3</option>
</para>
<informalexample>
<para>
Un exemple avec compression AC3:
<screen>mencoder dvd://2 -o title2.avi -oac lavc -lavcopts acodec=ac3 -ovc copy</screen>
</para>
</informalexample>
<para>
Contrairement aux codecs vid<69>o de <systemitem class="library">libavcodec</systemitem>,
ces codecs audio ne font pas un usage intelligents des bits qu'on leur donne
vu qu'ils ont des mod<6F>les psycho-accoustiques minimaux (quand ils en ont)
ce que la plupart des autres impl<70>mentations de codec comportent.
Cependant, notez que tous ces codecs audio sont tr<74>s rapides et fonctionnent qu'importe
leur environnement <20> partir du moment o<> <application>MEncoder</application> a <20>t<EFBFBD>
compil<69>e avec <systemitem class="library">libavcodec</systemitem> (ce qui est le
cas la plupart du temps), et ne d<>pend pas de biblioth<74>ques externes.
</para>
</sect2>
<sect2 id="menc-feat-dvd-mpeg4-lavc-encoding-options">
<title>Options d'encodage de libavcodec</title>
<para>
Id<49>alement, vous voudriez probablement juste dire <20> mencoder de passer en
mode "haute qualit<69>" et passer <20> autre chose.
Ce serait s<>rement sympa, mais c'est malheureusement dur <20> faire vu que les
diff<66>rentes options d'encodage donnent diff<66>rents r<>sultats de qualit<69>
en fonction du mat<61>riel source.
Ceci vient du fait que la compression d<>pende des propri<72>t<EFBFBD>s visuelles
de la vid<69>o en question.
Par exemple, un film d'animation et un film d'action ont des propri<72>t<EFBFBD>s tr<74>s
diff<66>rentes et n<>cessitent des options diff<66>rentes pour obtenir un encodage
optimal.
La bonne nouvelle, c'est que certaines options ne devraient jamais <20>tre mise <20>
part, comme <option>mbd=2</option>, <option>trell</option>, et <option>v4mv</option>.
Voir ci-dessous pour une description d<>taill<6C>e des options d'encodage communes.
</para>
<itemizedlist>
<title>Options <20> r<>gler:</title>
<listitem><para>
<emphasis role="bold">vmax_b_frames</emphasis>: 1 ou 2 est bon selon
le film.
Notez que si vous avez besoin d'avoir votre encodeur d<>codable par DivX5, vous
aurez besoin d'activer le support closed GOP, en utilisant l'option <option>cgop</option> de
<systemitem class="library">libavcodec</systemitem>, mais vous aurez besoin de d<>sactiver
la d<>tection de sc<73>ne, ce qui n'est pas une bonne id<69>e <20>tant donn<6E> que cela
affectera un peu l'efficacit<69> d'encodage.
</para></listitem>
<listitem><para>
<emphasis role="bold">vb_strategy=1</emphasis>: aide aux sc<73>nes avec de rapides
mouvements.
Sur certaines vid<69>os, vmax_b_frames peut affecter la qualit<69>, mais
vmax_b_frames=2 avec vb_strategy=1 aideront.
</para></listitem>
<listitem><para>
<emphasis role="bold">dia</emphasis>: port<72>e de recherche de mouvement. Le plus large
est l'<27>cart; ce sera mieux, mais aussi plus lent.
Des valeurs n<>gatives sont une <20>chelle compl<70>tement diff<66>rente.
De bonnes valeurs sont -1 pour un encodage rapide, ou 2-4 pour un plus lent.
</para></listitem>
<listitem><para>
<emphasis role="bold">predia</emphasis>: pr<70>-passe de recherche de mouvement.
Pas aussi important que dia. De bonnes valeurs sont 1 (par d<>faut) <20> 4. Cela
demande preme=2 pour <20>tre vraiment utile.
</para></listitem>
<listitem><para>
<emphasis role="bold">cmp, subcmp, precmp</emphasis>: Fonction de comparaison
pour l'estimation de mouvement.
Testez avec des valeurs de 0 (d<>faut), 2 (hadamard), 3 (dct), et 6 (taux de
distorsion).
0 est le plus rapide, et suffisant pour precmp.
Pour cmp et subcmp, 2 est bon pour les animations, et 3 est bon pour les
actions en direct.
6 peut-<2D>tre ou non un peu mieux, mais c'est lent.
</para></listitem>
<listitem><para>
<emphasis role="bold">last_pred</emphasis>: Nombre de pr<70>dicateurs de mouvement
<20> prendre depuis la frame pr<70>c<EFBFBD>dente.
1-3 (ou dans ces eaux) am<61>liore la vitesse de l'encodage quasiment sans contrepartie.
De plus hautes valeurs ralentiront sans avoir de gain r<>el.
</para></listitem>
<listitem><para>
<emphasis role="bold">cbp, mv0</emphasis>: Contr<74>le la s<>lection de macroblocs.
Un petit co<63>t en vitesse pour un petit gain en qualit<69>.
</para></listitem>
<listitem><para>
<emphasis role="bold">qprd</emphasis>: quantification adaptative bas<61>e sur la
complexit<69> du macrobloc.
Peut aider ou aggraver la situation ceci d<>pend de la vid<69>o et des autres options.
Cela peut causer des artefacts <20> moins que vous ne param<61>triez vqmax <20> certaines
valeurs raisonnablement petites (6 c'est bien, voire peut-<2D>tre 4);
vqmin=1 devrait aussi aider.
</para></listitem>
<listitem><para>
<emphasis role="bold">qns</emphasis>: tr<74>s lente, sp<73>cialement quand combin<69>e
avec qprd.
Cette option dira l'encodeur <20> minimiser le bruit d<> <20> la compression
d'artefact au lieu de faire strictement ressembler la vid<69>o encod<6F>e <20> la
source.
N'utilisez pas ceci <20> moins d'avoir d<>j<EFBFBD> bidouill<6C> tout ce qui est possible
et que les r<>sultats ne sont pas encore assez bons.
</para></listitem>
<listitem><para>
<emphasis role="bold">vqcomp</emphasis>: Bidouille du contr<74>le de taux.
Quelles sont les bonnes valeurs qui d<>pendent du film?
Vous pouvez de mani<6E>re s<>re laisser cela de c<>t<EFBFBD> si vous voulez.
R<>duire vqcomp met plus de bits sur les sc<73>nes de basse complexit<69>, l'augmenter
les met sur les sc<73>nes de haute complexit<69> (d<>faut: 0.5, port<72>e: 0-1. port<72>e
recommand<6E>e: 0.5-0.7).
</para></listitem>
<listitem><para>
<emphasis role="bold">vlelim, vcelim</emphasis>: Param<61>tre le seuil du seul
coefficient d'<27>limination pour les plans de luminance et de chroma.
Ceux-l<> sont encod<6F>s s<>par<61>ment dans tous les algorithmes de style MPEG.
L'id<69>e derri<72>re tout ceci est d'utiliser certaines bonnes heuristiques
pour d<>terminer quand le changement dans un bloc est inf<6E>rieur au seuil que
vous avez sp<73>cifi<66>, et dans ce cas, de simplement encoder le bloc comme <20>tant
"sans changement".
Cela <20>conomisera des bits et acc<63>l<EFBFBD>rera peut-<2D>tre l'encodage. vlelim=-4 et
vcelim=9 semblent <20>tre de bonnes valeurs pour les films en direct, mais
semblent ne pas aider avec les animations; quand vous voudrez encoder une animation,
vous devrez probablement les laisser inchang<6E>s.
</para></listitem>
<listitem><para>
<emphasis role="bold">qpel</emphasis>: Estimation de mouvement de quart de pixel.
MPEG-4 utilise la pr<70>cision de moiti<74> de pixel pour sa recherche de mouvement
par d<>faut, donc cette option vient avec un surplus car plus d'information seront
stock<63>es dans le fichier encod<6F>.
La compression gain/perte d<>pend du film, mais n'est habituellement pas tr<74>s
efficace sur les animations.
qpel induit toujours un surco<63>t significatif dans le temps de d<>codage du CPU
(+25% en pratique).
</para></listitem>
<listitem><para>
<emphasis role="bold">psnr</emphasis>: n'affecte pas l'encodage courant,
mais <20>crit un fichier journal donnant le type/taille/qualit<69> de chaque frame, et
imprime un r<>sum<75> du PSNR (rapport maximal du signal sur le bruit) <20> la fin.
</para></listitem>
</itemizedlist>
<itemizedlist>
<title>Options <20> <20>viter:</title>
<listitem><para>
<emphasis role="bold">vme</emphasis>: La valeur par d<>faut est la mieux.
</para></listitem>
<listitem><para>
<emphasis role="bold">lumi_mask, dark_mask</emphasis>: Quantification adaptative
pyscho-visuelle.
Vous ne voulez pas jouer avec ces options si vous tenez <20> la qualit<69>.
Des valeurs raisonnables peuvent <20>tre efficaces dans votre cas, mais soyez pr<70>venu
que ceci reste tr<74>s subjectif.
</para></listitem>
<listitem><para>
<emphasis role="bold">scplx_mask</emphasis>: Essaie d'<27>viter l'apparition d'artefacts
carr<72>s, mais le post-traitement est le mieux.
</para></listitem>
</itemizedlist>
</sect2>
<sect2 id="menc-feat-mpeg4-lavc-example-settings">
<title>Exemples de param<61>tres d'encodage</title>
<para>
Les param<61>tres suivant sont des exemples de combinaisons d'option de diff<66>rents
encodages qui affectent la vitesse et la qualit<69> pour un bitrate donn<6E>.
</para>
<para>
Tous les param<61>tres d'encodage sont test<73>s sur un <20>chantillon de vid<69>o de
720x448 @30000/1001 fps, le bitrate cible <20>tait 900kbps, et la machine <20>tait un
AMD-64 3400+ <20> 2400 Mhz en mode 64 bits.
Chaque param<61>tre d'encodage comporte la mesure de vitesse d'encodage (en
frames par seconde) et la perte PSNR (en dB) compar<61> au param<61>tre de "tr<74>s
haute qualit<69>".
Sachez que selon votre source, votre machine et les derniers d<>veloppements,
vous pourrez obtenir des r<>sultats tr<74>s diff<66>rents.
</para>
<para>
<informaltable frame="all">
<tgroup cols="4">
<thead>
<row><entry>Description</entry><entry>Options d'encodage</entry><entry>vitesse (en fps)</entry><entry>perte PSNR relative (en dB)</entry></row>
</thead>
<tbody>
<row>
<entry>Tr<EFBFBD>s haute qualit<69></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>Haute qualit<69></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>Rapide</entry>
<entry><option>vcodec=mpeg4:mbd=2:trell:v4mv:turbo</option></entry>
<entry>42fps</entry>
<entry>-0.74dB</entry>
</row>
<row>
<entry>Temps r<>el</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>Matrices inter/intra personnalis<69>es</title>
<para>
Avec cette fonctionnalit<69> de
<link linkend="ffmpeg"><systemitem class="library">libavcodec</systemitem></link>
vous pouvez rentrer des matrices personnalis<69>es inter (I-frames/frames cl<63>) et intra
(P-frames/frames pr<70>vu). La plupart des codecs supporte ceci - on rapporte que
<systemitem>mpeg1video</systemitem> et <systemitem>mpeg2video</systemitem> fonctionnent avec.
</para>
<para>
Cette fonctionnalit<69> est utilis<69>e habituellement pour r<>gler les matrices utilis<69>es
par les sp<73>cifications <ulink url="http://www.kvcd.net/">KVCD</ulink>.
</para>
<para>
La <emphasis role="bold">Matrice de Quantification KVCD &quot;Notch&quot; :</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>
Utilisation:
<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>Exemple</title>
<para>
Voil<69>, vous venez tout juste d'acheter votre exemplaire de 'Harry Potter et la
Chambre des Secrets' (<28>dition <20>cran large, bien s<>r), et vous voulez ripper ce
DVD ceci afin de pouvoir l'ajouter <20> votre PC Home Cin<69>ma. C'est un DVD de
r<>gion 1, donc en NTSC. L'exemple ci-dessous peut quand m<>me <20>tre adapt<70> au PAL,
si ce n'est que vous devrez retirer <option>-ofps 24000/1001</option> (parce que le
framerate de sortie est le m<>me que celui en entr<74>e), et bien s<>r les dimensions
de d<>coupage seront diff<66>rentes.
</para>
<para>
Apr<70>s avoir lanc<6E> <option>mplayer dvd://1</option>, nous suivons le processus
d<>taill<6C> dans la section <link linkend="menc-feat-telecine">Comment traiter le
t<>l<EFBFBD>cin<69> et l'entrelacement dans les DVDs NTSC</link> et d<>couvrir que c'est une
vid<69>o progressive en 24000/1001 fps, ce qui signifie que nous n'aurons pas besoin
d'utiliser un filtre inverse t<>l<EFBFBD>cin<69>, comme <option>pullup</option> ou <option>filmdint</option>.
</para>
<para>
Ensuite, nous voulons d<>terminer le rectangle de recadrage appropri<72>, donc
nous utilisons le filtre cropdetect:
<screen>mplayer dvd://1 -vf cropdetect</screen>
Cherchez une frame compl<70>tement remplie (comme une sc<73>ne
lumineuse), et vous verrez dans la console de sortie de <application>MPlayer</application>:
<screen>crop area: X: 0..719 Y: 57..419 (-vf crop=720:362:0:58)</screen>
Rejouons ensuite le film avec le filtre pour tester le r<>sultat:
<screen>mplayer dvd://1 -vf crop=720:362:0:58</screen>
Et nous nous apercevons que tout est parfait. Ensuite, nous nous assurons que
la hauteur et la largeur sont des multiples de 16. La largeur est bonne,
cependant la hauteur ne l'est pas. Vu que nous avons quelques notions minimales
de maths, nous savons que le plus proche multiple de 16 inf<6E>rieur <20> 362
est 352.
</para>
<para>
Nous pourrions juste utiliser <option>crop=720:352:0:58</option>, mais il
serait mieux d'enlever un peu du haut et un peu du bas afin de garder
le centre. Nous avons r<>tr<74>ci la hauteur de 10 pixels, mais nous ne voulons
pas augmenter le d<>calage de 5 pixels vu que c'est un nombre impair et que
cela affectera d<>favorablement la qualit<69>. A la place, nous augmenterons le
d<>calage y de 4 pixels:
<screen>mplayer dvd://1 -vf crop=720:352:0:62</screen>
Une autre raison pour retirer les pixels du haut et du bas est que nous nous
assurons que nous avons <20>limin<69> tous les pixels <20> moiti<74> noir s'ils
existent. Notez que si votre vid<69>o est t<>l<EFBFBD>cin<69>e, assurez-vous que le filtre
<option>pullup</option> (ou quelque soit le filtre inverse t<>l<EFBFBD>cin<69> que vous
avez d<>cid<69> d'utiliser) apparaissent dans la cha<68>ne de filtres avant que vous
d<>coupiez. Si il est entrelac<61>, d<>s-entrelacez-le avant d<>coupage.
(Si vous choisissez de pr<70>server la vid<69>o entrelac<61>e, alors soyez certain que
votre d<>calage de d<>coupage vertical est un multiple de 4.)
</para>
<para>
Si la perte de ces 10 pixels vous peine, vous pouvez, au lieu de r<>duire
les dimensions, prendre le plus proche multiple de 16.
La cha<68>ne de filtres ressemblerait <20> ceci:
<screen>-vf crop=720:362:0:58,scale=720:352</screen>
R<>duire la vid<69>o comme cela signifie qu'une petite quantit<69> de d<>tails est perdu
bien que cela ne soit probablement pas perceptible. Augmenter la taille
entra<72>nera une qualit<69> inf<6E>rieure (<28> moins que vous n'augmentiez le bitrate).
Le redimensionnement sauvera l'ensemble de ces pixels. C'est une diff<66>rence que vous
voudrez prendre en compte <20> chaque circonstance. Par exemple, si le DVD vid<69>o
<20>tait fait pour la t<>l<EFBFBD>vision, vous pourriez avoir int<6E>r<EFBFBD>t <20> <20>viter le
redimensionnement vertical, <20>tant donn<6E> que la ligne d'<27>chantillons correspond
<20> la mani<6E>re d'origine avec laquelle le contenu a <20>t<EFBFBD> enregistr<74>.
</para>
<para>
Apr<70>s v<>rification, nous voyons que notre film a un peu d'action et beaucoup de
d<>tails, donc nous prenons 2400Kbit pour notre bitrate.
</para>
<para>
Nous sommes maintenant pr<70>ts <20> faire les deux passes d'encodage. Premi<6D>re passe:
<screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \
-lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=1 \
-o Harry_Potter_2.avi</screen>
La seconde passe est la m<>me, si ce n'est que nous sp<73>cifions <option>vpass=2</option>:
<screen>mencoder dvd://1 -ofps 24000/1001 -oac copy -vf crop=720:352:0:62,hqdn3d=2:1:2 -ovc lavc \
-lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:mbcmp=3:autoaspect:vpass=2 \
-o Harry_Potter_2.avi</screen>
</para>
<para>
Les options <option>v4mv:mbd=2:trell</option> augmenteront consid<69>rablement la
qualit<69> au d<>pend de la dur<75>e d'encodage. Il y a peu de raison de ne pas
prendre en compte ces options quand le but premier est la qualit<69>. Les options
<option>cmp=3:subcmp=3:mbcmp=3</option> choisissent une fonction de comparaison
qui rend une plus haute qualit<69> que celle par d<>faut. Vous pouvez tenter d'exp<78>rimenter
avec ces param<61>tres (reportez-vous <20> la page man pour les valeurs possibles)
<20>tant donn<6E> que diff<66>rentes fonctions peuvent avoir un large impact sur la
qualit<69> selon le mat<61>riel source. Par exemple, si vous trouvez que
<systemitem class="library">libavcodec</systemitem> produit trop d'artefacts
carr<72>s, vous pouvez essayer de choisir le NSSE exp<78>rimental comme fonction
de comparaison via <option>*cmp=10</option>.
</para>
<para>
Pour ce film, le AVI r<>sultant durera 138 minutes et p<>sera <20> peu pr<70>s 3GB.
Si vous disiez que la taille du fichier n'<27>tait pas importante, cette taille
est parfaitement acceptable. Cependant, si vous la souhaitez plus petite,
vous pouvez essayer un bitrate inf<6E>rieur. Les augmentations de bitrates ont des
effets amoindris, tandis que nous pourrons clairement voir une
am<61>lioration <20> partir de 1800Kbit jusqu'<27> 2000Kbit, cela ne semblera pas
tellement rentable notablement au-dessus de 2000Kbit. Libre <20> vous
d'exp<78>rimenter jusqu'<27> totale satisfaction.
</para>
<para>
Parce que nous avons pass<73> la source vid<69>o au travers d'un filtre antibruit,
vous aimerez en rajouter un peu pendant la lecture. Ceci, avec le filtre de
post-traitement <option>spp</option>, am<61>liore de fa<66>on radicale la perception
de qualit<69> et aide <20> <20>liminer les artefacts carr<72>s de la vid<69>o.
Avec l'option <option>autoq</option> de <application>MPlayer</application>,
vous pouvez faire varier le montant de post-traitement achev<65> par le filtre spp
selon le CPU disponible. Aussi, <20> ce point, pourriez-vous vouloir demander
une correction gamma et/ou couleur qui convient mieux <20> l'affichage. Par exemple:
<screen>mplayer Harry_Potter_2.avi -vf spp,noise=9ah:5ah,eq2=1.2 -autoq 3</screen>
</para>
</sect2>
</sect1>
<sect1 id="menc-feat-xvid">
<title>Encod<EFBFBD> avec le codec <systemitem class="library">XviD</systemitem></title>
<para>
<systemitem class="library">XviD</systemitem> est une biblioth<74>que libre pour
encoder les flux vid<69>o de MPEG-4 ASP.
Avant de commencer <20> encoder, vous avez besoin de <link linkend="xvid">
param<61>trer <application>MEncoder</application> pour son support</link>.
</para>
<para>
Ce guide a pour principal objectif de fournir le m<>me genre d'information que
le guide d'encodage de x264.
Par cons<6E>quent, commencez par lire
<link linkend="menc-feat-x264-encoding-options-intro">la premi<6D>re partie</link>
de ce guide.
</para>
<sect2 id="menc-feat-xvid-intro">
<title>Quelles options devrais-je utiliser pour avoir les meilleurs r<>sultats?</title>
<para>
Commencez par passer en revue la page man de la section
<systemitem class="library">XviD</systemitem> de <application>MPlayer</application>.
Cette section est pr<70>vue pour <20>tre un suppl<70>ment <20> la page man.
</para>
<para>
Les param<61>tres XviD par d<>faut font d<>j<EFBFBD> une bonne distinction entre la
vitesse et la qualit<69>, donc vous pouvez sans risque vous en tenir <20> eux
si la section suivante vous laisse perplexe.
</para>
</sect2>
<sect2 id="menc-feat-xvid-encoding-options">
<title>Options d'encodage de <systemitem class="library">XviD</systemitem></title>
<itemizedlist>
<listitem><para>
<emphasis role="bold">vhq</emphasis>
Ce param<61>tre affecte l'algorithme de choix de macrobloc, o<> plus la valeur
du param<61>tre est <20>lev<65>e, meilleure sera la d<>cision.
Le param<61>tre par d<>faut peut <20>tre utilis<69> de fa<66>on s<>re pour tous les encodages,
alors que des param<61>tres plus <20>lev<65>s aident toujours le PSNR mais sont significativement
plus lents.
Veuillez noter qu'un meilleur PSNR ne veut pas forc<72>ment dire que l'image
sera mieux, mais vous informe de la proximit<69> par rapport <20> l'image originale.
D<>sactiver l'option acc<63>l<EFBFBD>rera de fa<66>on notable l'encodage; si la vitesse est un point
critique pour vous, la diff<66>rence peut valoir le coup.
</para></listitem>
<listitem><para>
<emphasis role="bold">bvhq</emphasis>
C'est pareil que vhq, mais cela agit sur les B-frames.
L'impact sur la vitesse est n<>gatives, et la qualit<69> est un peu am<61>lior<6F>e
(environ +0.1dB PSNR).
</para></listitem>
<listitem><para>
<emphasis role="bold">max_bframes</emphasis>
Un plus grand nombre de B-frames cons<6E>cutives permis am<61>liore habituellement
la compressibilit<69>, bien qu'il puisse <20>galement entra<72>ner plus d'artefacts carr<72>s.
Le param<61>trage par d<>faut est un bon compromis entre compressibilit<69> et qualit<69>,
mais vous pouvez l'augmenter jusqu'<27> 3 si vous <20>tes obnubil<69> par le bitrate.
Vous pouvez aussi le r<>duire <20> 1 ou 0 si vous avez pour seul but la qualit<69>
parfaite, cependant dans votre cas vous devriez vous assurer que le bitrate
cible est assez <20>lev<65> pour que l'encodeur n'ait pas <20> augmenter le
quantificateur pour l'atteindre.
</para></listitem>
<listitem><para>
<emphasis role="bold">bf_threshold</emphasis>
Ceci contr<74>le la sensibilit<69> de l'encodeur pour les B-frames, o<> une plus haute
valeur am<61>ne <20> ce que plus de B-frames soit utilis<69> (et vice versa).
Ce param<61>tre doit <20>tre utilis<69> avec <option>max_bframes</option>;
si vous <20>tes obnubil<69> par le bitrate, vous devrez augmenter <option>max_bframes</option>
et <option>bf_threshold</option>, tandis que vous devriez augmenter <option>max_bframes</option>
et r<>duire <option>bf_threshold</option> ainsi donc l'encodeur peut utiliser plus de B-frames
aux seuls endroits qui les n<>cessitent <emphasis role="bold">vraiment</emphasis>.
Un nombre bas de <option>max_bframes</option> et une valeur <20>lev<65>e de <option>bf_threshold</option>
n'est probablement pas un choix avis<69> vu qu'il obligera l'encodeur <20> mettre
des B-frames en des endroits qui n'en tireront pas de b<>n<EFBFBD>fice, mais en plus
r<>duiront la qualit<69> visuelle.
Cependant, si vous avez besoin d'<27>tre compatible avec des lecteurs qui
supportent seulement de vieilles versions DivX (ce qui revient <20> supporter jusqu'<27>
1 B-frame cons<6E>cutive), ceci sera votre seul espoir d'augmenter la
compressibilit<69> en utilisant les B-frames.
</para></listitem>
<listitem><para>
<emphasis role="bold">trellis</emphasis>
Optimise la proc<6F>dure de quantification pour obtenir un compromis optimal
entre le PSNR et le bitrate, ce qui permet de sauver de mani<6E>re significative
des bits.
Ces bits seront en retour utilis<69>s autre part sur la vid<69>o, augmentant l'ensemble
de la qualit<69> visuelle.
Vous devriez toujours l'utiliser <20>tant donn<6E> qu'il impacte <20>norm<72>ment sur la
qualit<69>.
M<>me si vous recherchez de la vitesse, ne le d<>sactivez pas jusqu'<27> ce que
vous r<>duisiez <option>vhq</option> et toutes les autres options plus gourmandes
en CPU <20> leur minimum.
</para></listitem>
<listitem><para>
<emphasis role="bold">hq_ac</emphasis>
Active une meilleure m<>thode d'estimation du co<63>t en coefficient, ce qui r<>duit
passablement la taille de fichier par environ 0.15 <20> 0.19% (ce qui correspond
<20> moins de 0.01dB PSNR d'augmentation), tandis qu'elle a un impact n<>gligeable
sur la vitesse.
Il est n<>anmoins recommand<6E> de toujours la laisser activ<69>e.
</para></listitem>
<listitem><para>
<emphasis role="bold">cartoon</emphasis>
Faite pour un meilleur encodage de contenu dessin anim<69>, et n'a pas d'impact
sur la vitesse <20>tant donn<6E> qu'il modifie juste les heuristiques
pour ce type de contenu.
</para></listitem>
<listitem><para>
<emphasis role="bold">me_quality</emphasis>
Ce param<61>tre contr<74>le la pr<70>cision de l'estimation de mouvement.
Le plus <20>lev<65> <option>me_quality</option> est, le plus pr<70>cis
l'estimation du mouvement d'origine sera, et mieux le clip r<>sultant
capturera le mouvement d'origine.
</para>
<para>
Le param<61>tre par d<>faut est le mieux dans tous les cas; bien qu'il ne
soit pas recommand<6E> de le d<>sactiver <20> moins que vous recherchiez vraiment
la rapidit<69>, vu que tout les bits sauv<75>s par une bonne estimation du
mouvement seront d<>pens<6E>s autre part, augmentant la qualit<69> g<>n<EFBFBD>rale.
Cependant, n'allez pas plus bas que 5, et m<>me ceci doit <20>tre utilis<69>
en dernier recours.
</para></listitem>
<listitem><para>
<emphasis role="bold">chroma_me</emphasis>
Am<41>liore l'estimation de mouvement en prenant aussi en compte l'information
de la chroma (couleur), alors que <option>me_quality</option> toute seule
utilise seulement la luma (niveau de gris).
Cela ralenti l'encodage de 5-10% mais am<61>liore pas mal la qualit<69> visuelle
en r<>duisant les effets de bloc et r<>duit la taille de fichier d'environ 1.3%.
Si vous cherchez de la vitesse, vous devriez d<>sactiver cette option avant de
commencer <20> consid<69>rer <20> la r<>duction de <option>me_quality</option>.
</para></listitem>
<listitem><para>
<emphasis role="bold">chroma_opt</emphasis>
A pour objectif d'augmenter la qualit<69> du chroma de l'image vers des
bords blanc/noirs pures, plut<75>t que d'am<61>liorer la compression.
Ceci peut aider <20> r<>duire l'effet "red stairs".
</para></listitem>
<listitem><para>
<emphasis role="bold">lumi_mask</emphasis>
Tente de donner moins de bitrate <20> une partie de l'image que l'oeil humain
ne peut pas tr<74>s bien voir, ce qui devrait permettre <20> l'encodeur de d<>penser
les bits sauv<75>s sur des parties plus importantes de l'image.
La qualit<69> de l'encodage li<6C>e <20> cette option d<>pend grandement des
pr<70>f<EFBFBD>rences personnelles et des param<61>tres de type et moniteurs utilis<69>s pour
le regarder (typiquement, cela ne semblera pas aussi bon si c'est plus
lumineux ou si c'est un moniteur TFT).
</para></listitem>
<listitem><para>
<emphasis role="bold">qpel</emphasis>
<20>l<EFBFBD>ve le nombre de vecteurs de mouvement candidats en augmentant la
pr<70>cision de l'estimation de mouvement de halfpel (demi-pixel) <20> quarterpel (quart de pixel).
L'id<69>e est de trouver de meilleurs vecteurs de mouvement pour
r<>duire le bitrate (ou augmenter la qualit<69> <20> bitrate constant).
Cependant, les vecteurs de mouvement avec une pr<70>cision quarterpel requi<75>rent
quelques bits en plus <20> coder, mais les vecteurs candidats ne donnent pas
toujours des r<>sultats vraiment meilleurs.
Assez souvent, le codec gaspille encore des bits sur la pr<70>cision en plus,
mais en retour il n'y aura que peu ou pas de qualit<69> suppl<70>mentaire.
Malheureusement, il n'y a aucune fa<66>on de pr<70>voir les avantages possible de
<option>qpel</option>, donc vous avez pr<70>cis<69>ment besoin de l'encoder avec
et sans pour en <20>tre s<>r.
</para><para>
<option>qpel</option> peut quasiment doubler la dur<75>e d'encodage, et ne
requiert pas moins de 25% de puissance processeur en plus pour d<>coder.
Cela n'est pas support<72> par tous les lecteurs.
</para></listitem>
<listitem><para>
<emphasis role="bold">gmc</emphasis>
Essaie de sauver des bits sur des sc<73>nes panoramiques en employant un
vecteur simple de mouvement pour la frame enti<74>re.
Cela augmente <20> peu pr<70>s toujours le PSNR, mais ralentit l'encodage
de fa<66>on significative (et aussi le d<>codage).
Par cons<6E>quent, vous devriez seulement l'employer si vous avez
augment<6E> <option>vhq</option> au maximum.
Le GMC de <systemitem class="library">XviD</systemitem> est plus sophistiqu<71>
que celui de DivX, mais il est seulement support<72> par quelques lecteurs.
</para></listitem>
</itemizedlist>
</sect2>
<sect2 id="menc-feat-xvid-encoding-profiles">
<title>Profils d'encodage</title>
<para>
XviD supporte des profils d'encodage via l'option <option>profile</option>,
ce qui est utilis<69> pour imposer des restrictions sur les propri<72>t<EFBFBD>s du flux
vid<69>o XviD pour qu'il puisse <20>tre relu sur tout ce qui supporte le profil
choisi.
Les restrictions relient les r<>solutions, les bitrates et certaines
fonctionnalit<69>s MPEG-4.
La table suivante montre ce que chaque profil supporte.
</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">Simple avanc<6E></entry>
<entry spanname="spa12-17">DivX</entry>
</row>
<row>
<entry>Nom de profil</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>NTSC Portable</entry>
<entry>PAL Portable</entry>
<entry>NTSC Home Cin<69>ma</entry>
<entry>PAL Home Cin<69>ma</entry>
<entry>TV Haute D<>finition</entry>
</row>
<row>
<entry>Largeur [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>Hauteur [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>Bitrate moyen maxi [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>Bitrate moyen maximal plus de 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>B-frames maxi</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>Quantification MPEG</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>Quantification adaptative</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>Encodage entrelac<61></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>Compensation globale du mouvement</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>Exemples de param<61>tres d'encodage</title>
<para>
Les param<61>tres suivant sont des exemples de diff<66>rentes combinaisons
d'option d'encodage qui affectent la compensation entre la vitesse et
la qualit<69> pour le m<>me bitrate cible.
</para>
<para>
Tous les param<61>tres d'encodage ont <20>t<EFBFBD> test<73>s sur un <20>chantillon vid<69>o <20>
720x448 @30000/1001 fps, le bitrate cible <20>tait <20> 900kbps, et la machine
<20>tait un AMD-64 3400+ <20> 2400 Mhz en mode 64 bits.
Chaque param<61>tre d'encodage exploite la vitesse d'encodage mesur<75> (en
frames par seconde) et la perte PSNR (en dB) en la comparant au param<61>tre
de "tr<74>s haute qualit<69>".
Veuillez comprendre que selon votre source vid<69>o, votre type de machine
les d<>veloppements logiciels, vous pouvez obtenir des r<>sultats tr<74>s
diff<66>rents.
</para>
<para>
<informaltable frame="all">
<tgroup cols="4">
<thead>
<row><entry>Description</entry><entry>Options d'encodage</entry><entry>vitesse (en fps)</entry><entry>Perte PSNR relative (en dB)</entry></row>
</thead>
<tbody>
<row>
<entry>Tr<EFBFBD>s haute qualit<69></entry>
<entry><option>chroma_opt:vhq=4:bvhq=1:quant_type=mpeg</option></entry>
<entry>16fps</entry>
<entry>0dB</entry>
</row>
<row>
<entry>Haute qualit<69></entry>
<entry><option>vhq=2:bvhq=1:chroma_opt:quant_type=mpeg</option></entry>
<entry>18fps</entry>
<entry>-0.1dB</entry>
</row>
<row>
<entry>Rapide</entry>
<entry><option>turbo:vhq=0</option></entry>
<entry>28fps</entry>
<entry>-0.69dB</entry>
</row>
<row>
<entry>Temps r<>el</entry>
<entry><option>turbo:nochroma_me:notrellis:max_bframes=0:vhq=0</option></entry>
<entry>38fps</entry>
<entry>-1.48dB</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
</sect1>
<sect1 id="menc-feat-x264">
<title>Encodage avec le codec <systemitem class="library">x264</systemitem></title>
<para>
<systemitem class="library">x264</systemitem> est une librairie libre pour
encoder des flux vid<69>o H.264/AVC.
Avant de commencer <20> encoder, vous avez besoin de <link linkend="codec-x264-encode">
r<>gler <application>MEncoder</application> pour le supporter</link>.
</para>
<sect2 id="menc-feat-x264-encoding-options">
<title>Options d'encodage de x264</title>
<para>
Veuillez commencer par passer en revue la section
<systemitem class="library">x264</systemitem> de la page man
de <application>MPlayer</application>.
Cette section a <20>t<EFBFBD> pr<70>vue pour <20>tre un compl<70>ment <20> la page man.
Vous trouverez ici rapidement des astuces sur le genre d'options qui est
le plus susceptible d'int<6E>resser la plupart des gens. La page man
est plus laconique, elle est aussi plus exhaustive, et cela offre
parfois beaucoup plus de d<>tails techniques.
</para>
<sect3 id="menc-feat-x264-encoding-options-intro">
<title>Introduction</title>
<para>Ce guide consid<69>re deux cat<61>gories majeures d'options d'encodage:</para>
<orderedlist>
<listitem><para>Options qui principalement compensent la dur<75>e d'encodage de la qualit<69>
</para></listitem>
<listitem><para>Options qui peuvent <20>tre utiles pour accomplir des pr<70>f<EFBFBD>rences personnelles
vari<72>es et des conditions sp<73>ciales</para></listitem>
</orderedlist>
<para>
Finalement, seul vous pouvez d<>cider quelles options permettent d'atteindre vos buts.
Le choix de la premi<6D>re classe d'options est la plus simple:
vous devez seulement d<>cider si vous pensez que les diff<66>rences de qualit<69>
justifient les diff<66>rences de vitesse. Pour la deuxi<78>me classe d'options,
les pr<70>f<EFBFBD>rences peuvent <20>tre bien plus subjectives, et plus de facteurs
peuvent <20>tre impliqu<71>s. Notez que certaines des options de type
"pr<70>f<EFBFBD>rences personnelles et de conditions sp<73>ciales" peuvent encore avoir
un impact impact sur la vitesse ou la qualit<69>, mais ce n'est pas l<> leur
principale utilit<69>. Quelques unes des options de "pr<70>f<EFBFBD>rence
personnelle" peuvent m<>me causer des changements qui semblent mieux pour
certaines personnes, mais semblent moins bon <20> d'autres.
</para>
<para>
Avant de continuer, il vous est n<>cessaire de comprendre que ce guide utilise seulement
une qualit<69> m<>trique: le PSNR global.
Pour une br<62>ve explication sur le PSNR, voir
<ulink url="http://en.wikipedia.org/wiki/PSNR">l'article Wikipedia sur le PSNR</ulink>.
PSNR global est le dernier nombre PSNR rapport<72> quand vous incluez l'option
<option>psnr</option> dans <option>x264encopts</option>.
Chaque fois que vous lisez une r<>clamation sur le PSNR, une des pr<70>tentions
derri<72>re la r<>clamation est que des bitrates <20>gaux sont utilis<69>s.
</para>
<para>
A peu pr<70>s tous les commentaires de ce guide pr<70>sument que vous utilisez
deux passages.
Lors de la comparaison des options, il y a deux principales raisons pour
l'utilisation d'un encodage en deux passes.
Premi<6D>rement, utiliser deux passes permet souvent de gagner environ 1dB
PSNR, ce qui est une tr<74>s grosse diff<66>rence.
Deuxi<78>mement, tester les options en faisant des comparaisons directes de
qualit<69> avec un encodage en un passage introduit un facteur confus important:
le bitrate varie souvent de fa<66>on significative avec chaque encodage.
Il n'est pas toujours facile de dire si les changements de qualit<69> sont
principalement d<>s aux changements d'options, ou si la plupart du temps ils
refl<66>tent essentiellement des diff<66>rences al<61>atoires dans le bitrate r<>alis<69>.
</para>
</sect3>
<sect3 id="menc-feat-x264-encoding-options-speedvquality">
<title>Options qui affectent principalement la vitesse et la qualit<69></title>
<itemizedlist>
<listitem><para>
<emphasis role="bold">subq</emphasis>:
Des options qui vous permettent de compenser la vitesse pour la qualit<69>,
<option>subq</option> et <option>frameref</option> (voir ci-dessous) sont
habituellement et de loin les plus importantes.
Si vous <20>tes int<6E>ress<73>s par le bidouillage soit de la vitesse soit de la
qualit<69>, ces options sont les premi<6D>res que vous devriez prendre en
consid<69>ration.
A propos de la dimension de la vitesse, les options <option>frameref</option>
et <option>subq</option> interagissent entre elles assez fortement.
L'exp<78>rience montre que, avec une frame de r<>f<EFBFBD>rence,
<option>subq=5</option> (le r<>glage par d<>faut) est environ 35% plus lent que
<option>subq=1</option>.
Avec 6 frames de r<>f<EFBFBD>rence, la p<>nalit<69> passe au dessus des 60%.
L'effet de <option>subq</option> sur le PSNR semble assez constant
ind<6E>pendamment du nombre de frames de r<>f<EFBFBD>rence.
Typiquement, <option>subq=5</option> r<>sulte en un PSNR global plus haut de
0.2-0.5 dB en comparaison <20> <option>subq=1</option>.
C'est habituellement assez pour <20>tre <20>vident.
</para>
<para>
<option>subq=6</option> est le plus lent, le plus <20>lev<65> mode de qualit<69>.
En comparaison <20> <option>subq=5</option>, il gagne habituellement un PSNR
global de 0.1-0.4 dB avec des co<63>ts en vitesse variant entre 25% et 100%.
A la diff<66>rence des autres niveaux de <option>subq</option>, le comportement
de <option>subq=6</option> ne d<>pend pas beaucoup de <option>frameref</option>
et <option>me</option>. A la place, l'efficacit<69> de <option>subq=6</option>
d<>pend principalement du nombre de B-frames utilis<69>es. Lors d'une utilisation
normale, cela signifie que <option>subq=6</option> a un large impact sur la
vitesse et la qualit<69> dans le cas complexe, des sc<73>nes avec beaucoup de mouvements,
mais il peut ne pas avoir beaucoup d'effets sur les sc<73>nes avec peu de mouvements.
Notez qu'il est encore recommand<6E> de toujours r<>gler les <option>bframes</option>
<20> d'autres valeurs que z<>ro (voir ci-dessous).
</para></listitem>
<listitem><para>
<emphasis role="bold">frameref</emphasis>:
<option>frameref</option> est r<>gl<67> <20> 1 par d<>faut, mais cela ne veut pas dire
qu'il est raisonnable de le laisser <20> 1.
La simple augmentation de <option>frameref</option> <20> 2 permet un gain de PSNR d'environ
0.15dB, avec une p<>nalit<69> de 5-10% sur la vitesse; cela semble <20>tre
un bon compromis.
<option>frameref=3</option> gagne environ 0.25dB de PSNR de mieux que
<option>frameref=1</option>, ce qui devrait <20>tre une diff<66>rence visible.
<option>frameref=3</option> est d'environ 15% plus lent que <option>frameref=1</option>.
Malheureusement, des retours diminuant se mettent en place rapidement.
<option>frameref=6</option> peut entra<72>ner un gain de seulement 0.05-0.1 dB
de mieux que <option>frameref=3</option> avec une p<>nalit<69> de
15% sur la vitesse.
Au del<65> de <option>frameref=6</option>, les gains en qualit<69> sont
habituellement tr<74>s faible (bien que vous deviez garder <20> l'esprit
que toute cet avis est <20> mod<6F>rer selon la source vid<69>o utilis<69>e).
Dans un cas typique, <option>frameref=12</option> am<61>liorera le PSNR
global d'un minuscule 0.02dB de mieux que <option>frameref=6</option>,
avec un surco<63>t sur la vitesse de 15%-20%.
Avec des valeurs aussi <20>lev<65>es de <option>frameref</option>, la seule vraie bonne
chose qui puisse <20>tre dite est que de l'augmenter m<>me un peu plus ne
<emphasis role="bold">nuira</emphasis> quasiment jamais au PSNR,
mais les b<>n<EFBFBD>fices sur la qualit<69> additionnelle sont <20> peine mesurables, et encore
moins perceptibles.
</para>
<note><title>Note:</title>
<para>
Augmenter le <option>frameref</option> <20> des valeurs inutilement <20>lev<65>es
<emphasis role="bold">peut affecter</emphasis> et <emphasis role="bold">habituellement affecte</emphasis>
l'efficacit<69> d'encodage si vous d<>sactivez le CABAC.
Avec le CABAC activ<69> (comportement par d<>faut), il n'y a pas vraiment de risque
qu'un r<>glage de <option>frameref</option> "trop <20>lev<65>" diminue l'efficacit<69>
de l'encodage, et dans l'avenir, des optimisations pouront peut-<2D>tre
rendre ce risque nul.
</para>
</note>
<para>
Si vous vous inqui<75>tez pour la vitesse, un compromis raisonnable est
d'utiliser des valeurs <option>subq</option> et <option>frameref</option> basses
sur le premier passage, et ensuite les augmenter sur le second passage.
Typiquement, cela a un effet n<>gatif n<>gligeable sur la qualit<69> finale.
Vous perdrez probablement bien moins de 0.1dB du PSNR, ce qui devrait
<20>tre une diff<66>rence beaucoup trop faible pour <20>tre visible.
Cependant, des valeurs diff<66>rentes de <option>frameref</option> peuvent
parfois affecter le choix du type de frame.
Tr<54>s probablement, ce sont des cas p<>riph<70>riques rares, mais si vous voulez
en <20>tre compl<70>tement certain, consid<69>rez que votre vid<69>o a soit des mod<6F>les
plein <20>cran, clignotants et r<>p<EFBFBD>titifs, soit des occlusions provisoires tr<74>s
grandes qui forcent une I-frame.
Ajustez le <option>frameref</option> de premier passage pour qu'il soit assez
large pour contenir la dur<75>e du cycle de clignotement (ou occlusion).
Par exemple, si la sc<73>ne clignote dans les deux sens entre deux images
au-dessus d'une dur<75>e de trois frames, r<>glez le <option>frameref</option> de
premier passage <20> 3 ou plus.
Le probl<62>me est probablement extr<74>mement rare sur des mat<61>riaux vid<69>o de type
action en directe, mais cela arrive quelquefois dans des captures de jeu vid<69>o.
</para></listitem>
<listitem><para>
<emphasis role="bold">me</emphasis>:
Cette option est utilis<69>e pour choisir une m<>thode de recherche d'estimation de mouvement.
Cette option modifie de mani<6E>re notable le rapport entre qualit<69> et vitesse.
<option>me=1</option> est seulement quelques pour cent plus rapide que
la recherche par d<>faut et entra<72>ne une diminution du PSNR global inf<6E>rieure <20> 0.1dB. Le
param<61>tre par d<>faut (<option>me=2</option>) est offre un compromis raisonnable
entre vitesse et qualit<69>. <option>me=3</option> am<61>liore de moins de 0.1dB le
PSNR global - la p<>nalit<69> sur la vitesse varie en fonction
du <option>frameref</option>. Pour de hautes valeurs du <option>frameref</option>
(par exemple 12 ou plus), <option>me=3</option> est environ 40% plus lent que la
valeur par d<>faut <option>me=2</option>. Avec <option>frameref=3</option>,
la p<>nalit<69> sur la vitesse chute dans les 25%-30%.
</para>
<para>
<option>me=4</option> utilise une recherche exhaustive qui est trop lente pour
une utilisation pratique.
</para>
</listitem>
<listitem><para>
<emphasis role="bold">4x4mv</emphasis>:
Cette option active l'utilisation des sous-partitions 8x4, 4x8 et 4x4 dans
les macroblocs pr<70>vus. L'activer r<>sulte en une perte de vitesse habituellement
dans les 10% <20> 15%. Cette option est plut<75>t inutile pour une source contenant
peu de mouvements, bien que dans certaines sources riches en mouvements,
ou bien des sources avec beaucoup de petits objets en mouvement, un
gain d'environ 0.1dB peut <20>tre esp<73>r<EFBFBD>.
</para>
</listitem>
<listitem><para>
<emphasis role="bold">bframes</emphasis>:
Si vous avez l'habitude d'encoder avec d'autre codecs, vous pourriez penser
que les trames-B ne sont pas toujours utiles.
Avec le H.264, ceci a chang<6E>: il y a de nouvelles techniques et types de blocs
qui sont possibles avec les trames-B.
Habituellement, m<>me un choix na<6E>f d'algorithme de trames-B peut avoir un
b<>n<EFBFBD>fice significatif sur le PSNR.
Il est int<6E>ressant de noter que l'utilisation de trames-B acc<63>l<EFBFBD>re
habituellement l<>g<EFBFBD>rement la seconde passe, et peut aussi acc<63>l<EFBFBD>rer
l'encodage en un seul passage si le choix de trames-B adaptatif est d<>sactiv<69>.
</para>
<para>
Avec le choix de trames-B adaptatif d<>sactiv<69>
(l'option <option>nob_adapt</option> de <option>x264encopts</option>),
le r<>glage optimal est habituellement inf<6E>rieur <20>
<option>bframes=1</option>, sinon les sc<73>nes riches en mouvement vont en souffrir.
Avec le choix de B-frame adaptatif activ<69> (le comportement par d<>faut), cela
ne pose plus de probl<62>me d'utiliser des valeurs plus <20>lev<65>es;
l'encodeur r<>duira l'utilisation de trames-B dans les sc<73>nes pour lesquelles
cela risque de diminuer la qualit<69>.
L'encodeur choisi rarement d'utiliser plus de 3 ou 4 trames-B;
param<61>trer cette option <20> une valeur plus <20>lev<65>e aura peu d'effet.
</para></listitem>
<listitem><para>
<emphasis role="bold">b_adapt</emphasis>:
Note: il est activ<69> par d<>faut.
</para>
<para>
Avec cette option activ<69>e, l'encodeur d<>cidera quand r<>duire le nombre
de trames-B utilis<69>es dans les sc<73>nes pour lesquelles ces trames
n'apporteraient rien.
Vous pouvez utiliser <option>b_bias</option> pour temp<6D>rer la tendance
de l'encodeur <20> ins<6E>rer des trames-B.
Le surco<63>t sur la vitesse des trames-B adaptatives est actuellement
plut<75>t modeste, mais il en est de m<>me pour le gain de qualit<69> potentiel.
En g<>n<EFBFBD>ral, cela ne fait pas de mal...
Notez que cela affecte seulement la vitesse et le choix du type de trames
lors de la premi<6D>re passe.
Les options <option>b_adapt</option> et <option>b_bias</option> n'ont pas
d'effet lors des passages suivants.
</para></listitem>
<listitem><para>
<emphasis role="bold">b_pyramid</emphasis>:
Vous pouvez aussi activer cette option si vous utilisez >=2 trames-B;
comme l'indique la page man, vous obtiendrez une faible am<61>lioration de la
qualit<69> sans surco<63>t en vitesse.
Notez que ces vid<69>os ne peuvent pas <20>tre lues avec les d<>codeurs utilisant
une version de libavcodec ant<6E>rieur au 5 mars 2005.
</para></listitem>
<listitem><para>
<emphasis role="bold">weight_b</emphasis>:
En th<74>orie, il n'y a beaucoup de gain <20> esp<73>rer de cette option.
En effet, dans des sc<73>nes de fondu ou de fondu au noir, la pr<70>diction
pond<6E>r<EFBFBD>e permet d'<27>conomiser beaucoup de bitrate.
Dans le MPEG-4 ASP, un fondu-au-noir est souvent mieux compress<73> comme une
co<63>teuse s<>rie de I-frames; utiliser la pr<70>diction pond<6E>r<EFBFBD>e pour les
trames-B permet d'en convertir une partie en plus petites B-frames.
Le co<63>t sur la dur<75>e d'encodage est minimal, <20>tant donn<6E> qu'aucun choix
suppl<70>mentaire n'a besoin d'<27>tre fait.
Aussi, contrairement <20> ce que les gens croient deviner, les besoins en CPU par
le d<>codeur ne sont pas <20>norm<72>ment affect<63> par la pr<70>diction pond<6E>r<EFBFBD>e, toutes
choses <20>tant <20>gales par ailleurs.
</para>
<para>
Malheureusement, l'algorithme actuel de choix de trames-B adaptative
a une forte tendance <20> <20>viter les trames-B pendant les fondus.
Tant que ce sera le cas, ajouter <option>nob_adapt</option>
<20> votre x264encopts sera une bonne id<69>e si vous pensez que les
fondus vont avoir un gros effet dans votre vid<69>o.
</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="menc-feat-x264-encoding-options-misc-preferences">
<title>Options diverses et/ou d<>pendant des go<67>ts de chacun</title>
<itemizedlist>
<listitem><para>
<emphasis role="bold">Encodage en deux passes</emphasis>:
On a sugg<67>r<EFBFBD> ci-dessus de toujours utiliser un encodage en deux passages,
mais il y a reste quelques cas pour ne pas l'utiliser. Par exemple, si vous
capturez la t<>l<EFBFBD>vision en direct et que vous l'encodez en temps r<>el, vous
<20>tes oblig<69> d'utiliser un encodage mono-passe.
Aussi, une compression en une passe est <20>videmment plus rapide qu'une en deux
passes pour un jeu d'options donn<6E> - un encodage en deux passes est presque deux
fois plus lent qu'un encodage en une passe.
</para>
<para>
Cependant, il y a de tr<74>s bonnes raisons pour utiliser l'encodage en deux passages.
D'une part, le taux de contr<74>le d'un seul passage ne peut pas pr<70>dire le futur, il
fait donc souvent des choix sous-optimaux parce qu'il ne peut pas voir l'ensemble
de la vid<69>o. Par exemple, supposez que vous ayez une vid<69>o de deux minutes
consistant en deux moiti<74>s distinctes. La premi<6D>re moiti<74> est une sc<73>ne
riche en mouvements pendant 60 secondes, ce qui, hors de tout contexte, demande
environ 2500kbps afin d'avoir l'air correct.
Une sc<73>ne de 60 secondes beaucoup plus statique suit et peut <20>tre tr<74>s bien <20>
300kbps. Supposez que vous demandiez 1400kbps sur la
th<74>orie que ceci soit suffisant pour les deux sc<73>nes. Un taux de
contr<74>le en un seul passage fera quelques "fautes" dans un cas comme celui-l<>.
Premi<6D>rement, il essaiera de viser 1400kbps pour les deux segments. Alors que le
premier segment va manquer de bits et donc avoir beaucoup d'artefacts de blocs,
le second segment va avoir trop de bits et les gaspiller. Ceci est d'autant plus difficile
<20> <20>viter que le probl<62>me se produit <20> la transition entre les deux sc<73>nes. Les premi<6D>res
secondes de la seconde partie vont <20>tre grandement sur-quantifi<66>s, parce que
le taux de contr<74>le suppose qu'il va avoir les m<>mes besoins en bitrate que pour
la premi<6D>re moiti<74> de la vid<69>o. Cette "p<>riode d'erreur" de sur-quantification pour
les mouvements faibles va <20>trangement mauvais, et utilisera en r<>alit<69> moins
que les 300kbps qu'il aurait pris pour le rendre correct. Il y a des fa<66>ons
d'att<74>nuer les pi<70>ges de l'encodage en simple passe, mais ils peuvent avoir
tendance <20> empirer la mauvaise pr<70>diction de bitrate.
</para>
<para>
Le taux de contr<74>le en multi-passes apporte d'<27>normes avantages sur une
compression mono-passe. En utilisant les statistiques r<>cup<75>r<EFBFBD>es depuis le
premier passage d'encodage, l'encodeur peut estimer, avec exactitude, le "co<63>t"
(en bits) de l'encodage de n'importe quelle frame donn<6E>e, <20> n'importe quel
quantificateur donn<6E>. Cela permet d'avoir une allocation de bits beaucoup plus
rationnelle car mieux planifi<66>e entre les sc<73>nes riches (beaucoup de
mouvements) et celles pauves en d<>tails (peu de mouvements). Voir
<option>qcomp</option> ci-dessous pour quelques suggestions sur la mani<6E>re
d'adapter cette allocation <20> vos besoins.
</para>
<para>
De plus, la compression en deux passes ne prend pas n<>cessairement deux fois plus de temps
que celle mono-passe. Vous pouvez jouer avec les options dans le premi<6D>re passe
pour avoir une vitesse plus <20>lev<65>e et une qualit<69> plus faible.
Si vous choisissez bien vos options, vous pouvez obtenir un premier passage
tr<74>s rapide.
La qualit<69> r<>sultante de la seconde passe sera l<>g<EFBFBD>rement plus basse parce
que la pr<70>diction de taille sera moins pr<70>cise, mais la diff<66>rence de qualit<69>
sera usuellement trop faible pour <20>tre visible. Essayez, par exemple,
d'ajouter <option>subq=1:frameref=1</option> au premier passage <option>x264encopts</option>.
Ensuite, sur le second passage, utilisez des options plus lentes pour avoir une
meilleure qualit<69>:
<option>subq=6:frameref=15:4x4mv:me=3</option>
</para></listitem>
<listitem><para>
<emphasis role="bold">Encodage en trois passages</emphasis>?
x264 offre la possibilit<69> de faire un nombre arbitraire de passages cons<6E>cutifs.
Si vous sp<73>cifiez <option>pass=1</option> lors de la premi<6D>re passe, alors
utilisez <option>pass=3</option> pour la passe suivante, cette passe
lira les statistiques calcul<75>es lors du passage pr<70>c<EFBFBD>dent, et <20>crira ses propres
statistiques. Une passe suivante aura une tr<74>s bonne base depuis laquelle
faire des pr<70>dictions tr<74>s pr<70>cises de tailles de trame pour un quantificateur donn<6E>.
En pratique, les gains sur la qualit<69> d'ensemble sont plut<75>t proches de z<>ro,
il est m<>me possible qu'une troisi<73>me passe d<>grade le PSNR global...
Pour utilisation typique, trois passages aident si vous obtenez une mauvaise
pr<70>diction de bitrate ou un mauvais rendu lors des transitions de sc<73>nes
lors de l'utilisation de seulement deux passages.
Ceci peut se produire sur les clips extr<74>mement courts. Il y a aussi quelques
cas sp<73>ciaux dans lesquels trois (ou plus) passages sont utiles pour les
utilisateurs avanc<6E>s, mais par souci de bri<72>vet<65>, ce guide ne traitera pas
ces cas sp<73>ciaux.
</para></listitem>
<listitem><para>
<emphasis role="bold">qcomp</emphasis>:
<option>qcomp</option> compense le nombre de bits allou<6F>s entre les trames
co<63>teuses car riches en mouvement et celles pauvres en mouvement. Dans
les cas extr<74>mes, <option>qcomp=0</option> vise un vrai bitrate constant.
Typiquement, cela rendrait des sc<73>nes riches en mouvements vraiment laides,
alors que les sc<73>nes plus statiques seraient absolument parfaites, mais cela
utiliserait aussi beaucoup plus de bits que n<>cessaire pour les rendre excellentes.
A l'autre extr<74>me, <option>qcomp=1</option> rend les param<61>tres de quantifications
(QP) presque constants. Un QP constant n'a pas l'air mauvais, mais la plupart des
gens pensent qu'il est plus raisonnable d'enlever quelques bits des sc<73>nes
co<63>teuses (car la perte de qualit<69> sera moins visible) et les r<>-allouer
aux sc<73>nes qui sont plus faciles <20> encoder pour qu'elles aient une excellente qualit<69>.
<option>qcomp</option> vaut 0.6 par d<>faut, ce qui peut <20>tre un
peu trop faible pour certains (des valeurs entre 0.7-0.8 sont aussi commun<75>ment
utilis<69>es).
</para></listitem>
<listitem><para>
<emphasis role="bold">keyint</emphasis>:
<option>keyint</option> est seulement l<> pour permetre de jouer sur le compromis entre la
pr<70>cision de la navigation dans les fichiers et leur compression.
Par d<>faut, <option>keyint</option> est <20>gal <20> 250.
Sur des sources <20> 25 fps, cela garantit que la navigation peut se faire
avec une pr<70>cision de 10 secondes.
Si vous pensez qu'il est important et utile de pouvoir faire une recherche
avec une granularit<69> de 5 secondes, mettez cette option <20> <option>keyint=125</option>;
cela d<>gradera un peu la qualit<69>/bitrate. Si vous vous souciez seulement
de la qualit<69> et non de la capacit<69> <20> faire une recherche, vous pouvez le
mettre <20> des valeurs beaucoup plus <20>lev<65>es (mais gardez <20> l'esprit que plus
vous augmenterez, moins il aura de gain visuels).
Le flux vid<69>o aura encore des points de recherche <20> chaque changement de
de sc<73>ne.
</para></listitem>
<listitem><para>
<emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
Ce sujet risque d'<27>tre une source de controverses.
</para>
<para>
H.264 d<>finit une proc<6F>dure simple pour retirer les blocs sur les I-blocs
qui utilisent des forces et des seuils pr<70>-r<>gl<67>ss en fonction du QP du
bloc en question.
Par d<>faut, les blocs QP <20>lev<65>s sont fortement filtr<74>s, les blocs <20> bas QP
ne seront pas "d<>bloqu<71>s" du tout.
Les pr<70>-r<>glages de force d<>finies par les standards sont bien choisis et
il y a de grandes chances qu'elles aient des PSNR optimaux quel que soit la
vid<69>o que vous compressez.
Les param<61>tres <option>deblockalpha</option> et <option>deblockbeta</option>
permettent de sp<73>cifier des offsets par rapport aux seuils de "d<>blocage"
pr<70>-d<>finis.
</para>
<para>
Il semble que beaucoup de gens pensent que baisser la force du filtre de
"d<>blocage" de beaucoup (par exemple -3) est une bonne id<69>e.
Ce n'est cependant presque jamais une bonne id<69>e, et dans la plupart des cas,
ceux qui font cela ne comprennent pas tr<74>s bien comment le d<>blocage
fonctionne par d<>faut.
</para>
<para>
La premi<6D>re et plus importante chose <20> savoir <20> propos du filtre de d<>blocage
in-loop est que les seuils par d<>faut sont <20> peu pr<70>s toujours optimaux du point de vue du PSNR.
Dans les rares cas o<> ce n'est pas le cas, le d<>calage id<69>al est de plus ou
moins 1.
Ajuster les param<61>tres de d<>blocage avec une quantit<69> plus importante a de forts
risques de d<>grader le PSNR.
Renforcer le filtrage fera dispara<72>tre plus de d<>tails; l'affaiblissement du filtre
augmentera la visibilit<69> des blocs.
</para>
<para>
C'est une mauvaise id<69>e que de baisser les seuils de d<>blocage si
votre source est de complexit<69> spatiale basse (c-<2D>-d avec peu de
d<>tails ou de bruit).
Le filtre in-loop fait un travail plut<75>t bon en cachant les artefacts
qui se produisent.
Cependant, si la source a une complexit<69> spatiale <20>lev<65>e, les
artefacts sont moins apparents.
Ceci vient du fait que "ringing" tend <20> ressembler <20> du d<>tail
ou du bruit.
La vision humaine remarque facilement qu'un d<>tail a <20>t<EFBFBD> enlev<65>
mais elle le remarque plus difficilement s'il y a du bruit faussement
repr<70>sent<6E>.
Subjectivement, le bruit et les d<>tails sont quelque peu interchangeables.
En baissant la force du filtre de d<>blocage, vous allez tr<74>s probablement
avoir des erreurs croissantes en ajoutant des artefacts de ringing mais
l'oeil ne les remarquera pas parce qu'il les confondra avec des d<>tails.
</para>
<para>
Ceci ne justifie <emphasis role="bold">toujours</emphasis> pas de diminuer
la force du filtre de d<>blocage.
Vous pouvez g<>n<EFBFBD>ralement obtenir une meilleure qualit<69> de bruit lors du
post-traitement.
Si votre encodage en H.264 est trop flou ou sale, essayez de lui rajouter
<option>-vf noise</option> quand vous jouez votre film encod<6F>.
<option>-vf noise=8a:4a</option> devrait cacher la plupart des artefacts
simples.
Cela aura l'air certainement mieux ce que ous obtiendriez en jouant
juste avec le filtre de d<>blocage.
</para></listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2 id="menc-feat-x264-example-settings">
<title>Exemples de param<61>tre d'encodage</title>
<para>
Les param<61>tres ci-dessous sont des exemples de diff<66>rentes combinaisons
d'option de compression illustrant le compromis entre vitesse et
qualit<69> pour un m<>me bitrate.
</para>
<para>
Tous les param<61>tres d'encodage sont test<73>s sur un <20>chantillon vid<69>o <20>
720x448 @30000/1001 fps, le bitrate cible est <20> 900kbps, et la machine
est un AMD-64 3400+ <20> 2400 Mhz en mode 64 bits.
Chaque param<61>tre d'encodage exploite la vitesse de compression mesur<75>e (en
frames par seconde) et la perte PSNR (en dB) en la comparant au param<61>tre
de "tr<74>s haute qualit<69>".
Veuillez comprendre que selon votre source, le type de votre machine et
les derniers d<>veloppements logiciels, vous pourrez obtenir des r<>sultats
tr<74>s diff<66>rents.
</para>
<para>
<informaltable frame="all">
<tgroup cols="4">
<thead>
<row><entry>Description</entry><entry>Options d'encodage</entry><entry>vitesse (en fps)</entry><entry>Perte PSNR relative (en dB)</entry></row>
</thead>
<tbody>
<row>
<entry>Tr<EFBFBD>s haute qualit<69></entry>
<entry><option>subq=6:4x4mv:8x8dct:me=3:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
<entry>6fps</entry>
<entry>0dB</entry>
</row>
<row>
<entry>Haute qualit<69></entry>
<entry><option>subq=5:4x4mv:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
<entry>13fps</entry>
<entry>-0.89dB</entry>
</row>
<row>
<entry>Rapide</entry>
<entry><option>subq=4:bframes=2:b_pyramid:weight_b</option></entry>
<entry>17fps</entry>
<entry>-1.48dB</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</sect2>
</sect1>
<sect1 id="menc-feat-vcd-dvd">
<title>Utiliser MEncoder pour cr<63>er des fichiers conforme VCD/SVCD/DVD.</title>
<sect2 id="menc-feat-vcd-dvd-constraints">
<title>Contraintes de Format</title>
<para>
<application>MEncoder</application> est capable de cr<63>er des fichiers MPEG
au format VCD, SCVD et DVD en utilisant la biblioth<74>que
<systemitem class="library">libavcodec</systemitem>.
Ces fichiers peuvent ensuite <20>tre utilis<69>s avec
<ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink>
ou
<ulink url="http://dvdauthor.sourceforge.net/">dvdauthor</ulink>
pour cr<63>er des disques lisibles par une platine de salon standard.
</para>
<para>
Les formats DVD, SVCD, et VCD sont sujets <20> de lourdes contraintes.
Seule une petite s<>lection des tailles d'image encod<6F>e et taux d'aspect
est disponible.
Si votre film ne respecte pas d<>j<EFBFBD> ces conditions, vous pouvez
avoir <20> dimensionner, d<>couper ou ajouter des bords noirs <20> l'image pour
la rendre conforme.
</para>
<sect3 id="menc-feat-vcd-dvd-constraints-resolution">
<title>Contraintes de format</title>
<informaltable frame="all">
<tgroup cols="9">
<thead>
<row>
<entry>Format</entry>
<entry>R<EFBFBD>solution</entry>
<entry>V. Codec</entry>
<entry>V. Bitrate</entry>
<entry>Taux d'<27>chantillonnage</entry>
<entry>A. Codec</entry>
<entry>A. Bitrate</entry>
<entry>FPS</entry>
<entry>Aspect</entry>
</row>
</thead>
<tbody>
<row>
<entry>NTSC DVD</entry>
<entry>720x480, 704x480, 352x480, 352x240</entry>
<entry>MPEG-2</entry>
<entry>9800 kbps</entry>
<entry>48000 Hz</entry>
<entry>AC3,PCM</entry>
<entry>1536 kbps (max)</entry>
<entry>30000/1001, 24000/1001</entry>
<entry>4:3, 16:9 (seulement pour 720x480)</entry>
</row>
<row>
<entry>NTSC DVD</entry>
<entry>352x240<footnote id='fn-rare-resolutions'><para>
Ces r<>solutions sont rarement utilis<69>es pour les DVDs
parce qu'ils ont une assez basse qualit<69>.</para></footnote></entry>
<entry>MPEG-1</entry>
<entry>1856 kbps</entry>
<entry>48000 Hz</entry>
<entry>AC3,PCM</entry>
<entry>1536 kbps (max)</entry>
<entry>30000/1001, 24000/1001</entry>
<entry>4:3, 16:9</entry>
</row>
<row>
<entry>NTSC SVCD</entry>
<entry>480x480</entry>
<entry>MPEG-2</entry>
<entry>2600 kbps</entry>
<entry>44100 Hz</entry>
<entry>MP2</entry>
<entry>384 kbps (max)</entry>
<entry>30000/1001</entry>
<entry>4:3</entry>
</row>
<row>
<entry>NTSC VCD</entry>
<entry>352x240</entry>
<entry>MPEG-1</entry>
<entry>1150 kbps</entry>
<entry>44100 Hz</entry>
<entry>MP2</entry>
<entry>224 kbps</entry>
<entry>24000/1001, 30000/1001</entry>
<entry>4:3</entry>
</row>
<row>
<entry>PAL DVD</entry>
<entry>720x576, 704x576, 352x576, 352x288</entry>
<entry>MPEG-2</entry>
<entry>9800 kbps</entry>
<entry>48000 Hz</entry>
<entry>MP2,AC3,PCM</entry>
<entry>1536 kbps (max)</entry>
<entry>25</entry>
<entry>4:3, 16:9 (seulement pour 720x576)</entry>
</row>
<row>
<entry>PAL DVD</entry>
<entry>352x288<footnoteref linkend='fn-rare-resolutions'/></entry>
<entry>MPEG-1</entry>
<entry>1856 kbps</entry>
<entry>48000 Hz</entry>
<entry>MP2,AC3,PCM</entry>
<entry>1536 kbps (max)</entry>
<entry>25</entry>
<entry>4:3, 16:9</entry>
</row>
<row>
<entry>PAL SVCD</entry>
<entry>480x576</entry>
<entry>MPEG-2</entry>
<entry>2600 kbps</entry>
<entry>44100 Hz</entry>
<entry>MP2</entry>
<entry>384 kbps (max)</entry>
<entry>25</entry>
<entry>4:3</entry>
</row>
<row>
<entry>PAL VCD</entry>
<entry>352x288</entry>
<entry>MPEG-1</entry>
<entry>1152 kbps</entry>
<entry>44100 Hz</entry>
<entry>MP2</entry>
<entry>224 kbps</entry>
<entry>25</entry>
<entry>4:3</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
Si votre film a un aspect 2.35:1 (la plupart des films d'action r<>cents), vous
devrez ajouter des bords noirs ou d<>couper le film <20> un aspect 16:9
pour faire un DVD ou un VCD.
Si vous ajoutez des bords noirs, essayez de les aligner aux fronti<74>res de
16-pixels de fa<66>on <20> minimiser l'impact sur la performance d'encodage.
Le DVD a heureusement un bitrate suffisamment <20>lev<65> pour que vous n'ayez pas trop
<20> vous inqui<75>ter pour l'efficacit<69> de l'encodage, mais le SVCD et le VCD sont
gaspillent tellement de bitrate qu'ils demandent beaucoup d'efforts pour avoir
une qualit<69> acceptable.
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-constraints-gop">
<title>Contraintes de Taille GOP</title>
<para>
DVD, VCD, et SVCD vous contraignent aussi <20> des tailles relativement basses
de GOP (Group of Pictures ou "Groupe d'Images").
Pour des mat<61>riaux <20> 30 fps la plus large taille de GOP permise est 18.
Pour 25 ou 24 fps, le maximum est 15.
La taille du GOP est r<>gl<67>e en utilisant l'option <option>keyint</option>.
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-constraints-bitrate">
<title>Contraintes de Bitrate</title>
<para>
Une vid<69>o VCD doit <20>tre n<>cessairement en CBR <20> 1152 kbps.
Cette contrainte grandement limitante vient aussi avec une taille du buffer
vbv de 327 kilobits extr<74>mement basse.
SVCD permet de varier des bitrates vid<69>o jusqu'<27> 2500 kbps, et une taille du buffer vbv l<>g<EFBFBD>rement
moins restrictive de 917 kilobits est permise.
Les bitrates de vid<69>o DVD peuvent aller jusqu'<27> 9800 kbps
(bien que les bitrates typiques valent <20> peu pr<70>s la moiti<74> de <20>a), et la taille
du buffer vbv est 1835 kilobits.
</para>
</sect3>
</sect2>
<sect2 id="menc-feat-vcd-dvd-output">
<title>Options de sortie</title>
<para>
<application>MEncoder</application> a des options de contr<74>le du format
de sortie.
En utilisant ces options nous pouvons lui dire de cr<63>er le type correct de
fichier.
</para>
<para>
Les options pour le VCD et le SVCD sont appel<65>es xvcd et xsvcd, parce que ce
sont des formats <20>tendus.
Elles ne sont pas strictement conforme, principalement parce que la sortie
ne contient pas de d<>calages de scan.
Si vous avez besoin de g<>n<EFBFBD>rer une image SVCD, vous devriez passer le fichier
de sortie <20> <ulink url="http://www.gnu.org/software/vcdimager/vcdimager.html">vcdimager</ulink>.
</para>
<para>
VCD:
<screen>
-of mpeg -mpegopts format=xvcd
</screen>
</para>
<para>
SVCD:
<screen>
-of mpeg -mpegopts format=xsvcd
</screen>
</para>
<para>
DVD:
<screen>
-of mpeg -mpegopts format=dvd
</screen>
</para>
<para>
DVD avec NTSC <20>tir<69>:
<screen>
-of mpeg -mpegopts format=dvd:telecine -ofps 24000/1001
</screen>
Ceci permet au contenu progressif <20> 24000/1001 fps d'<27>tre encod<6F> <20>
30000/1001 fps tout en conservant le support DVD.
</para>
<sect3 id="menc-feat-vcd-dvd-output-aspect">
<title>Rapport d'aspect</title>
<para>
L'argument d'aspect <option>-lavcopts</option> est utilis<69> pour encoder
le rapport d'aspect du fichier.
Durant la lecture le rapport d'aspect est utilis<69> pour redonner <20> la vid<69>o
la taille correcte.
</para>
<para>
16:9 ou "<22>cran Large"
<screen>
-lavcopts aspect=16/9
</screen>
</para>
<para>
4:3 ou "Plein <20>cran"
<screen>
-lavcopts aspect=4/3
</screen>
</para>
<para>
2.35:1 ou NTSC "Cin<69>mascope"
<screen>
-vf scale=720:368,expand=720:480 -lavcopts aspect=16/9
</screen>
Pour calculer la taille correcte de dimensionnement, utilisez la largeur
<20>tendu NTSC de 854/2.35 = 368
</para>
<para>
2.35:1 ou PAL "Cin<69>mascope"
<screen>
-vf scale="720:432,expand=720:576 -lavcopts aspect=16/9
</screen>
Pour calculer la taille correcte de dimensionnement, utilisez la largeur
<20>tendu PAL de 1024/2.35 = 432
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-output-srate">
<title>Conversion du Taux d'<27>chantillonnage</title>
<para>
Si le taux d'<27>chantillonnage de l'audio du fichier original n'est pas le m<>me
que celui demand<6E> par le format cible, la conversion du taux d'<27>chantillonnage
est requis.
Ceci est r<>alis<69> en utilisant ensemble l'option <option>-srate</option> et le
filtre audio <option>-af lavcresample</option>.
</para>
<para>
DVD:
<screen>
-srate 48000 -af lavcresample=48000
</screen>
</para>
<para>
VCD et SVCD:
<screen>
-srate 44100 -af lavcresample=44100
</screen>
</para>
</sect3>
</sect2>
<sect2 id="menc-feat-vcd-dvd-lavc">
<title>Utiliser libavcodec pour l'encodage VCD/SVCD/DVD</title>
<sect3 id="menc-feat-vcd-dvd-lavc-intro">
<title>Introduction</title>
<para>
<systemitem class="library">libavcodec</systemitem> peut <20>tre utilis<69> pour cr<63>er
des vid<69>os conformes aux standards VCD/SVCD/DVD en utilisant les options appropri<72>es.
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-lavc-options">
<title>lavcopts</title>
<para>
Ceci est une liste de champs de <option>-lavcopts</option> que
vous pourriez avoir besoin de changer si vous voulez convertir
film en VCD, SVCD, ou DVD:
</para>
<itemizedlist>
<listitem><para>
<emphasis role="bold">acodec</emphasis>:
<option>mp2</option> pour le VCD, le SVCD, ou le DVD PAL;
<option>ac3</option> est plus commun<75>ment utilis<69> pour le DVD.
L'audio PCM peut aussi <20>tre utilis<69>e pour le DVD, mais c'est surtout
une grosse perte d'espace.
Notez que l'audio MP3 n'est compatible avec aucun de ces formats, cependant
les lecteurs n'ont souvent aucun probl<62>me pour les jouer.
</para></listitem>
<listitem><para>
<emphasis role="bold">abitrate</emphasis>:
224 pour le VCD; jusqu'<27> 384 pour le SVCD; jusqu'<27> 1536 pour le DVD, mais
utilise commun<75>ment une gamme de valeurs de 192 kbps pour le st<73>r<EFBFBD>o <20>
384 kbps pour le son canaux 5.1.
</para></listitem>
<listitem><para>
<emphasis role="bold">vcodec</emphasis>:
<option>mpeg1video</option> pour le VCD;
<option>mpeg2video</option> pour le SVCD;
<option>mpeg2video</option> est habituellement utilis<69> pour le DVD mais on peut
aussi utiliser <option>mpeg1video</option> pour des r<>solutions CIF.
</para></listitem>
<listitem><para>
<emphasis role="bold">keyint</emphasis>:
Utilis<69> pour r<>gler la taille du GOP.
18 pour les mat<61>riaux <20> 30 fps, ou 15 pour les mat<61>riaux <20> 25/24 fps.
Les producteurs commerciaux semblent pr<70>f<EFBFBD>rer des keyframe <20> des intervalles
de 12.
Il est possible d'augmenter cette valeur et de rester compatible avec la
plupart des lecteurs.
Un <option>keyint</option> de 25 ne devrait jamais causer de probl<62>mes.
</para></listitem>
<listitem><para>
<emphasis role="bold">vrc_buf_size</emphasis>:
327 pour le VCD, 917 pour le SVCD, et 1835 pour le DVD.
</para></listitem>
<listitem><para>
<emphasis role="bold">vrc_minrate</emphasis>:
1152, pour le VCD. Peut <20>tre laiss<73> seul pour le SVCD et le DVD.
</para></listitem>
<listitem><para>
<emphasis role="bold">vrc_maxrate</emphasis>:
1152 pour le VCD; 2500 pour le SVCD; 9800 pour le DVD.
Pour le SVCD et le DVD, vous pouvez souhaiter utiliser des valeurs plus
basses selon vos pr<70>f<EFBFBD>rences.
</para></listitem>
<listitem><para>
<emphasis role="bold">vbitrate</emphasis>:
1152 pour le VCD;
jusqu'<27> 2500 pour le SVCD;
jusqu'<27> 9800 pour le DVD.
Pour les deux derniers formats, les valeurs de vbitrate devrait <20>tre r<>gl<67>es
selon vos go<67>ts.
Par exemple, si vous insistez pour faire tenir 20 heures ou plus sur un DVD,
vous pouvez utiliser vbitrate=400.
La qualit<69> vid<69>o r<>sultante sera probablement assez mauvaise.
Si vous essayez d'avoir la qualit<69> maximum possible sur un DVD, utilisez
vbitrate=9800, mais sachez que cela pourrait vous forcer
<20> ne stocker que moins d'une heure de vid<69>o sur un DVD simple couche.
</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="menc-feat-vcd-dvd-lavc-examples">
<title>Exemples</title>
<para>
Ceci est un param<61>trage typique minimal de <option>-lavcopts</option> pour
encoder une vid<69>o:
</para>
<para>
VCD:
<screen>
-lavcopts vcodec=mpeg1video:vrc_buf_size=327:vrc_minrate=1152:\
vrc_maxrate=1152:vbitrate=1152:keyint=15:acodec=mp2
</screen>
</para>
<para>
SVCD:
<screen>
-lavcopts vcodec=mpeg2video:vrc_buf_size=917:vrc_maxrate=2500:vbitrate=1800:\
keyint=15:acodec=mp2
</screen>
</para>
<para>
DVD:
<screen>
-lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\
keyint=15:acodec=ac3
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-lavc-advanced">
<title>Options Avanc<6E></title>
<para>
Pour une qualit<69> d'encodage plus <20>lev<65>e, vous pouvez aussi souhaiter ajouter
des options d'am<61>lioration de qualit<69> <20> lavcopts, comme <option>trell</option>,
<option>mbd=2</option>, et autres.
Notez que, bien que <option>qpel</option> et <option>v4mv</option> soient souvent
utile avec le MPEG-4, elles ne sont pas utilisables avec MPEG-1 ou MPEG-2.
Aussi, si vous essayez de cr<63>er un encodage DVD de tr<74>s haute qualit<69>,
peut-il <20>tre utile d'ajouter <option>dc=10</option> <20> lavcopts.
Le faire peut aider <20> r<>duire l'apparition de blocs dans les zones plates
color<6F>es.
Pour r<>sumer, la ligne suivante est un exemple de param<61>trage de lavcopts
pour une meilleure qualit<69> pour un DVD:
</para>
<para>
<screen>
-lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=8000:\
keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:\
vqmin=1:lmin=1:dc=10
</screen>
</para>
</sect3>
</sect2>
<sect2 id="menc-feat-vcd-dvd-audio">
<title>Encodage Audio</title>
<para>
Les VCD et SVCD supportent l'audio MPEG-1 layer II, en utilisant un des
encodeurs MP2 <systemitem class="library">toolame</systemitem>,
<systemitem class="library">twolame</systemitem>,
ou <systemitem class="library">libavcodec</systemitem>.
Le MP2 libavcodec est loin d'<27>tre aussi bon que les deux autres biblioth<74>ques,
cependant il devrait toujours <20>tre disponible en utilisation.
Les VCD ne supportent que l'audio avec un bitrate constant (CBR) alors que les SVCD
supportent aussi le bitrate variable (VBR).
Soyez prudents lors de l'utilisation du VBR car certains mauvais lecteurs
pourraient ne pas trop bien le supporter.
</para>
<para>
Pour l'audio DVD, le codec AC3 de <systemitem class="library">libavcodec</systemitem>
est utilis<69>.
</para>
<sect3 id="menc-feat-vcd-dvd-audio-toolame">
<title>toolame</title>
<para>
Pour un VCD et un SVCD:
<screen>
-oac toolame -toolameopts br=224
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-audio-twolame">
<title>twolame</title>
<para>
Pour un VCD et un SVCD:
<screen>
-oac twolame -twolameopts br=224
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-audio-lavc">
<title>libavcodec</title>
<para>
Pour un DVD avec un son 2 canaux:
<screen>
-oac lavc -lavcopts acodec=ac3:abitrate=192
</screen>
</para>
<para>
Pour un DVD avec un son 5.1 canaux:
<screen>
-channels 6 -oac lavc -lavcopts acodec=ac3:abitrate=384
</screen>
</para>
<para>
Pour un VCD et un SVCD:
<screen>
-oac lavc -lavcopts acodec=mp2:abitrate=224
</screen>
</para>
</sect3>
</sect2>
<sect2 id="menc-feat-vcd-dvd-all">
<title>Combiner le tout</title>
<para>
Cette section pr<70>sente certaines commandes compl<70>tes pour cr<63>er des vid<69>os
compatibles VCD/SVCD/DVD.
</para>
<sect3 id="menc-feat-vcd-dvd-all-pal-dvd">
<title>DVD PAL</title>
<para>
<screen>
mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\
harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:\
abitrate=192:aspect=16/9 -ofps 25 \
-o <replaceable>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-all-ntsc-dvd">
<title>DVD NTSC</title>
<para>
<screen>
mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:480,\
harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:\
abitrate=192:aspect=16/9 -ofps 30000/1001 \
-o <replaceable>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-all-pal-ac3-copy">
<title>AVI PAL Contenant Audio AC3 vers DVD</title>
<para>
Si la source a d<>j<EFBFBD> l'audio en AC3, utilise la copie -oac au lieu de la r<>-encoder.
<screen>
mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,\
harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:\
vbitrate=5000:keyint=15:aspect=16/9 -ofps 25 \
-o <replaceable>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-all-ntsc-ac3-copy">
<title>AVI NTSC Contenant Audio AC3 vers DVD</title>
<para>
Si la source a d<>j<EFBFBD> l'audio en AC3, et est en NTSC @ 24000/1001 fps:
<screen>
mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd:telecine \
-vf scale=720:480,harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:\
vrc_maxrate=9800:vbitrate=5000:keyint=15:aspect=16/9 -ofps 24000/1001 \
-o <replaceable>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-all-pal-svcd">
<title>SVCD PAL</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>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-all-ntsc-svcd">
<title>SVCD NTSC</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>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-all-pal-vcd">
<title>VCD PAL</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>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
<sect3 id="menc-feat-vcd-dvd-all-ntsc-vcd">
<title>VCD NTSC</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>film.mpg</replaceable> <replaceable>film.avi</replaceable>
</screen>
</para>
</sect3>
</sect2>
</sect1>
</chapter>