Licence CC BY-SA

1 heure pour encoder 5 secondes de vidéo

Codec AV1 : performant, mais coûteux ?

Le codec AV1 est un codec de dernière génération, libre et ouvert, qui est le fruit de la collaboration de plusieurs grands noms, cela prend la forme d’un consortium : l'Alliance for Open Media (AOM).

AV1 promet des performances de compression excellentes en maintenant une belle qualité d’image quand on le compare à H.264 qui reste, encore aujourd’hui, le codec de choix dans énormément d’applications à destination du Web.

Cependant, AV1 se plie mal — vraiment très mal — à l’encodage logiciel. J’ai testé l’encodeur de référence (de l’AOM) via ffmpeg. Voyons ce que ça donne.

Version source

Mon fichier source est une vidéo 1920×1080 en 60 FPS prise depuis un iPhone 8. Il s’agit de la source directe, telle qu’enregistrée par l’iPhone au moment de la capture. Voici les caractéristiques du flux vidéo de ~5 secondes de la source :

  • HEVC, profil Main L4.1
  • 1920×1080, 60 FPS (constant)
  • Bitrate de 12.0 Mb/s

Version H.264

Une version H.264 a été produite, laissant à ffmpeg le soin de sélectionner les bons presets H.264. L’encodeur est ici libx264, un encodeur logiciel rapide et réputé. L’encodeur matériel via VA-API de mon CPU Intel est plus performant encore, mais il ne produit pas un rendu aussi bon à bitrate égal.

Nous obtenons ainsi un fichier vidéo affichant un bitrate moyen de 9.2 Mb/s, l’encodage se fait en quelques secondes sur mon Intel Core i7–10710U.

Version AV1

Pour la version AV1, c’est un résultat bien différent : c’est bien 1 heure et 17 minutes d’encodage qui ont été nécessaires ! Le flux final a un bitrate moyen de 8.3 Mb/s, ce qui est certes meilleur que celui de la version H.264, mais ça ne semble pas être un gain mirobolant, surtout quand on passe de quelques secondes d’encodage à plus d’une heure.

Différence de qualité

AV1 se targue d’avoir une compression très performante. Ce n’est pas probant ici. Cependant, nous pouvons approcher le même problème sous un autre angle. En comparant le flux H.264 (9.2 Mb/s) et le flux AV1 (8.3 Mb/s), quel est celui qui a le meilleur rendu visuel à la fin ?

J’ai pris quelques captures grâce à ffmpeg pour comparer certains éléments de la vidéo, tantôt sur la version H.264, tantôt sur la version AV1. Ces captures ont été prises en PNG sans compression. Les captures sont assez lourdes (2.5 MB pour chaque fichier PNG), donc je ne mets ici que des éléments rognés, eux non plus sans compression.

Mes observations sont dans les blocs secrets. Ainsi, vous pouvez vous amuser à distinguer des éléments entre les deux versions sans être influencés.

Numéro d’immeuble

AV1 - numéro 16
AV1 - numéro 16
H264 - Numéro 16
H264 - Numéro 16

Mon avis subjectif :

Le numéro me semble plus distinct sur la version AV1. Cependant, cela est plus probant avec l’image de 1920×1080 complète.

Visage moyennement proche de la caméra

AV1 - Visage
AV1 - Visage
H264 - Visage
H264 - Visage

Mon avis subjectif :

Le visage semble présenter moins d’artefacts (blocs carrés) sur la version AV1. La délimitation entre le verre des lunettes et la peau bave moins et est plus propre sur la version AV1. La zone ombrée par les lunettes est plus propre sur la version AV1.

Poteau

AV1 - Poteau
AV1 - Poteau
H264 - Poteau
H264 - Poteau

Mon avis subjectif :

Sur les bandes blanches réfléchissantes des poteaux, la version AV1 semble conserver plus de détails.

Conclusion

L’encodeur software de référence de l’AOM me semble produire une meilleure qualité à bitrate plus réduit (de 1 Mb/s) que H.264. Cependant, le test n’est pas probant et mériterait certainement d’être suivi d’une analyse plus approfondie. Notamment en testant sur des fichiers 4K (qui ont vraiment besoin d’une grosse compression pour être praticables) et en s’assurant de comparer ces deux codecs avec des flags et des presets rendant la comparaison plus pertinente. Il faudrait aussi viser absolument les bitrates qui sont la norme dans la distribution Web (pour du 1080p 60 FPS, nos bitrates sont plutôt raisonnables en l’occurrence).

À noter qu’entre H.264 et AV1 nous sautons une génération, celle de HEVC (H.265) et de VP9. Les tests comparent en général H.264 directement avec AV1 car à part sur YouTube où VP9 s’est généralisé pour la distribution finale, H.264 reste quand même le codec dominant du Web. La comparaison est donc peu équitable techniquement, mais elle l’est du point de vue de l’expérience de l’internaute, puisque l’ambition d’AV1 est de devenir le nouveau codec standard et omniprésent du Web.

Enfin, même si l’encodage logiciel semble peu viable pour AV1, rassurez-vous : il est tout à fait possible de décoder décemment des flux AV1 logiciellement. Si vous consultez YouTube, il est même possible que vous ayez déjà eu des vidéos en AV1 décodées de façon logicielle, sans le moindre souci. Ma machine, peinant tant à encoder en AV1, décode un flux 4K encodé en AV1 sans drop et sans faire tourner les ventilateurs à fond, avec le décodeur logiciel dav1d.



5 commentaires

Intéressant, même si je mettrais deux bémols à ton approche :

  1. Tu pars d’une source déjà encodée avec pertes, avec un bitrate plutôt important mais quand même : tu cumules donc des dégradations, et il peut y avoir des phénomènes d’encodeur masqués par les dégradations de la source. On peut aussi se poser la question de la recompression d’une source aussi efficace que HEVC.
  2. Tu compares des images fixes, mais certains phénomènes de dégradation sont surtout visibles à l’animation.

J’avais un peu joué avec HEVC et H.264 à une époque, sur des sources en 1080p, et j’en avais retenu ceci en gros :

  • Les encodeurs matériels sont infiniment plus rapides (capables de faire du temps réel) mais beaucoup moins efficaces (fichiers finaux 1,5 à 2x plus gros pour qualité identique, ou bien qualité franchement moins bonne à taille égale, de façon très visible pour des bitrates « classiques »). Donc pour le HEVC : streaming, surveillance -> encodeur matériel, stockage avec qualité -> encodeur logiciel.
  • Même lent, l’encodeur logiciel HEVC n’était pas lent au point de l’AV1 que tu décris (une dizaine de FPS en 1080p en « slow », sur 12 threads, selon la complexité de l’image source).
  • Les presets au-delà de « 6. Slow » ne servent à rien à des qualités normales (c’est juste plus lent à encoder, pour la même taille et la même qualité visuelle).
  • Vouloir conserver certains détails de l’image, comme l’effet de grain, consomme énormément de bande passante (x1,5 minimum pour le grain – ce qui est assez logique puisque ça consiste en gros à ajouter du bruit aléatoire sur chaque image).
  • Les présets spéciaux (comme « image avec beaucoup de grain » ou « animation ») sont réellement utiles et efficaces.
  • En mode « cible : qualité » (et pas un bitrate fixe), la taille du fichier final en HEVC n’est pas prédictible en fonction de la source, même avec une source à bitrate fixe et connu. Certaine scènes se compressent très bien, d’autres non, sans qu’il n’y ait de logique claire apparente.
  • Attention aux profiles cible, certains ne sont pas compris par tous les décodeurs matériels.

Tu pars d’une source déjà encodée avec pertes, avec un bitrate plutôt important mais quand même : tu cumules donc des dégradations, et il peut y avoir des phénomènes d’encodeur masqués par les dégradations de la source. On peut aussi se poser la question de la recompression d’une source aussi efficace que HEVC.

C’est bien ma seule source, hélas. Ce flux HEVC, c’est bien ce qui a été produit par l’iPhone lors de la prise (encodé à la volée en hardware je suppose). J’ai pris soin de récupérer le fichier MOV source tel quel et non pas une version recompressée que l’iPhone fait volontiers par défaut (mais dans ce cas il sort un MP4 contenant un flux H.264).

Les nouveaux modèles sortent du flux beaucoup plus brut en ProRes, mais ce n’est pas le cas du mien. Mais je suis d’accord pour dire qu’on ne part pas d’une source idéale de toute façon. J’aimerais faire d’autres expérimentations avec des vidéos plus brutes à l’avenir.

HEVC est efficace, mais il s’agit ici d’un flux produit à la volée par un encodeur hardware, donc pas optimal non plus. 12 Mb/s (moyenne), c’est quand même généreux. Je crois qu’il y a une option pour faire du H.264 directement plutôt que de l’HEVC, mais je me sens pas de refaire le test pour ça. Je préfère le refaire avec du ProRes ou autre du même style.

Tu compares des images fixes, mais certains phénomènes de dégradation sont surtout visibles à l’animation.

À défaut de pouvoir comparer les vidéos animées, j’ai quand même pris deux screenshots : un sur keyframe (numéro, visage), l’autre entre deux keyframes (poteaux).

Les encodeurs matériels sont infiniment plus rapides (capables de faire du temps réel) mais beaucoup moins efficaces (fichiers finaux 1,5 à 2x plus gros pour qualité identique, ou bien qualité franchement moins bonne à taille égale, de façon très visible pour des bitrates « classiques »). Donc pour le HEVC : streaming, surveillance -> encodeur matériel, stockage avec qualité -> encodeur logiciel.

Même expérience, mais en plus la qualité n’est pas toujours en rendez-vous. Cela dit, les encodeurs hardware H.264 d’aujourd’hui semblent bien meilleurs en qualité produite. Anecdotes personnelles : j’ai observé que les encodeurs VT H264 d’Apple et celui de l’ATEM sont très décents à côté de libx264 qu’on prendra comme mètre étalon. En vrai, même les encodeurs H.264 et HEVC de mon Intel sont pas si mal. Mais sur du matériel plus vieux de chez TriCaster en revanche, j’ai déjà eu des bitrates énormes pour une qualité franchement bof… et c’était du 720p sur scène plutôt statique !

Même lent, l’encodeur logiciel HEVC n’était pas lent au point de l’AV1 que tu décris (une dizaine de FPS en 1080p en « slow », sur 12 threads, selon la complexité de l’image source).

Clairement, oui. D’expérience libx265 et libvpx pour VP9 (et en deux passes) sont lents, mais quand même « viables » pour de la vidéo pas en direct, si on est patient. Mais libaom-av1, bof…

Il existe des encodeurs AV1 concurrents qui sont censés être bien plus rapides que libaom-av1 utilisé ici, je les testerai sûrement à l’avenir.

Sur le blog de Cloudflare, je suis tombé sur un article où ils ont essayé de faire l’encodage logiciel avec leur CPU, modèle AMD EPYC 7642 48-Core. C’est vraiment lent.

ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libaom-av1 -crf 30 -b:v 0 -strict -2 av1_test.mkv […] Using a single core, encoding just two seconds of video at 30fps took over 30 minutes. Even if all 48 cores were used to encode, it would take at minimum over 43 seconds to encode just two seconds of video. Live encoding using only CPUs would require over 20 servers running at full capacity.

https://blog.cloudflare.com/av1-cloudflare-stream-beta/

En mode « cible : qualité » (et pas un bitrate fixe), la taille du fichier final en HEVC n’est pas prédictible en fonction de la source, même avec une source à bitrate fixe et connu. Certaine scènes se compressent très bien, d’autres non, sans qu’il n’y ait de logique claire apparente.

Mon échantillon de 5 secondes est pas très sympa : très peu statique, ça bouge en continu, mais il n’y a pas non plus de cut, donc c’est censé être un minimum prédictible.

Je pourrais éventuellement poster mon échantillon sur YouTube ou ailleurs pour qu’on se fasse une idée plus précise, mais il subira les ré-encodages de YouTube.

+1 -0

Pour ce genre de comparaisons et pour automatiser le process avec des collègues on avait écrit un script en Python qui prenait une vidéo source (représentative et courte) brute, on faisait varier les options de ffmpeg avec un fichier de sortie par set de paramètres. On sauvegardait aussi quelques paramètres comme le temps d’encodage.

Ensuite on extrayait automatiquement toutes les images dans un dossier par fichier vidéo, et on calculait la distance entre l’image source et cible. On pouvait ainsi évaluer sur une vidéo entière la qualité produite par rapport à l’original plus facilement.

Je ne me souviens pas quelle méthode de distance on avait choisi, je crois que c’est ImageMagick qui faisait ça (mais je n’en suis plus trop sûr). Ensuite il faut quand même vérifier grossièrement le résultat, car parfois la distance est un chouilla plus grande qu’une autre mais à l’oeil cela paraîtra mieux car ce n’est pas aux mêmes endroits que la différence se joue.

+4 -0

Pour compléter le commentaire de @Spacefox :

  • H.264 est présent depuis 2005–2006 avec x264
  • H.265 est présent depuis 2013
  • AV1 est présent depuis 1 an ou 2

Cela fait que depuis 20 ans, on a pu jouer avec toutes les options des encodeurs H.264 pour trouver les meilleurs compromis. En terme d’encodeur hardware, il n’y a en général que quelques profils disponibles.
Même chose pour le H.265 qui ne voit des encodeurs HW (embarqué dans les puces) que depuis 4–5 ans, là encore avec seulement quelques profils.
Et AV1 n’est présent que dans quelques puces et on en est au début de la technologie, tous les profils et options ne sont pas encore maîtrisés.

Donc au niveau encodeur software, tout dépend de l’implémentation qui est faite ainsi que de la compréhension des algorithmes et profils. En terme de temps de compression, le fait d’avoir des instructions spécifiques sur le CPU (je pense à AVX-512) peut aussi fortement jouer (selon l’implémentation de l’encodeur).

Autre point : les algorithmes ont été pensés pour des résolutions de base différentes.

  • H.264 est prévu pour du 720p et 1080p
  • H.265 est prévu pour du 1080p et de la 4K
  • AV1 est prévu pour de la 4K et de la 8K

Donc il y a des choix fait au niveau des algo qui peuvent avoir une influence.

Donc au niveau encodeur software, tout dépend de l’implémentation qui est faite ainsi que de la compréhension des algorithmes et profils. En terme de temps de compression, le fait d’avoir des instructions spécifiques sur le CPU (je pense à AVX-512) peut aussi fortement jouer (selon l’implémentation de l’encodeur).

L’encodeur libaom-av1 ne semble pas spécialement optimisé pour exploiter les instructions SIMD (là où le décodeur dav1d l’est clairement). Le projet rav1e a pour but d’essayer de pousser au maximum ces instructions pour encoder. Je n’ai pas essayé, je ne sais pas ce que ça vaut.

H.264 est prévu pour du 720p et 1080p
H.265 est prévu pour du 1080p et de la 4K
AV1 est prévu pour de la 4K et de la 8K

Je ne suis pas tout à fait convaincu par le fait de restreindre AV1 à la 4K et 8K. YouTube utilise (ou utilisait) bien AV1 pour certaines vidéos 1080p 60 FPS à fort trafic. On observe parfois que la version VP9, plus traditionnelle chez YouTube, est moins lourde ou à peu près pareille, aussi bien sur les déclinaisons 1080p que 4K. Il semblerait que l’objectif ne soit pas tellement l’économie de bande passante par rapport à VP9, mais plutôt la qualité visuelle pour un débit à peu près similaire. Hélas YouTube ne semble pas communiquer beaucoup là-dessus, mais Netflix le fait déjà plus et ont l’air de s’intéresser plus à la qualité offert qu’à l’économie massive de bande passante.

Par ailleurs, il y a d’autres motivations non techniques à vouloir se passer de H.264, le dominant du Web, mais aussi de HEVC (et même H.266) même sans faire de 4K/8K : c’est propriétaire, avec tout ce que ça implique. VP9 est certes ouvert, mais il n’a pas pris (en dehors de YouTube), il n’a pas renversé H.264. AV1, c’est aussi une nouvelle tentative d’imposer un codec ouvert dans l’écosystème du Web voire dans la phase de production pour le Web (qui reste pour l’instant H.264-only sur beaucoup de plateformes).

+3 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte