Wie ein Video-Codec funktioniert. Teil 2. Was, wofür, wie.

Erster Teil: Grundlagen der Arbeit mit Video und Bildern

Was? Ein Video-Codec ist ein Teil von Software/Hardware, das digitales Video komprimiert und/oder dekomprimiert.

Wofür? Trotz gewisser Einschränkungen in Bezug auf Bandbreite
und Speicherplatz fordert der Markt zunehmend qualitativ hochwertigeres Video. Erinnern Sie sich, wie wir im letzten Beitrag das Minimum für 30 Bilder pro Sekunde, 24 Bit pro Pixel bei einer Auflösung von 480×240 berechnet haben? Wir haben 82,944 Mbit/s ohne Kompression erhalten. Kompression ist derzeit die einzige Möglichkeit, HD/FullHD/4K auf Fernseher und ins Internet zu übertragen. Wie erreicht man das? Lassen Sie uns die Hauptmethoden kurz betrachten.

Die Übersetzung wurde mit Unterstützung von EDISON Software durchgeführt.

Wir sind spezialisiert auf Integration von Videoüberwachungssystemen, sowie Entwicklung von Mikrotomen.

Codec vs Container

Ein häufiger Fehler von Anfängern ist, den Codec für digitales Video mit dem Container für digitales Video zu verwechseln. Ein Container ist ein Format, eine Hülle, die Metadaten des Videos (und möglicherweise auch Audio) enthält. Komprimiertes Video kann als Nutzlast des Containers betrachtet werden.

In der Regel weist die Dateiendung eines Videodateiformats auf dessen Behältertyp hin. Eine Datei wie video.mp4 ist höchstwahrscheinlich ein Container. MPEG-4 Teil 14, während eine Datei namens video.mkv wahrscheinlich eine Matroska-Datei. Um sicher zu sein, welchen Codec und Behälterformat Sie haben, können Sie FFmpeg oder MediaInfo.

Ein wenig Geschichte

verwenden. Bevor wir zu Wie?übergehen, lassen Sie uns ein wenig in die Geschichte eintauchen, um einige alte Codecs besser zu verstehen.

Der Video Codec H.261 wurde 1990 (technisch 1988) eingeführt und wurde für eine Datenübertragungsrate von 64 Kbit/s entwickelt. Dabei wurden bereits Ideen wie Farbunterabtastung, Makroblöcke usw. eingesetzt. 1995 wurde der Standard für den Video Codec H.263veröffentlicht, der bis 2001 weiterentwickelt wurde.

Im Jahr 2003 wurde die erste Version von H.264/AVCabgeschlossen. Im selben Jahr veröffentlichte das Unternehmen „TrueMotion“ seinen kostenlosen Video Codec, der verlustbehaftete Videokompression unter dem Namen VP3. 2008 kaufte Google dieses Unternehmen und veröffentlichte VP8 im selben Jahr. Im Dezember 2012 brachte Google VP9heraus, der von etwa ¾ des Browser-Marktes (einschließlich mobiler Geräte) unterstützt wird.

AV1 — ist ein neuer, kostenloser Video-Codec mit offenem Quellcode, entwickelt von Allianz für offene Medien (AOMedia), zu deren Mitgliedern namhafte Unternehmen wie Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, Nvidia, Intel und Cisco gehören. Die erste Version des Codecs 0.1.0 wurde am 7. April 2016 veröffentlicht.

Die Entstehung von AV1

Anfang 2015 arbeitete Google an VP10, während Xiph (das zu Mozilla gehört) an Daalaarbeitete, und Cisco einen kostenlosen Video-Codec mit dem Namen Thor.

Dann MPEG LA gab zunächst jährliche Begrenzungen für HEVC (H.265) und Gebühren an, die achtmal höher waren als die für H.264, aber bald änderten sie erneut die Regeln:

ohne jährliche Grenze,
eine Gebühr für Inhalte (0,5 % des Umsatzes) und
eine Produktgebühr, die ungefähr zehnmal höher war als die für H.264.

Die Allianz für offene Medien wurde von Unternehmen aus verschiedenen Bereichen gegründet: Hardware-Herstellern (Intel, AMD, ARM, Nvidia, Cisco), Inhaltsanbietern (Google, Netflix, Amazon), Browser-Entwicklern (Google, Mozilla) und anderen.

Die Unternehmen hatten ein gemeinsames Ziel: einen Video-Codec ohne Lizenzgebühren. Dann tauchte AV1 mit einer deutlich einfacheren Patentlizenz. Timothy B. Terriberry hielt eine beeindruckende Präsentation, die zur Grundlage des aktuellen Konzepts von AV1 und dessen Lizenzmodell wurde.

Sie werden überrascht sein zu erfahren, dass Sie den AV1-Codec über den Browser analysieren können (Interessierte können die Seite besuchen aomanalyzer.org).

Universalcodec

Schauen wir uns die grundlegenden Mechanismen an, die diesem universellen Videocodec zugrunde liegen. Viele dieser Konzepte sind nützlich und werden in modernen Codecs wie VP9, AV1 und HEVCverwendet. Ich warne, dass viele der erklärten Dinge vereinfacht werden. Manchmal werden reale Beispiele (wie im Fall von H.264) verwendet, um die Technologien zu demonstrieren.

Schritt 1 – Bildaufteilung

Der erste Schritt besteht darin, das Bild in mehrere Abschnitte, Unterabschnitte und so weiter zu unterteilen.

Warum? Es gibt viele Gründe. Durch die Unterteilung des Bildes können Bewegungsvektoren genauer vorhergesagt werden, indem kleine Abschnitte für sich bewegende Teile verwendet werden. Während für statische Hintergründe auch größere Abschnitte ausreichend sein können.

In der Regel organisieren Codecs diese Abschnitte in Sektionen (oder Fragmente), Makroblöcke (oder Codierungsbaumblöcke) und zahlreiche Unterabteilungen. Die maximale Größe dieser Abschnitte variiert, wobei HEVC 64×64 festlegt, während AVC 16×16 verwendet, und Unterabteilungen können auf 4×4 verkleinert werden.

Erinnern Sie sich an die verschiedenen Arten von Frames aus dem letzten Artikel?! Dies kann auch auf die Blöcke angewendet werden, so dass wir I-Fragment, B-Block, P-Makroblock usw. haben können.

Für die, die üben möchten – sehen Sie, wie das Bild in Abschnitte und Unterabteilungen zerlegt wird. Dazu können Sie den bereits im letzten Artikel erwähnten verwenden, Intel Video Pro Analyzer (dem, der kostenpflichtig ist, aber eine kostenlose Testversion mit einer Einschränkung auf die ersten 10 Frames hat). Hier werden die Abschnitte analysiert. VP9:

Schritt 2 – Prognose

Sobald wir Abschnitte haben, können wir astrologische Prognosen für diese erstellen. Für INTER-Prognosen müssen Bewegungsvektoren und den Rest übermittelt werden, und für INTRA-Prognosen wird die Richtung der Prognose und der Rest übermittelt.

Schritt 3 – Transformation

Sobald wir den verbleibenden Block (vorgesehener Bereich → realer Bereich) erhalten, kann er möglicherweise so transformiert werden, dass wir wissen, welche Pixel verworfen werden können, während die Gesamtqualität erhalten bleibt. Es gibt einige Transformationen, die genaues Verhalten gewährleisten.

Obwohl es auch andere Methoden gibt, betrachten wir diese näher. diskrete Cosinustransformation (DCT — von diskrete Cosinustransformation). Die Hauptfunktionen der DCT:

• Transformiert Pixelblöcke in gleich große Frequenzkoeffizientenblöcke.
• Komprimiert die Energie und hilft, räumliche Redundanz zu beseitigen.
• Garantiert Rückführbarkeit.

Am 2. Februar 2017 veröffentlichten R.J. Cintra und F.M. Bayer einen Artikel über DCT-ähnliche Transformationen zur Bildkompression, die nur 14 Ergänzungen erforderten.

Machen Sie sich keine Sorgen, wenn Sie die Vorteile jedes Punktes nicht verstanden haben. Wir werden jetzt anhand konkreter Beispiele ihre tatsächliche Wertigkeit verdeutlichen.

Lassen Sie uns einen solchen 8×8 Pixelblock nehmen:

Dieser Block wird im folgenden 8x8 Pixelbild gerendert:

Wenden wir die DCT auf diesen Pixelblock an, erhalten wir einen Koeffizientenblock der Größe 8×8:

Und wenn wir diesen Block von Koeffizienten rendern, erhalten wir folgendes Bild:

Wie wir sehen, ähnelt dies nicht dem ursprünglichen Bild. Auffällig ist, dass der erste Koeffizient stark von den anderen abweicht. Dieser erste Koeffizient ist als DC-Koeffizient bekannt und repräsentiert alle Samples im Eingabearray, ähnlich wie ein Durchschnitt.

Dieser Block von Koeffizienten hat eine interessante Eigenschaft: Er trennt hochfrequente Komponenten von niederfrequenten.

In einem Bild ist der Großteil der Leistung auf niedrigeren Frequenzen konzentriert. Daher kann man, wenn man das Bild in seine Frequenzkomponenten umwandelt und die hochfrequenten Koeffizienten verwirft, die benötigte Datenmenge zur Beschreibung des Bildes reduzieren, ohne dabei zu viel Bildqualität zu opfern.

Frequenz bedeutet, wie schnell sich das Signal verändert.

Lassen Sie uns versuchen, das Wissen aus dem Testbeispiel anzuwenden, indem wir das ursprüngliche Bild in seine Frequenz (Block von Koeffizienten) umwandeln, wobei wir die DCT verwenden, und dann einige der weniger wichtigen Koeffizienten verwerfen.

Zuerst konvertieren wir es in den Frequenzbereich.

Dann entfernen wir 67 % der Koeffizienten, hauptsächlich im unteren rechten Bereich.

Schließlich rekonstruieren wir das Bild aus diesem entfernten Koeffizientenblock (denken Sie daran, dass dies umkehrbar sein muss) und vergleichen es mit dem Original.

Wir sehen, dass es dem ursprünglichen Bild ähnelt, aber es gibt viele Unterschiede zum Original. Wir haben 67,1875 % verworfen und haben dennoch etwas erhalten, das dem Original nahekommt. Es wäre möglich gewesen, die Koeffizienten durchdachter abzulehnen, um ein Bild von noch besserer Qualität zu erhalten, aber das ist ein anderes Thema.

Jeder Koeffizient wird unter Verwendung aller Pixel gebildet.

Wichtig: Jeder Koeffizient wird nicht direkt auf ein Pixel abgebildet, sondern stellt eine gewichtete Summe aller Pixel dar. Diese bemerkenswerte Grafik zeigt, wie der erste und zweite Koeffizient unter Verwendung von Gewichten berechnet wird, die für jeden Index einzigartig sind.

Sie können auch versuchen, die DCT zu visualisieren, indem Sie einen einfachen Bildaufbau auf dieser Basis betrachten. Zum Beispiel, hier ist das Zeichen A, das unter Verwendung jedes Koeffizienten gewichtet wird:

4. Schritt – Quantisierung

Nachdem wir im vorherigen Schritt einige Koeffizienten entfernt haben, führen wir im letzten Schritt (Transformation) eine spezielle Form der Quantisierung durch. In diesem Stadium ist es zulässig, Informationen zu verlieren. Einfacher gesagt, wir quantisieren die Koeffizienten, um eine Kompression zu erreichen.

Wie kann man einen Block von Koeffizienten quantisieren? Eine der einfachsten Methoden ist die gleichmäßige Quantisierung, bei der wir den Block nehmen, ihn durch einen Wert (z. B. 10) teilen und das Ergebnis runden.

Können wir diesen Block von Koeffizienten umkehren? Ja, das können wir, indem wir ihn mit demselben Wert multiplizieren, mit dem wir ihn geteilt haben.

Dieser Ansatz ist nicht der beste, da er die Bedeutung jedes Koeffizienten nicht berücksichtigt. Stattdessen könnte man eine Quantisierungs-Matrix verwenden, anstatt einen einzelnen Wert, wobei diese Matrix die DCT-Eigenschaften berücksichtigt und die meisten unteren rechten und einige oberen linken Koeffizienten quantisiert.

Schritt 5 – Entropiekodierung

Nachdem wir die Daten (Bildblöcke, Fragmente, Frames) quantisiert haben, können wir sie weiterhin verlustfrei komprimieren. Es gibt viele algorithmische Methoden zur Datenkompression. Wir werden kurz einige davon vorstellen; für ein tieferes Verständnis können Sie das Buch „Kompression verstehen: Datenkompression für moderne Entwickler“ lesen.Verstehen der Kompression: Datenkompression für moderne Entwickler»).

Videokodierung mit VLC

Angenommen, wir haben einen Zeichendatenstrom: a, e, r und t. Die Wahrscheinlichkeit (zwischen 0 und 1), wie häufig jedes Zeichen im Strom vorkommt, wird in dieser Tabelle dargestellt.

Wir können den wahrscheinlichsten Zeichen einzigartige, bevorzugt kleinere, binäre Codes zuweisen, während weniger wahrscheinliche Codes größer ausfallen.

Wir komprimieren den Strom, wobei wir annehmen, dass wir letztendlich 8 Bit pro Zeichen verwenden. Ohne Kompression würden 24 Bit pro Zeichen erforderlich sein. Wenn wir jede Zeichen durch seinen Code ersetzen, ergibt sich eine Einsparung!

Der erste Schritt besteht darin, das Zeichen e, das 10 entspricht, zu kodieren, und das zweite Zeichen ist a, das hinzugefügt wird (nicht mathematisch): [10] [0] und schließlich das dritte Zeichen t, der unseren endgültigen komprimierten Bitstrom auf [10] [0] [1110] bringt oder auch 1001110, wofür lediglich 7 Bit benötigt werden (3,4-mal weniger Platz als im Original).

Beachten Sie, dass jeder Code ein einzigartiger Code mit einem Präfix sein muss. Der Huffman-Algorithmus hilft, diese Zahlen zu finden. Obwohl diese Methode ihre Mängel hat, gibt es Videocodecs, die immer noch diese algorithmische Methode zur Komprimierung anbieten.

Sowohl der Encoder als auch der Decoder müssen Zugang zur Zeichentabelle mit ihren binären Codes haben. Daher muss auch die Tabelle in den Eingabedaten gesendet werden.

Arithmetische Codierung

Angenommen, wir haben einen Zeichendatenstrom: a, e, r, s und t, und ihre Wahrscheinlichkeit wird durch diese Tabelle dargestellt.

Mit dieser Tabelle erstellen wir Bereiche, die alle möglichen Zeichen enthalten, sortiert nach der häufigsten Anzahl.

Nun kodieren wir den Strom aus drei Zeichen: eat.

Zunächst wählen wir das erste Zeichen e, das sich im Unterbereich von 0,3 bis 0,6 (ohne inklusive) befindet. Wir nehmen diesen Unterbereich und teilen ihn erneut in den gleichen Proportionen wie zuvor, aber für diesen neuen Bereich.

Lassen Sie uns fortfahren, unseren Strom zu kodieren eat. Jetzt nehmen wir das zweite Zeichen a, der sich in einem neuen Unterbereich von 0,3 bis 0,39 befindet, und dann nehmen wir unser letztes Zeichen. t Und indem wir denselben Prozess erneut wiederholen, erhalten wir den letzten Unterbereich von 0,354 bis 0,372.

Wir müssen einfach eine Zahl im letzten Unterbereich von 0,354 bis 0,372 wählen. Lassen Sie uns 0,36 wählen (aber jede andere Zahl in diesem Bereich wäre ebenfalls möglich). Nur mit dieser Zahl können wir unseren ursprünglichen Stream rekonstruieren. Es ist wie wenn wir eine Linie innerhalb der Bereiche zeichnen, um unseren Stream zu kodieren.

Die umgekehrte Operation (das heißt, Dekodierung) ist ebenso einfach: Mit unserer Zahl 0,36 und unserem ursprünglichen Bereich können wir denselben Prozess wieder starten. Aber jetzt entdecken wir den Stream, der mit dieser Zahl kodiert wurde.

Im ersten Bereich bemerken wir, dass unsere Zahl mit dem Ausschnitt übereinstimmt, also ist das unser erstes Zeichen. Jetzt teilen wir diesen Unterbereich erneut auf, indem wir denselben Prozess wie zuvor durchführen. Hier können wir feststellen, dass 0,36 dem Zeichen entspricht, a, und nach der Wiederholung des Prozesses sind wir beim letzten Zeichen angekommen, t (wodurch unser ursprünglicher kodierter Stream entsteht. eat).

Sowohl für den Encoder als auch für den Decoder muss eine Wahrscheinlichkeitsmatrix für die Symbole vorhanden sein, daher ist es erforderlich, diese auch in den Eingangsdaten mitzuschicken.

Ganz elegant, oder? Jemand, der diese Lösung entwickelt hat, war wirklich clever. Einige Video-Codecs nutzen diese Technik (oder bieten sie zumindest als Option an).

Die Idee besteht darin, den quantisierten Bitstream verlustfrei zu komprimieren. In diesem Artikel fehlen wahrscheinlich viele Details, Ursachen, Kompromisse usw. Aber wenn Sie ein Entwickler sind, sollten Sie mehr darüber wissen. Neue Codecs versuchen, verschiedene Entropie-Codierungsalgorithmen wie ANS.

Schritt 6 – Bitstream-Format

Nachdem all dies getan ist, bleibt nur noch, die komprimierten Frames im Kontext der durchgeführten Schritte zu entpacken. Der Decoder muss explizit über die Entscheidungen informiert werden, die der Encoder getroffen hat. Alle erforderlichen Informationen müssen dem Decoder bereitgestellt werden: Farbtiefe, Farbraum, Auflösung, Prognoseinformationen (Bewegungsvektoren, gerichtete INTER-Prognose), Profil, Ebene, Bildrate, Typ des Frames, Bildnummer und vieles mehr.

Wir werden uns oberflächlich mit dem Bitstream vertrautmachen. H.264. Unser erster Schritt ist die Erzeugung eines minimalen H.264 Bitstreams (FFmpeg fügt standardmäßig alle Kodierungseinstellungen hinzu, wie SEI NAL — das erfahren wir gleich genauer). Dies können wir tun, indem wir unser eigenes Repository und FFmpeg verwenden.

./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264

Dieser Befehl erzeugt einen Rohbitstream H.264 mit einem Frame, einer Auflösung von 64×64 und einem Farbraum YUV420. Dafür verwenden wir das folgende Bild als Frame.

Der H.264 Bitstream

Standard AVC (H.264) legt fest, dass die Informationen in Makroframes (im Netzwerkverständnis) übermittelt werden, die als NAL bezeichnet werden (dies ist eine Art Abstraktionslevel im Netzwerk). Das Hauptziel von NAL ist es, ein „netzwerkfreundliches“ Video-Format bereitzustellen. Dieser Standard sollte auf Fernsehern (basierend auf Streams) und im Internet (basierend auf Paketen) funktionieren.

Es gibt ein Synchronisationsmarker, um die Grenzen der NAL-Elemente zu definieren. Jeder Synchronisationsmarker enthält den Wert 0x00 0x00 0x01, außer dem allerersten, der gleich ist 0x00 0x00 0x00 0x01. Wenn wir starten hexdump Für den generierten H.264-Bitstrom identifizieren wir mindestens drei NAL-Muster zu Beginn der Datei.

Wie bereits erwähnt, muss der Decoder nicht nur die Bilddaten, sondern auch Details zum Video, zu den Frames, zur Farbdarstellung, zu den verwendeten Parametern und vielem mehr kennen. Das erste Byte jedes NAL definiert dessen Kategorie und Typ.

Normalerweise ist das erste NAL im Bitstrom SPS. Dieser NAL-Typ informiert über allgemeine Kodierungsvariablen wie Profil, Ebene, Auflösung und mehr.

Wenn wir den ersten Synchronisationsmarker überspringen, können wir das erste Byte dekodieren, um zu erfahren, welcher NAL-Typ der erste ist.

Zum Beispiel ist das erste Byte nach dem Synchronisationsmarker gleich 01100111, wobei das erste Bit (0) im Feld forbidden_zero_bit. Die nächsten 2 Bits (11) geben uns das Feld nal_ref_idc, das angibt, ob dieses NAL ein Referenzfeld ist oder nicht. Und die restlichen 5 Bits (00111) geben uns das Feld nal_unit_type, in diesem Fall handelt es sich um einen SPS-Block (7) NAL.

Das zweite Byte (binary=01100100, hex=0x64, dec=100) im SPS NAL ist das Feld profile_idc, das das Profil zeigt, das der Encoder verwendet hat. In diesem Fall wurde das eingeschränkte Hochprofil verwendet (d.h. ein Hochprofil ohne Unterstützung für bidirektionale B-Segmente).

Wenn man die Bitstream-Spezifikation H.264 für SPS NAL betrachtet, findet man viele Werte für den Parameternamen, die Kategorie und die Beschreibung. Zum Beispiel schauen wir uns die Felder pic_width_in_mbs_minus_1 und pic_height_in_map_units_minus_1.

Wenn man einige mathematische Operationen mit den Werten dieser Felder ausführt, erhält man die Auflösung. Man kann 1920 x 1080 darstellen mit pic_width_in_mbs_minus_1 einem Wert von 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Wiederum, um Platz zu sparen, wurde anstelle von 1920 dies mit 119 gemacht.

Wenn man die Überprüfung unseres erzeugten Videos im Binärformat fortsetzt (z.B.: xxd -b -c 11 v/minimal_yuv420.h264), kann man zum letzten NAL übergehen, das das Frame selbst ist.

Hier sehen wir seine ersten 6 Byte-Werte: 01100101 10001000 10000100 00000000 00100001 11111111. Da bekannt ist, dass das erste Byte den NAL-Typ angibt, handelt es sich in diesem Fall um einen IDR-Segment (5), und dann kann es weiter untersucht werden:00101)

Mit den Informationen aus der Spezifikation kann der Fragmenttyp dekodiert werden (slice_type) und die Bildnummer (frame_num) unter anderen wichtigen Feldern.

Um die Werte einiger Felder (ue(v), me(v), se(v) oder tum(v), müssen wir das Fragment dekodieren, indem wir einen speziellen Dekoder verwenden, der auf dem exponentiellen Golomb-Codebasiert. Diese Methode ist sehr effektiv zum Codieren von Variablenwerten, insbesondere wenn viele Standardwerte vorhanden sind.

Werte slice_type und frame_num Die Werte für dieses Video betragen 7 (I-Fragment) und 0 (erstes Bild).

Der Bitstrom kann als Protokoll betrachtet werden. Wenn Sie mehr über den Bitstrom erfahren möchten, lohnt sich ein Blick in die Spezifikation ITU H.264. Hier ist ein Diagramm, das zeigt, wo sich die Bilddaten (YUV in komprimierter Form) befinden.

Es können auch andere Bitströme untersucht werden, wie VP9, H.265 (HEVC) oder sogar unser neuer bester Bitstrom AV1. Sind sie alle ähnlich? Nein, aber wenn Sie sich mit einem vertraut gemacht haben, werden die anderen viel einfacher zu verstehen sein.

Möchten Sie üben? Erkunden Sie den H.264-Bitstrom.

Es ist möglich, ein Einzelbildvideo zu generieren und MediaInfo zu verwenden, um den Bitstream zu analysieren. H.264. Tatsächlich steht es Ihnen sogar frei, den Quellcode einzusehen, der den Bitstream analysiert. H.264 (AVC).

Zur Übung kann der Intel Video Pro Analyzer verwendet werden (ich habe bereits erwähnt, dass das Programm kostenpflichtig ist, aber es gibt eine kostenlose Testversion mit einer Begrenzung auf 10 Frames?).

Übersicht

Es ist bemerkenswert, dass viele moderne Codecs dasselbe Modell verwenden, das wir gerade studiert haben. Hier betrachten wir das Flussdiagramm eines Video-Codecs. Thor. Es enthält alle Schritte, die wir durchlaufen haben. Der Sinn dieser Notiz ist es, dass Sie zumindest ein besseres Verständnis für die Innovationen und Dokumentationen in diesem Bereich entwickeln.

Früher haben wir berechnet, dass 139 GB Speicherplatz benötigt werden, um eine einstündige Videodatei in 720p-Qualität bei 30 fps zu speichern. Wenn wir die in diesem Artikel behandelten Methoden (interframe und intraframe Vorhersagen, Transformation, Quantisierung, Entropiekodierung usw.) verwenden, können wir (basierend darauf, dass wir 0,031 Bit pro Pixel verbrauchen) eine Videoqualität erreichen, die durchaus akzeptabel ist und nur 367,82 MB statt 139 GB Speicher benötigt.

Wie erreicht H.265 eine bessere Kompression als H.264?

Jetzt, da wir mehr darüber wissen, wie Codecs funktionieren, ist es einfacher zu verstehen, wie neue Codecs höhere Auflösungen mit weniger Bits bieten können.

Wenn man vergleicht AVC und HEVC, sollte man nicht vergessen, dass es fast immer eine Wahl zwischen einer höheren CPU-Belastung und dem Grad der Kompression ist.

HEVC hat mehr Abschnitts- (und Unterabschnitts-) Optionen als AVC, mehr Richtungen der internen Vorhersage, verbessertes Entropie-Codieren und vieles mehr. All diese Verbesserungen haben H.265 fähig gemacht, 50% mehr zu komprimieren als H.264.

Erster Teil: Grundlagen der Arbeit mit Video und Bildern

Quelle: habr.com