Erster Teil:
Was? Ein Video-Codec ist ein Teil der Software-/Hardware, der digitales Video komprimiert und/oder dekomprimiert.
Wofür? Trotz bestimmter Einschränkungen sowohl hinsichtlich der Bandbreite als auch des Speicherplatzes fordert der Markt immer hochwertigeres Video. Erinnern Sie sich, wie wir im letzten Beitrag den erforderlichen Minimum für 30 Bilder pro Sekunde, 24 Bit pro Pixel bei einer Auflösung von 480×240 berechnet haben? Wir erhielten 82,944 Mbit/s ohne Kompression. Kompression ist derzeit der einzige Weg, HD/FullHD/4K auf Fernsehern und im Internet zu übertragen. Wie wird dies erreicht? Lassen Sie uns nun die grundlegenden Methoden kurz betrachten.
Übersetzung wurde mit Unterstützung von EDISON Software erstellt.
Die Übersetzung wurde mit Unterstützung von EDISON Software erstellt.Wir beschäftigen uns mit , sowie .
Codec vs Container
Ein häufiger Fehler von Anfängern ist es, den Codec für digitales Video mit dem Container für digitales Video zu verwechseln. Ein Container ist ein gewisses Format – eine Art Wrapper, der Metadaten des Videos (und möglicherweise auch Audio) enthält. Komprimiertes Video kann als Nutzlast des Containers betrachtet werden.
In der Regel gibt die Dateierweiterung des Videofiles Aufschluss über dessen Container-Art. Beispielsweise ist die Datei video.mp4 höchstwahrscheinlich ein Container für MPEG-4 Part 14, während die Datei mit dem Namen video.mkv wahrscheinlich eine ist. Um ganz sicher über den Codec und das Format des Containers zu sein, können Sie oder .
Ein wenig Geschichte
Bevor wir zu Wie?, kommen, lassen Sie uns kurz in die Geschichte eintauchen, um einige ältere Codecs besser zu verstehen.
Video-Codec H.261 wurde 1990 (technisch gesehen 1988) eingeführt und wurde für eine Datenrate von 64 Kbit/s entwickelt. Es wurden bereits Ideen wie Farbunterabtastung, Makroblöcke usw. verwendet. 1995 wurde der Standard für den Video-Codec H.263, der bis 2001 weiterentwickelt wurde, veröffentlicht.
Im Jahr 2003 wurde die erste Version von H.264/AVCabgeschlossen. Im gleichen Jahr veröffentlichte das Unternehmen „TrueMotion“ seinen kostenlosen Video-Codec, der verlustbehaftet komprimiertes Video namens VP3. 2008 kaufte Google dieses Unternehmen und veröffentlichte VP8 im gleichen Jahr. Im Dezember 2012 brachte Google VP9, der auf etwa ¾ des Browser-Marktes (einschließlich mobiler Geräte) unterstützt wird.
AV1 — das ist ein neuer kostenloser Open-Source-Videocodec, entwickelt von Allianz für offene Medien (AOMedia), zu dessen Mitgliedern einige der bekanntesten Unternehmen gehören, wie: 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.
Die Geburt von AV1
Anfang 2015 arbeitete Google an VP10, während Xiph (das zu Mozilla gehört) an Daala, und Cisco einen kostenlosen Videocodec namens Thor.
Dann MPEG LA kündigte zunächst jährliche Obergrenzen für HEVC (H.265) und Gebühren an, die achtmal höher waren als für H.264, aber bald änderten sie die Regeln erneut:
ohne jährliche Obergrenze,
eine Gebühr für Inhalte (0,5% des Umsatzes) und
eine Gebühr pro Produkteinheit, die etwa zehnmal höher ist als für H.264.
Die Allianz für offene Medien wurde von Unternehmen aus verschiedenen Bereichen gegründet: Hersteller von Hardware (Intel, AMD, ARM, Nvidia, Cisco), Inhaltsanbieter (Google, Netflix, Amazon), Browserentwickler (Google, Mozilla) und anderen.
Die Unternehmen hatten ein gemeinsames Ziel – einen Videocodec ohne Lizenzgebühren. Dann tauchte AV1 mit einem viel einfacheren Patentlizenzmodell auf. Timothy B. Terriberry hielt eine beeindruckende Präsentation, die die Grundlage für das aktuelle Konzept von AV1 und sein Lizenzmodell wurde.
Sie werden überrascht sein, dass man den AV1-Codec über den Browser analysieren kann (Interessierte können die Adresse besuchen).
Universeller Codec
Lassen Sie uns die grundlegenden Mechanismen untersuchen, die dem universellen Videocodec zugrunde liegen. Die meisten dieser Konzepte sind nützlich und werden in modernen Codecs verwendet, wie VP9, AV1 und HEVC. Ich warne davor, dass viele der erklärten Dinge vereinfacht werden. Manchmal werden echte Beispiele (wie im Fall von H.264) verwendet, um Technologien zu demonstrieren.
Erster Schritt – Bildaufteilung
Der erste Schritt besteht darin, das Bild in mehrere Abschnitte, Unterabschnitte und so weiter zu unterteilen.
Warum? Es gibt viele Gründe. Wenn man das Bild aufteilt, kann man den Bewegungsvektor genauer vorhersagen, indem man kleine Abschnitte für kleine bewegte Teile verwendet. Während man bei einem statischen Hintergrund auch mit größeren Abschnitten auskommen kann.
In der Regel organisieren Codecs diese Abschnitte in Sektionen (oder Fragmente), Makroblöcke (oder Codierungsbaumblöcke) und eine Vielzahl von Unterabschnitten. Die maximale Größe dieser Abschnitte variiert; HEVC legt 64×64 fest, während AVC 16×16 verwendet, und Unterabschnitte können auf 4×4 reduziert werden.
Erinnern Sie sich an die verschiedenen Arten von Frames aus dem vorherigen Artikel?! Das lässt sich auch auf Blöcke anwenden, sodass wir I-Fragment, B-Block, P-Makroblock usw. haben können.
Für diejenigen, die üben möchten – schauen Sie sich an, wie das Bild in Abschnitte und Unterabschnitte zerlegt wird. Dazu kann das bereits im vorherigen Artikel erwähnte Tool verwendet werden. (das kostenpflichtig ist, aber eine kostenlose Testversion mit einer Begrenzung auf die ersten 10 Frames hat). Hier wurden die Abschnitte analysiert. VP9:
2. Schritt – Prognose
Sobald wir Abschnitte haben, können wir astrologische Prognosen darüber erstellen. Für INTER-Prognose müssen die Bewegungsvektoren und der Rest übergeben werden, während für INTRA-Prognose die Richtung der Prognose und der Rest übergeben werden müssen.
3. Schritt – Transformation
Nachdem wir den Restblock (vorhergesagter Abschnitt → tatsächlicher Abschnitt) erhalten haben, kann er so transformiert werden, dass wir wissen, welche Pixel verworfen werden können, während die Gesamtqualität erhalten bleibt. Es gibt einige Transformationen, die ein genaues Verhalten ermöglichen.
Obwohl es auch andere Methoden gibt, betrachten wir genauer die diskrete Kosinustransformation (DCT – von diskrete Kosinustransformation). Die Hauptfunktionen der DCT:
- Transformiert Pixelblöcke in gleich große Blöcke von Frequenzkoeffizienten.
- Komprimiert die Leistung und hilft, räumliche Redundanz zu beseitigen.
- Stellt die Umkehrbarkeit sicher.
Am 2. Februar 2017 veröffentlichten Cintra R.J. und Bayer F.M. einen Artikel über eine DCT-ähnliche Transformation zur Bildkompression, die nur 14 Additionen erfordert.
Keine Sorge, wenn Sie die Vorteile jedes Punktes nicht verstanden haben. Wir werden jetzt an konkreten Beispielen die tatsächliche Wertigkeit sehen.
Nehmen wir einen solchen Pixelblock 8×8:
Dieser Block wird in folgendes Bild mit 8 auf 8 Pixeln gerendert:
Wenden wir die DCT auf diesen Pixelblock an und erhalten einen Koeffizientenblock der Größe 8×8:
Und wenn wir diesen Koeffizientenblock rendern, erhalten wir folgendes Bild:
Wie wir sehen, sieht dies nicht aus wie das ursprüngliche Bild. Man kann feststellen, dass der erste Koeffizient stark von allen anderen abweicht. Dieser erste Koeffizient ist als DC-Koeffizient bekannt und stellt alle Abtastungen im Eingabearray dar, ähnlich dem Mittelwert.
Dieser Block von Koeffizienten hat eine interessante Eigenschaft: Er trennt hochfrequente Komponenten von niederfrequenten.
Im Bild ist der Großteil der Leistung auf niedrigeren Frequenzen konzentriert, daher kann man, wenn man das Bild in seine Frequenzkomponenten umwandelt und höhere Frequenzkoeffizienten verwirft, die Datenmenge zur Beschreibung des Bildes reduzieren, ohne die Bildqualität zu stark zu opfern.
Die Frequenz bedeutet, wie schnell sich das Signal ändert.
Lass uns versuchen, das Wissen, das wir im Testbeispiel gewonnen haben, anzuwenden, indem wir das ursprüngliche Bild in seine Frequenz (Koeffizientenblock) umwandeln, indem wir die DCT verwenden, und dann einige der weniger wichtigen Koeffizienten verwerfen.
Zuerst wandeln wir es in den Frequenzbereich um.
Als Nächstes verwerfen wir einen Teil (67%) der Koeffizienten, hauptsächlich den unteren rechten Teil.
Schließlich stellen wir das Bild aus diesem verworfenen Koeffizientenblock wieder her (denken Sie daran, es muss umkehrbar sein) und vergleichen mit dem Original.
Wir sehen, dass es dem ursprünglichen Bild ähnelt, aber viele Unterschiede zum Original aufweist. Wir haben 67,1875% verworfen und trotzdem etwas erhalten, das dem Original ähnlich ist. Man hätte die Koeffizienten durchdachter verwerfen können, um eine noch bessere Bildqualität zu erzielen, aber das ist ein Thema für die nächste Sitzung.
Jeder Koeffizient wird unter Verwendung aller Pixel gebildet.
Wichtig: Jeder Koeffizient entspricht nicht direkt einem Pixel, sondern stellt eine gewichtete Summe aller Pixel dar. Diese erstaunliche Grafik zeigt, wie der erste und der zweite Koeffizient unter Verwendung von Gewichten, die für jeden Index einzigartig sind, berechnet werden.
Sie können auch versuchen, die DCT zu visualisieren, indem Sie sich die einfache Formung eines Bildes basierend darauf ansehen. Zum Beispiel hier ist das Zeichen A, das unter Verwendung jedes Gewichtes des Koeffizienten gebildet wird:
Schritt 4 – Quantisierung
Nachdem wir im vorherigen Schritt einige Koeffizienten verworfen haben, führen wir im letzten Schritt (Quantisierung) eine spezielle Form der Quantisierung durch. In diesem Schritt ist es zulässig, Informationen zu verlieren. Oder 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. Dabei nehmen wir den Block, teilen ihn durch einen Wert (durch 10) und runden, was wir erhalten haben.
Können wir diesen Block von Koeffizienten umkehren? Ja, das können wir, indem wir mit demselben Wert multiplizieren, durch den wir geteilt haben.
Dieser Ansatz ist nicht der beste, da er die Bedeutung jedes Koeffizienten nicht berücksichtigt. Stattdessen könnte eine Quantisierungs-Matrix verwendet werden, die die DCT-Eigenschaft nutzt und die meisten unteren rechten und einige oberen linken Werte quantisiert.
5. Schritt – Entropie-Codierung
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 uns kurz mit einigen davon vertraut machen; für ein tieferes Verständnis können Sie das Buch „Understanding Compression: Data Compression for Modern Developers“ lesen.»).
Video-Codierung mit VLC
Angenommen, wir haben einen Strom von Zeichen: a, e, r und t. Die Wahrscheinlichkeit (im Bereich von 0 bis 1), wie oft jedes Zeichen im Strom vorkommt, ist in dieser Tabelle dargestellt.
| a | e | r | t | |
|---|---|---|---|---|
| Wahrscheinlichkeit | 0,3 | 0,3 | 0,2 | 0,2 |
Wir können den am wahrscheinlichsten vorkommenden Zeichen einzigartige binäre Codes (vorzugsweise kurze) zuweisen und die unwahrscheinlicheren Zeichen mit größeren Codes.
| a | e | r | t | |
|---|---|---|---|---|
| Wahrscheinlichkeit | 0,3 | 0,3 | 0,2 | 0,2 |
| Binärcode | 0 | 10 | 110 | 1110 |
Wir komprimieren den Strom, wobei wir annehmen, dass wir am Ende 8 Bit pro Zeichen aufwenden. Ohne Kompression würden 24 Bit pro Zeichen benötigt. Wenn wir jedes Zeichen durch seinen Code ersetzen, ergibt sich eine Einsparung!
Der erste Schritt besteht darin, das Zeichen zu codieren e, das 10 entspricht, und das zweite Zeichen ist a, das (nicht mathematisch) hinzugefügt wird: [10] [0], und schließlich das dritte Zeichen t, was unseren finalen komprimierten Bitstrom zu [10] [0] [1110] macht oder 1001110, wofür insgesamt nur 7 Bit benötigt werden (3,4 Mal weniger Platz als im Original).
Bitte beachten Sie, dass jeder Code ein einzigartiger Präfix-Code sein muss. hilft, diese Zahlen zu finden. Obwohl diese Methode nicht fehlerfrei ist, gibt es Video-Codecs, die weiterhin dieses algorithmische Verfahren zur Kompression anbieten.
Sowohl der Encoder als auch der Decoder müssen Zugriff auf die Zeichentabelle mit ihren binären Codes haben. Daher muss auch die Tabelle mit den Eingangsdaten gesendet werden.
Arithmetische Kodierung
Angenommen, wir haben einen Strom von Zeichen: a, e, r, s und 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 |
Mit dieser Tabelle erstellen wir die Bereiche, die alle möglichen Symbole enthalten, sortiert nach der größten Häufigkeit.
Lassen Sie uns nun den Stream von drei Symbolen codieren: essen.
Zuerst wählen wir das erste Symbol e, das sich im Unterbereich von 0,3 bis 0,6 (exklusive) befindet. Wir nehmen diesen Unterbereich und teilen ihn erneut in denselben Proportionen wie zuvor auf, jedoch für diesen neuen Bereich.
Lassen Sie uns unseren Stream weiter codieren essen. Nun nehmen wir das zweite Symbol a, das sich im neuen Unterbereich von 0,3 bis 0,39 befindet, und dann nehmen wir unser letztes Symbol t und, indem wir denselben Prozess 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 wir können auch jede andere Zahl in diesem Unterbereich wählen). Nur mit dieser Zahl können wir unseren ursprünglichen Stream wiederherstellen. Es ist, als würden wir eine Linie innerhalb der Bereiche zeichnen, um unseren Stream zu codieren.
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 starten. Aber jetzt identifizieren wir, unter Verwendung dieser Zahl, den mit dieser Zahl codierten Stream.
Mit dem ersten Bereich stellen wir fest, dass unsere Zahl dem Schnitt entspricht, daher ist dies unser erstes Symbol. Nun teilen wir diesen Unterbereich erneut auf, indem wir denselben Prozess wie zuvor durchführen. Hier kann man sehen, dass 0,36 dem Symbol aentspricht, und nach der Wiederholung des Prozesses erreichen wir das letzte Symbol t (wir bilden unseren ursprünglichen codierten Stream essen).
Sowohl der Encoder als auch der Decoder müssen über die Wahrscheinlichkeitstabelle der Symbole verfügen, daher ist es notwendig, diese ebenfalls in den Eingangsdaten zu übermitteln.
Ziemlich elegant, nicht wahr? Jemand, der diese Lösung erfunden hat, war verdammt klug. Einige Video-Codecs verwenden diese Technik (oder bieten sie zumindest als Option an).
Die Idee besteht darin, den quantisierten Bitstream verlustfrei zu komprimieren. Sicherlich fehlen in diesem Artikel Tonnen von Details, Gründen, Kompromissen usw. Aber Sie, wenn Sie ein Entwickler sind, sollten mehr wissen. Neue Codecs versuchen verschiedene Algorithmen der Entropiekodierung zu verwenden, wie zum Beispiel ANS.
Schritt 6 — Bitstream-Format
Nachdem Sie all dies erledigt haben, bleibt nur noch, die komprimierten Frames im Kontext der durchgeführten Schritte zu entpacken. Es ist notwendig, den Decoder explizit über die Entscheidungen, die der Encoder getroffen hat, zu informieren. Dem Decoder müssen alle erforderlichen Informationen bereitgestellt werden: Farbtiefe, Farbraum, Auflösung, Vorhersageinformationen (Bewegungsvektoren, gerichtete INTER-Vorhersage), Profil, Ebene, Bildrate, Bildtyp, Bildnummer und vieles mehr.
Wir werden uns flüchtig mit dem Bitstream vertraut machen H.264. Unser erster Schritt ist die Erstellung eines minimalen H.264-Bitstreams (FFmpeg fügt standardmäßig alle Kodierungsparameter hinzu, wie zum Beispiel SEI NAL — werden wir weiter unten herausfinden, was das ist). Wir können dies 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 generiert einen unkomprimierten Bitstream H.264 mit einem Frame, einer Auflösung von 64×64, im Farbraum YUV420. Dabei wird folgendes Bild als Frame verwendet.
H.264-Bitstream
Standard AVC (H.264) legt fest, dass die Informationen in Makroblöcken (im Netzwerkverständnis) übertragen werden, die als NAL bezeichnet werden (das ist eine Abstraktionsstufe im Netzwerk). Das Hauptziel von NAL besteht darin, eine „netzfreundliche“ Darstellung von Videos bereitzustellen. Dieser Standard sollte auf Fernsehern (basierend auf Streams) und im Internet (basierend auf Paketen) funktionieren.
Es gibt einen Synchronisationsmarker zur Bestimmung der Grenzen von NAL-Elementen. Jeder Synchronisationsmarker enthält den Wert 0x00 0x00 0x01, außer dem allerersten, der gleich ist 0x00 0x00 0x00 0x01. Wenn wir einen hexdump für den generierten H.264-Bitstream ausführen, identifizieren wir mindestens drei NAL-Muster am Anfang der Datei.
Wie gesagt, muss der Decoder nicht nur die Bilddaten kennen, sondern auch die Details des Videos, des Frames, der Farben, der verwendeten Parameter und vieles mehr. Das erste Byte jedes NAL bestimmt seine Kategorie und seinen Typ.
| NAL Typ Identifier | Beschreibung |
|---|---|
| 0 | Unbekannter Typ |
| 1 | Codierter Bildausschnitt ohne IDR |
| 2 | Codierter Datenabschnitt des Slice A |
| 3 | Codierter Datenabschnitt des Slice B |
| 4 | Codierter Datenabschnitt des Slice C |
| 5 | Codierter IDR-Ausschnitt des IDR-Bildes |
| 6 | Zusätzliche Informationen zur SEI-Erweiterung |
| 7 | SPS-Sequenzparameter-Satz |
| 8 | PPS-Bildparameter-Satz |
| 9 | Zugriffsseparator |
| 10 | Ende der Sequenz |
| 11 | Ende des Streams |
| … | … |
Normalerweise ist das erste NAL des Bitstroms SPS. Dieser NAL-Typ informiert über allgemeine Kodierungsvariablen wie Profil, Stufe, Auflösung usw.
Wenn wir den ersten Synchronisationsmarker überspringen, können wir das erste Byte dekodieren, um herauszufinden, welcher NAL-Typ das erste ist.
Zum Beispiel beträgt das erste Byte nach dem Synchronisationsmarker 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 dieser NAL ein Referenzfeld ist oder nicht. 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 ein eingeschränktes Hochprofil verwendet (d.h. ein Hochprofil ohne Unterstützung für bidirektionale B-Segmente).
Wenn wir die Spezifikation des Bitstroms H.264 für SPS-NAL prüfen, finden wir viele Werte für den Namen des Parameters, die Kategorie und die Beschreibung. Zum Beispiel blicken wir auf die Felder pic_width_in_mbs_minus_1 und 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 die Auflösung. Man kann 1920 x 1080 darstellen, indem man pic_width_in_mbs_minus_1 einen Wert von 119 verwendet ((119 + 1) * macroblock_size = 120 * 16 = 1920). Wiederum, um Platz zu sparen, wurde anstelle von 1920 dies mit 119 gemacht.
Wenn wir das von uns erstellte Video im Binärformat überprüfen (z.B.: xxd -b -c 11 v/minimal_yuv420.h264), können wir zum letzten NAL übergehen, das den Frame selbst darstellt.
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, ist es in diesem Fall (00101) ein IDR-Ausschnitt (5), und wir können es weiter untersuchen:
Mit Hilfe der Informationsspezifikation kann der Typ des Ausschnitts (slice_type) und die Frame-Nummer (frame_num) sowie andere wichtige Felder dekodiert werden.
Um die Werte einiger Felder (ue(v), me(v), se(v) oder te(v)) zu erhalten, müssen wir den Ausschnitt mit einem speziellen Dekoder dekodieren, der auf . Diese Methode ist sehr effektiv zur Kodierung von Variablenwerten, insbesondere wenn es viele Standardwerte gibt.
Werte slice_type und frame_num dieses Videos entsprechen 7 (I-Fragment) und 0 (erster Frame).
Der Bitstrom kann als Protokoll betrachtet werden. Wenn Sie mehr über den Bitstrom erfahren möchten, sollten Sie die Spezifikation ITU H.264. Hier ist ein Blockdiagramm, das zeigt, wo sich die Bilddaten befinden (YUV in komprimierter Form).
Sie können auch andere Bitströme untersuchen, wie VP9, H.265 (HEVC) oder sogar unseren neuen besten Bitstrom AV1. Sind sie alle ähnlich? Nein, aber wenn man sich mit mindestens einem vertraut gemacht hat, ist es viel einfacher, die anderen zu verstehen.
Möchten Sie üben? Untersuchen Sie den H.264-Bitstrom
Sie können ein Einzelbildvideo generieren und MediaInfo verwenden, um den Bitstrom zu analysieren H.264. Tatsächlich steht es Ihnen frei, auch den Quellcode anzusehen, der den Bitstrom analysiert. H.264 (AVC).
Zur Übung können Sie den Intel Video Pro Analyzer verwenden (ich habe bereits erwähnt, dass das Programm kostenpflichtig ist, aber es gibt eine kostenlose Testversion mit einer Begrenzung von 10 Frames?).
Überblick
Es sei darauf hingewiesen, dass viele moderne Codecs dasselbe Modell verwenden, das wir gerade gelernt haben. Lassen Sie uns das Blockdiagramm des Video-Codecs ansehen Thor. Es enthält alle Schritte, die wir durchlaufen haben. Der Sinn dieser Notiz ist, dass Sie zumindest ein besseres Verständnis für die Innovationen und Dokumentationen in diesem Bereich haben.
Früher wurde berechnet, dass 139 GB Speicherplatz erforderlich sind, um eine Video-Datei von einer Stunde Dauer in 720p und 30 fps zu speichern. Wenn wir die in diesem Artikel behandelten Methoden (interframe und intra-frame Vorhersagen, Transformation, Quantisierung, Entropiekodierung usw.) verwenden, können wir erreichen (ausgehend von 0,031 Bit pro Pixel), dass das Video von passabler Qualität nur 367,82 MB statt 139 GB Speicherplatz benötigt.
Wie erzielt H.265 eine bessere Komprimierungsrate als H.264?
Jetzt, da mehr über die Funktionsweise von Codecs bekannt ist, ist es einfacher zu verstehen, wie neue Codecs eine höhere Auflösung mit weniger Bits erreichen 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 Maß der Komprimierung ist.
HEVC hat mehr Abschnitts- (und Unterabschnitts-) Optionen als AVC, mehr Richtungen der internen Vorhersage, verbesserte Entropie-Codierung und vieles mehr. All diese Verbesserungen haben H.265 die Fähigkeit, 50 % mehr zu komprimieren als H.264.
Erster Teil:
Quelle: habr.com
