Der erste Teil:
Was? Ein Videocodec ist eine Software/Hardware, die digitale Videos komprimiert und/oder dekomprimiert.
Wofür? Trotz gewisser Einschränkungen sowohl hinsichtlich der Bandbreite als auch
und in Bezug auf den Datenspeicherplatz verlangt der Markt zunehmend hochwertigere Videos. Erinnern Sie sich, wie wir im letzten Beitrag das erforderliche Minimum für 30 Bilder pro Sekunde, 24 Bit pro Pixel und eine Auflösung von 480 x 240 berechnet haben? Ohne Komprimierung empfingen wir 82,944 Mbit/s. Komprimierung ist derzeit die einzige Möglichkeit, HD/FullHD/4K generell auf Fernsehbildschirme und das Internet zu übertragen. Wie wird dies erreicht? Schauen wir uns nun kurz die wichtigsten Methoden an.
Die Übersetzung wurde mit Unterstützung von EDISON Software erstellt.Wir sind verlobt , und auch .
Codec vs. Container
Ein häufiger Fehler, den Neulinge machen, ist die Verwechslung von digitalem Video-Codec und digitalem Video-Container. Ein Container ist ein bestimmtes Format. Ein Wrapper, der Video- (und möglicherweise Audio-)Metadaten enthält. Das komprimierte Video kann als Container-Nutzlast betrachtet werden.
Normalerweise gibt die Erweiterung einer Videodatei den Typ des Containers an. Beispielsweise ist die Datei video.mp4 wahrscheinlich ein Container MPEG-4 Part 14, und am wahrscheinlichsten ist eine Datei mit dem Namen video.mkv . Um ganz sicher zu sein, können Sie den Codec und das Containerformat verwenden oder .
Ein wenig Geschichte
Bevor wir dazu kommen Wie?, tauchen wir ein wenig in die Geschichte ein, um einige ältere Codecs etwas besser zu verstehen.
Video-Codec H.261 erschien 1990 (technisch gesehen 1988) und wurde für den Betrieb mit einer Datenübertragungsrate von 64 Kbit/s entwickelt. Es wurden bereits Ideen wie Farbunterabtastung, Makroblöcke usw. verwendet. Der Video-Codec-Standard wurde 1995 veröffentlicht H.263, die sich bis 2001 entwickelte.
Die erste Version wurde 2003 fertiggestellt H.264 / AVC. Im selben Jahr veröffentlichte TrueMotion seinen kostenlosen verlustbehafteten Videocodec namens VP3. Google kaufte das Unternehmen im Jahr 2008 und veröffentlichte VP8 das selbe Jahr. Im Dezember 2012 veröffentlichte Google VP9, und es wird in etwa dreiviertel des Browsermarktes (einschließlich mobiler Geräte) unterstützt.
AV1 ist ein neuer kostenloser und Open-Source-Videocodec, der von entwickelt wurde Allianz für offene Medien (AO-Medien), zu dem die bekanntesten Unternehmen gehören, wie zum Beispiel: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel und Cisco. Die erste Version des Codecs, 0.1.0, wurde am 7. April 2016 veröffentlicht.
Geburt von AV1
Anfang 2015 arbeitete Google daran VP10Xiph (im Besitz von Mozilla) arbeitete daran Daala, und Cisco hat einen eigenen kostenlosen Video-Codec namens „ Thor.
Dann MPEG-LA erste angekündigte jährliche Grenzwerte für HEVC (H.265) und eine achtmal höhere Gebühr als für H.8, aber schon bald änderten sie die Regeln erneut:
keine jährliche Begrenzung,
Inhaltsgebühr (0,5 % des Umsatzes) und
Die Einheitsgebühr ist etwa zehnmal höher als bei H.10.
Allianz für offene Medien wurde von Unternehmen aus verschiedenen Bereichen erstellt: Gerätehersteller (Intel, AMD, ARM, Nvidia, Cisco), Inhaltsanbieter (Google, Netflix, Amazon), Browser-Ersteller (Google, Mozilla) und andere.
Die Unternehmen hatten ein gemeinsames Ziel – einen lizenzfreien Video-Codec. Dann erscheint AV1 mit einer viel einfacheren Patentlizenz. Timothy B. Terryberry hielt eine beeindruckende Präsentation, die zum Ursprung des aktuellen AV1-Konzepts und seines Lizenzmodells wurde.
Sie werden überrascht sein, dass Sie den AV1-Codec über einen Browser analysieren können (Interessierte können hier klicken).).
Universeller Codec
Schauen wir uns die Hauptmechanismen an, die dem universellen Videocodec zugrunde liegen. Die meisten dieser Konzepte sind nützlich und werden in modernen Codecs verwendet, z VP9, AV1 и HEVC. Ich warne Sie, dass viele der erklärten Dinge vereinfacht werden. Manchmal werden Beispiele aus der Praxis (wie bei H.264) verwendet, um die Technologie zu demonstrieren.
1. Schritt – Bild aufteilen
Der erste Schritt besteht darin, den Rahmen in mehrere Abschnitte, Unterabschnitte und darüber hinaus zu unterteilen.
Wofür? Es gibt viele Gründe. Wenn wir ein Bild teilen, können wir den Bewegungsvektor genauer vorhersagen, indem wir kleine Abschnitte für kleine bewegliche Teile verwenden. Bei einem statischen Hintergrund können Sie sich hingegen auf größere Abschnitte beschränken.
Codecs organisieren diese Abschnitte normalerweise in Abschnitte (oder Blöcke), Makroblöcke (oder Codierungsbaumblöcke) und mehrere Unterabschnitte. Die maximale Größe dieser Partitionen variiert, HEVC legt sie auf 64x64 fest, während AVC 16x16 verwendet, und Unterpartitionen können auf bis zu 4x4 Größen aufgeteilt werden.
Erinnern Sie sich an die Rahmentypen aus dem letzten Artikel?! Dasselbe kann auf Blöcke angewendet werden, sodass wir ein I-Fragment, einen B-Block, einen P-Makroblock usw. haben können.
Wer üben möchte, kann sich ansehen, wie das Bild in Abschnitte und Unterabschnitte unterteilt wird. Dazu können Sie das bereits im vorherigen Artikel erwähnte verwenden. (die kostenpflichtige, aber mit einer kostenlosen Testversion, die auf die ersten 10 Frames beschränkt ist). Hier analysierte Abschnitte VP9:
2. Schritt – Prognose
Sobald wir Abschnitte haben, können wir für sie astrologische Vorhersagen erstellen. Für INTER-Prognosen übertragen werden müssen Bewegungsvektoren und der Rest und wird für die INTRA-Prognose übertragen Prognoserichtung und der Rest.
3. Schritt – Transformation
Sobald wir einen Restblock haben (vorhergesagter Abschnitt → realer Abschnitt), ist es möglich, ihn so umzuwandeln, dass wir wissen, welche Pixel verworfen werden können, während die Gesamtqualität erhalten bleibt. Es gibt einige Transformationen, die das genaue Verhalten liefern.
Obwohl es andere Methoden gibt, schauen wir uns diese genauer an. Diskrete Kosinustransformation (DCT - von diskrete Kosinustransformation). Hauptfunktionen von DCT:
- Konvertiert Pixelblöcke in gleich große Blöcke mit Frequenzkoeffizienten.
- Konzentriert die Leistung, um räumliche Redundanz zu beseitigen.
- Bietet Reversibilität.
2. Februar 2017 Sintra R.J. (Cintra, RJ) und Bayer F.M. (Bayer FM) hat einen Artikel über eine DCT-ähnliche Transformation zur Bildkomprimierung veröffentlicht, die nur 14 Additionen erfordert.
Machen Sie sich keine Sorgen, wenn Sie die Vorteile der einzelnen Punkte nicht verstehen. Lassen Sie uns nun konkrete Beispiele verwenden, um ihren wahren Wert zu erkennen.
Nehmen wir diesen 8x8-Pixelblock:
Dieser Block wird in das folgende 8 x 8 Pixel große Bild gerendert:
Wenden Sie DCT auf diesen Pixelblock an und erhalten Sie einen 8x8-Koeffizientenblock:
Und wenn wir diesen Koeffizientenblock rendern, erhalten wir das folgende Bild:
Wie Sie sehen, sieht es nicht wie das Originalbild aus. Sie können sehen, dass sich der erste Koeffizient stark von allen anderen unterscheidet. Dieser erste Koeffizient wird als DC-Koeffizient bezeichnet und repräsentiert alle Samples im Eingabearray, so etwas wie einen Durchschnitt.
Dieser Koeffizientenblock hat eine interessante Eigenschaft: Er trennt hochfrequente Komponenten von niederfrequenten.
In einem Bild ist die meiste Leistung auf niedrigere Frequenzen konzentriert. Wenn Sie also das Bild in seine Frequenzkomponenten umwandeln und die höheren Frequenzkoeffizienten verwerfen, können Sie die zur Beschreibung des Bildes erforderliche Datenmenge reduzieren, ohne zu große Einbußen bei der Bildqualität hinnehmen zu müssen.
Die Frequenz gibt an, wie schnell sich das Signal ändert.
Versuchen wir, die im Testfall gewonnenen Erkenntnisse anzuwenden, indem wir das Originalbild mithilfe von DCT in seine Frequenz (Koeffizientenblock) umwandeln und dann einen Teil der unwichtigsten Koeffizienten verwerfen.
Zuerst konvertieren wir es in den Frequenzbereich.
Als nächstes verwerfen wir einen Teil (67 %) der Koeffizienten, hauptsächlich den unteren rechten Teil.
Abschließend rekonstruieren wir das Bild aus diesem verworfenen Koeffizientenblock (denken Sie daran, dass er invertierbar sein muss) und vergleichen es mit dem Original.
Wir sehen, dass es dem Originalbild ähnelt, aber es gibt viele Unterschiede zum Original. Wir haben 67,1875 % weggeworfen und immer noch etwas erhalten, das dem Original ähnelt. Es wäre möglich, die Koeffizienten bewusster zu verwerfen, um ein Bild von noch besserer Qualität zu erhalten, aber das ist ein nächstes Thema.
Jeder Koeffizient wird unter Verwendung aller Pixel generiert
Wichtig: Jeder Koeffizient wird nicht direkt einem Pixel zugeordnet, sondern ist eine gewichtete Summe aller Pixel. Diese erstaunliche Grafik zeigt, wie der erste und der zweite Koeffizient mithilfe von Gewichtungen berechnet werden, die für jeden Index einzigartig sind.
Sie können auch versuchen, die DCT zu visualisieren, indem Sie sich eine einfache darauf basierende Bildformation ansehen. Hier ist zum Beispiel das Symbol A, das mit jedem Koeffizientengewicht generiert wird:
4. Schritt – Quantisierung
Nachdem wir im vorherigen Schritt einige Koeffizienten verworfen haben, führen wir im letzten Schritt (Transformation) eine spezielle Form der Quantisierung durch. In diesem Stadium ist es akzeptabel, dass Informationen verloren gehen. Oder einfacher gesagt: Wir quantisieren die Koeffizienten, um eine Komprimierung zu erreichen.
Wie kann man einen Koeffizientenblock quantisieren? Eine der einfachsten Methoden ist die gleichmäßige Quantisierung, bei der wir einen Block nehmen, ihn durch einen Wert (durch 10) dividieren und das Ergebnis runden.
Können wir diesen Koeffizientenblock umkehren? Ja, das können wir, indem wir mit demselben Wert multiplizieren, durch den wir dividiert haben.
Dieser Ansatz ist nicht der beste, da er die Bedeutung jedes einzelnen Koeffizienten nicht berücksichtigt. Anstelle eines einzelnen Werts könnte man eine Matrix von Quantisierern verwenden, und diese Matrix könnte die DCT-Eigenschaft ausnutzen, indem sie den Großteil des unteren rechten Teils und die Minderheit des oberen linken Teils quantisiert.
Schritt 5 – Entropiekodierung
Nachdem wir die Daten (Bildblöcke, Fragmente, Frames) quantisiert haben, können wir sie immer noch verlustfrei komprimieren. Es gibt viele algorithmische Möglichkeiten, Daten zu komprimieren. Wir werfen einen kurzen Blick auf einige davon. Für ein tieferes Verständnis können Sie das Buch „Komprimierung verstehen: Datenkomprimierung für moderne Entwickler“ lesen („").
Videokodierung mit VLC
Nehmen wir an, wir haben einen Strom von Charakteren: a, e, r и t. Die Wahrscheinlichkeit (im Bereich von 0 bis 1), wie oft jedes Zeichen in einem Stream vorkommt, wird in dieser Tabelle dargestellt.
| a | e | r | t | |
|---|---|---|---|---|
| Wahrscheinlichkeit | 0,3 | 0,3 | 0,2 | 0,2 |
Wir können den wahrscheinlichsten eindeutige Binärcodes (vorzugsweise kleine) und den weniger wahrscheinlichen größere Codes zuordnen.
| a | e | r | t | |
|---|---|---|---|---|
| Wahrscheinlichkeit | 0,3 | 0,3 | 0,2 | 0,2 |
| Binärcode | 0 | 10 | 110 | 1110 |
Wir komprimieren den Stream und gehen davon aus, dass wir am Ende 8 Bit für jedes Zeichen ausgeben. Ohne Komprimierung wären 24 Bit pro Zeichen erforderlich. Wenn Sie jedes Zeichen durch seinen Code ersetzen, erhalten Sie Einsparungen!
Der erste Schritt besteht darin, das Zeichen zu kodieren e, was gleich 10 ist, und das zweite Zeichen ist a, das hinzugefügt wird (nicht auf mathematische Weise): [10][0] und schließlich das dritte Zeichen t, was unseren endgültigen komprimierten Bitstrom gleich [10][0][1110] oder macht 1001110, das nur 7 Bit benötigt (3,4-mal weniger Platz als das Original).
Bitte beachten Sie, dass jeder Code ein eindeutiger Code mit einem Präfix sein muss. wird Ihnen helfen, diese Nummern zu finden. Obwohl diese Methode nicht ohne Mängel ist, gibt es Videocodecs, die diese algorithmische Methode zur Komprimierung immer noch anbieten.
Sowohl der Encoder als auch der Decoder müssen Zugriff auf eine Symboltabelle mit ihren Binärcodes haben. Daher ist es auch notwendig, eine Tabelle als Eingabe zu senden.
Arithmetische Codierung
Nehmen wir an, wir haben einen Strom von Charakteren: a, e, r, s и t, und ihre Wahrscheinlichkeit ist in dieser Tabelle dargestellt.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Wahrscheinlichkeit | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Mithilfe dieser Tabelle erstellen wir Bereiche mit allen möglichen Zeichen, sortiert nach der größten Zahl.
Lassen Sie uns nun einen Stream aus drei Zeichen codieren: essen.
Wählen Sie zunächst das erste Zeichen aus e, der im Teilbereich von 0,3 bis 0,6 liegt (ohne). Wir nehmen diesen Teilbereich und teilen ihn erneut in den gleichen Proportionen wie zuvor, jedoch für diesen neuen Bereich.
Fahren wir mit der Codierung unseres Streams fort essen. Nehmen Sie nun den zweiten Charakter a, der im neuen Unterbereich von 0,3 bis 0,39 liegt, und nehmen Sie dann unser letztes Zeichen t Wenn wir den gleichen Vorgang noch einmal wiederholen, erhalten wir den endgültigen Teilbereich von 0,354 bis 0,372.
Wir müssen lediglich eine Zahl im letzten Teilbereich von 0,354 bis 0,372 auswählen. Wählen wir 0,36 (Sie können aber auch jede andere Zahl in diesem Teilbereich wählen). Nur mit dieser Nummer können wir unseren ursprünglichen Stream wiederherstellen. Es ist, als würden wir eine Linie innerhalb der Bereiche ziehen, um unseren Stream zu kodieren.
Der umgekehrte Vorgang (d. h. Dekodierung) ist genauso einfach: Mit unserer Zahl 0,36 und unserem Anfangsbereich können wir den gleichen Prozess ausführen. Aber jetzt identifizieren wir anhand dieser Nummer den Stream, der mit dieser Nummer codiert ist.
Beim ersten Bereich bemerken wir, dass unsere Nummer dem Slice entspricht, daher ist dies unser erstes Zeichen. Jetzt teilen wir diesen Teilbereich erneut auf, indem wir dem gleichen Vorgang wie zuvor folgen. Hier sieht man, dass 0,36 dem Symbol entspricht a, und nachdem wir den Vorgang wiederholt hatten, kamen wir beim letzten Zeichen an t (bildet unseren ursprünglich codierten Stream essen).
Sowohl der Encoder als auch der Decoder müssen über eine Tabelle mit Symbolwahrscheinlichkeiten verfügen, daher ist es notwendig, diese auch in den Eingabedaten zu senden.
Ziemlich elegant, nicht wahr? Wer auch immer diese Lösung gefunden hat, war verdammt schlau. Einige Video-Codecs nutzen diese Technik (oder bieten sie zumindest als Option an).
Die Idee besteht darin, einen quantisierten Bitstrom verlustfrei zu komprimieren. Sicherlich fehlen in diesem Artikel jede Menge Details, Gründe, Kompromisse usw. Aber wenn Sie Entwickler sind, sollten Sie mehr wissen. Neue Codecs versuchen, unterschiedliche Entropiekodierungsalgorithmen zu verwenden, wie z JAHRE.
Schritt 6 – Bitstream-Format
Nach all dem bleibt nur noch das Entpacken der komprimierten Frames im Rahmen der durchgeführten Schritte. Der Decoder muss explizit über die vom Encoder getroffenen Entscheidungen informiert werden. Dem Decoder müssen alle notwendigen Informationen zur Verfügung gestellt werden: Bittiefe, Farbraum, Auflösung, Vorhersageinformationen (Bewegungsvektoren, gerichtete INTER-Vorhersage), Profil, Pegel, Bildrate, Bildtyp, Bildnummer und vieles mehr.
Wir werfen einen kurzen Blick auf den Bitstream H.264. Unser erster Schritt besteht darin, einen minimalen H.264-Bitstream zu erstellen (FFmpeg fügt standardmäßig alle Kodierungsoptionen hinzu, wie z SEI NAL — Was es ist, erfahren wir etwas weiter unten). Wir können dies mit unserem eigenen Repository und FFmpeg tun.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Dieser Befehl generiert einen Rohbitstrom H.264 mit einem Bild, 64×64 Auflösung, mit Farbraum YUV420. In diesem Fall wird das folgende Bild als Rahmen verwendet.
H.264-Bitstream
Standard AVC (H.264) bestimmt, dass Informationen in Makroframes (im Netzwerksinn) gesendet werden, genannt NAL (Dies ist eine Netzwerkabstraktionsebene). Das Hauptziel von NAL ist die Bereitstellung einer „webfreundlichen“ Videopräsentation. Dieser Standard sollte auf Fernsehgeräten (Stream-basiert) und im Internet (Paket-basiert) funktionieren.
Es gibt einen Synchronisationsmarker, um die Grenzen von NAL-Elementen zu definieren. Jedes Synchronisierungstoken enthält einen 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-Bitstream identifizieren wir mindestens drei NAL-Muster am Anfang der Datei.
Wie bereits erwähnt, muss der Decoder nicht nur die Bilddaten kennen, sondern auch die Details des Videos, des Bildes, der Farben, der verwendeten Parameter und vieles mehr. Das erste Byte jeder NAL definiert ihre Kategorie und ihren Typ.
| NAL-Typ-ID | Beschreibung |
|---|---|
| 0 | еизвестный тип |
| 1 | Kodiertes Bildfragment ohne IDR |
| 2 | Abschnitt mit codierten Slice-Daten A |
| 3 | Abschnitt mit codierten Slice-Daten B |
| 4 | Abschnitt mit codierten Slice-Daten C |
| 5 | Kodiertes IDR-Fragment eines IDR-Bildes |
| 6 | Weitere Informationen zur SEI-Erweiterung |
| 7 | SPS-Sequenzparametersatz |
| 8 | Satz von PPS-Bildparametern |
| 9 | Zugriffstrennzeichen |
| 10 | Ende der Sequenz |
| 11 | Ende des Threads |
| ... | ... |
Typischerweise ist die erste NAL eines Bitstroms SPS. Dieser NAL-Typ ist für die Information über allgemeine Codierungsvariablen wie Profil, Ebene, Auflösung usw. verantwortlich.
Wenn wir die erste Synchronisierungsmarkierung überspringen, können wir das erste Byte dekodieren, um herauszufinden, welcher NAL-Typ zuerst ist.
Das erste Byte nach dem Synchronisierungstoken ist beispielsweise 01100111, wobei das erste Bit (0) ist im Feld forbidden_zero_bit. Die nächsten 2 Bits (11) verrät uns das Feld nal_ref_idc, Dies gibt an, ob es sich bei dieser NAL um ein Referenzfeld handelt oder nicht. Und die restlichen 5 Bits (00111) verrät uns das Feld nal_unit_type, in diesem Fall ist es der SPS-Block (7) NAL.
Zweites Byte (binär=01100100, hex=0x64, Dez=100) in SPS ist NAL das Feld Profil_IDC, Hier wird das Profil angezeigt, das der Encoder verwendet hat. In diesem Fall wurde ein begrenztes Hochprofil verwendet (dh ein Hochprofil ohne bidirektionale B-Segment-Unterstützung).
Wenn Sie sich die Bitstream-Spezifikation ansehen H.264 Für SPS NAL finden wir viele Werte für Parameternamen, Kategorie und Beschreibung. Schauen wir uns zum Beispiel die Felder an pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Parametername | Kategorie | Beschreibung |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Wenn wir einige mathematische Operationen mit den Werten dieser Felder durchführen, erhalten wir eine Auflösung. Man kann mit 1920 x 1080 darstellen pic_width_in_mbs_minus_1 mit einem Wert von 119 ((119 + 1) * Macroblock_size = 120 * 16 = 1920). Auch hier haben wir, um Platz zu sparen, statt 1920 mit 119 kodiert.
Wenn wir unser erstelltes Video weiterhin in binärer Form überprüfen (zum Beispiel: xxd -b -c 11 v/minimal_yuv420.h264), dann können Sie zum letzten NAL gehen, das den Frame selbst darstellt.
Hier sehen wir die ersten 6 Byte-Werte: 01100101 10001000 10000100 00000000 00100001 11111111. Da bekannt ist, dass das erste Byte den NAL-Typ angibt, in diesem Fall (00101) ist ein IDR-Fragment (5), und dann können Sie es weiter untersuchen:
Anhand der Spezifikationsinformationen ist es möglich, den Fragmenttyp zu dekodieren (Slice_Type) und Rahmennummer (Frame_num) neben anderen wichtigen Bereichen.
Um die Werte einiger Felder zu erhalten (ue(v), me(v), se(v) Oder te(v)), müssen wir das Fragment mit einem speziellen Decoder dekodieren, der auf basiert . Diese Methode ist sehr effizient zum Kodieren von Variablenwerten, insbesondere wenn viele Standardwerte vorhanden sind.
Die Werte Slice_Type и Frame_num dieses Videos sind 7 (I-Fragment) und 0 (erstes Bild).
Ein Bitstrom kann als Protokoll betrachtet werden. Wenn Sie mehr über den Bitstream erfahren möchten, sollten Sie sich die Spezifikation ansehen ITU H.264. Hier ist ein Makrodiagramm, das zeigt, wo sich die Bilddaten befinden (YUV in komprimierter Form).
Andere Bitströme können untersucht werden, wie z VP9, H.265 (HEVC) oder sogar unser neuer bester Bitstream AV1. Sind sie alle ähnlich? Nein, aber wenn Sie mindestens einen verstanden haben, ist es viel einfacher, den Rest zu verstehen.
Willst du üben? Entdecken Sie den H.264-Bitstream
Sie können ein Einzelbildvideo generieren und MediaInfo verwenden, um den Bitstream zu untersuchen H.264. Tatsächlich hindert Sie nichts daran, sich den Quellcode anzusehen, der den Bitstrom analysiert H.264 (AVC).
Zum Üben können Sie Intel Video Pro Analyzer verwenden (habe ich schon gesagt, dass das Programm kostenpflichtig ist, es aber eine kostenlose Testversion mit einem Limit von 10 Bildern gibt?).
Beschreibung
Beachten Sie, dass viele moderne Codecs dasselbe Modell verwenden, das wir gerade untersucht haben. Schauen wir uns hier das Blockdiagramm des Videocodecs an Thor. Es enthält alle Schritte, die wir durchlaufen haben. Der Sinn dieses Beitrags besteht darin, Ihnen zumindest ein besseres Verständnis der Neuerungen und Dokumentationen in diesem Bereich zu vermitteln.
Zuvor wurde berechnet, dass 139 GB Speicherplatz erforderlich wären, um eine einstündige Videodatei in 720p-Qualität und 30 fps zu speichern. Wenn Sie die in diesem Artikel besprochenen Methoden verwenden (Interframe- und interne Vorhersagen, Transformation, Quantisierung, Entropiecodierung usw.), können Sie (basierend auf der Tatsache, dass wir 0,031 Bits pro Pixel ausgeben) ein Video von ganzer Länge erzielen zufriedenstellende Qualität, belegt nur 367,82 MB, nicht 139 GB Speicher.
Wie erreicht H.265 ein besseres Komprimierungsverhältnis als H.264?
Da wir nun mehr über die Funktionsweise von Codecs wissen, ist es einfacher zu verstehen, wie neuere Codecs höhere Auflösungen mit weniger Bits liefern können.
Wenn wir vergleichen AVC и HEVCEs sei daran erinnert, dass dies fast immer eine Wahl zwischen höherer CPU-Auslastung und höherem Komprimierungsverhältnis ist.
HEVC verfügt über mehr Abschnitts- (und Unterabschnitts-)Optionen als AVC, mehr interne Vorhersagerichtungen, verbesserte Entropiekodierung und mehr. Alle diese Verbesserungen wurden vorgenommen H.265 in der Lage, 50 % mehr zu komprimieren als H.264.
Der erste Teil:
Source: habr.com