<systemitem class="library">x264</systemitem> est une librairie libre pour encoder
des flux de vidéo H.264/AVC.
Avant de commencer à encoder, vous devez <link linkend="codec-x264-encode">
mettre en place son support pour <application>MEncoder</application></link>.

Commencez, s'il vous plaît, par lire la section
<systemitem class="library">x264</systemitem>
de la page de manuel de
<application>MPlayer</application>.
La présente section a pour but de compléter la page de manuel.

<listitem><para>Le compromis rapidité vs. qualité</para></listitem>
<listitem><para>Les options pour décider du type de frame</para></listitem>
<listitem><para>Le Ratecontrol et les options pour décider de la quantification</para></listitem>

Ce guide traite surtour du premier groupe d'options.
Les deux autres groupes sont plus une affaire de préférences
personnelles et de nécessités individuelles.

Avant tout, veuillez remarquer que ce guide n'utilise qu'une seule
mesure de qualité: le PSNR global.
Pour une brève explication de ce qu'est le PSNR, voir
<ulink url="l'article">http://en.wikipedia.org/wiki/PSNR">l'article de Wikipedia sur le PSNR</ulink>.
Le PSNR global est le dernier nombre généré quand vous activez
l'option <option>psnr</option> dans <option>x264encopts</option>.
A chaque fois que vous lisez une affirmation à propos du PSNR,
l'une des hypothèses sous-jacentes est que l'on utilise des bitrates égaux.

Presque tous les commentaires de ce guide supposent que
vous encodez en deux passages.
Quand on compare l'effet de certaines options, il y a deux raisons
majeures d'encoder en deux passages.
La première, c'est que le mode 'deux passages' permet de gagner
environ 1dB de PSNR, ce qui fait une grosse différence.
La deuxième, c'est qu'on peut douter de la pertinence des
comparaison de qualité en mode "un passage": d'un encodage à
l'autre, le bitrate est sujet des variations significatives.
Il n'est alors pas toujours facile de déterminer si les changements
perçus de qualité sont dus aux choix d'options différents ou seulement
à la différence de bitrate.

Parmi les options qui permettent d'arbitrer entre vitesse et
qualité, <option>subq</option> et <option>frameref</option>
sont généralement les plus importantes.
Si vous désirez jouer sur la vitesse ou la qualité, ce sont les deux
premières options qu'il vous faut considérer.

Au niveau de la vitesse, les options <option>frameref</option> et
<option>subq</option> interagissent assez fortement.
L'expérience montre que, avec une frame de référence,
<option>subq=5</option> prend environ 35% plus de temps que
<option>subq=1</option>.
Avec 6 frames de référence, le malus monte à 60%.
L'effet de <option>subq</option> sur le PSNR semble assez
constant quelquesoit le nombre de frames de référence.
Typiquement, <option>subq=5</option> permet de gagner
0.2-0.5 dB de PSNR global par rapport à <option>subq=1</option>.
La différence est suffisante pour être visible en général.

<emphasis role="bold">frameref</emphasis>:
<option>frameref</option> est fixé à 1 par défaut, mais cela
ne signifie pas que cette valeur est raisonnable.
Le simple fait de monter <option>frameref</option> à 2 permet
de gagner 0.15db de PSNR pour un ralentissement de 5 à 10%.
L'échange semble avantageux.
<option>frameref=3</option> permet de gagner 0.25dB de PSNR par
rapport à <option>frameref=1</option>, ce qui devrait être visible.
<option>frameref=3</option> est environ 15% plus lent que
<option>frameref=1</option>.
Malheureusement, on obtient rapidement des rendements décroissants.
<option>frameref=6</option> ne devrait permettre de gagner que
0.05-0.1 dB sur <option>frameref=3</option>, pour 15% de rapidité
en moins.
Au dessus de <option>frameref=6</option>, les gains de qualité sont
en général minimes (bien que, comme tout au long de cette discussion,
ces résultats peuvent varier grandement en fonction de la source).
Pour un cas suffisamment typique, <option>frameref=12</option>
n'augmentera le PSNR que de 0.02dB par rapport à
<option>frameref=6</option>, pour un coût en rapidité de 15% à 20%.
Pour d'aussi hautes valeurs de <option>frameref</option>, une augmentation
supplémentaire ne <emphasis role="bold">diminuera</emphasis>
très certainement pas le PSNR, mais les éventuels gains supplémentaires
en qualité seront à peine mesurables, et a fortiori imperceptibles.

Augmenter <option>frameref</option> dans des proportions trop importantes
<emphasis role="bold">peut</emphasis> et même
<emphasis role="bold">la plupart du temps</emphasis>
dégrade l'efficacité de de l'encodage si vous désactivez CABAC.
Avec CABAC activé (le comportement par défaut), l'éventualité d'augmenter "trop"
<option>frameref</option> semble assez peu probable pour que vous ayez à
vous en soucier, et à l'avenir, des optimisations pourraient aussi bien rendre ce cas impossible.

Si c'est la rapidité qui vous intéresse, un bon compromis est de
fixer des valeurs basses pour <option>subq</option> et
<option>frameref</option> au premier passage, puis de les augmenter
au second passage. Cela n'a typiquement qu'un effet négligable sur
la qualité finale: vous ne devriez perdre que 0.1dB de PSNR au
maximum, ce qui devrait être trop faible pour être remarquable.
Cependant, la valeur de <option>frameref</option> peut influencer
le choix du type de frame.
Most likely, these are rare outlying cases, but if you want to
be pretty sure, consider whether your video has either
fullscreen repetitive flashing patterns or very large temporary
occlusions which might force an I-frame.
Adjust the first-pass <option>frameref</option> so it is large
enough to contain the duration of the flashing cycle (or occlusion).
For example, if the scene flashes back and forth between two images
over a duration of three frames, set the first pass
<option>frameref</option> to 3 or higher.
Cette difficulté intervient rarement dans les vidéos habituelles,
mais elle peut se présenter dans les captures de jeux video.

<emphasis role="bold">me</emphasis>:
This option is for choosing the motion estimation search method.
Altering this option provides a straightforward quality-vs-speed
tradeoff. <option>me=1</option> is only a few percent faster than
the default search, at a cost of under 0.1dB global PSNR. The
default setting (<option>me=2</option>) is a reasonable tradeoff
between speed and quality. <option>me=3</option> gains a little under
0.1dB global PSNR, with a speed penalty that varies depending on
<option>frameref</option>. At high values of
<option>frameref</option> (e.g. 12 or so), <option>me=3</option>
is about 40% slower than the default <option> me=2</option>. With
<option>frameref=3</option>, the speed penalty incurred drops to
25%-30%.

<option>me=4</option> uses an exhaustive search that is too slow for
practical use.

<emphasis role="bold">4x4mv</emphasis>:
This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
predicted macroblocks. Enabling it results in a fairly consistent
10%-15% loss of speed. This option is rather useless in source
containing only low motion, however in some high-motion source,
particularly source with lots of small moving objects, gains of
about 0.1dB can be expected.

<emphasis role="bold">bframes</emphasis>:
The usefulness of B-frames is questionable in most other codecs
you may be used to.
In H.264, this has changed: there are new techniques and block
types that are possible in B-frames.
Usually, even a naive B-frame choice algorithm can have a
significant PSNR benefit.
It is also interesting to note that if you turn off the adaptive
B-frame decision (<option>nob_adapt</option>), encoding with
<option>bframes</option> usually speeds up encoding speed somewhat.

With adaptive B-frame decision turned off
(<option>x264encopts</option>'s <option>nob_adapt</option>),
the optimal value for this setting will usually range from
<option>bframes=1</option> to <option>bframes=3</option>.
With adaptive B-frame decision on (the default behavior), it is
probably safe to use higher values; the encoder will try to
reduce the use of B-frames in scenes where they would hurt
compression.

If you are going to use <option>bframes</option> at all, consider
setting the maximum number of B-frames to 2 or higher in order to
take advantage of weighted prediction.

<emphasis role="bold">b_adapt</emphasis>:
Note: This is on by default.

With this option enabled, the encoder will use some simple
heuristics to reduce the number of B-frames used in scenes that
might not benefit from them as much.
You can use <option>b_bias</option> to tweak how B-frame-happy
the encoder is.
The speed penalty of adaptive B-frames is currently rather modest,
but so is the potential quality gain.
It usually does not hurt, however.
Note that this only affects speed and frametype decision on the
first pass.
<option>b_adapt</option> and <option>b_bias</option> have no
effect on subsequent passes.

<emphasis role="bold">b_pyramid</emphasis>:
You might as well enable this option if you are using >=2 B-frames;
as the man page says, you get a little quality improvement at no
speed cost.
Note that these videos cannot be read by libavcodec-based decoders
older than about March 5, 2005.

<emphasis role="bold">weight_b</emphasis>:
In typical cases, there is not much gain with this option.
However, in crossfades or fade-to-black scenes, weighted
prediction gives rather large bitrate savings.
In MPEG-4 ASP, a fade-to-black is usually best coded as a series
of expensive I-frames; using weighted prediction in B-frames
makes it possible to turn at least some of these into much more
reasonably-sized B-frames.
Encoding time cost seems to be minimal, if there is any.
Also, contrary to what some people seem to guess, the decoder
CPU requirements are not much affected by weighted prediction,
all else being equal.

Unfortunately, the current adaptive B-frame decision algorithm
has a strong tendency to avoid B-frames during fades.
Until this changes, it may be a good idea to add
<option>nob_adapt</option> to your x264encopts, if you expect
fades to have a significant effect in your particular video
clip.

<emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
This topic is going to be a bit controversial.

H.264 defines a simple deblocking procedure on I-blocks that uses
pre-set strengths and thresholds depending on the QP of the block
in question.
By default, high QP blocks are filtered heavily, and low QP blocks
are not deblocked at all.
The pre-set strengths defined by the standard are well-chosen and
the odds are very good that they are PSNR-optimal for whatever
video you are trying to encode.
The <option>deblockalpha</option> and <option>deblockbeta</option>
parameters allow you to specify offsets to the preset deblocking
thresholds.

Many people seem to think it is a good idea to lower the deblocking
filter strength by large amounts (say, -3).
This is however almost never a good idea, and in most cases,
people who are doing this do not understand very well how
deblocking works by default.

The first and most important thing to know about the in-loop
deblocking filter is that the default thresholds are almost always
PSNR-optimal.
In the rare cases that they are not optimal, the ideal offset is
plus or minus 1.
Adjusting deblocking parameters by a larger amount is almost
guaranteed to hurt PSNR.
Strengthening the filter will smear more details; weakening the
filter will increase the appearance of blockiness.

It is definitely a bad idea to lower the deblocking thresholds if
your source is mainly low in spacial complexity (i.e., not a lot
of detail or noise).
The in-loop filter does a rather excellent job of concealing
the artifacts that occur.
If the source is high in spacial complexity, however, artifacts
are less noticeable.
This is because the ringing tends to look like detail or noise.
Human visual perception easily notices when detail is removed,
but it does not so easily notice when the noise is wrongly
represented.
When it comes to subjective quality, noise and detail are somewhat
interchangeable.
By lowering the deblocking filter strength, you are most likely
increasing error by adding ringing artifacts, but the eye does
not notice because it confuses the artifacts with detail.

This <emphasis role="bold">still</emphasis> does not justify
lowering the deblocking filter strength, however.
You can generally get better quality noise from postprocessing.
If your H.264 encodes look too blurry or smeared, try playing with
<option>-vf noise</option> when you play your encoded movie.
<option>-vf noise=8a:4a</option> should conceal most mild
artifacting.
It will almost certainly look better than the results you
would have gotten just by fiddling with the deblocking filter.