Die Magie von H.264 (2016)
(sidbala.com)- H.264, das für Internetvideos, Blu-ray, Mobiltelefone, Überwachungskameras und Drohnen verwendet wird, ist ein Video-Kompressionsstandard, der sich entwickelt hat, um Full-Motion-Video mit realistischer Bandbreite zu übertragen
- Unkomprimiertes 1080p-60Hz-Video kommt auf Basis von
1920×1080×60×3auf etwa 370MB/s, sodass selbst auf eine 50-GB-Blu-ray nur ungefähr 2 Minuten passen - Der Kern der Kompression ist verlustbehaftete Kompression: weniger auffällige Details werden reduziert, und durch Transformation in den Frequenzbereich, Quantisierung und Chroma-Subsampling wird die Datenmenge verringert
- Die zeitliche Kompression teilt Frames in I-frames, P-frames und B-frames auf und rekonstruiert mit Bewegungsvektoren von 16×16-Pixel-Makroblöcken statt vollständiger Frames nur die Veränderungen
- Im Beispiel war ein 5 Sekunden langes 60-fps-H.264-Video mit 300 Frames 175KB groß, während ein einzelner PNG-Screenshot 1015KB groß war; das ursprüngliche 1,2-GB-Video schrumpfte auf 175KB
Die Daten, die H.264 reduzieren will
- H.264 ist ein Standard für Video-Kompressions-Codecs, der breit für Internetvideos, Blu-ray, Mobiltelefone, Überwachungskameras, Drohnen usw. verwendet wird
- Das Ziel ist, die für die Übertragung von Full-Motion-Video benötigte Bandbreite zu verringern
- Viele der hier behandelten Konzepte gelten nicht nur für H.264, sondern für Videokompression allgemein
Warum unkomprimiertes Video so groß ist
- Eine einfache unkomprimierte Videodatei ist ein 2D-Puffer-Array mit den Pixeldaten jedes Frames und kann als 3D-Byte-Array mit zwei räumlichen Dimensionen und einer zeitlichen Dimension betrachtet werden
- Jedes Pixel verwendet 3 Byte für die drei Grundfarben Rot, Grün und Blau
- 1080p-60Hz-Video erzeugt nach der folgenden Rechnung etwa 370MB/s an Rohdaten
1920 × 1080 × 60 × 3
- Bei dieser Größe passen nur etwa 2 Minuten auf eine 50-GB-Blu-ray, und auch Transport und Speicherung werden schwierig
Ein 5-Sekunden-Video kleiner als ein einziges PNG
- Das Beispiel mit der Apple-Homepage zeigt die Wirkung der H.264-Kompression sehr anschaulich
- Das 5-Sekunden-Video mit 60 fps hat 300 Frames, aber die Dateigröße beträgt nur etwa ein Fünftel eines einzelnen PNG-Frames
- Obwohl das Video scheinbar 300-mal mehr Daten enthält, ist es kleiner, weshalb H.264 viel effizienter als PNG wirkt
Informationen, die bei verlustbehafteter Kompression verworfen werden
- H.264 ist ein verlustbehafteter Kompressions-Codec, der weniger wichtige Bits verwirft und nur wichtige Bits behält
- PNG ist ein verlustfreier Kompressions-Codec, bei dem sich das ursprüngliche Quellbild bitgenau aus dem kodierten Bild wiederherstellen lässt
- H.264 arbeitet nicht, indem es Teile des Bildes abschneidet oder bestimmte Quadranten verwirft, sondern reduziert wie andere verlustbehaftete Bildalgorithmen Detailinformationen
- Im Beispielbild verschwinden Details wie die Löcher im Lautsprechergitter des MacBook Pro, doch ohne Vergrößerung ist der Unterschied schwer zu erkennen
- Schon in diesem Schritt schrumpft das Bild auf etwa 7% seiner ursprünglichen Größe
Entropie und Redundanzentfernung
- Informationsentropie ist die Anzahl der Bits, die benötigt werden, um eine Information darzustellen, und unterscheidet sich von der bloßen Größe eines Datensatzes
- Man kann sie als minimale Bitzahl verstehen, die nötig ist, um mögliche Zustände auszudrücken, etwa bei den Ergebnissen eines Münzwurfs
- Wenn bei zehn Würfen nur Kopf fällt, kann man statt
HHHHHHHHHHeinfach „10-mal Kopf“ schreiben und es kürzer ausdrücken - Dieser Prozess verändert die Information selbst nicht, sondern verkürzt nur ihre Darstellung und entfernt damit Redundanz
- Solche allgemeinen verlustfreien Encoder nennt man Entropie-Encoder
Frequenzbereich und Quantisierung
- Daten, die sich über Raum oder Zeit verändern, lassen sich in ein anderes Koordinatensystem transformieren, und auch Helligkeitswerte eines Bildes können im Frequenzbereich dargestellt werden
- Im Frequenzbereich liegen niedrige Frequenzanteile eher im Zentrum, hohe Frequenzanteile eher an den Rändern
- Feine Muster wie ein Gitter in einem Bild entsprechen hochfrequenten Anteilen, während sanfte Farb- und Helligkeitsverläufe niedrigen Frequenzen entsprechen
- Wenn man die Ränder eines Bildes im Frequenzbereich maskiert, kann man Hochfrequenzinformationen verwerfen; nach der Rücktransformation in das normale x-y-Koordinatensystem erhält man ein dem Original ähnliches Bild mit weniger Details
- Ändert man die Maskengröße, lässt sich auch der Detailgrad des Ausgabebildes anpassen
- Im Beispiel war der Informationsgehalt selbst bei nur 2% des Originals ohne Vergrößerung kaum als Unterschied wahrnehmbar
- In der verlustbehafteten Kompression nennt man diesen Prozess Quantisierung (quantization)
Chroma-Subsampling
- Das menschliche Auge und Gehirn nehmen Helligkeitsänderungen gut wahr, unterscheiden feine Farbunterschiede jedoch vergleichsweise schlecht
- Bei TV-Signalen werden RGB-Farbdaten in Y+Cb+Cr umgewandelt
Y: Luma, also praktisch die Helligkeit in SchwarzweißCb,Cr: Chroma, also die Farbinformationen
- RGB und YCbCr sind hinsichtlich der Informationsentropie gleichwertig
- In der Schwarzweiß-TV-Zeit gab es nur das Y-Signal; mit dem Aufkommen des Farbfernsehens wurden die Farbinformationen als Cb und Cr kodiert und zusammen mit Y übertragen
- Schwarzweiß-Fernseher nutzen nur die Y-Komponente, Farbfernseher verwenden zusätzlich die Chroma-Komponenten und wandeln intern in RGB zurück
- In H.264 wird die Y-Komponente in voller Auflösung gespeichert, während die C-Komponenten mit nur einem Viertel der Auflösung gespeichert werden
- Chroma-Subsampling verwirft einen Teil der Farbinformationen, halbiert damit die gesamte Bandbreite und hält den visuellen Unterschied klein
- Diese Technik ist keine Besonderheit von H.264, sondern wird seit Jahrzehnten breit eingesetzt
Bewegungskompensation und zeitliche Kompression
- H.264 ist ein Standard für Kompression mit Bewegungskompensation
- Es geht über die räumliche Kompression innerhalb einzelner Frames hinaus und behandelt mehrere Frames gemeinsam entlang der Zeitachse
- Bei Videos wie einem Tennisspiel, bei dem die Kamera fest steht und sich nur der Ball bewegt, muss nicht jedes Mal der gesamte Hintergrund gespeichert werden
- Bilder werden meist in 16×16-Pixel-Makroblöcke unterteilt, und die Bewegung wird auf Blockebene geschätzt
- Es gibt grob drei Arten von Frames
- I-frame: ein Frame, der alle Bits enthält, die zum Aufbau des gesamten Frames nötig sind
- P-frame: ein prädiktiver Frame, der die Bewegungsvektoren jedes Makroblocks aus dem vorherigen Frame kodiert
- B-frame: ein bidirektional prädizierter Frame, der sowohl aus vergangenen als auch aus zukünftigen Frames vorhergesagt wird
- Der Decoder beginnt beim letzten I-frame und addiert dann die Deltas der Bewegungsvektoren der folgenden Frames, um den aktuellen Frame zu konstruieren
- Das Beispielvideo mit der Apple-Homepage besteht faktisch aus drei I-frames, in denen sich Makroblöcke bewegen, und lässt sich deshalb besonders gut komprimieren
Warum es nach dem Zurückspulen kurz stoppt
- Das Phänomen, dass ein Video auf YouTube nach dem Zurückspringen um ein paar Sekunden nicht sofort weiterläuft, hängt mit der Struktur von H.264 zusammen
- Springt der Nutzer zu einem beliebigen Frame, muss der Decoder ab dem nächstgelegenen I-frame neu berechnen
- Danach müssen die Deltas der Bewegungsvektoren bis zum Ziel-Frame aufsummiert werden, um den aktuellen Frame zu erzeugen, was rechenintensiv ist
- Diese Methode ist räumlich sehr effizient, erfordert beim Dekodieren jedoch Rechenaufwand
Der letzte verlustfreie Kompressionsschritt
- Selbst in I-frames bleiben nach den verlustbehafteten Schritten noch redundante Informationen übrig
- Auch bei den Bewegungsvektoren der Makroblöcke in P-frames und B-frames können Gruppen mit identischen Werten entstehen
- Besonders bei Testvideos mit schwenkendem Bild bewegen sich viele Makroblöcke um denselben Betrag
- Der Entropie-Encoder verarbeitet diese Redundanz
- Da der Entropie-Encoder ein allgemeiner verlustfreier Encoder ist, lassen sich die eingegebenen Daten wiederherstellen
Beispiel-Kompressionsrate
- Das ursprüngliche Beispielvideo wurde in der ungewöhnlichen Auflösung
1232×1154aufgenommen - Bei 5 Sekunden und 60 fps ergibt sich für das Original nach der folgenden Rechnung eine Größe von etwa 1.2GB
1232 × 1154 × 60 × 3 × 5
- Das komprimierte H.264-Video ist 175KB groß
- Umgerechnet mit der Auto-Analogie des Artikels entspricht das einem Auto mit 3000 Pfund, das auf 0.4 Pfund, also 6,5 Unzen, geschrumpft ist
- Diese Erklärung der Kompressionsrate vereinfacht jahrzehntelange Forschung stark; mehr Details finden sich auf der H.264/MPEG-4 AVC Wikipedia Page
1 Kommentare
Meinungen auf Hacker News
AV1 ist ein Codec mit besserer Lizenzlage und noch mehr Magie
Meta macht VP9/AV1-Streams beim Videostreaming schrittweise zur Basis: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
Auch für Videoanrufe wird AV1 eingesetzt: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
Microsoft hat ebenfalls begonnen, AV1 in Teams zu nutzen, und AV1 enthält Werkzeuge zur Videocodierung, die besonders für Screen Sharing nützlich sind: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
Die meisten Videos, die man heute auf YouTube sieht, sind VP9 oder AV1; H.264 sieht man nur noch gelegentlich
H.264 wird sich noch ziemlich lange halten, aber es sieht sehr danach aus, dass AV1 die neue Basis für Internetvideo wird
Aus Entwicklersicht muss es für alle zugänglich sein, aber im Moment wartet man noch darauf, dass diese Fähigkeit bei der Mehrheit der Nutzer ankommt
Es wäre gut, wenn mehr Nutzer Hardware mit AV1-Encoding/-Decoding kaufen würden; ein Logo wie „AV1 inside“ scheint nötig
In der iPhone-Reihe bietet zum Beispiel bislang nur das iPhone 15 Pro Hardware-Decoding
Ich musste Vorlesungsvideos aufnehmen und als relativ kleine 720p-Dateien hochladen; das Material zeigte eine Person, die sich bei mäßiger Beleuchtung langsam vor den dünnen, scharfen Linien eines weißen Whiteboards bewegt, und das Standard-Encoding-Profil von x264 passte dafür nicht gut
Trotzdem konnte ich nach ein, zwei Tagen Herumprobieren an den Einstellungen erreichen, dass es auf einem Laptop von etwa 2014 mit nur einer iGPU in der Nacht nach der Vorlesung durchlief und ich das Ergebnis am darauffolgenden Tag hochladen konnte
libaom dagegen zeigte an, dass das Rendering eines dreistündigen Videos etwa eine Woche dauern würde, und die Defaults waren so schlecht, dass keine Zeit zum Experimentieren blieb
Das war vor vier Jahren, also ist es heute vermutlich besser, aber Wunder erwarte ich nicht
Das muss nicht unbedingt ein Problem sein, aber das eigentliche Problem von AV1 ist, dass die Kompression viel zu rechenintensiv ist
Oder vielleicht sind einfach meine Augen besser geworden
Es wäre schön, wenn es einen Artikel gäbe, der dieses Thema gründlich untersucht
Verwandte Beiträge:
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - März 2022, 219 Kommentare
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - Mai 2019, 180 Kommentare
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - Mai 2018, 1 Kommentar
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - November 2016, 219 Kommentare
Acht Jahre nach der Veröffentlichung dieses Artikels läuft ein erheblicher Teil der H.264-Patente bald aus, grob in den nächsten ein bis zwei Jahren: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
Das ist nicht überraschend, wenn man bedenkt, dass die erste Version des H.264-Standards 2003 erschien und Patente normalerweise 20 Jahre gültig sind
Die Vorgängergeneration H.263 und MPEG-4 ASP ist bereits patentfrei und in der Public Domain
Und was ist mit H.265? Die Zahl ist doch um eins höher? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
Beim H.265-Encoding ist der zusätzliche Rechenaufwand im Verhältnis zum eingesparten Speicherplatz zu groß
Eine Datei, die mit H.264 in 1 Stunde auf 1 GB schrumpfen würde, schrumpft mit H.265 in 12 Stunden auf 850 MB, so in der Art
Je nach Einsatzgebiet braucht man wegen der deutlich breiteren Client-Unterstützung vielleicht ohnehin eine H.264-Version
Wenn man Rechenressourcen auf Datacenter-Niveau hat oder einen Streamingdienst betreibt, bei dem sich 150 MB Ersparnis pro Video summieren, würde man wohl auf H.265 setzen, aber in vielen realistischen Fällen ist das schwer zu rechtfertigen
Es liegt ungefähr auf dem Niveau von VP9, aber wegen der Lizenzprobleme war eine breite Übernahme bis heute schwierig
VVC/H.266 scheint das gleiche Problem zu haben, und AV1 ist fast genauso gut und wird bereits deutlich häufiger eingesetzt
Neuere Codecs komprimieren besser, aber die Komplexität wächst nichtlinear
Die Dateigrößen wurden deutlich kleiner als mit H.264
Der Standard ist auch 10 Jahre jünger als H.264: H.264 stammt von 2003, H.265 von 2013
Bei dem Beispiel „Wenn man eine Münze 10-mal wirft und jedes Mal Kopf kommt, sagt man nicht HHHHHHHHHH, sondern ‚10 Würfe und alle Kopf‘“ scheint in der H-Zeichenkette schon etwas verlustbehaftete Kompression zu stecken
Ich erinnere mich noch, als H.264 zum ersten Mal herauskam
Damals war ich ziemlich in mplayer vertieft und habe oft die neuesten Releases heruntergeladen und gebaut
Als ich meine erste H.264-Datei bekam, konnte mplayer sie nicht lesen, also musste ich die Entwicklungsversion herunterladen und bauen
Es funktionierte, und mir wurden zwei Dinge klar: Die Bildqualität war erstaunlich, und mein Athlon 1800+ kam damit nicht klar
In späteren Versionen von mplayer oder libavcodec wurde die Performance deutlich besser, aber an diesen Tag erinnere ich mich bis heute
Ich habe mplayer schon ewig nicht mehr benutzt, aber damals war er das Beste
Ich habe früher bei einem Unternehmen gearbeitet, das videobasierte Produkte entwickelte; eine andere Firma aus Las Vegas verkaufte unseren Führungskräften einen „revolutionären Video-Codec“ samt Player, und um ihn zu nutzen, musste man ein NDA unterschreiben
Beim Ausprobieren verhielt er sich wie mplayer, und zwar viel zu exakt
Nach fünf weiteren Minuten Recherche flog die Sache auf, und die Führungskräfte, die dieser Firma viel Geld gezahlt hatten, standen ziemlich blamiert da
Es ist erstaunlich leicht, auch im Tech-Bereich nichttechnische Entscheider zu täuschen
Denn die Angst, den Anschluss zu verlieren, ist einfach zu groß
Kluge Leute holen sich gute Engineers zur Bewertung dazu; Dunning-Kruger-Kandidaten stellen sich mit gezücktem Portemonnaie in die Schlange
Es gab eine Zeit, in der ich ein 1999 übernommenes Startup verlassen wollte; damals arbeitete ich an MPEG-Encoding.
Eine der Firmen, bei denen ich mich vorstellte, sagte, sie habe ein neues Verfahren zur Videokompression entwickelt, und zeigte mir nach Unterzeichnung einer NDA einen kurzen Clip, der mit einem nicht echtzeitfähigen Software-Codec encodiert/decodiert worden war.
Ich wurde als jemand interviewt, der eine ASIC-Version dieses Algorithmus bauen sollte, aber schon nach 1–2 Minuten Ausgabe konnte ich erahnen, was er tat.
Ich ging davon aus, dass das Beispiel auf die Stärken des Algorithmus zugeschnitten war, schlug eine schwierigere Szene vor und erklärte auch, wie die Methode meiner Ansicht nach funktionierte.
Sie bestätigten es weder noch dementierten sie es, luden mich aber zu einem zweiten Gespräch ein.
Im zweiten Gespräch sprach ich mit dem Gründerpaar, CEO/CTO; ihr Plan war nicht, ASICs zu verkaufen, sondern den Codec geheim zu halten und mit ASICs ein DSL-basiertes Kabelnetz für die Videoverteilung aufzubauen.
Ich sagte: „Das klingt, als hätte man einen besseren Vergaser erfunden und wolle nun eine Autofabrik bauen, um mit GM zu konkurrieren“, und sie nahmen das nicht gut auf.
Der Punkt, an dem diese Geschichte mit H.264 zusammenhängt, ist ihre Behauptung: „Bestehende Kompression ist an ihre Grenzen gestoßen, deshalb kann nur unser Codec hochauflösendes Video über DSL-Leitungen schicken.“
Ich antwortete, Kompressoren würden weiter besser werden, und selbst wenn nicht, würde schnelleres Internet in den Haushalten die Schwelle, die sie zu überwinden glaubten, selbst verschwinden lassen.
Sie sagten, nach den Gesetzen der Physik gebe es eine Obergrenze für die Bitrate, die sich über Kupferdrähte übertragen lasse, und diese Grenze sei bereits erreicht.
Ich bekam kein Angebot und wollte auch keines.
Die Firma erhielt VC-Geld, machte aber ein paar Jahre später dicht; andere entwickelten wesentlich effizientere Codecs, und 2-Mbps-Internetanschlüsse waren nicht die Grenze.
In dem eigentlichen Algorithmus steckten vermutlich viel clevere Mathematik und algorithmische Kraft; technisch waren sie also keine Dummköpfe, ihnen fehlte Geschäftssinn.
So wiedererzählt klinge ich wie ein angeberischer Besserwisser, aber es war eines von zwei Malen in meinem Leben, in denen ich etwas sah und binnen Sekunden die geheime Zutat erkannte.
Beispiele dafür, dass ich ein Idiot war, gibt es viel mehr.
Den Algorithmus habe ich nie bestätigt bekommen, aber an den Silhouetten-Artefakten war es ziemlich offensichtlich.
MPEG komprimiert Bilder ähnlich wie JPEG in kleine Blöcke (8x8, 16x16 usw.); das begrenzt den Bereich, in dem räumliche Redundanz genutzt wird, begrenzt aber auch den Rechenaufwand, diese Redundanz zu finden.
Ihr Codec sah nach etwas aus, das Microsoft Ende der 1990er für die Talisman-Grafikarchitektur vorgeschlagen hatte.
Statt in feste Blöcke zu unterteilen, schien er eine Frame-Sequenz zu analysieren und strukturell zusammenhängende Regionen mit halb willkürlichen Grenzen zu finden.
Bei einem Tennismatch etwa ist der Hintergrund ziemlich „starr“; wenn die Kamera schwenkt und sich ein Pixel bewegt, ist es wahrscheinlich, dass benachbarte Pixel dieselbe räumliche Transformation erfahren.
Der Spieler verändert sich von Frame zu Frame, aber in diesem Klumpen gibt es Korrelationen von Beleuchtung und Position.
Nachdem solche Regionen identifiziert waren, wurde vermutlich das Bild dieser Region auf eine JPEG-ähnliche Weise komprimiert und im nächsten Frame analysiert, wie eine Region in den nächsten Frame per affiner oder allgemeinerer Transformation übergeht, um das mit einigen Parametern zu codieren.
Das bildet die Grundlage für die Vorhersage des nächsten Frames, und wenn sie gut passt, braucht man nicht viele Bits, um den Vorhersagefehler zu korrigieren.
Sie bekamen 32 Mio. Dollar von VCs und traten 2002 aus dem Stealth Mode heraus.
Was danach aus ihnen wurde, habe ich nicht gefunden.
Der Artikel ist großartig, aber der Ausdruck Information Entropy wirkt, als sei er ein eigener Begriff, und gehört für mich zu den nervigsten Formulierungen vom Typ „ATM machine“.
Der Artikel selbst ist gut, aber die Formulierung ist wirklich heftig.
Im Jahr 02016 war H.264 in vielen Ländern patentgebundene Magie.
Heute wurde der Standard im August 02004 nach einem Jahr öffentlicher Standardisierungsarbeit veröffentlicht, Patente gelten nur 20 Jahre ab Anmeldedatum, und auf bereits Veröffentlichtes kann man kein Patent anmelden; daher sind die meisten bereits abgelaufen oder laufen in wenigen Monaten ab.
In den USA gibt es bei eigener Veröffentlichung eine einjährige Schonfrist, aber falls es eine Ausnahme gibt, würde ich sie gern hören.
userbinator verwies auf https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264..., aber die meisten dort aufgeführten Patente haben Prioritätsdaten nach der Finalisierung des H.264-Standards und können daher für eine Implementierung von H.264 selbst nicht wesentlich sein.
Es sei denn, man behauptet, zum Zeitpunkt der Standardisierung sei nicht bekannt gewesen, dass es implementierbar sei; das ist aber ziemlich wenig überzeugend.
Erstaunlich ist, dass in den letzten 20 Jahren zwar Dinge herauskamen, die man als etwas besser bezeichnen kann, aber nach meinen Tests mit ffmpeg-Implementierungen nichts wesentlich Besseres.
Wenn der patentfreie Status gesichert ist, wird H.264 wohl für einige Zeit noch stärker zum Standard-Codec werden, ob man es mag oder nicht.
AV1 bietet bei derselben Bandbreite etwas bessere visuelle Qualität, ist aber deutlich langsamer und anfällig für Patente, die noch so spät wie 02018 angemeldet wurden.
„Weil man den Decoder angewiesen hat, zu einem beliebigen Frame zu springen, muss er vom nächsten I-Frame aus beginnen und die Bewegungsvektor-Deltas bis zum aktuellen Frame erneut aufsummieren, weshalb es kurz stockt“ – das war 2016.
Heutzutage liegt es daran, dass YouTube weiß, dass du Firefox verwendest.