subq: Des options qui vous permettent de jouer sur le compromis vitesse-qualité, subq et frameref (voir ci-dessous) sont habituellement de loin les plus importantes. Si vous êtes intéressés par le bidouillage soit de la vitesse soit de la qualité, ces options sont les premières que vous devriez prendre en considération. Sur la vitesse, les options frameref et subq interagissent entre elles assez fortement. L'expérience montre que, avec une image de référence, subq=5 (le réglage par défaut) est environ 35% plus lent que subq=1. Avec 6 images de référence, la pénalité passe au dessus des 60%. L'effet de subq sur le PSNR semble assez constant indépendamment du nombre d'images de référence. Typiquement, subq=5 résulte en un PSNR global supérieur de 0.2-0.5 dB par rapport à subq=1. C'est habituellement assez pour être visible.

subq=6 est le mode le plus lent et le plus élevé en qualité. Par rapport à subq=5, il gagne habituellement de 0.1-0.4 dB en PSNR avec des coûts en vitesse variant de 25% à 100%. A la différence des autres niveaux de subq, le comportement de subq=6 ne dépend pas beaucoup de frameref et me. Au lieu de cela, l'efficacité de subq=6 dépend principalement du nombre d'images B utilisées. Lors d'une utilisation normale, cela signifie que subq=6 a un grand impact sur la vitesse et la qualité dans le cas de scènes d'action complexes, mais il peut ne pas avoir beaucoup d'effets sur les scènes avec peu de mouvements. Notez qu'il est recommandé de toujours régler bframes à des valeurs autres que zéro (voir ci-dessous).

frameref: frameref est réglé à 1 par défaut, mais il ne faut pas penser que cela implique qu'il est raisonnable de le laisser à 1. Augmenter simplement frameref à 2 permet un gain de PSNR d'environ 0.15dB, avec une pénalité de 5-10% sur la vitesse; cela semble être un bon compromis. frameref=3 gagne environ 0.25dB de PSNR par rapport à frameref=1, ce qui devrait être une différence visible. frameref=3 est environ 15% plus lent que frameref=1. Malheureusement, les gains diminuent rapidement. frameref=6 peut entraîner un gain de seulement 0.05-0.1 dB par rapport à frameref=3 avec une pénalité de 15% sur la vitesse. Au delà de frameref=6, les gains en qualité sont habituellement très faible (bien que vous deviez garder à l'esprit à travers toute cette discussion que cela peut varier fortement selon la source vidéo utilisée). Dans un cas raisonnablement typique, frameref=12 améliorera le PSNR global d'un minuscule 0.02dB par rapport à frameref=6, avec un surcoût sur la vitesse de 15%-20%. Avec des valeurs aussi élevées de frameref, la seule vraie bonne chose qui puisse être dite est que de l'augmenter même au delà ne nuira presque certainement jamais au PSNR, mais les bénéfices sur la qualité sont à peine mesurables, et encore moins perceptibles.

Si la vitesse vous intéresse, un compromis raisonnable est d'utiliser des valeurs de subq et frameref basses pour la première passe, et de les augmenter ensuite sur pour la seconde passe. Typiquement, cela a un effet négatif négligeable sur la qualité finale: vous perdrez probablement bien moins de 0.1dB en PSNR, ce qui devrait être une différence beaucoup trop faible pour être visible. Cependant, des valeurs différentes de frameref peuvent parfois affecter le choix du type de frame. Ce sont très probablement des cas périphériques rares, mais si vous voulez en être complètement certain, regardez si votre vidéo a soit des motifs plein écran, clignotants et répétitifs, soit de très grandes occlusions provisoires qui pourraient nécessiter une image I1. Ajustez le frameref de la première passe pour qu'il soit assez grand pour contenir la durée du cycle de clignotement (ou d'occlusion). Par exemple, si la scène fait clignoter deux images sur une durée de trois images, réglez le frameref de la première passe à 3 ou plus. Ce problème est probablement extrêmement rare sur des vidéos de type action, mais cela arrive quelquefois dans des captures de jeu vidéo.

me: Cette option sert pour le choix de la méthode de recherche d'estimation de mouvement. Cette option modifie de manière directe le compromis entre qualité et vitesse. me=dia n'est plus rapide que de quelques pourcents par rapport à la recherche par défaut et entraîne une diminution du PSNR global inférieure à 0.1dB. Le paramètre par défaut (me=hex) est un compromis raisonnable entre vitesse et qualité. me=umh améliore de moins de 0.1dB le PSNR global avec une pénalité sur la vitesse variant en fonction de frameref. Pour de hautes valeurs de frameref (par exemple 12 ou plus), me=umh est environ 40% plus lent que le me=2 par défaut. Avec frameref=3, la pénalité sur la vitesse chute à 25%-30%.

me=esa utilise une recherche exhaustive qui est trop lente pour une utilisation pratique.

partitions=all: Cette option autorise l'utilisation des sous-partitions 8x4, 4x8 et 4x4 (en plus de celles présentes par défaut) dans les macroblocs prédits. L'autoriser résulte en une perte de vitesse raisonnablement consistente de 10%-15%. Cette option est plutôt inutile pour les videos sources contenant uniquements de faibles mouvements, particulièrement pour les sources avec beaucoup de petits objets en mouvement. Un gain d'environ 0.1dB peut être espéré.

bframes: Si vous avez l'habitude d'encoder avec d'autre codecs, vous avez peut-être réalisé que les images 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 images B. Habituellement, même un algorithme de choix d'image B naïf peut avoir un bénéfice significatif sur le PSNR. Il est intéressant de noter que l'utilisation d'images B accélère habituellement légèrement la seconde passe, et peut aussi accélérer l'encodage en une seule passe si le choix adaptatif d'image B est désactivé.

Avec le choix adaptatif d'image B désactivé (l'option nob_adapt de x264encopts), le réglage optimal n'est habituellement pas supérieur à bframes=1, sinon les scènes riches en mouvement vont en souffrir. Avec le choix adaptatif d'image B 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 d'images B dans les scènes où cela endommagerait la compression. L'encodeur choisi rarement d'utiliser plus de 3 ou 4 images B; régler cette option à une valeur plus élevée aura peu d'effet.

b_adapt: Note: activé par défaut.

Avec cette option activée, l'encodeur utilise une procédure de décision raisonnablement rapide pour réduire le nombre d'images B utilisées dans les scènes pour lesquelles leur utilisation n'apporterait pas grand-chose. Vous pouvez utiliser b_bias pour affiner la tendance de l'encodeur à insérer des images B. La pénalité de vitesse du chois adaptatif d'images B est actuellement plutôt modeste, mais il en est de même pour le potentiel gain en qualité. En général, cela ne fait pas de mal. Notez que cela affecte uniquement la vitesse et le choix du type d'image lors de la première passe. Les options b_adapt et b_bias n'ont pas d'effet lors des passages suivants.

b_pyramid: Vous pouvez aussi activer cette option si vous utilisez 2 images B ou plus; 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 basés sur libavcodec antérieurs au 5 mars 2005 (environ).

weight_b: En théorie, il n'y a beaucoup de gain à espérer de cette option. Cependant, dans les scènes de fondu, la prédiction pondérée permet d'économiser beaucoup en débit (kbit/s). Dans le MPEG-4 ASP, un fondu-au-noir est habituellement le mieux compressé en tant qu'une coûteuse série d'images I; utiliser la prédiction pondérée pour les images B permet d'en convertir au moins une partie images B bien plus légères. Le coût en 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 semblent deviner, les besoins en puissance informatique du décodeur ne sont pas beaucoup affectés par la prédiction pondérée, tout le reste étant équivalent.

Malheureusement, l'algorithme adaptatif de choix d'images B actuel a une forte tendance à éviter les images B pendant les fondus. Jusqu'à ce que cela change, cela peut être une bonne idée d'ajouter nob_adapt à votre x264encopts si vous pensez que les fondus auront un impact important dans votre vidéo.

Encodage en deux passes: On a suggéré ci-dessus de toujours utiliser un encodage en deux passages, mais il reste tout de même quelques raisons pour ne pas l'utiliser. Par exemple, si vous faites une capture de la télévision et l'encodez en temps réel, vous êtes obligé d'utiliser un encodage 1 passe. De plus, le 1 passe est évidemment plus rapide que le 2 passes; si vous utilisez exactement les mêmes options lors des 2 passes, l'encodage 2 passes est presque deux fois plus lent.

Cependant, il y a de très bonnes raisons pour utiliser l'encodage 2 passes. D'une part, le contrôle de débit du mono-passe n'est pas medium et fait donc souvent des choix peu raisonnables parce qu'il n'a pas de vue d'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 qui dure 60 secondes qui, isolée, requière environ 2500kbit/s pour être correct. Suit immédiatement une scène de 60 secondes beaucoup moins exigeante qui peut être très bien à 300kbit/s. Supposez que vous demandiez 1400kbps en supposant que cela soit suffisant pour s'accomoder des deux scènes. Le contrôle de débit du mono-passe commettra des "fautes" dans un tel cas. Premièrement, il visera 1400kbit/s pour les deux segments. Le premier segment sera quantifié à l'excès et aura donc des artefacts de blocs de façon irrationnelle et inacceptable. Le second segment sera trop peu quantifié, il aura l'air parfait, mais le coût en débit de cette perfection sera complètement irrationnel. Ce qui est encore plus difficile à éviter est le problème de transition entre les 2 scènes. Les premières secondes de la seconde partie seront grandement surquantifiées, parce que le contrôle de débit s'attend encore aux exigences qu'il a rencontrées dans la première partie. Cette "période d'erreur" pendant laquelle les faibles mouvements sont sur-quantifiés aura l'air parkinsonien, et utilisera en réalité moins que les 300kbit/s 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 à augmenter les erreurs de prédiction de débit.

Le contrôle du débit en multi-passes peut apporter d'énormes avantages par rapport au mono-passe. En utilisant les statistiques récupérées lors de la première passe d'encodage, l'encodeur peut estimer, avec une précision raisonnable, le "coût" (en bits) de l'encodage de n'importe quelle image, à n'importe quel quantificateur. Cela permet d'avoir une allocation des bits beaucoup plus rationnelle et mieux planifiée entre les scènes coûteuses (beaucoup de mouvements) et celles bon marché (peu de mouvements). Voir qcomp ci-dessous pour quelques suggestions sur la manière d'ajuster cette allocation à votre guise.

De plus, l'encodage en deux passes ne prend pas nécessairement deux fois plus de temps que le simple passe. Vous pouvez jouer avec les options lors de la première passe pour avoir une vitesse plus élevée et une qualité plus faible. Si vous choisissez bien vos options, vous pouvez obtenir une première passe très rapide. La qualité résultante de la seconde passe sera légèrement plus basse parce que la prédiction de la taille sera moins précise, mais la différence de qualité sera normalement trop faible pour être visible. Essayez, par exemple, d'ajouter subq=1:frameref=1 à la première passe x264encopts. Ensuite, sur la seconde passe, utilisez des options plus lentes pour avoir une meilleure qualité: subq=6:frameref=15:partitions=all:me=umh

Encodage en trois passes ? x264 offre la possibilité de faire un nombre arbitraire de passes consécutives. Si vous spécifiez pass=1 lors de la première passe, puis utilisez pass=3 pour la passe suivante, cette dernière passe lira les statistiques calculées lors du passage précédent, et écrira ses propres statistiques. Une autre passe suivante aura une très bonne base pour faire des prédictions très précises de tailles des images pour un quantificateur donné. En pratique, les gains sur la qualité d'ensemble sont généralement proches de zéro et il est très possible que la troisième passe donne un PSNR global plus faible que le précédent. Typiquement, le 3 passes aide si vous obtenez une mauvaise prédiction de débit ou un mauvais rendu lors des transitions de scènes quand vous utilisez seulement deux passes. Ceci peut se produire sur les clips extrêmement courts. Il y a aussi quelques cas spéciaux dans lesquels trois (ou plus) passes sont utiles pour les utilisateurs avancés, mais par souci de brièveté, ce guide ne traitera pas ces cas spéciaux.

qcomp: qcomp gère l'allocation des bits entre les images "coûteuses" des scènes riches en mouvement et celles "bon marché" des scènes de faible mouvement. La valeur minimale, qcomp=0 s'emplie à réaliser un vrai débit 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. La valeur maximale, qcomp=1 rend les paramètres de quantifications (QP) presque constants. Un QP constant donne un bon rendu, mais la plupart des gens pensent qu'il est plus raisonnable d'enlever quelques bits des scènes coûteuses (où la perte de qualité n'est pas aussi visible) et de les ré-allouer aux scènes qui sont plus faciles à encoder à une excellente qualité. qcomp vaut 0.6 par défaut, ce qui peut être légèrement trop faible au goût de nombre de personnes (0.7-0.8 sont aussi communément utilisées).

keyint: keyint permet de jouer sur le compromis entre la précision de la navigation dans les fichiers et leur efficacité de compression. Par défaut, keyint est égal à 250. Sur des videos à 25 images par secondes, 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, règlez à keyint=125; cela dégradera légèrement le rapport qualité/débit. 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 (bien entendu, plus vous augmenterez, moins il aura de gain visuels). Le flux vidéo aura toujours des points de recherche tant qu'il y aura des changements de de scène.

deblock: Ce sujet risque d'être une source de controverses.

H.264 définit une procédure simple de déblocage sur les blocs I ayant des forces et des seuils pré-réglés en fonction du QP du bloc en question. Par défaut, les blocs à QP élevés sont fortement filtrés et les blocs à faible QP ne le sont pas du tout. Les forces pré-réglées définies par les standards sont bien choisies et il y a de grandes chances pour qu'elles soient optimales du point de vue du PSNR quel que soit la vidéo que vous encodez. Les paramètres de deblock vous permettent de spécifier des décalages par rapport aux seuils de déblocage pré-définis.

Beaucoup de gens semblent penser que baisser grandement la force du filtre de déblocage (par exemple -3) est une bonne idée. Ce n'est cependant presque jamais le cas et dans la plupart des cas, ceux qui le font ne comprennent pas très bien comment le déblocage fonctionne par défaut.

La première et plus importante chose à savoir à propos du filtre de déblocage de H264 est que les seuils par défaut sont presque toujours optimaux du point de vue du PSNR. Dans les rares cas où ils ne le sont pas, le décalage idéal est de plus ou moins 1. Décaler les paramètres de déblocage d'une plus grande valeur est presqu'une garantie de dégradation du PSNR. Augmenter la force du filtre diluera les détails; la baisser augmentera l'effet de bloc.

C'est une mauvaise idée que de baisser les seuils de déblocage si votre source est principalement de faible complexité spatiale (c-à-d avec peu de détails ou de bruit). Le filtre de H264 réussit très bien à camoufler les artefacts qui se apparaissent. De toutes façons, si la complexité spatiale de la source est élevée, les artefacts sont moins discernables parce qu'ils tendent à ressembler à du détail ou du bruit. La vision humaine remarque facilement qu'un détail a été enlevé mais ne remarque pas si facilement quand un bruit est mal représenté. Quand il s'agit de qualité subjective, le bruit et les détails sont d'une certaine façon interchangeables. En baissant la force du filtre de déblocage, vous allez très probablement augmenter les erreurs en ajoutant des artefacts mais l'oeil ne les remarquera pas parce qu'il les confondra avec des détails.

Cependant, ceci ne justifie toujours pas une diminution de 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 jouer avec -vf noise quand vous visionner votre film encodé. -vf noise=8a:4a devrait camoufler la plupart des artefacts légers. Cela aura l'air certainement mieux que ce que vous obtiendriez en jouant uniquement avec le filtre de déblocage.