La magie de H.264 (2016)
(sidbala.com)- H.264, utilisé pour la vidéo sur Internet, les Blu-ray, les téléphones portables, les caméras de sécurité et les drones, est un standard de compression vidéo qui a évolué pour transmettre de la vidéo en mouvement fluide avec une bande passante réaliste
- Une vidéo 1080p 60 Hz non compressée représente environ 370 Mo/s selon
1920×1080×60×3, au point qu’un disque Blu-ray de 50 Go ne peut en contenir qu’environ 2 minutes - Le cœur de la compression repose sur la compression avec perte : elle réduit les détails les moins visibles et diminue le volume de données via la transformation dans le domaine fréquentiel, la quantification et le sous-échantillonnage de la chrominance
- La compression temporelle divise les images en I-frame, P-frame et B-frame, puis reconstruit les variations au lieu de l’image entière grâce aux vecteurs de mouvement de macroblocs de 16×16 pixels
- Dans l’exemple, une vidéo H.264 de 5 secondes à 60 fps, soit 300 images, pèse 175 Ko, alors qu’une seule capture d’écran PNG pèse 1015 Ko, et la vidéo source de 1,2 Go est réduite à 175 Ko
Les données que H.264 cherche à réduire
- H.264 est un standard de codec de compression vidéo largement utilisé pour la vidéo sur Internet, les Blu-ray, les téléphones portables, les caméras de sécurité, les drones, etc.
- Son objectif est de réduire la bande passante nécessaire à la transmission de vidéo en mouvement fluide
- Une grande partie des concepts abordés ici s’appliquent non seulement à H.264, mais aussi à la compression vidéo en général
Pourquoi la vidéo non compressée est trop volumineuse
- Un fichier vidéo non compressé simple est un tableau de buffers 2D contenant les données de pixels de chaque image, qu’on peut voir comme un tableau d’octets 3D avec deux dimensions spatiales et une dimension temporelle
- Chaque pixel utilise 3 octets pour les trois couleurs primaires : rouge, vert et bleu
- Une vidéo 1080p 60 Hz génère environ 370 Mo/s de données brutes selon le calcul suivant
1920 × 1080 × 60 × 3
- À cette taille, un disque Blu-ray de 50 Go ne peut contenir qu’environ 2 minutes de vidéo, et le stockage comme le transfert deviennent difficiles
Une vidéo de 5 secondes plus petite qu’une seule image PNG
- L’exemple de la page d’accueil d’Apple montre de manière intuitive l’effet de la compression H.264
- La vidéo de 5 secondes à 60 fps contient 300 images, mais sa taille n’est qu’environ un cinquième de celle d’une seule image PNG
- À première vue, une vidéo qui contient 300 fois plus de données paraît donc plus petite, ce qui donne à H.264 une efficacité bien supérieure à celle du PNG
Les informations supprimées par la compression avec perte
- H.264 est un codec de compression avec perte qui jette les bits les moins importants et conserve les plus importants
- Le PNG est un codec de compression sans perte, ce qui permet de reconstruire bit à bit l’image source d’origine à partir de l’image encodée
- H.264 ne fonctionne pas en découpant l’image ou en supprimant un quadrant entier ; comme d’autres algorithmes d’image avec perte, il réduit plutôt les informations de détail
- Dans l’image d’exemple, des détails comme les trous de la grille des haut-parleurs du MacBook Pro disparaissent, mais il est difficile de voir la différence sans zoomer
- À elle seule, cette étape ramène déjà l’image à environ 7 % de sa taille d’origine
Entropie et élimination de la redondance
- L’entropie de l’information correspond au nombre de bits nécessaires pour représenter une information, ce qui n’est pas la même chose que la taille brute d’un jeu de données
- On peut la comprendre comme le nombre minimal de bits nécessaire pour représenter des états possibles, comme les résultats d’un lancer de pièce
- Si une pièce lancée 10 fois donne toujours face, au lieu d’écrire
HHHHHHHHHH, on peut l’exprimer plus brièvement par « 10 fois face » - Ce processus ne modifie pas l’information elle-même : il en réduit seulement la représentation pour supprimer la redondance
- Ce type d’encodeur sans perte à usage général est appelé encodeur entropique
Domaine fréquentiel et quantification
- Les données qui varient dans l’espace ou dans le temps peuvent être transformées dans un autre système de coordonnées, et les valeurs de luminosité d’une image peuvent elles aussi être représentées dans le domaine fréquentiel
- Dans le domaine fréquentiel, les composantes de basse fréquence se trouvent vers le centre, et les hautes fréquences vers les bords
- Les motifs de détail fins, comme une grille, correspondent à des composantes haute fréquence, tandis que les variations douces de couleur ou de luminosité relèvent des basses fréquences
- En masquant les bords d’une image dans le domaine fréquentiel, on peut supprimer les informations haute fréquence ; puis, en revenant aux coordonnées x-y classiques, on obtient une image proche de l’originale mais avec moins de détails
- En changeant la taille du masque, on peut aussi ajuster le niveau de détail de l’image de sortie
- Dans l’exemple, même lorsque l’entropie de l’information tombe à 2 % de celle de l’original, la différence reste difficile à percevoir sans zoom
- En compression avec perte, ce processus est appelé quantification (quantization)
Sous-échantillonnage de la chrominance
- L’œil humain et le cerveau détectent très bien les variations de luminosité, mais distinguent relativement moins bien les fines différences de couleur
- Dans les signaux TV, les données couleur RGB sont converties en Y+Cb+Cr
Y: la luminance, essentiellement la luminosité en noir et blancCb,Cr: la chrominance, c’est-à-dire les composantes de couleur
- Du point de vue de l’entropie de l’information, RGB et YCbCr sont équivalents
- À l’époque de la télévision en noir et blanc, seul le signal Y existait ; avec l’arrivée de la TV couleur, les informations de couleur ont été encodées dans Cb et Cr puis transmises avec Y
- Les téléviseurs noir et blanc ne lisent que la composante Y, tandis que les téléviseurs couleur utilisent aussi les composantes de chrominance avant de reconvertir le tout en RGB en interne
- Dans H.264, la méthode consiste à stocker la composante Y à pleine résolution, et les composantes C à un quart de la résolution
- Le sous-échantillonnage de la chrominance supprime une partie de l’information de couleur afin de réduire de moitié la bande passante totale, tout en gardant une faible différence visuelle
- Cette technique n’est pas propre à H.264 : elle est largement utilisée depuis des décennies
Compensation de mouvement et compression temporelle
- H.264 est un standard de compression à compensation de mouvement
- Il va au-delà de la compression spatiale à l’intérieur d’une seule image en traitant plusieurs images ensemble dans la dimension temporelle
- Dans une vidéo comme un match de tennis, où la caméra est fixe et seule la balle bouge, il n’est pas nécessaire de stocker tout l’arrière-plan à chaque image
- L’image est généralement divisée en macroblocs de 16×16 pixels, et le mouvement est estimé bloc par bloc
- Il existe trois grands types d’images
- I-frame : une image qui contient tous les bits nécessaires pour reconstruire l’image complète
- P-frame : une image prédictive qui encode les vecteurs de mouvement de chaque macrobloc à partir de l’image précédente
- B-frame : une image prédictive bidirectionnelle qui se base à la fois sur des images passées et futures
- Le décodeur part de la dernière I-frame, puis ajoute les deltas de vecteurs de mouvement des images suivantes pour reconstruire l’image courante
- Dans l’exemple de la page d’accueil d’Apple, la vidéo se résume essentiellement à des macroblocs qui se déplacent à partir de trois I-frames, ce qui la rend particulièrement facile à compresser
Pourquoi il y a parfois une pause après un retour en arrière
- Le fait que des vidéos comme celles de YouTube ne reprennent pas immédiatement après un retour de quelques secondes est lié à la structure de H.264
- Quand l’utilisateur saute à une image arbitraire, le décodeur doit repartir de l’I-frame la plus proche
- Il doit ensuite accumuler les deltas de vecteurs de mouvement jusqu’à l’image visée pour reconstruire l’image courante, ce qui a un coût de calcul élevé
- Cette méthode est extrêmement efficace en termes d’espace, mais le décodage demande des calculs
La dernière étape de compression sans perte
- Même après les étapes avec perte, il reste encore des informations redondantes dans les I-frames
- Les vecteurs de mouvement des macroblocs dans les P-frames et B-frames peuvent eux aussi former des groupes ayant les mêmes valeurs
- En particulier, dans les vidéos de test où l’écran effectue un panoramique, plusieurs macroblocs se déplacent de la même quantité
- L’encodeur entropique traite cette redondance
- Comme l’encodeur entropique est un encodeur sans perte à usage général, les données en entrée restent récupérables
Taux de compression dans l’exemple
- La vidéo source de l’exemple a été capturée dans une résolution atypique de
1232×1154 - Pour 5 secondes à 60 fps, sa taille brute est d’environ 1,2 Go selon le calcul suivant
1232 × 1154 × 60 × 3 × 5
- La vidéo H.264 compressée pèse 175 Ko
- Repris avec l’analogie automobile du texte, cela revient à réduire une voiture de 3000 livres à 0,4 livre, soit 6,5 onces
- Cette explication du taux de compression simplifie fortement plusieurs décennies de recherche ; pour plus de détails, voir H.264/MPEG-4 AVC Wikipedia Page
1 commentaires
Avis de Hacker News
AV1 est un codec à la licence plus favorable, et encore plus magique
Meta fait progressivement de VP9/AV1 la base par défaut pour le streaming vidéo : https://www.streamingmedia.com/Producer/Articles/Editorial/F...
AV1 est aussi utilisé pour les appels vidéo : https://engineering.fb.com/2024/03/20/video-engineering/mobi...
Microsoft a également commencé à utiliser AV1 dans Teams, et AV1 dispose d’outils de codage vidéo particulièrement utiles pour le partage d’écran : https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
La plupart des vidéos que l’on voit aujourd’hui sur YouTube sont en VP9 ou AV1, et H.264 n’apparaît plus qu’occasionnellement
H.264 restera présent encore longtemps, mais AV1 semble bien parti pour devenir la nouvelle base de la vidéo sur Internet
Du point de vue des développeurs, il faut que tout le monde puisse y accéder ; pour l’instant, on attend que cette fonctionnalité arrive chez la majorité des utilisateurs
Ce serait bien que davantage d’utilisateurs achètent du matériel doté de l’encodage/décodage AV1, et il faudrait sans doute un logo du type « AV1 inside »
Par exemple, dans la gamme iPhone, seul l’iPhone 15 Pro propose encore le décodage matériel
Je devais enregistrer des vidéos de cours et les mettre en ligne sous forme de fichiers 720p relativement petits ; la vidéo montrait une personne se déplaçant lentement devant les lignes fines et nettes d’un tableau blanc, avec un éclairage médiocre, et le profil d’encodage par défaut de x264 n’était pas adapté
J’ai tout de même passé un jour ou deux à ajuster les paramètres, jusqu’à pouvoir lancer l’encodage la nuit suivant le cours sur un portable doté seulement d’un iGPU datant d’environ 2014, puis publier le résultat le lendemain
En revanche, libaom annonçait environ une semaine pour rendre une vidéo de 3 heures, et ses réglages par défaut étaient tellement mauvais que je n’avais pas le loisir d’expérimenter
C’était il y a 4 ans, donc cela s’est sans doute amélioré depuis, mais je ne m’attends pas non plus à des miracles
Ce n’est pas forcément un problème, mais le vrai souci d’AV1 est que la compression demande beaucoup trop de calcul
Ou alors, c’est peut-être ma vue qui s’est améliorée
J’aimerais bien lire un article qui creuse ce sujet en profondeur
Articles connexes :
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - mars 2022, 219 commentaires
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - mai 2019, 180 commentaires
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - mai 2018, 1 commentaire
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - novembre 2016, 219 commentaires
Aujourd’hui, 8 ans après la rédaction de cet article, une grande partie des brevets H.264 devraient bientôt expirer, d’ici environ 1 à 2 ans : https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
Ce n’est pas surprenant si l’on considère que la première version du standard H.264 est sortie en 2003 et que les brevets sont généralement valables 20 ans
Les générations précédentes, H.263 et MPEG-4 ASP, ont déjà vu leurs brevets expirer et sont dans le domaine public
Alors, et H.265 ? Le nombre est plus grand, non ? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
L’encodage H.265 demande beaucoup trop de calcul en plus par rapport à l’espace économisé
Par exemple, un fichier que H.264 réduirait à 1 Go en 1 heure, H.265 mettrait 12 heures à le réduire à 850 Mo
Selon l’usage, il peut de toute façon falloir une version H.264, dont la prise en charge côté client est bien plus large
Si l’on dispose de ressources de calcul de niveau datacenter, ou si l’on exploite un service de streaming où 150 Mo économisés par vidéo finissent par s’accumuler, on passera sans doute à H.265, mais dans beaucoup de cas concrets c’est difficile à justifier
Il est à peu près au niveau de VP9, mais à cause des problèmes de licence, il a eu du mal à être adopté partout
VVC/H.266 semble avoir le même problème, tandis qu’AV1 est presque aussi bon et déjà beaucoup plus largement adopté
Les codecs plus récents compressent mieux, mais leur complexité augmente de façon non linéaire
La taille des fichiers est devenue bien plus petite qu’en H.264
La norme est aussi 10 ans plus récente que H.264 : H.264 date de 2003, H.265 de 2013
Dans l’exemple « si vous lancez une pièce 10 fois et qu’elle tombe toujours sur pile, au lieu d’écrire HHHHHHHHHH, il suffit de dire “10 lancers, tous pile” », il me semble que la chaîne de H contient déjà un peu de compression avec perte
Je me souviens de l’arrivée de H.264
À l’époque, j’étais à fond sur mplayer et je téléchargeais et compilais souvent les dernières versions
La première fois que j’ai récupéré un fichier H.264, mplayer n’a pas pu le lire, et j’ai dû récupérer puis compiler une version de développement
Ça a marché, et j’ai compris deux choses : la qualité d’image était bluffante, et mon Athlon 1800+ n’était pas à la hauteur
Les performances se sont ensuite beaucoup améliorées dans les versions de mplayer ou de libavcodec, mais je me souviens encore de ce jour-là
Ça fait vraiment longtemps que je n’ai pas utilisé mplayer, mais à l’époque c’était ce qui se faisait de mieux
J’ai travaillé autrefois dans une entreprise qui développait des produits vidéo, et une autre société de Las Vegas avait vendu à nos dirigeants un « codec vidéo révolutionnaire » et un lecteur, avec obligation de signer un NDA pour l’utiliser
À l’usage, ça se comportait comme mplayer, mais vraiment trop comme mplayer
Cinq minutes d’enquête de plus ont suffi à les démasquer, et les dirigeants qui avaient payé cette société une grosse somme se sont retrouvés ridiculisés
Même dans la tech, il est étonnamment facile de tromper des décideurs non techniques
Parce qu’ils ont trop peur de prendre du retard
Les gens intelligents font appel à de bons ingénieurs pour évaluer, tandis que les victimes de Dunning-Kruger font la queue avec leur portefeuille à la main
Il y a eu une période où je m’apprêtais à quitter une startup acquise en 1999, et à l’époque je faisais de l’encodage MPEG
L’une des entreprises où j’ai passé un entretien disait avoir créé une nouvelle méthode de compression vidéo ; après signature d’un NDA, elle m’a montré un court clip encodé/décodé avec un codec logiciel non temps réel
Je passais un entretien pour être la personne qui construirait une version ASIC de cet algorithme, mais il m’a suffi de regarder une ou deux minutes de sortie pour deviner ce qu’il faisait
J’ai supposé que l’exemple était choisi pour mettre en valeur les forces de l’algorithme, j’ai proposé une scène qui lui poserait plus de difficultés et j’ai aussi expliqué, selon moi, comment il fonctionnait
Ils n’ont ni confirmé ni démenti, mais m’ont convoqué pour un second entretien
Lors de ce second entretien, j’ai parlé avec le couple de fondateurs, CEO/CTO ; leur plan n’était pas de vendre des ASIC, mais de garder le codec secret et d’utiliser l’ASIC pour construire un réseau câblé sur DSL afin de distribuer de la vidéo
Je leur ai dit : « on dirait que vous avez inventé un meilleur carburateur et que vous voulez construire une usine automobile pour concurrencer GM », et ils ne l’ont pas bien pris
Le lien avec H.264, c’est que leur argument était : « la compression existante a atteint ses limites, donc seul notre codec peut envoyer de la vidéo haute définition sur une ligne DSL »
Je leur ai répondu que les compresseurs continueraient à s’améliorer et que, même si ce n’était pas le cas, l’arrivée d’un Internet plus rapide dans les foyers ferait disparaître le seuil qu’ils pensaient pouvoir franchir
Ils disaient que, selon les lois de la physique, il existe une limite au débit binaire qu’on peut envoyer sur un fil, et que cette limite était déjà atteinte
Je n’ai pas reçu d’offre d’embauche, et je n’en voulais pas
Cette entreprise a levé de l’argent auprès de VC, mais a fermé quelques années plus tard ; d’autres ont créé des codecs bien plus efficaces, et une connexion Internet à 2 Mbit/s n’était pas une limite
Il devait y avoir beaucoup de mathématiques ingénieuses et de puissance algorithmique dans l’algorithme réel : techniquement, ce n’étaient pas des idiots, ils manquaient surtout de sens des affaires
Raconté comme ça, ça me fait passer pour un monsieur-je-sais-tout prétentieux, mais c’est l’une des deux fois de ma vie où j’ai vu quelque chose et compris en quelques secondes l’ingrédient secret
Les exemples où j’ai été idiot sont bien plus nombreux
L’algorithme ne m’a jamais été confirmé, mais les artefacts de silhouette le rendaient assez évident
MPEG, comme JPEG, compresse les images en petits blocs (8x8, 16x16, etc.), ce qui limite la portée sur laquelle on exploite la redondance spatiale, mais limite aussi le coût de calcul pour trouver cette redondance
Leur codec ressemblait à ce que Microsoft avait proposé à la fin des années 1990 pour l’architecture graphique Talisman
Au lieu de découper en blocs fixes, il semblait analyser des séquences d’images pour trouver des régions structurellement cohérentes aux frontières semi-arbitraires
Par exemple, dans un match de tennis, l’arrière-plan est assez proche d’un « corps rigide » : si la caméra panoramique déplace un pixel, les pixels voisins ont de fortes chances de subir la même transformation spatiale
Le joueur change d’une image à l’autre, mais ce bloc présente des corrélations d’éclairage et de position
Après avoir identifié ces régions, ils devaient compresser l’image de chaque région d’une façon proche de JPEG, puis, dans l’image suivante, analyser comment une région subissait une transformation affine, ou plus générale, vers l’image suivante, et l’encoder avec quelques paramètres
Cela sert de base à la prédiction de l’image suivante et, si l’ajustement est bon, il ne faut pas beaucoup de bits pour corriger l’erreur de prédiction
Elle aurait reçu 32 millions de dollars de VC et serait sortie du mode stealth en 2002
Je n’ai pas trouvé ce qu’elle est devenue ensuite
L’article est très chouette, mais employer Information Entropy comme si c’était un terme distinct fait partie des expressions du genre « ATM machine » qui me hérissent le plus
L’article lui-même est bon, mais l’expression est vraiment frappante
En 02016, H.264 était une magie enchaînée par des brevets dans plusieurs pays
Aujourd’hui, la norme a été publiée en août 02004 après un an de travail de normalisation ouvert, les brevets ne durent que 20 ans à compter de leur date de dépôt, et on ne peut pas breveter ce qui a déjà été rendu public ; donc la plupart ont expiré ou expireront dans quelques mois
Aux États-Unis, il existe un délai de grâce d’un an si l’on a soi-même divulgué l’invention, mais s’il y a une exception, j’aimerais vraiment l’entendre
userbinator a pointé vers https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264..., mais la plupart des brevets qui y figurent ont des dates de priorité postérieures à la finalisation de la norme H.264, ils ne peuvent donc pas être indispensables à une implémentation de H.264 lui-même
Sauf à soutenir qu’au moment de la normalisation on ne savait pas que c’était implémentable, mais ce n’est guère convaincant
Ce qui est étonnant, c’est que ces vingt dernières années ont vu apparaître des choses qu’on peut dire légèrement meilleures, mais, d’après mes tests avec l’implémentation ffmpeg, rien de nettement meilleur
Si son statut sans brevet est garanti, il me paraît très probable que H.264 s’ancre encore davantage comme codec standard pendant un bon moment, qu’on le veuille ou non
AV1 offre une qualité visuelle un peu meilleure à bande passante égale, mais il est beaucoup plus lent et reste vulnérable à des brevets déposés aussi tard qu’en 02018
« Le décodeur marque une pause parce qu’on lui a demandé de sauter à une image arbitraire : il doit donc repartir de l’I-frame la plus proche et refaire le calcul qui additionne les deltas de vecteurs de mouvement jusqu’à l’image courante », c’est une explication de 2016
Aujourd’hui, c’est parce que YouTube sait que tu utilises Firefox