comparison DOCS/xml/fr/encoding-guide.xml @ 18402:b3c5e79aeab8

2nd part of review by Pierre Lombard + some more fixes by me. Hopefully now this file doesn't like it was babelfished ;)

18401:deb6419b0e85

</para>
<note><title>Note:</title>
<para>
  Augmenter le <option>frameref</option> à des valeurs inutilement élevées
  <emphasis role="bold">peut affecter</emphasis> et <emphasis role="bold">habituellement affecte</emphasis>
  l'efficacité d'encodage si vous arrêtez le CABAC.
  Avec le CABAC activé (comportement par défaut), la possibilité de réglagles
  de <option>frameref</option> "trop élevé" actuellement semble trop distant 
  pour même s'en inquiéter, et dans l'avenir, les optimisations peuvent enlever 
  complètement cette possibilité.
</para>
</note>

<para>
  Si vous vous inquiétez pour la vitesse, un compromis raisonnable est 

  sur le premier passage, et ensuite les augmenter sur le second passage.
  Typiquement, cela a un effet négatif négligeable sur la qualité finale.
  Vous perdrez probablement bien moins de 0.1dB du PSNR, ce qui devrait
  être une différence beaucoup trop faible pour être visible.
  Cependant, des valeurs différentes de <option>frameref</option> peuvent
  parfois affecter le choix du frametype.
  Très probablement, ce sont des cas périphériques rares, mais si vous voulez 
  en être complètement certain, considérez que votre vidéo a soit des modèles 
  plein écran, clignotants et répétitifs, soit des occlusions provisoires très 
  grandes qui forcent une I-frame.
  Ajustez le <option>frameref</option> de premier passage pour qu'il soit assez 

  premier passage à 3 ou plus.
  Le problème est probablement extrêmement rare sur des matériaux vidéo de type 
  action en directe, mais cela arrive quelquefois dans des captures de jeu vidéo.
</para></listitem>

<!--STARTOF-REREADME-->
<listitem><para>
  <emphasis role="bold">me</emphasis>:
  Cette option est pour choisir la méthode de recherche d'estimation de mouvement.
  Modifier cette option fournit une compromis franche entre qualité et vitesse. 
  <option>me=1</option> est seulement quelque pourcent plus rapide que
  la recherche par défaut, à un coût en dessous de 0.1dB du PSNR global. Le 
  paramètre par défaut (<option>me=2</option>) est une compensation raisonnable
  entre vitesse et qualité. <option>me=3</option> gagne un petit peu en dessous 
  de 0.1dB du PSNR global, avec une pénalité sur la vitesse qui varie dépendamment 
  du <option>frameref</option>.  A de hautes valeurs du <option>frameref</option> 
  (e.g. 12 ou autre), <option>me=3</option> est environ 40% plus lente que la 
  valeur par défaut <option> me=2</option>. Avec <option>frameref=3</option>, 
  la pénalité encourue sur la vitesse chute à 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évus. L'activer résulte en une assez consistente perte de 
  vitesse de 10%-15%. Cette option est plutôt inutile dans une source contenant
  seulement des mouvements bas, bien que dans certaines sources de mouvement élevés,
  particulièrement des sources avec beaucoup de petits objets en mouvement, un 
  gain d'environ 0.1dB peut être attendu.
</para>
</listitem>

<listitem><para>
  <emphasis role="bold">bframes</emphasis>:
  Si vous avez l'habitude d'encoder avec d'autre codecs, vous pourriez avoir 
  trouvé que les B-frames ne sont pas toujours utile.
  Avec le H.264, ceci a changé: il y a de nouvelles techniques et types de blocs 
  qui sont possibles avec les B-frames.
  Habituellement, même un choix naïf d'algorithme de B-frame peut avoir un 
  bénéfice significatif sur le PSNR.
  Il est intéressant de noter que l'utilisation de B-frames accélère 
  habituellement le second passage de manière légère, et peut aussi accélèrer 
  un encodage en un seul passage si le choix de B-frame adaptatif est stoppé.
</para>
<para>
  Avec le choix de B-frame adaptatif stoppé
  (<option>nob_adapt</option> de <option>x264encopts</option>),
  la valeur optimale pour le paramètrage est habituellement pas plus que
  <option>bframes=1</option>, ou bien les scènes élevées en mouvement peuvent 
  en patir.
  Avec le choix de B-frame adaptatif activé (le comportement par défaut), il 
  est sûr d'utiliser des valeurs plus élevées; l'encodeur réduira l'utilisation 
  de B-frames dans les scènes où cela pourrait abîmer la compression.
  L'encodeur choisi rarement d'utiliser plus de 3 ou 4 B-frames;
  paramètrer cette option a une valeur plus élevée aura peu d'effet.
</para></listitem>

<listitem><para>
  <emphasis role="bold">b_adapt</emphasis>:
  Note: il est activé par défaut.
</para>
<para>
  Avec cette option activée, l'encodeur utilisera un traitement de choix 
  raisonnablement rapide pour réduire le nombre de B-frames utilisés par les 
  scènes qui ne pourraient pas en bénéficier autant qu'elles le voudraient.
  Vous pouvez utiliser <option>b_bias</option> pour bidouiller combien 
  l'encodeur est heureux de ces B-frames.
  La pénalité sur la vitesse des B-frames adaptatives est actuellement
  plutôt modeste, mais il en est de même pour le gain potentiel en qualité.
  Cela n'endomage pas habituellement, cependant.
  Notez que cela affecte seulement le choix de vitesse et de frametype sur 
  le premier passage.
  <option>b_adapt</option> et <option>b_bias</option> n'ont aucun effet sur 
  les passages suivants.
</para></listitem>

<listitem><para>
  <emphasis role="bold">b_pyramid</emphasis>:
  Vous devriez aussi bien activer cette option si vous utilisez >=2 B-frames;
  comme la page man le dit, vous obtiendrez une faible améliroration de la 
  qualité avec aucun surcoût sur la vitesse.
  Notez que ces vidéos ne peuvent pas être lues sur des décodeurs basés sur 
  une version de libavcodec datant d'avant le 5 Mars, 2005.
</para></listitem>

<listitem><para>
  <emphasis role="bold">weight_b</emphasis>:
  Dans des cas typiques, il n'y a pas assez de gain avec cette option.
  Cependant, dans des scènes crossfades ou fade-to-black, la prédiction de 
  poids donne de plutôt larges bénéfices en bitrate.
  Dans le MPEG-4 ASP, un fade-to-black est habituellement mieux codé comme une 
  série de I-frames onéreuses; utiliser la prédiction de poids dans les 
  B-frames rend possible la conversion d'un certain nombre en de beaucoup plus 
  petites B-frames.
  Le coût sur la durée d'encodage est minimal, étant donné qu'aucun choix 
  supplémentaire n'a besoin d'être fait.
  Aussi, contrairement à ce que les gens semble deviner, les requis en CPU par 
  le décodeur ne sont pas énormement affecté par la prédiction de poids, tout 
  le reste étant égal.
</para>
<para>
  Malheureusement, l'algorithme courant de choix de B-frame adaptative
  a une forte tendance à éviter les B-frames durant les fondus.
  Jusqu'à ce que cela change, il peut être une bonne idée d'ajouter
  <option>nob_adapt</option> à votre x264encopts, si vous vous attendiez
  à ce que le fondu ait un plus grand effet sur votre clip vidéo particulier.
</para></listitem>
</itemizedlist>
</sect3>

<sect3 id="menc-feat-x264-encoding-options-misc-preferences">
<title>Options concernants des préférences diverses</title>
<itemizedlist>
<listitem><para>
  <emphasis role="bold">Encodage en deux passages</emphasis>:
  Ci-dessus, il a été suggéré de toujours utiliser un encodage en deux passages, 
  mais il y a encore des raisons pour ne pas l'utiliser. Par exemple, si vous 
  capturez la télévision en direct et l'encoder en temps réel, vous êtes forcé 
  d'utiliser un encodage en un passage.
  Aussi, un passage est évidemment plus rapide que deux passages; si vous 
  utilisez l'exact même jeu d'options sur les deux passages, deux passages 
  d'encodage est à peu près deux fois plus lent.
</para>
<para>
  Encore, il y a de très bonnes raisons pour utiliser l'encodage en deux passages. 
  Pour une chose, taux de contrôle d'un seul passage n'est pas psychic, et il 
  fait souvent des choix irraisonnables parce qu'il ne peut pas voir l'ensemble 
  de l'image. Par exemple, supposez que vous avez une vidéo de deux minutes de 
  long consistant en deux moitiés distinctes. La première moitié est une scène
  à mouvement élevé durant 60 secondes ce qui, en de manière isolée, demande 
  environ 2500kbps afin d'avoir l'air correcte.
  Immédiatement suivi d'une scène de 60 secondes beaucoup moins demandante qui 
  a l'air bien à 300kbps. Supposez que vous demandiez pour 1400kbps sur la 
  théorie que ceci est suffisant pour accomoder les deux scènes. Un taux de 
  contrôle en un seul passage fera quelques "fautes" dans un cas comme celui-là. 
  Premièrement, il ciblera 1400kbps pour les deux segments. Le premier segment 
  pourrait finir lourdement sur-quantifié, l'entraînant à ressembler à un bloc
  de façon inadmissible et irraisonable. le second segment serait lourdement 
  sous-quantifié; cela pourrait avoir l'air parfait, mais le coût en bitrate de 
  cette perfection sera complètement irraisonnable. Ce qui est d'autant plus dur 
  à éviter que le problème est à la transition entre les deux scènes. Les premières 
  secondes de moitié de mouvement lente sera grandement sur-quantifié, parce que 
  le taux de contrôle prévoit encore le genre de conditions en bitrate qu'il 
  rencontre dans la première moitié de la vidéo. Cette "période d'erreur" de 
  grandement sur-quantifié mouvement faible aura l'air mauvais, et utilisera 
  réellement moins que les 300kbps qu'il aurait pris pour le rendre un semblant 
  correct. IL y a des façons pour atténuer les pièges de l'encodage en simple 
  passage, mais ils peuvent tendre à augmenter la mauvaise prédiction de bitrate.
</para>
<para>
  Le taux de contrôle multiple passage peut offrir d'énormes avantages sur un 
  encodage simple passage.
  En utilisant les statistiques récupérées depuis le premier passage d'encodage, 
  l'encodeur peut estimer, avec une raisonnable exactitude, le "coût" (en bits) 
  de l'encodage de n'importe quelle frame donnée, à n'importe quel quantificateur 
  donné. Cela permet une beaucoup plus rationnelle, mieux plannifiée allocation 
  de bits entre les scènes onéreuses (mouvement élevé) et bon marché (mouvement 
  faible). Voir <option>qcomp</option> ci-dessous pour quelques idées sur comment 
  bidouiller cette allocation à vos besoins.
</para>
<para>
  D'ailleurs, deux passages n'ont pas besoin de prendre deux fois plus de temps 
  qu'un seul passage. Vous pouvez bidouiller les options dans le premier passage
  pour une vitesse plus élevée et une qualité plus faible.
  Si vous choisissez bien vos options, vous pouvez obtenir un premier passage 
  très rapide.
  La qualité résultante dans le second passage sera légèrement plus basse parce 
  que la prédiction de taille est moins précise, mais la différence de qualité 
  est normalement beaucoup trop petite pour être visible. Essayez, par exemple, 
  d'ajouter <option>subq=1:frameref=1</option> au premier passage <option>x264encopts</option>. 
  Ensuite, sur le second passage, utilise des options plus lentes, de plus 
  grandes qualités:
  <option>subq=6:frameref=15:4x4mv:me=3</option>
</para></listitem>
<listitem><para>
  <emphasis role="bold">Encodage en trois passages</emphasis>?

  x264 offre la capacité de faire un nombre arbitraire de passages consécutifs. 
  Si vous spécifiez <option>pass=1</option> sur le premier passage, alors 
  utilisez <option>pass=3</option> sur un passage suivant, le passage suivant
  lira les statistiques depuis le passage précédent, et écrira ses propres 
  statistiques. Un passage additionnel suivant celui-là aura une très bonne base
  depuis laquelle faire des prédictions hautement précises de framesizes à un
  quantificateur choisi. En pratique, les gains sur la qualité d'ensemble de 
  ceci est habituellement proche de zéro, et tout à fait possiblement un 
  troisième passage résultera en un PSNR global légèrement plus mauvais que le 
  passage avant ça. Dans une utilisation typique, trois passages aident si vous 
  obtenez soit une mauvaise prédiction de bitrate ou soit une mauvaise apparence 
  des transitions de scènes lors de l'utilisation de seulement deux passages.
  Ceci peut se produire sur les clips extrêmement courts. Il y a aussi quelques 
  cas spéciaux dans lequels trois (ou plus) passages sont pratiqués pour les 
  utilisateurs avancés, mais par souci de brièveté, ce guide omet de traiter ces 
  cas spéciaux.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qcomp</emphasis>:
  <option>qcomp</option> compense le nombre de bits alloués entre les frames 
  "onéreux" mouvement élevé et les frames "bon marché" mouvement bas. A une 
  extrémité, <option>qcomp=0</option> vis pour le vrai bitrate constant. 
  Typiquement cela rendrait des scènes élevées en mouvement complètement moches, 
  tandis que les scènes basses en mouvement seraient absolument parfaites, mais 
  utiliseraient aussi beaucoup plus de bitrates qu'ils n'en auraient besoin dans 
  le but de les rendre simplement excellentes. A une autre extrémité, <option>qcomp=1</option> 
  réalise le paramètre de quantification (QP) presque constant. Un QP constant 
  n'a pas l'air mauvais, mais la plupart des gens pensent qu'il est plus raisonnable 
  d'enlever quelques bitrates des scènes extrêmement onéreuses (où la perte de 
  qualité ne sera pas aussi apparente) et les ré-allouer aux scènes qui sont 
  plus faciles à encoder à une excellente qualité.
  <option>qcomp</option> est règlé à 0.6 par défaut, ce qui pourrait être un 
  peu faible pour les goûts de plein de gens (0.7-0.8 sont aussi communément 
  utilisé).
</para></listitem>
<listitem><para>
  <emphasis role="bold">keyint</emphasis>:
  <option>keyint</option> est seulement pour compenser l'habilité de recherche 
  de fichiers contre l'efficacité de codage. Par défaut, <option>keyint</option> 
  est paramètré à 250. Sur des matériaux à 25 fps, cela garanti l'habilité de 
  faire une recherche avec une précision de 10 secondes. Si vous pensez qu'il 
  serait important et utile d'être capable de faire une recherche dans les 5 
  secondes de précision, paramètrez <option>keyint=125</option>;
  cela endommagera un peu la qualité/bitrate. Si vous vous inquiétez seulement 
  de la qualité et non de l'habilité à faire une recherche, vous pouvez le 
  paramètrer à des valeurs beaucoup plus élevées (comprenant qu'il y a des 
  retours diminuants qui peuvent devenir extrèmement bas, ou même zéro). Le flux 
  vidéo aura encore des points recherchables aussi longtemps qu'il y aura des 
  changements dans la scène.
</para></listitem> 
<listitem><para>
  <emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
  Ce sujet va être un peu controversé.
</para>
<para>
  H.264 défini une simple procédure de déblocage sur les I-blocs qui utilise
  des pré-règlages de forces et de seuils en dépendance avec le QP du bloc en 
  question.
  Par défaut, des blocs QP élevés sont fortement filtrés, et des blocs QP bas
  ne sont pas débloqués du tout.
  Les pré-règlages de forces définies par les standards sont bien choisis et les 
  chances sont très bonnes pour qu'elles aient des PSNR optimal quelque soit la 
  vidéo que vous essayez d'encoder.
  Les paramètres de <option>deblockalpha</option> et <option>deblockbeta</option>
  vous permettent de spécifier des décalages aux pré-règlages des seuils de 
  déblocage.
</para>
<para>
  Beaucoup de gens semblent penser que c'est une bonne idée de baisser la force
  du filtre de déblocage par de large montants (disons, -3).
  Ce n'est cependant presque jamais une bonne idée, et dans la plupart des cas, 
  les gens qui le font ne comprennent pas très bien comment le déblocage 
  fonctionne par défaut.
</para>
<para>
  La première et plus importante chose à savoir à propos du filtre de déblocage 
  in-loop est que les seuils par défaut sont à peu près toujours optimals PSNR.
  Dans les rares cas où ils ne sont pas optimals, le décalage idéal est plus ou 
  moins 1.
  Ajustant les paramètres de déblocage par un montant plus large est à peu près 
  garanti d'abimer le PSNR.
  Le renforcement du filtre enduira plus de détails; l'affaiblissement du filtre 
  augmentera l'aspect du carré.
</para>
<para>
  C'est définitivement une mauvaise idée de baisser les seuils de déblocage si
  votre source est principalement basse en complexité spaciale (i.e., peu de 
  détail ou bruit).
  Le filtre in-loop fait un travail plutôt excellent en cachant les artefacts 
  qui se surviennent.
  Si la source est élevée en complexité spaciale, cependant, les artefacts sont
  moins apparents.
  C'est parce que le déclencheur tend à ressembler à du détail ou du bruit.
  La perception visuelle humaine remarque facilement quand un détail est enlevé,
  mais elle ne remarque pas si facilement quand le bruit est faussement 
  représenté.
  Quand on en vient à une qualité subjective, bruit et détail sont quelque peu 
  interchangeables.
  En baissant la force du filtre de déblocage, vous aurez des erreurs 
  croissantes le plus susceptible en ajoutant des artefacts qui donneront 
  l'alerte, mais l'oeil ne les remarque pas parce qu'il confond les 
  artefacts avec des détails.
</para>

<para>
  Ceci ne justifie <emphasis role="bold">toujours</emphasis> pas d'abaisser 
  la force du filtre de déblocage, cependant.
  Vous pouvez généralement obtenir une meilleure qualité de bruit du 
  post-traitement.
  Si votre encodage en H.264 est trop flou ou souillé, essayez de lui rajouter
  <option>-vf noise</option> quand vous jouez votre film encodé.
  <option>-vf noise=8a:4a</option> devrez cacher la plupart des simples 
  artefacts.
  Cela aura l'air certainement mieux que les résultats que vous auriez obtenus 
  juste en jouant du violon avec le filtre de déblocage.
</para></listitem>
</itemizedlist>
</sect3>
</sect2>

<sect2 id="menc-feat-x264-example-settings">
<title>Exemples de paramètre d'encodage</title>

<para>
  Les paramètres suivant sont des exemples de différentes combinaisons 
  d'option d'encodage qui affectent la compensation entre la vitesse et 
  la qualité pour le même bitrate cible.
</para>

<para>
  Tous les paramètres d'encodage sont testés sur un échantillon vidéo à 
  720x448 @30000/1001 fps, le bitrate cible était à 900kbps, et la machine 
  était un AMD-64 3400+ à 2400 Mhz en mode 64 bits.
  Chaque paramètre d'encodage exploite la vitesse d'encodage mesuré (en
  frames par seconde) et la perte PSNR (en dB) en la comparant au paramètre 
  de "très haute qualité".
  Veuillez comprendre que dépendemment de votre source, de votre type de machine
  et des avancements en développement, vous pouvez obtenir des résultats très 
  différents.
</para>

<para>
<informaltable frame="all">
<tgroup cols="4">

</informaltable>
</para>
</sect2>

</sect1>
<!--ENDOF-REREADME-->
<sect1 id="menc-feat-vcd-dvd">
<title>Utiliser MEncoder pour créer des fichiers conforme VCD/SVCD/DVD.</title>

<sect2 id="menc-feat-vcd-dvd-constraints">
<title>Contraintes de Format</title>

    <row>
        <entry>Format</entry>
        <entry>Résolution</entry>
        <entry>V. Codec</entry>
        <entry>V. Bitrate</entry>
        <entry>Taux d'Echantillonnage</entry>
        <entry>A. Codec</entry>
        <entry>A. Bitrate</entry>
        <entry>FPS</entry>
        <entry>Aspect</entry>
    </row>

<para>
  DVD, VCD, et SVCD vous contraignent aussi à des tailles relativement basses 
  de GOP (Group of Pictures ou "Groupe d'Images").
  Pour des matériaux à 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é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éo VCD doit être nécessairement en CBR à 1152 kbps.
  Cette contrainte grandement limitante vient aussi avec une taille du buffer 
  vbv de 327 kilobits extrèmement basse.
  SVCD permet de varier des bitrates vidéo jusqu'à 2500 kbps, et une taille du buffer vbv légèrement 
  moins restrictive de 917 kilobits est permise.
  Les bitrates de vidéo DVD peuvent aller jusqu'à 9800 kbps 
  (bien que les bitrates typiques valent à peu près la moitié de ça), et la taille 
  du buffer vbv est 1835 kilobits.

  Durant la lecture le rapport d'aspect est utilisé pour redonner à la vidéo 
  la taille correcte.
</para>

<para>
  16:9 ou "Ecran Large"
  <screen>
  -lavcopts aspect=16/9
  </screen>
</para>

<para>
  4:3 ou "Plein Ecran"
  <screen>
  -lavcopts aspect=4/3
  </screen>
</para>

</para>

</sect3>

<sect3 id="menc-feat-vcd-dvd-output-srate">
<title>Conversion du Taux d'Echantillonnage</title>
<para>
  Si le taux d'échantillonnage de l'audio du fichier original n'est pas le même 
  que celui demandé par le format cible, la conversion du taux d'échantillonnage 
  est requis.
  Ceci est réalisé en utilisant ensemble l'option <option>-srate</option> et le 

  <option>mp2</option> pour le VCD, le SVCD, ou le DVD PAL;
  <option>ac3</option> est plus communément utilisé pour le DVD.
  L'audio PCM peut aussi être utilisé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
  le kecteurs n'ont souvent aucun problème pour les jouer.
</para></listitem>

<listitem><para>
  <emphasis role="bold">abitrate</emphasis>:
  224 pour le VCD; jusqu'à 384 pour le SVCD; jusqu'à 1536 pour le DVD, mais 

  aussi utiliser <option>mpeg1video</option> pour des résolutions CIF.
</para></listitem>

<listitem><para>
  <emphasis role="bold">keyint</emphasis>:
  Utilisé pour règler la taille du GOP.
  18 pour les matériaux à 30 fps, ou 15 pour les matériaux  à 25/24 fps.
  Les producteurs commerciaux semblent préférer des keyframe à des intervalles 
  de 12.
  Il est possible d'augmenter cette valeur et de rester compatible avec la 
  plupart des lecteurs.

  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. Pëut être laissé 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.

<listitem><para>
  <emphasis role="bold">vbitrate</emphasis>:
  1152 pour le VCD;
  jusqu'à 2500 pour le SVCD;
  jusqu'à 9800 pour le DVD.
  Pour les deux derniers formats, les valeurs de vbitrate devrait être règlé
  selon vos goûts.
  Par exemple, si vous insistez pour faire tenir 20 heures ou plus sur un DVD, 
  vous pouvez utiliser vbitrate=400.
  La qualité vidéo résutante sera probablement assez mauvaise.
  Si vous essayez d'avoir la qualité maximum possible sur un DVD, utilisez 
  vbitrate=9800, mais sachez que cela pourrait vous forcer
  à ne stocker que moins d'une heure de vidé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ètrage typique minimal de <option>-lavcopts</option> pour
  encoder une vidéo:
</para>
<para>
  VCD:
  <screen>

  utile avec le MPEG-4, elles ne sont pas utilisables avec MPEG-1 ou MPEG-2.
  Aussi, si vous essayez de créer un encodage DVD de très haute qualité,
  peut-il être utile d'ajouter <option>dc=10</option> à lavcopts.
  Le faire peut aider à réduire l'apparition de blocs dans les zones plates 
  colorées.
  Pour résumer, la ligne suivante est un exemple de paramètrage de lavcopts 
  pour une meilleure qualité pour un DVD:
</para>

<para>
  <screen>

18402:b3c5e79aeab8

</para>
<note><title>Note:</title>
<para>
  Augmenter le <option>frameref</option> à des valeurs inutilement élevées
  <emphasis role="bold">peut affecter</emphasis> et <emphasis role="bold">habituellement affecte</emphasis>
  l'efficacité d'encodage si vous désactivez le CABAC.
  Avec le CABAC activé (comportement par défaut), il n'y a pas vraiment de risque
  qu'un réglage de <option>frameref</option> "trop élevé" diminue l'efficacité
  de l'encodage, et dans l'avenir, des optimisations pouront peut-être
  rendre ce risque nul.
</para>
</note>

<para>
  Si vous vous inquiétez pour la vitesse, un compromis raisonnable est 

  sur le premier passage, et ensuite les augmenter sur le second passage.
  Typiquement, cela a un effet négatif négligeable sur la qualité finale.
  Vous perdrez probablement bien moins de 0.1dB du PSNR, ce qui devrait
  être une différence beaucoup trop faible pour être visible.
  Cependant, des valeurs différentes de <option>frameref</option> peuvent
  parfois affecter le choix du type de frame.
  Très probablement, ce sont des cas périphériques rares, mais si vous voulez 
  en être complètement certain, considérez que votre vidéo a soit des modèles 
  plein écran, clignotants et répétitifs, soit des occlusions provisoires très 
  grandes qui forcent une I-frame.
  Ajustez le <option>frameref</option> de premier passage pour qu'il soit assez 

  premier passage à 3 ou plus.
  Le problème est probablement extrêmement rare sur des matériaux vidéo de type 
  action en directe, mais cela arrive quelquefois dans des captures de jeu vidéo.
</para></listitem>

<listitem><para>
  <emphasis role="bold">me</emphasis>:
  Cette option est utilisée pour choisir une méthode de recherche d'estimation de mouvement.
  Cette option modifie de manière notable le rapport entre qualité et vitesse. 
  <option>me=1</option> est seulement quelques pour cent plus rapide que
  la recherche par défaut et entraîne une diminution du PSNR global inférieure à 0.1dB. Le 
  paramètre par défaut (<option>me=2</option>) est offre un compromis raisonnable
  entre vitesse et qualité. <option>me=3</option> améliore de moins de 0.1dB le
  PSNR global - la pénalité 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é 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évus. L'activer résulte en une perte de vitesse habituellement
  dans les 10% à 15%. Cette option est plutô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 être espéré.
</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é: il y a de nouvelles techniques et types de blocs
  qui sont possibles avec les trames-B.
  Habituellement, même un choix naïf d'algorithme de trames-B peut avoir un
  bénéfice significatif sur le PSNR.
  Il est intéressant de noter que l'utilisation de trames-B accélère
  habituellement légèrement la seconde passe, et peut aussi accélérer
  l'encodage en un seul passage si le choix de trames-B adaptatif est désactivé.
</para>
<para>
  Avec le choix de trames-B adaptatif désactivé
  (l'option <option>nob_adapt</option> de <option>x264encopts</option>),
  le réglage optimal est habituellement inférieur à
  <option>bframes=1</option>, sinon les scènes riches en mouvement vont en souffrir.
  Avec le choix de B-frame adaptatif activé (le comportement par défaut), cela
  ne pose plus de problème d'utiliser des valeurs plus élevées;
  l'encodeur réduira l'utilisation de trames-B dans les scènes pour lesquelles
  cela risque de diminuer la qualité.
  L'encodeur choisi rarement d'utiliser plus de 3 ou 4 trames-B;
  paramétrer cette option à une valeur plus élevée aura peu d'effet.
</para></listitem>

<listitem><para>
  <emphasis role="bold">b_adapt</emphasis>:
  Note: il est activé par défaut.
</para>
<para>
  Avec cette option activée, l'encodeur décidera quand réduire le nombre
  de trames-B utilisées dans les scènes pour lesquelles ces trames
  n'apporteraient rien.
  Vous pouvez utiliser <option>b_bias</option> pour tempérer la tendance
  de l'encodeur à insérer des trames-B.
  Le surcoût sur la vitesse des trames-B adaptatives est actuellement
  plutôt modeste, mais il en est de même pour le gain de qualité potentiel.
  En géné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è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élioration de la 
  qualité sans surcoût en vitesse.
  Notez que ces vidéos ne peuvent pas être lues avec les décodeurs utilisant
  une version de libavcodec antérieur au 5 mars 2005.
</para></listitem>

<listitem><para>
  <emphasis role="bold">weight_b</emphasis>:
  En théorie, il n'y a beaucoup de gain à espérer de cette option.
  En effet, dans des scènes de fondu ou de fondu au noir, la prédiction
  pondérée permet d'économiser beaucoup de bitrate.
  Dans le MPEG-4 ASP, un fondu-au-noir est souvent mieux compressé comme une
  coûteuse série de I-frames; utiliser la prédiction pondérée pour les
  trames-B permet d'en convertir une partie en plus petites B-frames.
  Le coût sur la durée d'encodage est minimal, étant donné qu'aucun choix 
  supplémentaire n'a besoin d'être fait.
  Aussi, contrairement à ce que les gens croient deviner, les besoins en CPU par 
  le décodeur ne sont pas énormément affecté par la prédiction pondérée, toutes
  choses étant égales par ailleurs.
</para>
<para>
  Malheureusement, l'algorithme actuel de choix de trames-B adaptative
  a une forte tendance à éviter les trames-B pendant les fondus.
  Tant que ce sera le cas, ajouter <option>nob_adapt</option>
  à votre x264encopts sera une bonne idée si vous pensez que les
  fondus vont avoir un gros effet dans votre vidéo.
</para></listitem>
</itemizedlist>
</sect3>

<sect3 id="menc-feat-x264-encoding-options-misc-preferences">
<title>Options diverses et/ou dépendant des goûts de chacun</title>
<itemizedlist>
<listitem><para>
  <emphasis role="bold">Encodage en deux passes</emphasis>:
  On a suggéré 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évision en direct et que vous l'encodez en temps réel, vous 
  êtes obligé d'utiliser un encodage mono-passe.
  Aussi, une compression en une passe est évidemment plus rapide qu'une en deux
  passes pour un jeu d'options donné - 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ès bonnes raisons pour utiliser l'encodage en deux passages.
  D'une part, le taux de contrôle d'un seul passage ne peut pas prédire le futur, il
  fait donc souvent des choix sous-optimaux parce qu'il ne peut pas voir l'ensemble 
  de la vidéo. Par exemple, supposez que vous ayez une vidéo de deux minutes 
  consistant en deux moitiés distinctes. La première moitié est une scène
  riche en mouvements pendant 60 secondes, ce qui, hors de tout contexte, demande
  environ 2500kbps afin d'avoir l'air correct.
  Une scène de 60 secondes beaucoup plus statique suit et peut être très bien à
  300kbps. Supposez que vous demandiez 1400kbps sur la 
  théorie que ceci soit suffisant pour les deux scènes. Un taux de 
  contrôle en un seul passage fera quelques "fautes" dans un cas comme celui-là.
  Premiè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
  à éviter que le problème se produit à la transition entre les deux scènes. Les premières 
  secondes de la seconde partie vont être grandement sur-quantifiés, parce que 
  le taux de contrôle suppose qu'il va avoir les mêmes besoins en bitrate que pour
  la première moitié de la vidéo. Cette "période d'erreur" de sur-quantification pour
  les mouvements faibles va étrangement mauvais, et utilisera en réalité moins
  que les 300kbps qu'il aurait pris pour le rendre correct. Il y a des façons
  d'atténuer les pièges de l'encodage en simple passe, mais ils peuvent avoir
  tendance à empirer la mauvaise prédiction de bitrate.
</para>
<para>
  Le taux de contrôle en multi-passes apporte d'énormes avantages sur une
  compression mono-passe. En utilisant les statistiques récupérées depuis le
  premier passage d'encodage, l'encodeur peut estimer, avec exactitude, le "coût"
  (en bits) de l'encodage de n'importe quelle frame donnée, à n'importe quel
  quantificateur donné. Cela permet d'avoir une allocation de bits beaucoup plus
  rationnelle car mieux planifiée entre les scè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ère
  d'adapter cette allocation à 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ère passe
  pour avoir une vitesse plus élevée et une qualité plus faible.
  Si vous choisissez bien vos options, vous pouvez obtenir un premier passage 
  très rapide.
  La qualité résultante de la seconde passe sera légèrement plus basse parce 
  que la prédiction de taille sera moins précise, mais la différence de qualité 
  sera usuellement trop faible pour ê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é:
  <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é de faire un nombre arbitraire de passages consécutifs. 
  Si vous spécifiez <option>pass=1</option> lors de la première passe, alors 
  utilisez <option>pass=3</option> pour la passe suivante, cette passe
  lira les statistiques calculées lors du passage précédent, et écrira ses propres 
  statistiques. Une passe suivante aura une très bonne base depuis laquelle
  faire des prédictions très précises de tailles de trame pour un quantificateur donné.
  En pratique, les gains sur la qualité d'ensemble sont plutôt proches de zéro,
  il est même possible qu'une troisième passe dégrade le PSNR global...
  Pour utilisation typique, trois passages aident si vous obtenez une mauvaise
  prédiction de bitrate ou un mauvais rendu lors des transitions de scènes
  lors de l'utilisation de seulement deux passages.
  Ceci peut se produire sur les clips extrêmement courts. Il y a aussi quelques 
  cas spéciaux dans lesquels trois (ou plus) passages sont utiles pour les 
  utilisateurs avancés, mais par souci de brièveté, ce guide ne traitera pas
  ces cas spéciaux.
</para></listitem>
<listitem><para>
  <emphasis role="bold">qcomp</emphasis>:
  <option>qcomp</option> compense le nombre de bits alloués entre les trames
  coûteuses car riches en mouvement et celles pauvres en mouvement. Dans
  les cas extrêmes, <option>qcomp=0</option> vise un vrai bitrate constant. 
  Typiquement, cela rendrait des scènes riches en mouvements vraiment laides, 
  alors que les scè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ême, <option>qcomp=1</option> rend les paramè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ènes
  coûteuses (car la perte de qualité sera moins visible) et les ré-allouer
  aux scènes qui sont plus faciles à encoder pour qu'elles aient une excellente qualité.
  <option>qcomp</option> vaut 0.6 par défaut, ce qui peut être un 
  peu trop faible pour certains (des valeurs entre 0.7-0.8 sont aussi communément 
  utilisé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écision de la navigation dans les fichiers et leur compression.
  Par défaut, <option>keyint</option> est égal à 250.
  Sur des sources à 25 fps, cela garantit que la navigation peut se faire
  avec une précision de 10 secondes.
  Si vous pensez qu'il est important et utile de pouvoir faire une recherche
  avec une granularité de 5 secondes, mettez cette option à <option>keyint=125</option>;
  cela dégradera un peu la qualité/bitrate. Si vous vous souciez seulement
  de la qualité et non de la capacité à faire une recherche, vous pouvez le
  mettre à des valeurs beaucoup plus élevées (mais gardez à l'esprit que plus
  vous augmenterez, moins il aura de gain visuels).
  Le flux vidéo aura encore des points de recherche à chaque changement de
  de scène.
</para></listitem> 
<listitem><para>
  <emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
  Ce sujet risque d'être une source de controverses.
</para>
<para>
  H.264 définit une procédure simple pour retirer les blocs sur les I-blocs
  qui utilisent des forces et des seuils pré-régléss en fonction du QP du
  bloc en question.
  Par défaut, les blocs QP élevés sont fortement filtrés, les blocs à bas QP
  ne seront pas "débloqués" du tout.
  Les pré-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éo que vous compressez.
  Les paramètres <option>deblockalpha</option> et <option>deblockbeta</option>
  permettent de spécifier des offsets par rapport aux seuils de "déblocage"
  pré-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ée.
  Ce n'est cependant presque jamais une bonne idée, et dans la plupart des cas, 
  ceux qui font cela ne comprennent pas très bien comment le déblocage 
  fonctionne par défaut.
</para>
<para>
  La première et plus importante chose à savoir à propos du filtre de déblocage 
  in-loop est que les seuils par défaut sont à peu près toujours optimaux du point de vue du PSNR.
  Dans les rares cas où ce n'est pas le cas, le décalage idéal est de plus ou 
  moins 1.
  Ajuster les paramètres de déblocage avec une quantité plus importante a de forts
  risques de dégrader le PSNR.
  Renforcer le filtrage fera disparaître plus de détails; l'affaiblissement du filtre 
  augmentera la visibilité des blocs.
</para>
<para>
  C'est une mauvaise idée que de baisser les seuils de déblocage si
  votre source est de complexité spatiale basse (c-à-d avec peu de 
  détails ou de bruit).
  Le filtre in-loop fait un travail plutôt bon en cachant les artefacts 
  qui se produisent.
  Cependant, si la source a une complexité spatiale élevée, les
  artefacts sont moins apparents.
  Ceci vient du fait que "ringing" tend à ressembler à du détail
  ou du bruit.
  La vision humaine remarque facilement qu'un détail a été enlevé
  mais elle le remarque plus difficilement s'il y a du bruit faussement
  représenté.
  Subjectivement, le bruit et les détails sont quelque peu interchangeables.
  En baissant la force du filtre de déblocage, vous allez trè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éralement obtenir une meilleure qualité 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é.
  <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ètre d'encodage</title>

<para>
  Les paramètres ci-dessous sont des exemples de différentes combinaisons 
  d'option de compression illustrant le compromis entre vitesse et
  qualité pour un même bitrate.
</para>

<para>
  Tous les paramètres d'encodage sont testés sur un échantillon vidéo à 
  720x448 @30000/1001 fps, le bitrate cible est à 900kbps, et la machine 
  est un AMD-64 3400+ à 2400 Mhz en mode 64 bits.
  Chaque paramètre d'encodage exploite la vitesse de compression mesurée (en
  frames par seconde) et la perte PSNR (en dB) en la comparant au paramètre 
  de "très haute qualité".
  Veuillez comprendre que selon votre source, le type de votre machine et
  les derniers développements logiciels, vous pourrez obtenir des résultats
  très différents.
</para>

<para>
<informaltable frame="all">
<tgroup cols="4">

</informaltable>
</para>
</sect2>

</sect1>
<sect1 id="menc-feat-vcd-dvd">
<title>Utiliser MEncoder pour créer des fichiers conforme VCD/SVCD/DVD.</title>

<sect2 id="menc-feat-vcd-dvd-constraints">
<title>Contraintes de Format</title>

    <row>
        <entry>Format</entry>
        <entry>Résolution</entry>
        <entry>V. Codec</entry>
        <entry>V. Bitrate</entry>
        <entry>Taux d'échantillonnage</entry>
        <entry>A. Codec</entry>
        <entry>A. Bitrate</entry>
        <entry>FPS</entry>
        <entry>Aspect</entry>
    </row>

<para>
  DVD, VCD, et SVCD vous contraignent aussi à des tailles relativement basses 
  de GOP (Group of Pictures ou "Groupe d'Images").
  Pour des matériaux à 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é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éo VCD doit être nécessairement en CBR à 1152 kbps.
  Cette contrainte grandement limitante vient aussi avec une taille du buffer 
  vbv de 327 kilobits extrêmement basse.
  SVCD permet de varier des bitrates vidéo jusqu'à 2500 kbps, et une taille du buffer vbv légèrement 
  moins restrictive de 917 kilobits est permise.
  Les bitrates de vidéo DVD peuvent aller jusqu'à 9800 kbps 
  (bien que les bitrates typiques valent à peu près la moitié de ça), et la taille 
  du buffer vbv est 1835 kilobits.

  Durant la lecture le rapport d'aspect est utilisé pour redonner à la vidéo 
  la taille correcte.
</para>

<para>
  16:9 ou "Écran Large"
  <screen>
  -lavcopts aspect=16/9
  </screen>
</para>

<para>
  4:3 ou "Plein Écran"
  <screen>
  -lavcopts aspect=4/3
  </screen>
</para>

</para>

</sect3>

<sect3 id="menc-feat-vcd-dvd-output-srate">
<title>Conversion du Taux d'échantillonnage</title>
<para>
  Si le taux d'échantillonnage de l'audio du fichier original n'est pas le même 
  que celui demandé par le format cible, la conversion du taux d'échantillonnage 
  est requis.
  Ceci est réalisé en utilisant ensemble l'option <option>-srate</option> et le 

  <option>mp2</option> pour le VCD, le SVCD, ou le DVD PAL;
  <option>ac3</option> est plus communément utilisé pour le DVD.
  L'audio PCM peut aussi être utilisé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ème pour les jouer.
</para></listitem>

<listitem><para>
  <emphasis role="bold">abitrate</emphasis>:
  224 pour le VCD; jusqu'à 384 pour le SVCD; jusqu'à 1536 pour le DVD, mais 

  aussi utiliser <option>mpeg1video</option> pour des résolutions CIF.
</para></listitem>

<listitem><para>
  <emphasis role="bold">keyint</emphasis>:
  Utilisé pour régler la taille du GOP.
  18 pour les matériaux à 30 fps, ou 15 pour les matériaux  à 25/24 fps.
  Les producteurs commerciaux semblent préférer des keyframe à des intervalles 
  de 12.
  Il est possible d'augmenter cette valeur et de rester compatible avec la 
  plupart des lecteurs.

  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 être laissé 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.

<listitem><para>
  <emphasis role="bold">vbitrate</emphasis>:
  1152 pour le VCD;
  jusqu'à 2500 pour le SVCD;
  jusqu'à 9800 pour le DVD.
  Pour les deux derniers formats, les valeurs de vbitrate devrait être réglées
  selon vos goûts.
  Par exemple, si vous insistez pour faire tenir 20 heures ou plus sur un DVD, 
  vous pouvez utiliser vbitrate=400.
  La qualité vidéo résultante sera probablement assez mauvaise.
  Si vous essayez d'avoir la qualité maximum possible sur un DVD, utilisez 
  vbitrate=9800, mais sachez que cela pourrait vous forcer
  à ne stocker que moins d'une heure de vidé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étrage typique minimal de <option>-lavcopts</option> pour
  encoder une vidéo:
</para>
<para>
  VCD:
  <screen>

  utile avec le MPEG-4, elles ne sont pas utilisables avec MPEG-1 ou MPEG-2.
  Aussi, si vous essayez de créer un encodage DVD de très haute qualité,
  peut-il être utile d'ajouter <option>dc=10</option> à lavcopts.
  Le faire peut aider à réduire l'apparition de blocs dans les zones plates 
  colorées.
  Pour résumer, la ligne suivante est un exemple de paramétrage de lavcopts 
  pour une meilleure qualité pour un DVD:
</para>

<para>
  <screen>