comparison DOCS/xml/fr/encoding-guide.xml @ 19237:d1dcbdd74a4d

Part 2 of the various fixes features by Jerome Ferrari

19236:a11efc8d23be

  comme si elle était entièrement entrelacée.
  </para>
  </listitem>

<listitem><para>
  Traitez-la comme entrelacée. Certaines frames des parties progressive auront 
  besoin d'être dupliquées, ce qui entraînera en un sautillement inégal. Encore une 
  fois, les filtres dés-entrelaç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ées vidéo d'un DVD sont stockées dans un format appelé YUV 4:2:0. Dans 
  la vidéo YUV, la luma (&quot;luminosité&quot;) et le chroma (&quot;couleur&quot;)
  sont stockés séparément. Parce que l'oeil humain est somme toute moins sensible
  à la couleur qu'il ne l'est à la luminosité, 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é de quatre pixels de luma (deux sur chaque coté) ont un pixel de 
  chroma commun. Vous devez découper un YUV 4:2:0 progressif à 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 à faire à un YUV 4:2:0 entrelacé, la situation devient un peu plus
  compliqué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é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é, ils sont deux pixels côte à côte, et les deux autres pixels
  sont côte à côte deux lignes de scan plus bas. Les deux pixels de luma dans la 
  ligne de scan intermédiaire sont à partir de l'autre champ, et donc partage un 
  pixel de chroma diffé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 égal.
  </para>

  <para>
  Pour la vidéo télécinée, je recommande que le découpage prenne place après l'inverse
  téléciné. Une fois la vidéo progressive vous avez seulement besoin de découper par 
  nombres pairs. Si vous voulez vraiment gagner la légère accélération que la découpe
  peut offrir, vous devez découper verticalement par multiples de quatre
  ou bien le filtre inverse-téléciné n'aura pas les bonnes données.
  </para>

  <para>
  Pour la vidéo entrelacée (pas télécinée), vous devez toujours découper verticalement
  par multiples de quatre à moins que vous n'utilisiez <option>-vf field</option> avant de découper.
  </para>
  </listitem>

<listitem><formalpara>
  <title>A propos des paramètres d'encodage et de la qualité:</title>
  <para>
  Juste parce que je recommande <option>mbd=2</option> ici ne veut pas dire
  que cela ne devrait pas être utilisé 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é, et vous devriez toujours utiliser au moins 
  une des deux à 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é d'encodage (et réduisent la vitesse d'encodage) mais ceci est au delà
  de la porté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éo progressive est sûr, et est habituellement une bonne idée à moins qu'il
  ait été vérifié que la source est entiè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ées pour <option>lavcopts</option> masquent cette 
  différence, en limitant la perte de performance due à l'utilisation de <option>pullup</option> à 2%.
  </para>
  </formalpara>
  </listitem>

fournit un encodage simple pour plusieurs formats vidéos et audio intéressants.
Vous pouvez encoder vers les codecs suivant (la liste suivante est plus ou moins à jour):
</para>

<sect2 id="menc-feat-enc-libavcodec-video-codecs">
<title>codecs vidéo de <systemitem class="library">libavcodec</systemitem></title>

<para>
<informaltable frame="all">
<tgroup cols="2">
<thead>

  </entry></row>
</tbody>
</tgroup>
</informaltable>

La première colonne contient les noms de codec qui doivent être passés aprè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>

  </row>
</tbody>
</tgroup>
</informaltable>

La première colonne contient les noms du codec qui devra être passée après l'option 
<literal>acodec</literal>, comme ceci: <option>-lavcopts acodec=ac3</option>
</para>

<informalexample>
<para>
Un exemple avec compression AC3:

</para>
</informalexample>

<para>
  Contrairement aux codecs vidé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èles psycho-accoustiques minimaux (quand ils en ont)
  ce que la plupart des autres implémentations de codec comportent.
  Cependant, notez que tous ces codecs audio sont très rapides et fonctionnent qu'importe
  leur environnement à partir du moment où <application>MEncoder</application> a été
  compilée avec <systemitem class="library">libavcodec</systemitem> (ce qui est le
  cas la plupart du temps), et ne dépend pas de bibliothèques externes.
</para>
</sect2>

<title>Options d'encodage de libavcodec</title>

<para>
  Idéalement, vous voudriez probablement juste dire à mencoder de passer en 
  mode "haute qualité" et passer à autre chose.
  Ce serait sûrement sympa, mais c'est malheureusement dur à faire vu que les 
  différentes options d'encodage donnent différents résultats de qualité 
  en fonction du matériel source.
  Ceci vient du fait que la compression dépende des propriétés visuelles
  de la vidéo en question.
  Par exemple, un film d'animation et un film d'action ont des propriétés très 
  différentes et nécessitent des options différentes pour obtenir un encodage 
  optimal.
  La bonne nouvelle, c'est que certaines options ne devraient jamais être mise à 
  part, comme <option>mbd=2</option>, <option>trell</option>, et <option>v4mv</option>.
  Voir ci-dessous pour une description détaillée des options d'encodage communes.
</para>


<itemizedlist>
<title>Options à 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ène, ce qui n'est pas une bonne idée étant donné que cela 
  affectera un peu l'efficacité d'encodage.
</para></listitem>

<listitem><para>
  <emphasis role="bold">vb_strategy=1</emphasis>: aide aux scènes avec de rapides 
  mouvements.
  Sur certaines vidéos, vmax_b_frames peut affecter la qualité, mais 
  vmax_b_frames=2 avec vb_strategy=1 aideront.
</para></listitem>

<listitem><para>
  <emphasis role="bold">dia</emphasis>: portée de recherche de mouvement. Le plus large 
  est l'écart; ce sera mieux, mais aussi plus lent.
  Des valeurs négatives sont une échelle complètement diffé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é-passe de recherche de mouvement.
  Pas aussi important que dia. De bonnes valeurs sont 1 (par défaut) à 4. Cela 
  demande preme=2 pour ê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-être ou non un peu mieux, mais c'est lent.
</para></listitem>

<listitem><para>
  <emphasis role="bold">last_pred</emphasis>: Nombre de prédicateurs de mouvement 
  à prendre depuis la frame précédente.
  1-3 (ou dans ces eaux) amé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ôle la sélection de macroblocs.
  Un petit coût en vitesse pour un petit gain en qualité.
</para></listitem>

<listitem><para>
  <emphasis role="bold">qprd</emphasis>: quantification adaptative basée sur la
  complexité du macrobloc.
  Peut aider ou aggraver la situation ceci dépend de la vidéo et des autres options.
  Cela peut causer des artefacts à moins que vous ne paramétriez vqmax à certaines
  valeurs raisonnablement petites (6 c'est bien, voire peut-être 4); 
  vqmin=1 devrait aussi aider.
</para></listitem>

<listitem><para>
  <emphasis role="bold">qns</emphasis>: très lente, spécialement quand combinée
  avec qprd.
  Cette option dira l'encodeur à minimiser le bruit dû à la compression
  d'artefact au lieu de faire strictement ressembler la vidéo encodée à la 
  source.
  N'utilisez pas ceci à moins d'avoir déjà bidouillé 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ôle de taux.
  Quelles sont les bonnes valeurs qui dépendent du film?
  Vous pouvez de manière sûre laisser cela de côté si vous voulez.
  Réduire vqcomp met plus de bits sur les scènes de basse complexité, l'augmenter 
  les met sur les scènes de haute complexité (défaut: 0.5, portée: 0-1. portée 
  recommandée: 0.5-0.7).
</para></listitem>

<listitem><para>
  <emphasis role="bold">vlelim, vcelim</emphasis>: Paramètre le seuil du seul 
  coefficient d'élimination pour les plans de luminance et de chroma.
  Ceux-là sont encodés séparément dans tous les algorithmes de style MPEG.
  L'idée derrière tout ceci est d'utiliser certaines bonnes heuristiques
  pour déterminer quand le changement dans un bloc est inférieur au seuil que 
  vous avez spécifié, et dans ce cas, de simplement encoder le bloc comme étant 
  "sans changement".
  Cela économisera des bits et accélérera peut-être l'encodage. vlelim=-4 et 
  vcelim=9 semblent ê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és.
</para></listitem>

<listitem><para>
  <emphasis role="bold">qpel</emphasis>: Estimation de mouvement de quart de pixel.
  MPEG-4 utilise la précision de moitié de pixel pour sa recherche de mouvement 
  par défaut, donc cette option vient avec un surplus car plus d'information seront 
  stockées dans le fichier encodé.
  La compression gain/perte dépend du film, mais n'est habituellement pas très 
  efficace sur les animations.
  qpel induit toujours un surcoû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 écrit un fichier journal donnant le type/taille/qualité de chaque frame, et 
  imprime un résumé du PSNR (rapport maximal du signal sur le bruit) à la fin.
</para></listitem>

</itemizedlist>

<itemizedlist>
<title>Options à é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 à la qualité.
  Des valeurs raisonnables peuvent être efficaces dans votre cas, mais soyez prévenu 
  que ceci reste très subjectif.
</para></listitem>

<listitem><para>
  <emphasis role="bold">scplx_mask</emphasis>: Essaie d'éviter l'apparition d'artefacts 
  carrés, mais le post-traitement est le mieux.
</para></listitem>
</itemizedlist>
</sect2>

<sect2 id="menc-feat-mpeg4-lavc-example-settings">

19237:d1dcbdd74a4d

  comme si elle était entièrement entrelacée.
  </para>
  </listitem>

<listitem><para>
  Traitez-le comme entrelacée. Certaines images des parties progressives auront 
  besoin d'être dupliquées, ce qui entraînera un sautillement irrégulier. Encore une 
  fois, les filtres désentrelaçant peuvent légèrement dégrader les parties
  progressives.
  </para></listitem>

</itemizedlist>
</sect3>

</sect2>

<sect2 id="menc-feat-telecine-footnotes">
<title>Notes de bas de pages</title>
<orderedlist>
<listitem><formalpara>
  <title>A propos de recadrage:</title>
  <para>
  Les données vidéo d'un DVD sont stockées dans un format appelé YUV 4:2:0. Dans 
  la vidéo YUV, la luminance (&quot;luminosité&quot;) et la chrominance (&quot;couleur&quot;)
  sont stockés séparément. Parce que l'oeil humain est d'une certaine façon moins sensible
  à la couleur qu'à la luminosité, dans une image YUV 4:2:0 il n'y a 
  qu'un pixel de chrominance pour 4 pixels de luminance. Dans une image progressive, 
  chaque carré de quatre pixels de luminance (deux de chaque coté) a un pixel de 
  chrominance commun. Vous devez recadrer le YUV 4:2:0 progressif à 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 à faire à un YUV 4:2:0 entrelacé, la situation devient un peu plus
  compliquée. Au lieu d'avoir chaque série de quatre pixels de luminance se partager un pixel 
  de chrominance dans une <emphasis>image</emphasis>, chaque série de quatre pixels de luminance 
  dans chaque <emphasis>champs</emphasis> se partage un pixel de chrominance. Quand les 
  trames sont entrelacées pour former une image, chaque ligne de scan fait un 
  pixel de haut. Maintenant, au lieu d'avoir la série de quatre pixels de luminance 
  dans un carré, il y a deux pixels côte à côte sur une ligne et les deux autres pixels
  de la série sont côte à côte deux lignes de scan plus bas. Les deux pixels de luminance dans la 
  ligne de scan intermédiaire appartiennent à une autre trame, et donc partage un 
  pixel de chrominance différent avec deux pixels de luminance deux lignes de scan plus loin. 
  Toute cette confusion rend nécessaire d'avoir des dimensions de recadrage
  et de décalage verticales multiples de quatre. Dans le sens horizontal, il suffit que les 
  dimensions restent paires.
  </para>

  <para>
  Pour la vidéo télécinée, il est recommandé que le recadrage se fasse après le
  téléciné-inverse. Une fois que la vidéo est progressive, il vous suffit de recadrer par 
  nombres pairs. Si vous voulez accélérer légèrement la vitess d'encodage, en jouant sur les
  dimensions de recadrage, vous devez recadrer verticalement par multiples de quatre
  ou bien le filtre de téléciné-inverse n'aura pas les données adéquates.
  </para>

  <para>
  Pour la vidéo entrelacée (pas télécinée), vous devez toujours recadrer verticalement
  par multiples de quatre à moins que vous n'utilisiez l'option <option>-vf field</option> avant.
  </para>
  </listitem>

<listitem><formalpara>
  <title>A propos des paramètres d'encodage et de la qualité:</title>
  <para>
  Le fait que l'option <option>mbd=2</option> est recommandée ici ne veut pas dire
  qu'elle ne devrait pas être utilisée 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 plus la qualité, et vous devriez toujours les utiliser
  à moins que la baisse de vitesse d'encodage ne soit prohibitive 
  (ex: encodage en temps réel). Il y a bien d'autres options de
  <systemitem class="library">libavcodec</systemitem> qui augmentent la qualité d'encodage
  (et réduisent sa rapidité) mais ceci est au delà du propos de ce document.
  </para>
  </formalpara>
  </listitem>

<listitem><formalpara>
  <title>A propos de la performance de pullup:</title>
  <para>
  Utiliser l'option <option>pullup</option> (avec <option>softskip</option>) 
  sur une vidéo progressive est sans danger, et c'est généralement une bonne idée à moins qu'il
  soit certain  que la source est entièrement progressive.
  La perte de performance est faible dans 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ées de <option>lavcopts</option> masquent cette 
  différence, en limitant la perte de performance due à l'utilisation de <option>pullup</option> à 2%.
  </para>
  </formalpara>
  </listitem>

fournit un encodage simple pour plusieurs formats vidéos et audio intéressants.
Vous pouvez encoder vers les codecs suivant (la liste suivante est plus ou moins à jour):
</para>

<sect2 id="menc-feat-enc-libavcodec-video-codecs">
<title>Codecs vidéo de <systemitem class="library">libavcodec</systemitem></title>

<para>
<informaltable frame="all">
<tgroup cols="2">
<thead>

  </entry></row>
</tbody>
</tgroup>
</informaltable>

La première colonne contient les noms de codec qui doivent être donnés après la
configuration de <literal>vcodec</literal>, par exemple 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>

  </row>
</tbody>
</tgroup>
</informaltable>

La première colonne contient les noms de codec qui doivent être donnés après l'option 
<literal>acodec</literal>, par exemple comme ceci: <option>-lavcopts acodec=ac3</option>
</para>

<informalexample>
<para>
Un exemple avec compression AC3:

</para>
</informalexample>

<para>
  Contrairement aux codecs vidéo de <systemitem class="library">libavcodec</systemitem>, 
  ses codecs audio ne font pas un usage avisé des bits qu'ils consomment
  car ils leur manquent certains modèles psycho-acoustiques minimaux (quand ils en ont)
  ce que la plupart des autres implémentations de codecs possèdent.
  Cependant, notez que tous ces codecs audio sont très rapides et sont disponibles
  à partir du moment où <application>MEncoder</application> a été
  compilé avec <systemitem class="library">libavcodec</systemitem> (ce qui est le
  cas la plupart du temps), et ne dépend pas de bibliothèques externes.
</para>
</sect2>

<title>Options d'encodage de libavcodec</title>

<para>
  Idéalement, vous voudriez probablement juste dire à mencoder de passer en 
  mode "haute qualité" et passer à autre chose.
  Ce serait sûrement sympa, mais c'est malheureusement difficile à implémenter car les 
  différentes options d'encodage donnent des résultats de qualité différents
  en fonction du matériel source.
  Ceci vient du fait que la compression dépend des propriétés visuelles
  de la vidéo en question.
  Par exemple, un film d'animation et un film d'action ont des propriétés très 
  différentes et nécessitent des options différentes pour obtenir un encodage 
  optimal.
  La bonne nouvelle, c'est que certaines options ne devraient jamais être omises,
  comme <option>mbd=2</option>, <option>trell</option>, et <option>v4mv</option>.
  Voir ci-dessous pour une description détaillée des options d'encodage les plus communes.
</para>


<itemizedlist>
<title>Options à 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 encodage 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ène, ce qui n'est pas une bonne idée étant donné que cela 
  affectera un peu l'efficacité d'encodage.
</para></listitem>

<listitem><para>
  <emphasis role="bold">vb_strategy=1</emphasis>: aide pour les scènes avec beaucoup de
  mouvement. Sur certaines vidéos, l'option vmax_b_frames peut affecter la qualité, mais
  utiliser vmax_b_frames=2 avec vb_strategy=1 aide.
</para></listitem>

<listitem><para>
  <emphasis role="bold">dia</emphasis>: portée de de la passe de recherche de mouvement.
   Plus la valeur de cette option est élevée, meilleure sera la qualité et plus l'encodage sera lent.
  Les valeurs négatives représentent une échelle complètement diffé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>: portée de recherche de mouvement en pré-passe.
  Pas aussi important que dia. De bonnes valeurs vont de 1 (par défaut) à 4. Cela 
  requière preme=2 pour être réellement utile.
</para></listitem>

<listitem><para>
  <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Fonction de comparaison 
  pour l'estimation de mouvement.
  Testez avec les valeurs 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 
  films d'action.
  6 peut être (ou non) un peu meilleur, mais est lent.
</para></listitem>

<listitem><para>
  <emphasis role="bold">last_pred</emphasis>: Nombre de prédicteurs de mouvement 
  à prendre depuis l'image précédente.
  1-3 (ou dans ces eaux) améliore la qualité pratiquement sans perte en vitesse.
  De plus hautes valeurs ralentiront l'encodage sans réel gain.
</para></listitem>

<listitem><para>
  <emphasis role="bold">cbp, mv0</emphasis>: Contrôle la sélection de macroblocs.
  Un petit coût en vitesse pour un petit gain en qualité.
</para></listitem>

<listitem><para>
  <emphasis role="bold">qprd</emphasis>: quantification adaptative basée sur la
  complexité des macroblocs.
  Peut aider ou gêner selon la vidéo et les autres options.
  Cela peut causer des artefacts à moins que vous ne paramétriez vqmax à des
  valeurs raisonnablement petites (6 c'est bien, voire peut-être 4); 
  vqmin=1 devrait aussi aider.
</para></listitem>

<listitem><para>
  <emphasis role="bold">qns</emphasis>: très lente, spécialement quand combinée
  avec qprd. Avec cette option, l'encodeur minimise le bruit dû aux artefacts de compression
  au lieu de faire correspondre strictement la vidéo encodée à la source.
  Ne l'utilisez pas à moins d'avoir déjà peaufiné tout le reste et que les
  résultats ne soient pas encore assez bons.
</para></listitem>

<listitem><para>
  <emphasis role="bold">vqcomp</emphasis>: mise au point du contrôle de débit.
  La nature du film définiera quelles sont les bonnes valeurs à appliquer
  Vous pouvez sans problème laisser cette option de côté si vous voulez.
  Réduire vqcomp met plus de bits sur les scènes de basse complexité, l'augmenter 
  les met sur les scènes de haute complexité (défaut: 0.5, portée: 0-1. recommandé: 0.5-0.7).
</para></listitem>

<listitem><para>
  <emphasis role="bold">vlelim, vcelim</emphasis>: Définit le coefficient du seuil d'élimination pour
  la luminance et les plans de chrominance.
  Ils sont encodés séparément dans tous les algorithmes de style MPEG.
  L'idée derrière tout ceci est d'utiliser de bonnes heuristiques
  pour déterminer quand le changement dans un bloc est inférieur au seuil que 
  vous avez spécifié, et dans ce cas, de simplement encoder le bloc comme étant 
  "sans changement".
  Cela économise des bits et accélére peut-être l'encodage. vlelim=-4 et 
  vcelim=9 semblent être de bonnes valeurs pour les films de "scènes réelles", mais 
  semblent ne pas aider avec les films d'animation; quand vous voudrez encoder une animation, 
  vous devriez probablement les laisser tel quel.
</para></listitem>

<listitem><para>
  <emphasis role="bold">qpel</emphasis>: Estimation de mouvement de quart de pixel.
  MPEG-4 utilise une précision d'un demi pixel pour sa recherche de mouvement 
  par défaut, donc cette option augmente la quantité d'information qui est 
  stockée dans le fichier encodé. Le gain ou la perte en terme de compression 
  dépend du film, mais ce n'est habituellement pas très efficace pour les animations.
  qpel induit toujours un surcoût significatif en temps de décodage (+25% en pratique).
</para></listitem>

<listitem><para>
  <emphasis role="bold">psnr</emphasis>: n'affecte pas l'encodage
  mais écrit un fichier journal donnant le type/taille/qualité de chaque image, et 
  imprime un résumé du PSNR (rapport signal sur bruit) à la fin.
</para></listitem>

</itemizedlist>

<itemizedlist>
<title>Options qu'il n'est pas recommandé de changer:</title>
<listitem><para>
  <emphasis role="bold">vme</emphasis>: La valeur par défaut est la meilleure.
</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 à la qualité.
  Des valeurs raisonnables peuvent être efficaces dans votre cas, mais soyez prévenu,  
  ceci reste très subjectif.
</para></listitem>

<listitem><para>
  <emphasis role="bold">scplx_mask</emphasis>: Essaie d'empêcher l'apparition d'artefacts 
  dûs aux blocs, mais le post-traitement est plus efficace.
</para></listitem>
</itemizedlist>
</sect2>

<sect2 id="menc-feat-mpeg4-lavc-example-settings">