Configuration du x264

kurtnoise · Sound Master Inscrit le: 19 Oct 2002 Messages: 6012 Localisation: 06

Avec la norme AVC/H.264, le Standard MPEG-4 se voit doter d'un nouveau format de compression Vidéo. Celui-ci est apparu au cours de l'année 2003 et a été finalisé conjointement par 2 groupes d'experts : le MPEG comittee (Moving Pictures Experts Group) et le VCEG comittee (Video Coding Experts Group). A la base, cette norme a été developpée par l'équipe JVT (Joint Video Team), qui inclut un certain nombre d'experts issus des 2 comités pré-cités.

Les initiales AVC font référence simplement au terme d'Advanced Video Coding (Codage Vidéo Avancé) que l'on oppose habituellement à la norme ASP (Advanced Simple Profile) dont des codecs comme XviD ou DivX font partie.

Ainsi donc, le x264 est l'un des compresseurs que l'on retrouve sous cette catégorie dite AVC. Il en existe déjà d'autres comme par exemple le JM, celui de Mainconcept, celui de Nero Digital, etc...Pour information, vous pouvez retrouver la liste complète accompagnée de différents liens explicatifs dans ce post.

Tous sont donc plus ou moins développés intensivement à l'heure actuelle puisque la norme AVC est appelée à remplacer, un jour ou l'autre, la norme ASP. Cependant l'x264 fait partie de ceux qui sont les plus intéressants, et ce sur plusieurs points :

Il est multiplateforme, donc compatible avec Windows, Linux, UniX, Mac OS...
Open Source, de ce fait chacun peut y apporter des modifications et améliorations.
Gratuit, là ou d'autres compresseurs issus de la même catégorie sont payants.
Une Vitesse d'encodage relativement rapide.
Une Qualité au final plus que raisonnable, que ce soit visuellement ou métriquement.

Son développement n'a réellement commencé qu'en 2003 lorsque Fenrir l'a récrit complètement puis repris progressivement, entre autres, par akupenguin au cours de l'année 2004. Pour avoir un aperçu des dernières améliorations, vous pouvez zieuter le blog de Dark Shikari, qui a rejoint l'équipe récemment.

Remarque n°1 : la version VFW n'est plus officiellement mise à jour et a même été supprimée des sources depuis la revision 581 (octobre 2006). Cependant, vous devriez trouver quelques versions récentes à la page suivante. Aujourd'hui étant obsolète, seule l'archive PDF des explications est conservée (cf fichier joint).

Remarque n°2 : l'x264 est décrit ici en tant que compresseur, non pas comme un codec proprement dit (aka Codeur/Décodeur).

kurtnoise · Sound Master Inscrit le: 19 Oct 2002 Messages: 6012 Localisation: 06

Configuration de la CLI

Le compresseur x264 peut être également utilisé en dehors de la sphère VFW via une application tout en ligne de commandes. C'est ce genre d'interface qui est le plus souvent utilisée sous des plateformes Linux ou autre système Unix spécialisé. Sachez aussi que si vous êtes adeptes de Mplayer/Mencoder, vous pouvez retrouver intégralement les commandes qui vont suivre puisque ce compresseur a été ajouté à la très longue liste de codecs déjà présents sous cette application.

Autre remarque qui peut être intéressante : la version CLI (Command Line Interface) pour windows peut être compilée de manière à se que l'on ait le support avs en input. Autrement dit, on a la possibilité de réaliser des encodes à partir de scripts avisynth. Si vous roulez sous un autre OS, le format d'input peut être soit un fichier AVI ou bien directement un fichier brute YUV.
Concernant le format de sortie, là encore plusieurs possibilités suivant la manière dont a été faite la compilation : soit le format raw h264 ou le conteneur matroska que l'on a par défaut, soit directement encapsulé dans le conteneur mp4. Peut importe l'OS ici. Il suffit juste d'avoir certaines librairies de GPAC au bon endroit. Pour vérifier les différentes possibilités qui s'offrent à vous, il suffit de lancer la CLI dans une invite de commandes sans aucuns paramètres optionnels. Par exemple :
Par exemple :

Citation:

x264 core 40 r380
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (yes)

Ici le support avs et mp4 sont donc bien disponibles (yes 2 fois). Sachez également que le site officiel de l'x264 ne fournit pas de package déjà compilé. Donc, soit vous le faites vous-même, soit il faudra récupérer une version déjà compilée. Par ce lien ou ici, vous pourrez trouver des versions pour les plateformes windows. Dernier élément préalable, l'avs en entrée et le mp4 en sortie ne sont apparus qu'a partir de la révision 202. Donc, vérifiez bien la version que vous récupérez.

Notons également, qu'a l'été 2009 (révision 1177 exactement) est apparu un système de presets. Ce dernier n'est disponible que par l'interface en ligne de commandes. De ce faite, l'utilisation du compresseur x264 en est simplifiée. Plus de détails par la suite.

Sachez qu'une partie des explications qui vont suivre sont extraites directement des man pages de mplayer, traduites en français par Guillaume Poirier. Je tiens donc à le remercier pour tout le travail accompli dans ce cadre.

Presets

--profile baseline|main|high : Force le profil défini par le standard H.264. Profil high par défaut. Certains appareils ou platines ne supportent pas ce profil. Il faut donc l'ajuster.

--preset : permet la simplification de l'utilisation du compresseur. En spécifiant un nom particulier, des paramètres prédéfinis sont activés/désactivés/tunés en interne. Ses presets sont les suivants (du plus rapides au plus lents) :

ultrafast
veryfast
faster
fast
medium [par défaut]
slow
slower
veryslow
placebo

L'utilisateur peut affiner un preset choisi. Ainsi, les paramètres spécifiés prendront la main par rapport aux paramètres internes définis par le preset.

--tune : permet d'affiner un paramétrage suivant un contenu/cible spécifique. Ces tunings sont au nombre de 5 :

film [optimal pour des sources type films]
animation [optimal pour des sources type animations]
grain [pour des sources contenant du grain]
psnr [pour optimiser la métrique PSNR]
ssim [pour optimiser la métrique SSIM]
fastdecode [pour avoir un décodage le plus rapide possible]
touhou [paramétrage spécial dédié au jeu vidéo - source connue pour "stresser" les codecs vidéos]

--slow-firstpass : en spécifiant ceci, la première passe n'utilisera pas les paramètres les plus rapides.

Frame-Type Options

-I ou –-keyint [nbre entier] :Taille Maximale du GOP (Group of Pictures). Autrement dit, cela permet de définir l'intervalle maximum entre les frames-IDR. La valeur par défaut est 250. Il faut savoir qu'un intervalle plus important fait économiser des bits, et donc améliore la qualité, mais rend le seeking moins précis. Autre point qui peut être souligné, la norme AVC contrairement aux MPEG-1/2/4 ASP, ne souffre d'aucune dérive de DCT avec des grandes valeurs de keyint.

-i ou –-min-keyint [nbre entier] : Taille Minimale du GOP (Group of Pictures). Permet donc de définir l'intervalle minimum entre chaque frames-IDR. La valeur par défaut proposée dans la CLI est fixée à 25. Si des changements de scène apparaissent dans cet intervalle, ils seront alors quand même encodés en frames-clés, mais n'initient pas un nouveau GOP. Pour la norme standard H.264, les I-Frames n'encadrent pas nécessairement un groupe fermé de frames prédites (closed GOP) car une P-Frame peut aussi être prédite à partir d'autres frames que celles la précédant (voir aussi frameref). Ainsi, les Frames-clés ne permettent pas nécessairement une navigation plus précise dans le film. Les frames-IDR empêchent donc les P-Frames qui les suivent d'être prédites à partir de trames précédant les Frames-IDR.

--scenecut [nbre entier] : Contrôle avec quelle insistance on insère les I-Frames en plus, par exemple lors des changements de scène. La valeur par défaut est fixée à 40. L'échelle de valeurs s'échelonne entre l'intervalle [0 et 100]. Avec une valeur de scenecut faible, le codec aura tendance à ne mettre des Frames-clés que toutes les <keyint> Frames. Une bonne valeur de scenecut est celle qui place une I-Frame de façon la plus optimale. Avec une valeur trop grande, le compresseur choisira plus de I-Frames, ce qui gâche des bits. La valeur 0 permet de désactiver la détection des changements de scène. De ce faite les Frames-clés ne seront insérées que toutes les <keyint> Frames, même s'il vient d'y avoir un changement de scène. Cela n'est guère recommandé et gâche des bits puisque les changements de scène encodés par des P-Frames sont aussi coûteux en bits que les I-Frames, mais ne remettent pas à zéro le "compteur keyint".

--no-scenecut : désactive la décision adaptative des I-Frame.

-b ou --bframe [nbre entier] : Nombre maximum de B-Frames consécutives entre les I et P Frames. Valeur par défaut égale à 3. Valeurs possibles comprises entre 0 et 16.

--b-adapt 0|1|2 : le compresseur x264, par défaut, décide par lui-même d'adapter de manière optimale le nombre de B-Frames à utiliser. Cependant, il est possible de désactiver cette adaptabilité (mais non recommandé) en utilisant cette commande.
Une valeur de 0 désactive la méthode de décision adaptative. Une valeur de 1 (valeur par défaut) est un bon compromis entre vitesse et qualité sur la méthode employée. Une valeur de 2 engendre une méthode d'adaptabilité plus lente mais plus précise. Ce mode détecte correctement les fondus et donne généralement une meilleur qualité. Par contre, la vitesse d'encodage s'en ressent dès lors que l'on combine un nombre élevé de B-Frames. C'est pourquoi, il est conseillé de garder un nombre de B-Frames relativement bas (aux alentours de 3) lorsque l'on désire utiliser ce mode. Cela peut également réduire la vitesse de la 1ère passe lors d'un mode threadé.

--b-bias [nbre entier] : Contrôle la décision prise par le paramètre b_adapt. Un biais plus important produit plus de B-Frames. Valeur par défaut fixée à 0. Intervalle de valeurs possibles [-100 100].

--b-pyramid : Autorise les B-Frames à servir de référence pour prédire d'autres trames. Si on prend par exemple 3 B-Frames consécutives : I0 B1 B2 B3 P4. Sans cette option, alors les B-Frames ont les mêmes restrictions que la norme MPEG-[124]. Elles sont alors codées dans l'ordre I0 P4 B1 B2 B3, et toutes les trames-Bidirectionnelles sont prédites à partir de I0 et P4. A l'inverse, si cette option est active, alors elles seront codées comme I0 P4 B2 B1 B3. B2 est la même que ci-dessus, mais B1 est prédite à partir de I0 et B2, et B3 est prédite à partir de B2 et P4. Cela améliore généralement légèrement la compressiblité, et ne dégrade pas la vitesse d'encodage. Cependant, ça reste expérimental. Elle n'est pas encore peaufinée, et n'aide pas toujours la compression. Pour l'activation de cette variable, vous devez spécifier un niveau de bframes >= 2. Principal inconvénient : augmente de 2 trames le délais de décodage.

--no-cabac : Permet de désactiver le système CABAC (Context-Adaptive Binary Arithmetic Coding ou en français Codage de l'information adaptée en fonction du contexte). Le compresseur x264 l'utilise par défaut. Si vous désactivez ce procédé, c'est le système CAVLC (Context-Adaptive Variable Length Coding) qui rentre en jeu. Le CABAC ralenti un peu l'encodage mais permet d'économiser 10 à 15% du bitrate. À moins que vous ayez besoin de décoder à vitesse élevée, vous ne devriez jamais le désactiver.

-r ou –-ref [nbre entier] : Nombre de Frames de référence à utiliser comme prédicteur pour les B-Frames et les P-Frames. Valeur par défaut à 3. Echelle de valeurs possibles comprises entre [1 16]. Est efficace avec les dessins animés, mais avec des films dont les sujets sont réels, on n'observe plus d'amélioration significative
au-delà d'environ 6 Frames de référence. Il faut savoir que cette variable n'a pas d'effet sur le temps de décodage, mais augmente la quantité de mémoire nécessaire pour le décodage. Quelques décodeurs ne gèrent qu'au plus 15 trames de référence. De même, pour des encodes de type Blu-ray ou destinés aux boîtes multimédias, une valeur max se situe à 4.

--no-deblock : désactive le filtre de deblocking. Le filtre de deblocking intégré (inloop) est une caractéristique propre à la norme h.264. Cela permet d'atténuer les effets de blocs. Étant donné qu'il prend assez peu de temps au regard de l'amélioration visuelle qu'il procure, il est déconseillé de le désactiver.

-f ou –-deblock [alpha:beta] : paramètres alpha et beta de l'inloop. Par défaut, ces seuils sont fixés à 0. (alpha=0 et beta=0). Concernant l'alpha : il permet de déterminer à quel point le filtre peut modifier l'apparence de chacun des pixels de l'image. Une fois cela fait, il détermine la différence maximale à la limite des blocs filtrés. Une valeur positive réduit les artefacts de blocking, mais enlève du détail à l'image. Le paramétrage par défaut de ce filtre permet généralement d'atteindre une qualité optimale, il est donc conseillé de laisser la valeur par défaut ou de ne la changer qu'un peu. Par contre, si votre source vidéo souffre déjà d'artefacts de blocking ou de bruit que vous voulez atténuer, vous devriez l'augmenter un peu.
Paramètre beta : Affecte le seuil de détail. Les blocs très détaillés ne sont pas filtrés, puisque l'effet de lissage dû au filtre seraient plus visibles que l'effet de bloc original.

Les valeurs possibles pour ces 2 paramètres s'échelonnent entre [-6 et +6].

--interlaced : active le mode pour l'entrelacement. Utilise la syntaxe MBAFF (Macroblock-Adaptive Frame/Field) mais n'utilise pas le mode adaptatif.

Rate Control

-q ou –-qp [nbre entier] : Permet de contrôler le quantizer constant. Valeur par défaut à 23. Une valeur comprise dans l'intervalle 20-40 semble convenir parfaitement pour des encodes en 1 passe. L'échelle de valeur possibles est comprise entre [0 et 51]. Une valeur plus faible code l'image plus fidèlement, mais prend plus de place. Notez que la quantification dans la norme H.264 fonctionne différemment de celle du MPEG-1/2/4-ASP : l'échelle des paramètres de quantification (QP) du H264 est logarithmique. Pour les matheux, l'équivalence est approximativement H264QP = 12 + 6*log2(MPEGQP). Ce qui donne par exemple, MPEG-4 ASP à QP=2 est équivalent à QP=18 pour la norme H264.

A noter que la valeur Q=0 fait référence au mode lossless (compression sans perte).

-B ou –-bitrate [nbre entier] : Fixe le débit binaire (bitrate) à utiliser en kbits par seconde. Désactivé par défaut. Pour un encodage en débit binaire constant (CBR), vous devez définir ce paramètre.

--crf [nbre flottant] : Permet de fixer un facteur pour le taux de compression de telle manière à avoir une qualité constante sur une seule passe tout en bénéficiant du système d'encodage ABR. La valeur doit être comprise entre [0 et 51]. Par défaut fixée à 23. Une valeur égale à 0 correspond au mode lossless (compression sans perte).

--qpmin [nbre entier] : Défini le quantizer minimum. Fixé à 10 par défaut. 10-30 semble être un intervalle raisonnable. Echelle de valeurs possibles [1-51]. (Mode CBR ou Mode 2 passes).

--qpmax [nbre entier] : Défini le quantizer maximum. Fixé à 51 par défaut qui est la valeur maximale. Echelle de valeurs possibles [1-51]. (Mode CBR ou Mode 2 passes).

--qpstep [nbre entier] : Permet de contrôler la différence maximale de quantizer autorisé d'une trame à l'autre. Valeur par défaut à 4. (Mode CBR ou Mode 2 passes).

--ratetol [flottant] : Permet de contrôler l'écart par rapport au débit binaire donné (pas d'unité particulière). Valeur par défaut fixée à 1.0. (Mode ABR ou Mode 2 passes).

--vbv-maxrate [nbre entier] : Définie le pic maximum de débit binaire, en kbps. (Mode ABR ou Mode 2 passes). 0 par défaut.

--vbv-bufsize [nbre entier] : temps de moyennage de vbv_maxrate, en kbits. Par défaut : aucun, mais doit être définie si --vbv-maxrate est activé. (Mode ABR ou Mode 2 passes). 0 par défaut.

--vbv-init [nbre flottant] : Permet de définir le niveau initial du tampon du RateControl. C'est en quelque sorte une fraction de la taille totale de ce buffer. Echelle de valeurs possibles comprises entre [0.0 et 1.0]. Fixé à 0.9 par défaut.

--ipratio [nbre flottant] : Facteur de quantification entre les I-Frames et les P-Frames. Valeur par défaut fixée à 1.40.

--pbratio [nbre flottant] : Facteur de quantification entre les P-Frames et les B-Frames. Valeur par défaut fixée à 1.30.

--chroma-qp-offset [nbre entier] : Permet d'utiliser un quantizer différent pour la chroma et la luma. Valeur fixée par défaut à 0. Echelle de valeurs possibles comprise entre [-12 et 12]. L'intervalle [-2 / +2] est recommandé.

--aq-mode 0|1|2 : permet de fixer le mode de Quantization Adaptatif (AQ). Sans cet algorithme, le compresseur x264 a tendance à sous-estimer l'allocation de bits sur les parties peu détaillées. En activant ce paramètre, une meilleure allocation est faite sur tous les macroblocs de la vidéo. Une valeur de 0 désactive l'AQ. Une valeur de 1 (par défaut) redistribue les bits sur toute la vidéo uniformément. Tandis que le mode 2 (Auto-Variance AQ) affine le calcul de cette redistribution en essayant d'adapter la force de l'algorithme. Ce dernier est encore expérimental.

--aq-strength [nbre flottant] : contrôle la force de l'AQ. Valeur par défaut à 1.0. En jouant avec cette valeur, on réduit le blocking et le blurring dans les zones de textures et peu saturées. Une valeur de 0.5 contrôle faiblement l'AQ tandis qu'une valeur de 1.5 est plus fort.

-p ou –pass 1|2|3 : Active le Mode 2 ou 3 passes. Il est recommandé de toujours encoder en mode 2 ou 3 passes puisque cela permet une distribution plus adéquate des bits et améliore grandement la qualité globale. La première passe (pass=1) sert à écrire le fichier de statistiques. Vous devriez désactiver des options gourmandes en temps processeur pour cette première passe.
En mode deux passes, la seconde passe (pass=2) se base sur le fichier de stats pour allouer le bon nombre de bits aux trames (ratecontrol).
En mode trois passes, la seconde passe (pass=3, non ce n'est pas une erreur) fait les deux : elle lit le fichier de stats, puis ré-écrit par dessus. C'est pourquoi il est préférable de sauvegarder ce fichier de stats si vous rencontrez un problème matériel éventuel. Lors de cette passe, il est conseillé d'utiliser toutes les options d'encodage à l'exception de celles vraiment très gourmandes en CPU. La troisième passe (pass=2) fait la même chose que la seconde, à la différence près qu'elle dispose des stats de la deuxième passe pour mieux travailler. Si vous envisagez ce mode 3 passes, sachez que vous pouvez utiliser toutes les options d'encodage, même les plus gourmandes.
La première passe peut être effectuée à un débit binaire constant (CBR) ou à quantizer constant (CQP). À quantizer constant, le résultat est souvent meilleur mais requiert que vous deviniez un qp_constant qui serait proche du débit binaire souhaité. Mieux vaut alors se tromper en sous-estimant le qp_constant, et donc avoir un bitrate un peu plus haut que prévu. Les passes suivantes sont ABR (débit binaire moyen) et vous devez définir un débit binaire. Ce Mode 3 passes étant tout nouveau pour le x264, les développeurs vous invite à partager votre expérience sur les meilleures combinaisons possibles en matière de paramètres pour avoir la meilleure qualité possible.

--stats [chaîne] : Permet de spécifier le nom de fichier statistiques pour le Mode 2 ou 3 passes.

--rceq [chaîne] : Permet d'écrire l'équation du RateControl. Formellement : blurCpl x^(1-qComp).

--qcomp [nbre flottant] : Utile que pour le Mode 2 passes. Cela permet de contrôler la compression des quantizers. Valeur par défaut fixée à 0.6. Echelle de valeurs possibles comprise entre [0.0 et 1.0]. Une faible valeur (i.e qui tend vers 0) rend le débit binaire plus constant alors qu'une valeur importante (i.e qui tend vers 1) rend les quantizers plus constants.

--cplxblur [nbre flottant] : Utile que pour le Mode 2 passes. Permet de contrôler le flou temporel de la complexité de trame estimée avant la compression de la courbe (défaut = 20). Valeurs possibles comprises entre [0 et 999]. Des valeurs plus faibles permettent au quantizer de ne plus changer d'une Frame à l'autre. Tandis que des valeurs plus hautes forcent une variation plus douce. Cette variable permet de s'assurer que chaque I-Frame ait une qualité comparable aux P-Frames suivantes, et garantit qu'une alternance de Frames à complexité forte et faible (par exemple un dessin animé dont la cadence d'animation est faible) ne gâche pas de bits en faisant fluctuer les quantizers.

--qblur [nbre flottant] : Même précision que précédemment, cette variable n'est qu'utile que pour un Mode 2 passes. Elle permet donc de contrôler le flou temporel entre les quantizers après la compression de la courbe (défaut = 0.5). Echelle de valeurs possibles comprises entre [0 et 99]. Une faible valeur permet aux quantizers de voir leur valeur fluctuer plus d'une trame à l'autre, tandis qu' une valeur forte oblige la variation à être plus progressive.

--zones <zone0><zone1> ....: Comme pour le XviD, l'x264 permet de contrôler le débit pour une zone bien particulière du flux à encoder. On entend par zone ici, le nombre de frames à encodér (exemple le générique de fin pour un film). Chaque zone est définie par le triplet <trame de début>,<trame de fin>,<option> où option peut être le quantizer "q=[0-51]" (q compris entre 0 et 51) ou le multiplicateur du débit "b=[0.01-100.0]" (b compris entre 0.01 et 100).
A noter que l'option q n'est pas respectée strictement. Elle affecte uniquement le stade de planning du contrôleur de débit (ratecontrol), et est encore sujet à la compensation de débordement et à qp_min/qp_max. (Mode ABR ou Mode 2 passes).

--qpfile [chaîne] : Permet de forcer le type de frames et de QPs. Très utile lorsque l'on veut forcer des numéros de Frames correspondant aux débuts de chapitres.
Par exemple:

Code:

3245 I -1
6578 I -1
87655 I -1

le premier nombre fait référence au numéro de frame, I spécifie le type de frame (ici une Frame IDR) et -1 laisse le choix du quantizer par le compresseur lui-même.

Analyse

-A ou –-partitions [chaîne] : différentes options pour l'analyse des macroblocs. L'idée est de trouver le type et la taille des macroblocs qui décrit le mieux une certaine région de l'image. Par exemple, un travelling est mieux représenté par des blocs 16x16, tandis qu'un petit objet en mouvement sera mieux codé par des petits blocs. Il est toujours recommandé de faire une analyse complète. Les différents choix possibles :

None : aucune option est précisée.
All : analyse complète avec tous les types de macroblocs.
i4x4 : en spécifiant ceci, la recherche n'est faite que sur les I-Frames de taille 4x4.
p8x8 : l'alayse se base en plus sur les types de macro-blocs p16x8, p8x16, p8x8. Sans cette option, les P-Frames n'utiliseront que les types i16x16, i4x4, p16x16. Activé par défaut.
p4x4 : Utilise en plus les types de macro-blocs p8x4, p4x8, p4x4. Sans cette option, les P-Frames n'utiliseront que les types i16x16, i4x4, p16x16, p16x8, p8x16, p8x8. Cette option requiert p8x8.
b8x8 : Utilise en plus les types de macro-blocs b16x8, b8x16, b8x8. Sans cette option, les B-Frames n'utiliseront que les types i16x16, i4x4, b16x16.
i8x8 : Utilise en plus les types de macros-blocs pour les Frames Intra. Requiert l'option --8x8dct (voir plus bas).

Précision supplémentaire, le terme "tous les candidats" ne signifie pas forcément tous les types de macroblocs possibles. Les types 4x4, 4x8 et 8x4 ne sont essayés que si 8x8 est meilleur que 16x16.

--direct none|temporal|spatial|auto : Détermine le type de prédicteur de mouvement utilisé pour les macroblocs directs dans les B-Frames. Option sur spatial par défaut. Suivant le Mode Spatial, les vecteurs de mouvements sont extrapolés d'après les blocs adjacents. Tandis que pour le Mode Temporal, ces derniers sont interpolés d'après la P-Frame suivante. Les prédicteurs spatiaux et temporels sont approximativement de la même vitesse. Ils produisent également un PSNR similaire, mais les temporels sont souvent plus jolis. L'option none donnera une qualité médiocre et la vitesse n'en sera que plus lente. Avec le mode auto, le compresseur choisira lui-même automatiquement le type de prédicteurs suivant la complexité des frames.

--no-weightb : Désactive la prédiction pondérée des B-Frames. Si vous activez cette option, alors les macroblocs prédits bidirectionnellement auront leurs trames de référence pondérés de la même valeur. Par défaut, les pondérations seront déterminées par la position temporelle de la B-Frame par rapport à celles de référence.

--me [chaîne] : Choix de la méthode en se qui concerne l'estimation du mouvement des pixels. Il y a 5 méthodes possibles :

- La plus rapide : la méthode de recherche en "diamant". (--me dia)
- Celle appliquée par défaut, la méthode de recherche hexagonale. (--me hex)
- Recherche multi-hexagonale. (--me umh)
- Lente : la recherche dite "exhaustive". (--me esa)
- La très lente : la recherche sur la base de l'algorithme hadamard. (--me tesa)

Suivant chaque itérations, les macroblocs sont parcourus pour déterminer les vecteurs de mouvement des blocs de pixels. On retient celui qui donne la distorsion la plus faible. A partir de là, on teste les vecteurs de mouvement voisins. La méthode qui est utilisée ici permet donc de définir le nombre de vecteurs voisins qui seront testés. Pour se qui la recherche en « diamant », la méthode consiste à tester les 4 vecteurs de mouvements voisins. Pour la recherche hexagonale, c'est les 6 vecteurs de mouvement voisins.

--merange [entier] : Rang maximum pour la recherche des vecteurs de mouvement. Valeur par défaut à 16.

--mvrange [nbre flottant]: limite le rang maximum de vecteurs de mouvement. Depuis que le compresseur limite cela par défaut (511,75) pour des raisons de compatibilité de norme H.264, il est inutile de le modifié. Valeur automatique à -1 par défaut.

--mvrange-thread [nbre entier] : contrôle le buffer minimum entre chaque threads. Valeur automatique à -1 par défaut.

-m ou –-subme [entier] : Valeurs possibles [1|2|3|4|5|6|7|8|9|10]. Ce paramètre permet de contrôler le compromis qualité/vitesse lié aux décisions du processus d'estimation du mouvement. -m=5 peut augmenter jusqu'à 10% le taux de compression par rapport à -m=1. Quelques détails complémentaires sur les différents modes :

--psy-rd : contrôle la force de l'optimisation psychovisuel.

--no-mixed-refs : Désactive pour chaque partition de blocs 8x8 ou 16x8 le choix de leurs trames de référence.

--no-chroma-me : Permet d'ignorer la chroma dans l'estimation de mouvement. Nécessite cependant une valeur de -m égale à 5. (-m 5).

--no-8x8dct : Permet de désactiver le fameux High Profile de la norme h264. La dct est donc à la fois spatiale et adaptative.

-t ou -–trellis [entier] : Permet d'activer la quantisation basée sur le Rate-Distorsion (distorsion du taux). Trois choix possibles : 0|1|2. Option que l'on retrouve également pour le XviD. L'x264 n'utilise pas le même algorithme mais le système de fonctionnement peut être mis en parallèle. C'est une sorte de seconde passe concernant le processus de quantisation de manière à avoir une meilleure efficience concernant la DCT. Par défaut cette option n'est pas activée (-t = 0). Si vous optez pour une valeur de -t = 1 alors le processus se fera seulement à la fin de l'encodage du MacroBloc. A l'inverse, si vous choisissez -t = 2, alors le processus s'exercera sur tous les modes de décisions. Requiert le mode CABAC (activé par défaut).

--no-fast-pskip : en choisissant cette option, on désactive la détection la plus proche pour les P-Frames.

--no-dct-decimate : permet de désactiver le seuil des coefficients au niveau de la DCT pour les P-Frames.

--nr [entier] : NR pour Noise Reduction. Autrement dit, une option agissant comme un filtre pour réduire certains artefacts que l'on nomme plus sommairement "bruits". Par défaut, une valeur de 0 désactive ce filtre. L'échelle de valeurs possibles s'étend de 1 à 16.

--deadzone inter [entier] : permet de spécifier la taille de la quantification inter pour les zones sensibles à fort détails et granulosités pour des débits mediums ou élevés. Valeurs possibles s'échelonnent entre [0 et 32] par défaut fixée à 21.

--deadzone intra [entier] : permet de spécifier la taille de la quantification intra pour les zones sensibles à fort détails et granulosités pour des débits mediums ou élevés. Valeurs possibles s'échelonnent entre [0 et 32] par défaut fixée à 11. En dessous de celle-ci (proche de 0), peut aider quant à la préservation des détails. L'utilisation combinée d'une matrice de quantification CQM peut également être bénéfique.

--cqm [chaîne] : active un preset de matrice de quantification. 2 choix possibles, soit la forme jvt issue de l'équipe de développeurs qui est à l'origine de la norme AVC, soit la forme flat, celle par défaut.

--cqmfile [chaîne] : si vous voulez spécifier d'autres matrices de quantifications, choisissez cette option. Le compresseur lira directement le fichier contenant les différentes matrices. Attention, les matrices spécifiées dans ce fichier doivent respecter une certaine forme (voir pour exemple le fichier des matrices de l'encodeur h264 de référence JM).

--cqm4 [liste] : permet de spécifier des matrices de quantification personnalisées pour les blocs 4x4. Prend comme argument une liste de 16 nombre entiers séparés par une virgule.

--cqm8 [liste] : permet de spécifier des matrices de quantification personnalisées pour les blocs 8x8. Prend comme argument une liste de 64 nombre entiers séparés par une virgule.

--cqm4i, --cqm4p, --cqm8i, --cqm8p : permet de spécifier des matrices de quantification pour traiter à la fois la luminance et la chrominance concernant les blocs 4x4 et 8x8.

--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc : permet de spécifier des matrices de quantification soit pour la chrominance, soit pour la luminance. (c pour chroma et y pour la luma).

Video Usability Info (Annex E)

Les paramètres VUI settings ne sont pas utilisés par l'encodeur mais sont simplement des suggestions pour la lecture. Voir le fichier vui.txt pour plus de détails dans le svn.

--overscan [chaîne] : permet de spécifier le paramétrage de l'overscan. 3 options possibles : undef, show, crop. Par défaut, cette option est non-définie (undef).

--videoformat [chaîne] : permet de spécifier le format de votre vidéo d'origine. (component, pal, ntsc, secam, mac, undef). Par défaut, cette option est non-définie (undef).

--fullrange [chaîne] : permet d'inclure le paramètre du rang d'échantillonnage de la chrominance et de la luminance (off, on). Par défaut sur off.

--colorprim [chaîne] : permet de spécifier les couleurs primaires de votre source vidéo. Plusieurs choix possibles : undef, bt709, bt470m, bt470bg, smpte170m, smpte240m, film.Par défaut non-défini (undef).

--transfer [chaîne] : permet d'avoir les caractéristiques sur le mode de transfert. Plusieurs choix s'offrent à vous : undef, bt709, bt470m, bt470bg, linear, log100, log316, smpte170m, smpte240m. Par défaut, option non-définie (undef).

--colormatrix [chaîne] : permet de spécifier les préférences quant à la matrice de couleurs utilisée. Plusieurs choix possibles : undef, bt709, fcc, bt470bg, smpte170m, smpte240m, GBR, YcgCo. Par défaut, option non-définie (undef).

--chromaloc [nbre entier] : permet de spécifier la localisation de l'échantillon de chroma. Valeurs possibles : 0 à 5. 0 par défaut.

Input/Output

-o ou –-output [nom du fichier]: Permet de spécifier l'emplacement du nom de fichier de sortie.

--sar width:height : permet de spécifier le Sample Aspect Ratio (SAR). Avec width la largeur et height la hauteur.

--fps float|rational : Permet de spécifier le FrameRate de votre fichier à encoder. (float = valeur flottante. Exemple 25.000. Rational = rationnel. Exemple : 30).

--seek [entier] : Pour spécifier le numéro de la 1ère frame à encoder.

--frames [entier] : Permet de spécifier le nombre maximal de Frames à encoder. Utile pour faire des tests. A noter que vous pouvez le faire également via la fonction Trim() sous Avisynth, réservé, il est vrai, aux plateformes Windows.

--level [entier] : Définit le niveau du flux comme définit dans l'Annexe A de la norme standard H.264 (par défaut, valeur fixée à 40. Valeurs possibles comprises entre [1 et 5.1]. Plus exactement, cette option est utilisée pour indiquer au décodeur quelles options du codec il doit gérer. N'utilisez ce paramètre que si vous saisissez bien ce qu'il signifie, et qu'il vous faut le modifier. Un lien pour avoir plus de détails sur ce sujet.

-v ou –-verbose : Permet d'avoir les statistiques de chaque frames dans l'invite de commandes.

--no-progress : Permet de désactiver l'indicateur d'avancement du processus.

--quiet : Mode silencieux. C'est à dire que vous n'aurez aucune indication de votre encodage dans l'invite de commandes si vous spécifiez cette option.

--psnr : active tous les calculs de PSNR (Peak Square Noise Ratio) en sortie.

--ssim : active tous les calculs SSIM en sortie.

--threads [entier] : Cette nouvelle option permet de découper chaque frame en tranche (slice) et les encode en parallèle. Par défaut, la valeur est fixée à 1. Autorise de plus le décodage "multi-threadé" si le décodeur le gère (pas libavcodec pour le moment). Il faut savoir que cette option dégrade un peu la compressibilité.

--thread-input : permet au frameserver qu'est Avisynth d'utiliser un thread dédié au cours du processus d'encodage.

--asm : écrase toutes les optimisations CPU déjà spécifiées en interne. Utile seulement pour les développeurs.

--no-asm : Désactive toutes les optimisations CPU de votre PC lors de l'encodage.

--visualize : Permet de voir les types de Macroblocs sur la vidéo encodée.

--sps-id [entier] : Permet de choisir un identifiant spécifique pour le SPS et le PPS.

--aud : Permet d'utiliser l'accès aux délimiteurs d'unité.

Quelques Applications utilisant l'x264

VLC :: Lecteur & Transcodeur pour Windows, Linux, Mac OS
HandBrake :: Transcodeur pour Windows, Linux, Mac OS
D-Vision :: Transcodeur pour Mac OS
TCVP :: Lecteur & Transcodeur pour Unix
Avidemux :: Transcodeur pour Windows, Linux, Mac OS
MPlayer/Mencoder :: Lecteur & Transcodeur pour Windows, Linux, Mac OS
FFMPEG :: Transcodeur pour Windows, Linux, Mac OS
FFdshow :: Décodeur pour Windows
MeGUI :: Transcodeur pour Windows
StaxRip :: Transcodeur pour Windows
Winamp :: Lecteur & Transcodeur pour Windows
MKVMagic :: Transcodeur pour Windows
MediaCoder :: Transcodeur pour Windows
Mencoder GUI :: Transcodeur pour Windows

Copyright © 24/04/2005 : Kurtnoise
Document soumis au Copyleft : cette oeuvre est libre, vous pouvez la redistribuer et/ou la modifier selon les termes de la Licence Art Libre.
Cliquez ici pour afficher un exemplaire de cette Licence.

d'Oursse

Equateur · Scène Francophone Inscrit le: 22 Oct 2002 Messages: 695

Question subsidiaire à ceux qui ont testé extensivement ce codec (moi perso, je n'ai pas remarqué). Est-ce que le "deblocking filter", si supérieur à zéro, ou inversement, arrive au final à faire varier le niveau de compression du codec sur une source donnée?

Tyler_Durden · Super membre Inscrit le: 23 Oct 2002 Messages: 1832 Localisation: France - 93

Citation:

# Deblocking Filter : autre caractéristique intrinsèque de la norme AVC. Filtre permettant de réduire les artefacts causés par les blocs. Il est conseillé de ne pas le désactiver. Vous pouvez contrôler ce seuil de filtrage. Valeur possible comprise entre -6 et 6. par défaut, le seuil est fixé à 0. Une valeur positive réduit beaucoup plus les artefacts des blocs de pixels mais peut également lisser certains détails.
Si vous envisagez de réaliser raisonnablement des encodes de haute qualité, il peut être judicieux de diminuer légèrement cette valeur par défaut (-1 voir -2). Cependant, si votre source possède déjà du blocking ou du bruit et que vous désirez le réduire d'autant plus, alors il est préférable d'augmenter légèrement cette valeur.

la valeur agit sur la puissance du deblocking ou sur le quantizer a partir duquel le deblocking est activé ? (ou les deux ?)

Si ça agit sur la puissance du deblocking, alors a haut quantizer (tres haut), on doit gagner en compressibilité en poussant la puissance.
Avec deblocking, une image encodée -a haut quantizer- doit etre plus proche, metriquement, de la source que la meme image encodée sans deblocking. Comme elle va servir d'image de reference a la prochaine, la frame "lissée" donnera de meilleurs resultats -surtout que le blocking rajoute des hautes frequences...-, enfin ça reste théorique (!)

Equateur · Scène Francophone Inscrit le: 22 Oct 2002 Messages: 695

Oui, ok, on devrait gagner en bits pour chaque frame "deblocked", mais est-ce que ces bits ne sont pas réutilisés par la suite? D'où ma question de départ, sur l'intégralité d'une source. Il est vrai que je n'ai jamais poussé plus loin que (-2; +2) cette fonction, mais je n'ai pas remarqué de grosses variations...

Manao

Alors voici un petit test montrant l'effet de l'inloop, à différents quantizers :

Code:

Quantizer | Force | Taille | PSNR
-----------------------------------
18 | 0 | 5011 | 45.927
18 | -6 | 5076 | 45.896
18 | 3 | 4941 | 45.779
18 | 6 | 5021 | 44.814
-----------------------------------
26 | 0 | 1817 | 41.089
26 | -6 | 1869 | 40.793
26 | 3 | 1797 | 41.002
26 | 6 | 1889 | 40.286
-----------------------------------
34 | 0 | 648 | 36.509
34 | -6 | 685 | 36.187
34 | 3 | 645 | 36.369
34 | 6 | 667 | 36.007

Comme vous pouvez le constater, la taille la plus petite est souvent atteinte avec un deblocking de l'ordre de 3, quelque soit le quantizer. Cependant, ce qui compte reste quoiqu'il arrive le ratio taille / qualité, et dans ce cas, l'optimal ( pour le psnr ) est une force de deblocking à 0 ( la force varie en fonction du quantizer, et la force '0' a été choisie de manière à maximer le compromis taille / qualité en permanence ).

Visuellement, comme aucun décodeur ( pour l'instant ) ne permet de visualiser l'image non déblockée, je conseillerais toujours de mettre un deblocking entre -4 et 0 ( j'aime pas le flou ). Une fois qu'un tel décodeur existera, les deblocking supérieurs à 0 seront envisageables.

Tyler_Durden · Super membre Inscrit le: 23 Oct 2002 Messages: 1832 Localisation: France - 93

Citation:

mais est-ce que ces bits ne sont réutilisés par la suite?

tu parles pour un encodage quantizer constant ? Si c'est ça, non, je pense pas. les bits gagner le sont définitivement. Peut etre qu'a bas quantizer, par contre, le "in-loop" est a proscrire.
La seule chose est qu'il faut définir la "puissance" du deblocking a utilisé au décodage (a définir, de toute façon quelque soit sa valeur)

A quel quantizer, tes tests ? avec une valeur de -2, tu as eu un fichier plus petit qu'avec +2 ?
Faudrait essayer -6/0/+6 a quantizer 40.

Manao

Et pour info, sur le fonctionnement du deblocking :

Le deblocking utilise lors du traitement deux seuils ( alpha et beta ) qui sont calculés en fonction du quantizer effectif de l'image. Ce quantizer effectif est la somme du quantizer réel, et de la force de deblocking rajoutée ( -6 / +6 ).

Les tables pour ces deux valeurs sont les suivantes ( 0 -> pas de traitement, et sinon, plus c'est grand, plus le deblocking est fort )

Code:

QP | <16 | 16 | 20 | 25 | 30 | 35 | 40 | 45 | 50
alpha | 0 | 4 | 7 | 13 | 25 | 45 | 80 | 144 | 255
beta | 0 | 2 | 3 | 4 | 8 | 10 | 13 | 15 | 18

kurtnoise · Sound Master Inscrit le: 19 Oct 2002 Messages: 6012 Localisation: 06

A quand un deblocking filter adaptatif pour le x264 ? Very Happy

Sinon, j'avais une question. Je sais pas si tu pourras y répondre Manao...mais tu as sûrement plus testé que moi ce compresseur, est-il préférable *actuellement* d'utiliser la version VFW ou la CLI ?

Je ne parle pas en terme de possibilité d'output mais plutôt niveau qualité intrinsèque (i.e les options que l'on ne retrouve pas sous la version VFW sont-elles pleinement fonctionnelles dans la CLI ?).

Equateur · Scène Francophone Inscrit le: 22 Oct 2002 Messages: 695

Merci à vous deux pour vos précieuses réponses.

Manao

Fondamentalement, non.

La CLI permet de faire tout ce que le VFW permet, plus quelques trucs en plus, qui ne sont pas nécessaires dans l'usage de tout les jours, ou qui sont trop complexe pour l'utilisateur 'moyen' ( principalement les paramètres de rate control, plus le chroma quantizer offset, les restrictions de quantizers, peutêtre aussi le chroma motion )

Manao

La réponse précédente était pour Kurtnoise, bien sûr.

Equateur : je me quote : "l'optimal ( pour le psnr ) est une force de deblocking à 0".

Ensuite, le deux passes n'a pas d'importance en ce qui concerne le deblocking : quelque soit le quantizer ( et donc la décision de rate control prise pour l'image courante ), la force 0 est celle qui maximise (*) le compromis PSNR / taille.

Bien évidemment, dans le cas d'un encodage à quantizer constant ( où la taille n'intéresse pas ) seul le PSNR est intéressant, et dans ce cas, rien n'assure que le deblocking 0 soit celui qui donne le meilleur résultat ( bien que ça ait été le cas sur les exemples donnés ).

(*) : statistiquement parlant, bien sur, il existe forcément des contre exemples. Mais pour un grand nombre varié de contenu, c'est le meilleur.

Ensuite, pour couper court aux inévitables critiques sur la maximisation du psnr ( comme indice de qualité ) : quoiqu'on en dise, le psnr est corrélé à la qualité visuelle, donc, une meilleure mesure faisant défaut, essayer de la maximiser est un objectif valable.

Sur la façon d'appliquer le deblocking : il ne dépend pas du mode de prédiction pour les B. Par contre, le deblocking dépend du type de blocs à la frontière qui va être debloquée : l'intra / intra, intra / inter, inter / inter seront débloqués différemment. Le deblocking dépend d'autres paramètres aussi ( mais ça devient trop technique là ).

Pour finir, quelques infos en vrac sur comment tester l'effet de certains paramètres : il ne faut pas faire un seul encodage à quantizer constant. Il ne faut pas essayer de choisir les réglages qui minimisent la taille à quantizer donné, ni celui qui maximise le psnr / l'indice de qualité choisi.

Deux méthodes sont valables : l'une consiste à faire plusieurs encodages, avec les mêmes réglages, à différents quantizer, et à reporter sur un graphique les couples psnr / taille qui formeront alors une courbe. Pour comparer deux réglages différents, il suffit de regarder lequel possède la courbe la plus élevée.

L'autre consiste à viser le même bitrate avec deux réglages différents, et à regarder lequel semble le meilleur. Ce dernier a cependant le défaut de dépendre de l'algorithme de rate control.

Equateur · Scène Francophone Inscrit le: 22 Oct 2002 Messages: 695

Ok, manao et merci pour la rapidité de la réponse...

Pour ce qui concerne ma question au sujet de l'indice de qualité, c'était juste pour savoir ce que tu appelais "qualité". Il n'est pas question, pour ma part, de chercher à "polémiquer" la-dessus.

Donc, conclusion et pour simplifer, au sujet du déblocking, pour un encodage en 2 passes, la valeur par défaut se trouve être la plus adaptée dans la majorité des cas, et à quant constant, l'issue finale se trouve être plus liée à la qualité de la source.

Pratiquement, si faire varier le deblocking (-4,0), c'est préférable de le faire à quant constant car son impact est plus important que sur du 2 passes... J'ai bien compris?! Cheesy Grin

Manao

Citation:

Il n'est pas question, pour ma part, de chercher à "polémiquer" la-dessus.

Les points d'exclamation me faisaient peur Razz

Citation:

si faire varier le deblocking (-4,0), c'est préférable de le faire à quant constant car son impact est plus important que sur du 2 passes... J'ai bien compris?

Non : le deblocking a la même influence quelque soit le type de rate control. La seule différence est la finalité de l'encodage.

Enfin, en fait le problème c'est que l'encodage à quantizer constant est une hérésie ( parce que sans finalité ), donc on en parle plus et tout est plus simple.