1 heure pour encoder 5 secondes de vidéo

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.

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.

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.

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).

J’ai un peu joué avec les formats d’image HEIC et AVIF (en gros : HEVC et AV1 mais pour une seule image, même si on peut mettre des animations) et le résultat est proche de ce qui est décrit dans ce billet : c’est très efficace (beaucoup plus que l’antique JPEG, plus que webp) muis atrocement lent à la compression. Sur une seule image c’est pas un problème, mais mieux vaut ne pas avoir de grosse série à compresser.

Les deux formats se valent en terme de rapport qualité/poids, d’ailleurs, la différence se fait surtout sur les fonctionnalités annexes et le support. Idem avec JPEG XL (qui lui est très mal supporté par contre).

PS : attention, avec les réglages par défaut de ImageMagick, AVIF donne l’impression d’être plus efficace que HEIC (images en sortie plus petites), mais c’est surtout parce que ledit réglage par défaut est plus agressif (images en sortie de moins bonne qualité). Pour une taille en sortie identique, la qualité est presque identique sur les deux formats.

J’ai à mon tour joué avec l’encodeur logiciel de l’AOM (SVT-AV1), la version intégrée dans le dernier HandBrake 1.6 – à la base je voulais tester celui qui est intégré en matériel dans ma nouvelle carte graphique, mais apparemment pour l’instant il n’est utilisable que dans OBS, donc pas pour ce que je veux en faire.

En fait, cet encodeur logiciel est très paramétrable ; en particulier il y a deux grands réglages :

1. La qualité (RF), entre 0 et 63. Cf cette doc pour les valeurs utiles (valable pour toutes les familles de codecs).
2. Les presets (Q), entre 0 et 12. Ce réglage a un impact massif sur les performances (et sur la qualité finale). Q6 est à peu près aussi rapide que l’encodeur HEVC logiciel chez moi ; Q12 est plus de 10x plus rapide ; Q1 est plus de 10x plus lent.

La doc officielle a tout un tableau concernant l’impact du preset de qualité. Ce qu’il faut en retenir c’est ça :

Generally speaking, presets 1–3 represent extremely high efficiency, for use when encode time is not important and quality/size of the resulting video file is critical. Presets 4–6 are commonly used by home enthusiasts as they represent a balance of efficiency and reasonable compute time. Presets between 7 and 12 are used for fast and real-time encoding.

Pour vous donner une idée, en full HD, un réglage RF30 Q6 est à peu près aussi rapide que HEVC (logiciel) et produit un fichier à peine plus petit, mais pour une qualité un peu meilleure.

Dans tous les cas, l’encodeur matériel HEVC – au moins celui d’AMD – est uniquement fait pour du temps réel ; même en mode « Vas-y soit le plus lent possible et sort le fichier le plus petit possible » il produit un fichier sensiblement moins bon en qualité et beaucoup plus gros (à la louche 4 pour 3) que l’encodeur logiciel. Le principal avantage, c’est qu’il le génère 10x plus vite.