x264
est une librairie libre pour
encoder des flux vidéo H.264/AVC.
Avant de commencer à encoder, vous avez besoin de
régler MEncoder pour le supporter.
Veuillez commencer par passer en revue la section
x264
de la page man
de MPlayer.
Cette section a été prévue pour être un complément à la page man.
Vous trouverez ici rapidement des astuces sur le genre d'options qui est
le plus susceptible d'intéresser la plupart des gens. La page man
est plus laconique, elle est aussi plus exhaustive, et cela offre
parfois beaucoup plus de détails techniques.
Ce guide considère deux catégories majeures d'options d'encodage:
Options qui principalement compensent la durée d'encodage de la qualité
Options qui peuvent être utiles pour accomplir des préférences personnelles variées et des conditions spéciales
Finalement, seul vous pouvez décider quelles options permettent d'atteindre vos buts. Le choix de la première classe d'options est la plus simple: vous devez seulement décider si vous pensez que les différences de qualité justifient les différences de vitesse. Pour la deuxième classe d'options, les préférences peuvent être bien plus subjectives, et plus de facteurs peuvent être impliqués. Notez que certaines des options de type "préférences personnelles et de conditions spéciales" peuvent encore avoir un impact impact sur la vitesse ou la qualité, mais ce n'est pas là leur principale utilité. Quelques unes des options de "préférence personnelle" peuvent même causer des changements qui semblent mieux pour certaines personnes, mais semblent moins bon à d'autres.
Avant de continuer, il vous est nécessaire de comprendre que ce guide utilise seulement une qualité métrique: le PSNR global. Pour une brève explication sur le PSNR, voir l'article Wikipedia sur le PSNR. PSNR global est le dernier nombre PSNR rapporté quand vous incluez l'option psnr dans x264encopts. Chaque fois que vous lisez une réclamation sur le PSNR, une des prétentions derrière la réclamation est que des bitrates égaux sont utilisés.
A peu près tous les commentaires de ce guide présument que vous utilisez deux passages. Lors de la comparaison des options, il y a deux principales raisons pour l'utilisation d'un encodage en deux passes. Premièrement, utiliser deux passes permet souvent de gagner environ 1dB PSNR, ce qui est une très grosse différence. Deuxièmement, tester les options en faisant des comparaisons directes de qualité avec un encodage en un passage introduit un facteur confus important: le bitrate varie souvent de façon significative avec chaque encodage. Il n'est pas toujours facile de dire si les changements de qualité sont principalement dûs aux changements d'options, ou si la plupart du temps ils reflètent essentiellement des différences aléatoires dans le bitrate réalisé.
subq: Des options qui vous permettent de compenser la vitesse pour la qualité, subq et frameref (voir ci-dessous) sont habituellement et 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. A propos de la dimension de la vitesse, les options frameref et subq interagissent entre elles assez fortement. L'expérience montre que, avec une frame de référence, subq=5 (le règlage par défaut) est environ 35% plus long que subq=1. Avec 6 frames 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 de frames de référence. Typiquement, subq=5 résulte en un PSNR global plus haut de 0.2-0.5 dB en comparaison à subq=1. C'est habituellement assez pour être évident.
subq=6 est le plus lent, le plus élevé mode de qualité. En comparaison à subq=5, il gagne habituellement un PSNR global de 0.1-0.4 dB avec des coûts en vitesse variant entre 25% et 100%. A la différence des autres niveaux de subq, le comportement de subq=6 ne dépend pas beaucoup de frameref et me. A la place, l'efficacité de subq=6 dépend principalement du nombre de B-frames utilisées. Lors d'une utilisation normale, cela signifie que subq=6 a un large impact sur la vitesse et la qualité dans le cas complexe, des scènes avec beaucoup de mouvements, mais il peut ne pas avoir beaucoup d'effets sur les scènes avec peu de mouvements. Notez qu'il est encore recommandé de toujours régler les bframes à d'autres valeurs que zéro (voir ci-dessous).
frameref: frameref est règlé à 1 par défaut, mais ceci ne devrait pas être pris en compte pour justifier qu'il est raisonnable de le mettre à 1. En augmentant simplement frameref à 2 permet un gain d'environ 0.15dB sur le PSNR avec une pénalité à 5-10% sur la vitesse; cela semble être un bon compromis. frameref=3 gagne environ 0.25dB de PSNR de mieux que frameref=1, ce qui devrait être une différence visible. frameref=3 est d'environ 15% plus lent que frameref=1. Malheureusement, des retours diminuants se mettent en place rapidement. frameref=6 peut entraîner un gain de seulement 0.05-0.1 dB de mieux que 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 que toute cet avis est à modérer selon la source vidéo utilisée). Dans un cas typique, frameref=12 améliorera le PSNR global d'un minuscule 0.02dB de mieux que 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 un peu plus ne nuira quasiment jamais au PSNR, mais les bénéfices sur la qualité additionnelle sont à peine mesurables, et encore moins perceptibles.
Augmenter le frameref à des valeurs inutilement élevées peut affecter et habituellement affecte l'efficacité d'encodage si vous arrêtez le CABAC. Avec le CABAC activé (comportement par défaut), la possibilité de réglagles de frameref "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é.
Si vous vous inquiétez pour la vitesse, un compromis raisonnable est d'utiliser des valeurs subq et frameref basses sur le premier passage, et ensuite les augmenter sur le second passage. Typiquement, cela a un effet négatif négligeable sur la qualité 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 frameref 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 frameref de premier passage pour qu'il soit assez large pour contenir la durée du cycle de clignotement (ou occlusion). Par exemple, si la scène clignote dans les deux sens entre deux images au-dessus d'une durée de trois frames, réglez le frameref de 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.
me: 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. me=1 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 (me=2) est une compensation raisonnable entre vitesse et qualité. me=3 gagne un petit peu en dessous de 0.1dB du PSNR global, avec une pénalité sur la vitesse qui varie dépendamment du frameref. A de hautes valeurs du frameref (e.g. 12 ou autre), me=3 est environ 40% plus lente que la valeur par défaut me=2. Avec frameref=3, la pénalité encourue sur la vitesse chute à 25%-30%.
me=4 utilise une recherche exhaustive qui est trop lente pour une utilisation pratique.
4x4mv: 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.
bframes: 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é.
Avec le choix de B-frame adaptatif stoppé (nob_adapt de x264encopts), la valeur optimale pour le paramètrage est habituellement pas plus que bframes=1, 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.
b_adapt: Note: il est activé par défaut.
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 b_bias 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. b_adapt et b_bias n'ont aucun effet sur les passages suivants.
b_pyramid: 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.
weight_b: 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.
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 nob_adapt à votre x264encopts, si vous vous attendiez à ce que le fondu ait un plus grand effet sur votre clip vidéo particulier.
Encodage en deux passages: 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.
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.
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 qcomp ci-dessous pour quelques idées sur comment bidouiller cette allocation à vos besoins.
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 subq=1:frameref=1 au premier passage x264encopts. Ensuite, sur le second passage, utilise des options plus lentes, de plus grandes qualités: subq=6:frameref=15:4x4mv:me=3
Encodage en trois passages? x264 offre la capacité de faire un nombre arbitraire de passages consécutifs. Si vous spécifiez pass=1 sur le premier passage, alors utilisez pass=3 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.
qcomp: qcomp 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é, qcomp=0 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é, qcomp=1 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é. qcomp 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é).
keyint: keyint est seulement pour compenser l'habilité de recherche de fichiers contre l'efficacité de codage. Par défaut, keyint 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 keyint=125; 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.
deblockalpha, deblockbeta: Ce sujet va être un peu controversé.
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 deblockalpha et deblockbeta vous permettent de spécifier des décalages aux pré-règlages des seuils de déblocage.
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.
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é.
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.
Ceci ne justifie toujours 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 -vf noise quand vous jouez votre film encodé. -vf noise=8a:4a 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.
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.
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.
Description | Options d'encodage | vitesse (en fps) | Perte PSNR relative (en dB) |
---|---|---|---|
Très haute qualité | subq=6:4x4mv:8x8dct:me=3:frameref=5:bframes=3:b_pyramid:weight_b | 6fps | 0dB |
Haute qualité | subq=5:4x4mv:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b | 13fps | -0.89dB |
Rapide | subq=4:bframes=2:b_pyramid:weight_b | 17fps | -1.48dB |