Erweiterte Videocodierung - Advanced Video Coding

Erweiterte Videocodierung
Erweiterte Videocodierung für allgemeine audiovisuelle Dienste
H.264-Blockdiagramm mit Qualitätsfaktor.jpg
Status In voller Stärke
Jahr begonnen 2003
Letzte Version 13.0
Juni 2019
Organisation ITU-T , ISO , IEC
Komitee SG16 ( VCEG ), MPEG
Basisstandards H.261 , H.262 (auch bekannt als MPEG-2 Video ), H.263 , MPEG-1
Zugehörige Normen H.265 (auch bekannt als HEVC), H.266 (auch bekannt als VVC)
Domain Video-Kompression
Webseite https://www.itu.int/rec/T-REC-H.264

Advanced Video Coding ( AVC ), auch als H.264 oder MPEG-4 Part 10 bezeichnet, Advanced Video Coding ( MPEG-4 AVC ), ist ein Videokompressionsstandard, der auf blockorientierter, bewegungskompensierter Integer-DCT- Codierung basiert . Es ist das bei weitem am häufigsten verwendete Format für die Aufnahme, Komprimierung und Verteilung von Videoinhalten, das von 91% der Entwickler der Videoindustrie (Stand September 2019) verwendet wurde. Es unterstützt Auflösungen bis einschließlich 8K UHD .

Die Absicht des H.264/AVC-Projekts bestand darin, einen Standard zu schaffen, der eine gute Videoqualität bei wesentlich niedrigeren Bitraten als frühere Standards bieten kann (dh die Hälfte oder weniger der Bitrate von MPEG-2 , H.263 oder MPEG- 4 Teil 2 ), ohne die Komplexität des Designs so zu erhöhen, dass es unpraktisch oder zu teuer wäre. Dies wurde mit Funktionen wie einer ganzzahligen diskreten Kosinustransformation mit reduzierter Komplexität (Ganzzahl-DCT), variabler Blockgrößensegmentierung und Mehrbild- Zwischenbild-Vorhersage erreicht . Ein weiteres Ziel war es, genügend Flexibilität zu bieten, damit der Standard auf eine Vielzahl von Anwendungen in einer Vielzahl von Netzwerken und Systemen angewendet werden kann, einschließlich niedriger und hoher Bitraten, niedrig- und hochauflösender Video-, Rundfunk- , DVD- Speicherung, RTP / IP- Paketnetze und ITU-T- Multimedia- Telefoniesysteme . Der H.264-Standard kann als "Standardfamilie" angesehen werden, die sich aus einer Reihe verschiedener Profile zusammensetzt, wobei sein "High Profile" das mit Abstand am häufigsten verwendete Format ist. Ein bestimmter Decoder decodiert mindestens ein, aber nicht unbedingt alle Profile. Der Standard beschreibt das Format der kodierten Daten und wie die Daten dekodiert werden, spezifiziert jedoch keine Algorithmen zum Kodieren von Video – dies bleibt den Entwicklern von Kodierern überlassen, und es wurde eine Vielzahl von Kodierungsschemata entwickelt entwickelten. H.264 wird normalerweise für verlustbehaftete Komprimierung verwendet , obwohl es auch möglich ist, wirklich verlustfrei kodierte Bereiche in verlustbehafteten Bildern zu erstellen oder seltene Anwendungsfälle zu unterstützen, bei denen die gesamte Kodierung verlustfrei ist.

H.264 wurde von der ITU-T Video Coding Experts Group (VCEG) der Study Group 16 zusammen mit der ISO/IEC JTC1 Moving Picture Experts Group (MPEG) standardisiert . Die Projektpartnerschaft ist als Joint Video Team (JVT) bekannt. Der ITU-T H.264-Standard und der ISO/IEC MPEG-4  AVC-Standard (ehemals ISO/IEC 14496-10 – MPEG-4 Part 10, Advanced Video Coding) werden gemeinsam gepflegt, sodass sie technisch identisch sind. Die endgültigen Entwurfsarbeiten an der ersten Version der Norm wurden im Mai 2003 abgeschlossen, und in nachfolgenden Ausgaben wurden verschiedene Erweiterungen ihrer Fähigkeiten hinzugefügt. High Efficiency Video Coding (HEVC), auch bekannt als H.265 und MPEG-H Part 2, ist ein Nachfolger von H.264/MPEG-4 AVC, das von denselben Organisationen entwickelt wurde, während frühere Standards noch allgemein verwendet werden.

H.264 ist vielleicht am bekanntesten als das am häufigsten verwendete Videocodierungsformat auf Blu-ray-Discs . Es wird auch häufig für das Streamen von Internetquellen wie Videos von Netflix , Hulu , Amazon Prime Video , Vimeo , YouTube und dem iTunes Store , Websoftware wie Adobe Flash Player und Microsoft Silverlight sowie für verschiedene HDTV- Sendungen über terrestrische Kanäle verwendet ( ATSC , ISDB-T , DVB-T oder DVB-T2 ), Kabel- ( DVB-C ) und Satelliten- ( DVB-S und DVB-S2 ) Systeme.

H.264 ist durch Patente verschiedener Parteien eingeschränkt. Eine Lizenz, die die meisten (aber nicht alle) für H.264 wesentlichen Patente abdeckt, wird von einem von MPEG LA verwalteten Patentpool verwaltet .

Die kommerzielle Nutzung patentierter H.264-Technologien erfordert die Zahlung von Lizenzgebühren an MPEG LA und andere Patentinhaber. MPEG LA hat die kostenlose Nutzung von H.264-Technologien für das kostenlose Streaming von Internetvideos für Endbenutzer zugelassen, und Cisco Systems zahlt im Namen der Benutzer von Binärdateien für seinen Open-Source- H.264-Encoder Lizenzgebühren an MPEG LA .

Benennung

Der H.264-Name folgt der ITU-T- Namenskonvention, wobei der Standard ein Mitglied der H.26x-Reihe der VCEG -Videocodierungsstandards ist; der Name MPEG-4 AVC bezieht sich auf die Namenskonvention in ISO / IEC MPEG , wobei der Standard Teil 10 von ISO/IEC 14496 ist, der als MPEG-4 bekannten Standardsammlung. Der Standard wurde gemeinsam in einer Partnerschaft von VCEG und MPEG entwickelt, nach früheren Entwicklungsarbeiten in der ITU-T als VCEG-Projekt namens H.26L. Es ist daher üblich, auf den Standard mit Namen wie H.264/AVC, AVC/H.264, H.264/MPEG-4 AVC oder MPEG-4/H.264 AVC zu verweisen, um das gemeinsame Erbe hervorzuheben. Gelegentlich wird er auch als "der JVT-Codec" bezeichnet, in Anlehnung an die Organisation Joint Video Team (JVT), die ihn entwickelt hat. (Eine solche Partnerschaft und Mehrfachbenennung ist nicht ungewöhnlich. Zum Beispiel ist der als MPEG-2 bekannte Videokomprimierungsstandard auch aus der Partnerschaft zwischen MPEG und der ITU-T entstanden, wobei MPEG-2-Video in der ITU-T-Gemeinschaft als H . bekannt ist .262.) Einige Softwareprogramme (wie der VLC Media Player ) identifizieren diesen Standard intern als AVC1.

Geschichte

Gesamtgeschichte

Anfang 1998 veröffentlichte die Video Coding Experts Group (VCEG – ITU-T SG16 Q.6) eine Aufforderung zur Einreichung von Vorschlägen für ein Projekt namens H.26L mit dem Ziel, die Codierungseffizienz zu verdoppeln (dh die für ein gegebenes Maß an Wiedergabetreue) im Vergleich zu anderen existierenden Videocodierungsstandards für eine breite Vielfalt von Anwendungen. VCEG wurde von Gary Sullivan ( Microsoft , ehemals PictureTel , USA) geleitet. Der erste Entwurfsentwurf für diese neue Norm wurde im August 1999 angenommen. Im Jahr 2000 wurde Thomas Wiegand ( Heinrich-Hertz-Institut , Deutschland) Co-Vorsitzender des VCEG.

Im Dezember 2001 bildeten VCEG und die Moving Picture Experts Group ( MPEG  – ISO/IEC JTC 1/SC 29 /WG 11) ein Joint Video Team (JVT), um den Videocodierungsstandard fertigzustellen. Die formelle Genehmigung der Spezifikation erfolgte im März 2003. Den Vorsitz des JVT hatten (wird) Gary Sullivan , Thomas Wiegand und Ajay Luthra ( Motorola , USA: später Arris , USA). Im Juli 2004 wurde das Projekt Fidelity Range Extensions (FRExt) abgeschlossen. Von Januar 2005 bis November 2007 arbeitete das JVT an einer Erweiterung von H.264/AVC in Richtung Skalierbarkeit durch einen Annex (G) namens Scalable Video Coding (SVC). Das Führungsteam des JVT wurde um Jens-Rainer Ohm ( RWTH Aachen , Deutschland) erweitert. Von Juli 2006 bis November 2009 arbeitete das JVT an Multiview Video Coding (MVC), einer Erweiterung von H.264/AVC auf 3D-Fernsehen und Free- View- TV mit begrenzter Reichweite . Diese Arbeit beinhaltete die Entwicklung von zwei neuen Profilen des Standards: dem Multiview High Profile und dem Stereo High Profile.

Während der Entwicklung des Standards wurden zusätzliche Nachrichten entwickelt, die ergänzende Verbesserungsinformationen (SEI) enthalten. SEI-Nachrichten können verschiedene Arten von Daten enthalten, die das Timing der Videobilder angeben oder verschiedene Eigenschaften des codierten Videos beschreiben oder wie es verwendet oder verbessert werden kann. Es werden auch SEI-Nachrichten definiert, die beliebige benutzerdefinierte Daten enthalten können. SEI-Nachrichten haben keinen Einfluss auf den Kerndecodierungsprozess, können jedoch angeben, wie das Video zur Nachbearbeitung oder Anzeige empfohlen wird. Einige andere High-Level-Eigenschaften des Videoinhalts werden in Video-Usability-Informationen (VUI) übermittelt, wie beispielsweise die Angabe des Farbraums zur Interpretation des Videoinhalts. Bei der Entwicklung neuer Farbräume, beispielsweise für Videos mit hohem Dynamikumfang und großem Farbraum , wurden zusätzliche VUI-Kennungen hinzugefügt, um sie anzuzeigen.

Erweiterungen des Fidelity-Sortiments und Berufsprofile

Die Standardisierung der ersten Version von H.264/AVC wurde im Mai 2003 abgeschlossen. Im ersten Projekt zur Erweiterung des ursprünglichen Standards entwickelte die JVT dann die sogenannten Fidelity Range Extensions (FRExt). Diese Erweiterungen ermöglichten eine qualitativ hochwertigere Videocodierung, indem sie eine höhere Genauigkeit der Abtastbittiefe und höher aufgelöste Farbinformationen unterstützten, einschließlich der Abtaststrukturen, die als Y′C B C R 4:2:2 (auch bekannt als YUV 4:2:2 ) und 4 bekannt sind: 4:4. Mehrere andere Merkmale auch in dem FRExt Projekt aufgenommen wurden, wie beispielsweise eine 8 × 8 - Ganzzahl Zugabe diskrete Kosinustransformation (integer DCT) mit adaptivem Schalten zwischen den 4 × 4 und 8 × 8 - Transformationen, Encoder spezifizierte Wahrnehmungsbasierten Quantisierung Wichtungsmatrizen, effiziente verlustfreie Codierung zwischen Bildern und Unterstützung zusätzlicher Farbräume. Die Entwurfsarbeiten für das FRExt-Projekt wurden im Juli 2004 abgeschlossen und die Entwurfsarbeiten dafür wurden im September 2004 abgeschlossen.

Anschließend wurden fünf weitere neue Profile (siehe unten Version 7) entwickelt, die hauptsächlich für professionelle Anwendungen gedacht waren Mapping) und das Verwerfen eines der früheren FRExt-Profile (das High 4:4:4-Profil), das laut Branchenfeedback anders hätte gestaltet werden sollen.

Skalierbare Videocodierung

Das nächste wichtige Feature, das dem Standard hinzugefügt wurde, war Scalable Video Coding (SVC). SVC ist in Anhang G von H.264/AVC spezifiziert und erlaubt die Konstruktion von Bitströmen, die Schichten von Unterbitströmen enthalten, die ebenfalls dem Standard entsprechen, einschließlich eines solchen Bitstroms, der als "Basisschicht" bekannt ist und von einem H. 264/AVC- Codec , der SVC nicht unterstützt. Für eine zeitliche Skalierbarkeit des Bitstroms (dh das Vorhandensein eines Unterbitstroms mit einer kleineren zeitlichen Abtastrate als der Hauptbitstrom) werden beim Ableiten des Unterbitstroms vollständige Zugriffseinheiten aus dem Bitstrom entfernt. In diesem Fall werden eine High-Level-Syntax und Interprädiktions-Referenzbilder in dem Bitstrom entsprechend konstruiert. Andererseits wird für die räumliche und qualitative Skalierbarkeit des Bitstroms (dh das Vorhandensein eines Unterbitstroms mit einer geringeren räumlichen Auflösung/Qualität als der Hauptbitstrom) die NAL ( Network Abstraction Layer ) aus dem Bitstrom entfernt, wenn der Unterbitstrom abgeleitet wird . In diesem Fall wird für eine effiziente Codierung typischerweise eine Zwischenschicht-Vorhersage (dh die Vorhersage des Signals mit höherer räumlicher Auflösung/Qualität aus den Daten des Signals mit niedrigerer räumlicher Auflösung/Qualität) verwendet. Die Erweiterungen für Scalable Video Coding wurden im November 2007 abgeschlossen.

Multiview-Videocodierung

Die nächste wichtige Funktion, die dem Standard hinzugefügt wurde, war Multiview Video Coding (MVC). Spezifiziert in Anhang H von H.264/AVC ermöglicht MVC die Konstruktion von Bitstreams, die mehr als eine Ansicht einer Videoszene darstellen. Ein wichtiges Beispiel für diese Funktionalität ist die stereoskopische 3D -Videocodierung. In der MVC-Arbeit wurden zwei Profile entwickelt: Multiview High Profile unterstützt eine beliebige Anzahl von Ansichten und Stereo High Profile wurde speziell für stereoskopisches Video mit zwei Ansichten entwickelt. Die Erweiterungen für Multiview Video Coding wurden im November 2009 abgeschlossen.

Stereoskopische 3D-AVC- und MFC-Codierung

Später wurden zusätzliche Erweiterungen entwickelt, die 3D-Videocodierung mit gemeinsamer Codierung von Tiefenkarten und Textur (bezeichnet als 3D-AVC), Multi-Resolution-Frame-kompatible (MFC) stereoskopische und 3D-MFC-Codierung, verschiedene zusätzliche Kombinationen von Funktionen und höhere Frames umfassten Größen und Bildraten.

Versionen

Versionen des H.264/AVC-Standards umfassen die folgenden abgeschlossenen Überarbeitungen, Korrigenda und Ergänzungen (Daten sind endgültige Zulassungsdaten in ITU-T, während endgültige Zulassungsdaten für "Internationale Standards" in ISO/IEC etwas anders und in den meisten Fällen etwas später sind Fälle). Jede Version stellt Änderungen gegenüber der nächstniedrigeren Version dar, die in den Text integriert ist.

  • Version 1 (Edition 1): (30. Mai 2003) Erste freigegebene Version von H.264/AVC mit Baseline-, Main- und Extended-Profilen.
  • Version 2 (Ausgabe 1.1): (7. Mai 2004) Berichtigung mit verschiedenen kleineren Korrekturen.
  • Version 3 (Ausgabe 2): (1. März 2005) Wesentliche Ergänzung mit der ersten Änderung, die die Fidelity Range Extensions (FRExt) einrichtet. Diese Version hat die Profile High, High 10, High 4:2:2 und High 4:4:4 hinzugefügt. Nach einigen Jahren wurde das High Profile zum am häufigsten verwendeten Profil des Standards.
  • Version 4 (Ausgabe 2.1): (13. September 2005) Berichtigung mit verschiedenen kleineren Korrekturen und Hinzufügen von drei Seitenverhältnisindikatoren.
  • Version 5 (Ausgabe 2.2): (13. Juni 2006) Änderung bestehend aus der Entfernung des früheren High 4:4:4-Profils (verarbeitet als Korrigendum in ISO/IEC).
  • Version 6 (Edition 2.2): (13. Juni 2006) Änderung bestehend aus kleineren Erweiterungen wie der Unterstützung des erweiterten Farbraums (gebündelt mit den oben genannten Seitenverhältnisindikatoren in ISO/IEC).
  • Version 7 (Ausgabe 2.3): (6. April 2007) Änderung mit der Hinzufügung des Vorhersageprofils High 4:4:4 und vier Nur-Intra-Profilen (High 10 Intra, High 4:2:2 Intra, High 4:4 :4 Intra und CAVLC 4:4:4 Intra).
  • Version 8 (Ausgabe 3): (22. November 2007) Wichtige Ergänzung zu H.264/AVC mit der Ergänzung für Scalable Video Coding (SVC) mit den Profilen Scalable Baseline, Scalable High und Scalable High Intra.
  • Version 9 (Ausgabe 3.1): (13. Januar 2009) Berichtigung mit geringfügigen Korrekturen.
  • Version 10 (Ausgabe 4): (16. März 2009) Änderung, die die Definition eines neuen Profils (des Constrained Baseline-Profils) mit nur der gemeinsamen Teilmenge von Fähigkeiten enthält, die in verschiedenen zuvor spezifizierten Profilen unterstützt werden.
  • Version 11 (Ausgabe 4): (16. März 2009) Wichtige Ergänzung zu H.264/AVC mit der Ergänzung für die Erweiterung Multiview Video Coding (MVC), einschließlich des Profils Multiview High.
  • Version 12 (Ausgabe 5): (9. März 2010) Änderung mit Definition eines neuen MVC-Profils (Stereo High-Profil) für die Videocodierung mit zwei Ansichten mit Unterstützung von Interlaced-Codierungswerkzeugen und Angabe einer zusätzlichen Supplemental Enhancement Information (SEI)-Nachricht als SEI-Nachricht der Rahmenverpackungsanordnung bezeichnet.
  • Version 13 (Ausgabe 5): (9. März 2010) Berichtigung mit geringfügigen Korrekturen.
  • Version 14 (Ausgabe 6): (29. Juni 2011) Änderung, die eine neue Ebene (Ebene 5.2) spezifiziert, die höhere Verarbeitungsraten in Bezug auf maximale Makroblöcke pro Sekunde unterstützt, und ein neues Profil (das Progressive High-Profil), das nur die Rahmencodierungstools unterstützt des zuvor angegebenen High-Profils.
  • Version 15 (Ausgabe 6): (29. Juni 2011) Berichtigung mit geringfügigen Korrekturen.
  • Version 16 (Ausgabe 7): (13. Januar 2012) Änderung mit Definition von drei neuen Profilen, die hauptsächlich für Echtzeitkommunikationsanwendungen gedacht sind: die Profile Constrained High, Scalable Constrained Baseline und Scalable Constrained High.
  • Version 17 (Ausgabe 8): (13. April 2013) Ergänzung mit zusätzlichen SEI-Nachrichtenindikatoren.
  • Version 18 (Ausgabe 8): (13. April 2013) Änderung zur Spezifizierung der Codierung von Tiefenkartendaten für stereoskopisches 3D-Video, einschließlich eines Multiview-Tiefen-High-Profils.
  • Version 19 (Ausgabe 8): (13. April 2013) Berichtigung zur Korrektur eines Fehlers im Sub-Bitstream-Extraktionsprozess für Multiview-Video.
  • Version 20 (Ausgabe 8): (13. April 2013) Änderung zur Angabe zusätzlicher Farbraumkennungen (einschließlich Unterstützung der ITU-R-Empfehlung BT.2020 für UHDTV ) und eines zusätzlichen Modelltyps in der Tone-Mapping-Informations-SEI-Nachricht.
  • Version 21 (Ausgabe 9): (13. Februar 2014) Änderung zur Spezifizierung des Profils Enhanced Multiview Depth High.
  • Version 22 (Ausgabe 9): (13. Februar 2014) Änderung zur Angabe der Multi-Resolution-Frame-kompatiblen (MFC)-Erweiterung für stereoskopisches 3D-Video, des MFC-High-Profils und geringfügiger Korrekturen.
  • Version 23 (Ausgabe 10): (13. Februar 2016) Änderung zur Angabe von MFC-Stereovideo mit Tiefenkarten, dem MFC-Tiefen-High-Profil, der Mastering-Display-Farbvolumen-SEI-Nachricht und zusätzlichen farbbezogenen VUI-Codepunkt-Identifikatoren.
  • Version 24 (Ausgabe 11): (14. Oktober 2016) Änderung zur Angabe zusätzlicher Stufen der Decoderfähigkeit, die größere Bildgrößen unterstützen (Stufen 6, 6.1 und 6.2), die grüne Metadaten-SEI-Nachricht, die alternative Tiefeninformations-SEI-Nachricht und zusätzliche farbbezogene VUI-Codepoint-Bezeichner.
  • Version 25 (Ausgabe 12): (13. April 2017) Änderung zur Spezifizierung des Profils Progressive High 10, Hybrid Log-Gamma (HLG) und zusätzlicher farbbezogener VUI-Codepunkte und SEI-Meldungen.
  • Version 26 (Ausgabe 13): (13. Juni 2019) Änderung zur Angabe zusätzlicher SEI-Meldungen für Umgebungsanzeigeumgebung, Inhaltslichtpegelinformationen, Inhaltsfarbvolumen, äquatoriale Projektion, Cubemap-Projektion, Kugelrotation, bereichsweises Packen, omnidirektionales Ansichtsfenster, SEI-Manifest und SEI-Präfix.

Patentinhaber

Die folgenden Organisationen halten ein oder mehrere Patente im H.264/AVC- Patentpool von MPEG LA .

H.264/AVC-Patentinhaber (ab November 2020)
Organisation Aktive Patente Abgelaufene Patente Patente insgesamt
Panasonic Corporation 1.135 62 1.197
Godo Kaisha IP-Bridge 1.111 19 1.130
LG Elektronik 875 115 990
Dolby Laboratories 754 21 775
Toshiba 357 34 391
Microsoft 176 39 215
Nippon Telegraph und Telefon (einschließlich NTT Docomo ) 187 2 189
Sony 116 31 147
Fraunhofer-Gesellschaft 125 16 141
Google 136 3 139
GE- Videokomprimierung 136 0 136
Fujitsu 92 14 106
Mitsubishi Electric 54 50 104
Tagivan II LLC 77 0 77
Samsung-Elektronik 23 40 63
Maxell 51 2 53
Philips 5 39 44
Video 41 2 43
Ericsson 34 0 34
Forschungsinstitut für Elektronik und Telekommunikation (ETRI) von Korea 32 0 32

Anwendungen

Das H.264-Videoformat hat einen sehr breiten Anwendungsbereich, der alle Formen von digital komprimiertem Video abdeckt, von Internet-Streaming-Anwendungen mit niedriger Bitrate bis hin zu HDTV-Broadcast- und Digital Cinema-Anwendungen mit nahezu verlustfreier Codierung. Bei Verwendung von H.264 werden Bitrateneinsparungen von 50 % oder mehr im Vergleich zu MPEG-2 Teil 2 gemeldet. H.264 bietet beispielsweise die gleiche digitale Satelliten-TV-Qualität wie aktuelle MPEG-2-Implementierungen mit weniger als der Hälfte der Bitrate, wobei aktuelle MPEG-2-Implementierungen mit etwa 3,5 Mbit/s und H.264 mit nur 1,5 arbeiten Mbit/s. Sony behauptet, dass der 9-Mbit/s-AVC-Aufnahmemodus der Bildqualität des HDV- Formats entspricht, das ungefähr 18–25 Mbit/s verwendet.

Um die Kompatibilität und problemlose Übernahme von H.264/AVC zu gewährleisten, haben viele Normungsgremien ihre videobezogenen Standards geändert oder ergänzt, sodass Benutzer dieser Standards H.264/AVC einsetzen können. Sowohl das Blu-ray Disc- Format als auch das inzwischen eingestellte HD-DVD- Format enthalten H.264/AVC High Profile als eines von drei obligatorischen Videokomprimierungsformaten. Das Digital Video Broadcast Project ( DVB ) genehmigte Ende 2004 die Verwendung von H.264/AVC für das Rundfunkfernsehen.

Das Standardisierungsgremium des Advanced Television Systems Committee (ATSC) in den Vereinigten Staaten genehmigte im Juli 2008 die Verwendung von H.264/AVC für das Rundfunkfernsehen, obwohl der Standard noch nicht für feste ATSC-Sendungen in den Vereinigten Staaten verwendet wird. Es wurde auch für die Verwendung mit dem neueren ATSC-M/H- Standard (Mobile/Handheld) zugelassen, wobei die AVC- und SVC-Teile von H.264 verwendet werden.

Die Märkte CCTV (Closed Circuit TV) und Videoüberwachung haben die Technologie in viele Produkte integriert.

Viele gängige DSLRs verwenden H.264-Videos, die in QuickTime MOV-Container verpackt sind, als natives Aufnahmeformat.

Abgeleitete Formate

AVCHD ist ein von Sony und Panasonic entwickeltes hochauflösendes Aufnahmeformat , das H.264 verwendet (entspricht H.264, während zusätzliche anwendungsspezifische Funktionen und Einschränkungen hinzugefügt werden).

AVC-Intra ist ein reines Intraframe- Komprimierungsformat, das von Panasonic entwickelt wurde .

XAVC ist ein von Sony entwickeltes Aufnahmeformat, das Stufe 5.2 von H.264/MPEG-4 AVC verwendet, was die höchste von diesem Videostandard unterstützte Stufe ist. XAVC kann 4K-Auflösungen (4096 × 2160 und 3840 × 2160) mit bis zu 60  Bildern pro Sekunde (fps) unterstützen. Sony hat angekündigt, dass zu den Kameras, die XAVC unterstützen, zwei CineAlta- Kameras gehören – die Sony PMW-F55 und die Sony PMW-F5. Die Sony PMW-F55 kann XAVC mit 4K-Auflösung bei 30 fps bei 300 Mbit/s und 2K-Auflösung bei 30 fps bei 100 Mbit/s aufzeichnen . XAVC kann 4K-Auflösung bei 60 fps mit 4:2:2-Chroma-Sampling bei 600 Mbit/s aufnehmen.

Entwurf

Merkmale

Blockschaltbild von H.264

H.264/AVC/MPEG-4 Part 10 enthält eine Reihe neuer Funktionen, die es ermöglichen, Video viel effizienter als ältere Standards zu komprimieren und mehr Flexibilität für die Anwendung in einer Vielzahl von Netzwerkumgebungen zu bieten. Einige dieser Schlüsselfunktionen umfassen insbesondere:

  • Mehrbild- Zwischenbild-Vorhersage mit den folgenden Funktionen:
    • Die Verwendung von zuvor kodierten Bildern als Referenzen auf eine viel flexiblere Weise als in früheren Standards, wodurch in einigen Fällen bis zu 16 Referenzbilder (oder 32 Referenzfelder bei Zeilensprungkodierung) verwendet werden können. In Profilen, die Nicht- IDR- Frames unterstützen, geben die meisten Stufen an, dass genügend Pufferung verfügbar sein sollte, um mindestens 4 oder 5 Referenzframes bei maximaler Auflösung zu ermöglichen. Dies steht im Gegensatz zu früheren Standards, bei denen die Grenze normalerweise eins war; oder im Fall von herkömmlichen " B-Bildern " (B-Frames) zwei.
    • Bewegungskompensation mit variabler Blockgröße (VBSMC) mit Blockgrößen von bis zu 16×16 und so klein wie 4×4, was eine präzise Segmentierung von Bewegungsbereichen ermöglicht. Die unterstützten Luma- Vorhersageblockgrößen umfassen 16 × 16, 16 × 8, 8 × 16, 8 × 8, 8 × 4, 4 × 8 und 4 × 4, von denen viele zusammen in einem einzigen Makroblock verwendet werden können. Chroma-Prädiktionsblockgrößen sind entsprechend kleiner, wenn Chroma-Subsampling verwendet wird.
    • Die Fähigkeit, mehrere Bewegungsvektoren pro Makroblock (ein oder zwei pro Partition) zu verwenden, mit einem Maximum von 32 im Fall eines B-Makroblocks, der aus 16 4×4-Partitionen aufgebaut ist. Die Bewegungsvektoren für jeden 8×8 oder größeren Partitionsbereich können auf unterschiedliche Referenzbilder zeigen.
    • Die Möglichkeit, jeden Makroblocktyp in B-Frames zu verwenden , einschließlich I-Makroblöcken, was zu einer viel effizienteren Codierung bei Verwendung von B-Frames führt. Diese Funktion wurde insbesondere bei MPEG-4 ASP ausgelassen .
    • Sechs-Tap-Filterung zur Ableitung von Halb-Pel-Luma-Sample-Vorhersagen für eine schärfere Subpixel-Bewegungskompensation. Eine Viertelpixelbewegung wird durch lineare Interpolation der Halbpixelwerte abgeleitet, um Rechenleistung zu sparen.
    • Viertelpixel- Präzision zur Bewegungskompensation, die eine genaue Beschreibung der Verschiebungen von bewegten Bereichen ermöglicht. Für Chroma wird die Auflösung typischerweise sowohl vertikal als auch horizontal halbiert (siehe 4:2:0 ), daher verwendet die Bewegungskompensation von Chroma ein Achtel-Chroma-Pixelraster.
    • Gewichtete Vorhersage, die es einem Encoder ermöglicht, die Verwendung einer Skalierung und eines Versatzes bei der Durchführung der Bewegungskompensation anzugeben, und bietet in besonderen Fällen einen erheblichen Leistungsvorteil – wie z. B. Einblenden zu Schwarz, Einblenden und Überblenden. Dies umfasst eine implizite gewichtete Vorhersage für B-Frames und eine explizite gewichtete Vorhersage für P-Frames.
  • Räumliche Vorhersage von den Kanten benachbarter Blöcke für die "Intra" -Codierung, anstelle der reinen "DC"-Vorhersage in MPEG-2 Teil 2 und der Transformationskoeffizienten-Vorhersage in H.263v2 und MPEG-4 Teil 2. Dies beinhaltet luma Vorhersageblockgrößen von 16×16, 8×8 und 4×4 (von denen innerhalb jedes Makroblocks nur ein Typ verwendet werden kann ).
  • Ganzzahlige diskrete Kosinustransformation (Ganzzahl-DCT), eine Art der diskreten Kosinustransformation (DCT), bei der die Transformation eine ganzzahlige Näherung der Standard-DCT ist. Es verfügt über auswählbare Blockgrößen und eine exakt übereinstimmende Integer-Berechnung, um die Komplexität zu reduzieren, einschließlich:
    • Eine exakt übereinstimmende, ganzzahlige 4×4 räumliche Blocktransformation, die eine präzise Platzierung von Restsignalen mit wenig von dem " Klingeln " ermöglicht, das oft bei früheren Codec-Designs gefunden wird. Es ähnelt dem in früheren Standards verwendeten Standard-DCT, verwendet jedoch eine kleinere Blockgröße und eine einfache Ganzzahlverarbeitung. Im Gegensatz zu den auf Kosinus basierenden Formeln und Toleranzen, die in früheren Standards (wie H.261 und MPEG-2) ausgedrückt wurden, liefert die Ganzzahlverarbeitung ein genau spezifiziertes decodiertes Ergebnis.
    • Eine exakt übereinstimmende Integer 8×8 räumliche Blocktransformation, die eine effizientere Komprimierung hochkorrelierter Regionen als mit der 4×4 Transformation ermöglicht. Dieses Design basiert auf dem Standard-DCT, ist jedoch vereinfacht und so gestaltet, dass es eine exakt spezifizierte Dekodierung bereitstellt.
    • Adaptive Codiererauswahl zwischen den 4×4 und 8×8 Transformationsblockgrößen für die Ganzzahltransformationsoperation.
    • Eine sekundäre Hadamard-Transformation, die an "DC"-Koeffizienten der primären räumlichen Transformation durchgeführt wird, die auf Chroma-DC-Koeffizienten (und in einem speziellen Fall auch Luma) angewendet wird, um noch mehr Kompression in glatten Bereichen zu erhalten.
  • Verlustfreie Makroblock-Codierungsfunktionen, einschließlich:
    • Ein verlustfreier "PCM-Makroblock"-Darstellungsmodus, in dem Videodatenabtastwerte direkt dargestellt werden, was eine perfekte Darstellung bestimmter Bereiche und eine strikte Begrenzung der codierten Datenmenge für jeden Makroblock ermöglicht.
    • Ein verbesserter verlustfreier Makroblock-Darstellungsmodus, der eine perfekte Darstellung spezifischer Bereiche ermöglicht, während er normalerweise wesentlich weniger Bits verwendet als der PCM-Modus.
  • Flexible Interlaced- Scan-Videocodierungsfunktionen, einschließlich:
    • Makroblockadaptive Frame-Field-Codierung (MBAFF) unter Verwendung einer Makroblock-Paarstruktur für als Frames codierte Bilder, die 16×16-Makroblöcke im Halbbildmodus ermöglicht (im Vergleich zu MPEG-2, bei dem die Halbbildmodus-Verarbeitung in einem als Vollbild kodierten Bild) ergibt die Verarbeitung von 16×8 Halbmakroblöcken).
    • Bildadaptive Frame-Field-Codierung (PAFF oder PicAFF) ermöglicht eine frei wählbare Mischung von Bildern, die entweder als komplette Frames codiert werden, wobei beide Felder zur Codierung kombiniert werden, oder als einzelne Einzelfelder.
  • Ein Quantisierungsdesign mit:
    • Logarithmische Schrittweitensteuerung für einfacheres Bitratenmanagement durch Encoder und vereinfachte inverse Quantisierungsskalierung
    • Vom Encoder ausgewählte frequenzangepasste Quantisierungsskalierungsmatrizen für wahrnehmungsbasierte Quantisierungsoptimierung
  • Ein In-Loop- Deblocking-Filter , der die Blockierungsartefakte verhindert, die bei anderen DCT-basierten Bildkomprimierungstechniken üblich sind, was zu einem besseren visuellen Erscheinungsbild und einer besseren Komprimierungseffizienz führt
  • Ein Entropiecodierungsdesign, das Folgendes umfasst:
    • Kontextadaptive binäre arithmetische Codierung (CABAC), ein Algorithmus zum verlustfreien Komprimieren von Syntaxelementen im Videostream, der die Wahrscheinlichkeiten von Syntaxelementen in einem bestimmten Kontext kennt. CABAC komprimiert Daten effizienter als CAVLC, erfordert jedoch erheblich mehr Verarbeitung zum Decodieren.
    • Kontextadaptive Variable-Length-Codierung (CAVLC), die eine Alternative zu CABAC mit geringerer Komplexität für die Codierung von quantisierten Transformationskoeffizientenwerten ist. Obwohl CAVLC eine geringere Komplexität als CABAC hat, ist es aufwendiger und effizienter als die Verfahren, die typischerweise verwendet werden, um Koeffizienten in anderen früheren Designs zu codieren.
    • Eine übliche einfache und hochstrukturierte Codierung mit variabler Länge (VLC) für viele der Syntaxelemente, die nicht von CABAC oder CAVLC codiert werden, die als Exponential-Golomb-Codierung (oder Exp-Golomb) bezeichnet wird.
  • Verlustresilienzfunktionen, einschließlich:
    • Eine Network Abstraction Layer (NAL)-Definition, die die Verwendung derselben Video-Syntax in vielen Netzwerkumgebungen ermöglicht. Ein sehr grundlegendes Designkonzept von H.264 besteht darin, in sich geschlossene Pakete zu erzeugen, um die Header-Duplizierung wie im Header Extension Code (HEC) von MPEG-4 zu entfernen. Dies wurde erreicht, indem Informationen, die für mehr als ein Slice relevant sind, aus dem Medienstrom entkoppelt wurden. Die Kombination der übergeordneten Parameter wird als Parametersatz bezeichnet. Die H.264-Spezifikation umfasst zwei Arten von Parametersätzen: Sequence Parameter Set (SPS) und Picture Parameter Set (PPS). Ein aktiver Sequenzparametersatz bleibt während einer codierten Videosequenz unverändert, und ein aktiver Bildparametersatz bleibt innerhalb eines codierten Bildes unverändert. Die Sequenz- und Bildparametersatzstrukturen enthalten Informationen wie die Bildgröße, die verwendeten optionalen Codiermodi und die Makroblock-zu-Slice-Gruppen-Karte.
    • Flexible Macroblock Ordering (FMO), auch bekannt als Slice Groups, und Arbitrary Slice Ordering (ASO), die Techniken zum Restrukturieren der Anordnung der Darstellung der Fundamentalbereiche ( Makroblöcke ) in Bildern sind. FMO und ASO werden normalerweise als Fehler-/Verlustrobustheitsmerkmal betrachtet und können auch für andere Zwecke verwendet werden.
    • Datenpartitionierung (DP), eine Funktion, die die Möglichkeit bietet, wichtigere und weniger wichtige Syntaxelemente in verschiedene Datenpakete zu trennen, wodurch die Anwendung von ungleichem Fehlerschutz (UEP) und andere Arten der Verbesserung der Fehler-/Verlustrobustheit ermöglicht werden.
    • Redundante Slices (RS), eine Fehler-/Verlust-Robustheitsfunktion, die es einem Encoder ermöglicht, eine zusätzliche Darstellung eines Bildbereichs (normalerweise mit geringerer Wiedergabetreue) zu senden, die verwendet werden kann, wenn die primäre Darstellung beschädigt ist oder verloren geht.
    • Bildnummerierung, eine Funktion, die die Erstellung von "Untersequenzen" ermöglicht, die eine zeitliche Skalierbarkeit durch optionales Einfügen zusätzlicher Bilder zwischen anderen Bildern sowie die Erkennung und Verbergung von Verlusten ganzer Bilder ermöglicht, die aufgrund von Netzwerkpaketverlusten oder Kanälen auftreten können Fehler.
  • Das Umschalten von Slices, SP- und SI-Slices genannt, ermöglicht es einem Codierer, einen Decoder anzuweisen, in einen laufenden Videostrom zu springen, für solche Zwecke wie das Umschalten der Video-Streaming-Bitrate und den "Trick-Modus"-Betrieb. Wenn ein Decoder mit der SP/SI-Funktion in die Mitte eines Videostreams springt, kann er eine genaue Übereinstimmung mit den decodierten Bildern an dieser Stelle im Videostream erzielen, obwohl er unterschiedliche Bilder oder überhaupt keine Bilder als Referenzen verwendet hat Der Schalter.
  • Ein einfacher automatischer Prozess, um die versehentliche Emulation von Startcodes zu verhindern , bei denen es sich um spezielle Bitfolgen in den codierten Daten handelt, die einen wahlfreien Zugriff auf den Bitstrom und die Wiederherstellung der Byteausrichtung in Systemen ermöglichen, die die Bytesynchronisation verlieren können.
  • Ergänzende Verbesserungsinformationen (SEI) und Video-Usability-Informationen (VUI), bei denen es sich um zusätzliche Informationen handelt, die für verschiedene Zwecke in den Bitstream eingefügt werden können, z. SEI-Nachrichten können beliebige benutzerdefinierte Metadaten-Payloads oder andere Nachrichten mit im Standard definierter Syntax und Semantik enthalten.
  • Hilfsbilder, die beispielsweise für Alpha-Compositing verwendet werden können .
  • Unterstützung von Monochrom (4:0:0), 4:2:0, 4:2:2 und 4:4:4 Chroma-Sampling (je nach ausgewähltem Profil).
  • Unterstützung einer Bittiefenpräzision von 8 bis 14 Bit pro Sample (je nach ausgewähltem Profil).
  • Die Möglichkeit, einzelne Farbebenen als eigenständige Bilder mit eigenen Slice-Strukturen, Makroblock-Modi, Bewegungsvektoren usw. zu codieren, wodurch Codierer mit einer einfachen Parallelisierungsstruktur entworfen werden können (nur in den drei 4:4:4-fähigen Profilen unterstützt) .
  • Bildreihenfolgezählung, eine Funktion, die dazu dient, die Reihenfolge der Bilder und die Werte der Abtastwerte in den decodierten Bildern von Zeitinformationen isoliert zu halten, wodurch Zeitinformationen von einem System separat übertragen und gesteuert/geändert werden können, ohne den decodierten Bildinhalt zu beeinträchtigen.

Diese Techniken, zusammen mit einigen anderen, helfen H.264, unter einer Vielzahl von Umständen und in einer Vielzahl von Anwendungsumgebungen eine deutlich bessere Leistung als jeder frühere Standard zu erzielen. H.264 kann oft eine radikal bessere Leistung erbringen als MPEG-2-Video – normalerweise wird die gleiche Qualität bei der halben Bitrate oder weniger erzielt, insbesondere bei Videoinhalten mit hoher Bitrate und hoher Auflösung.

Wie andere ISO/IEC MPEG-Videostandards verfügt auch H.264/AVC über eine Referenzsoftwareimplementierung, die kostenlos heruntergeladen werden kann. Sein Hauptzweck ist es, Beispiele für H.264/AVC-Funktionen zu geben, anstatt per se eine nützliche Anwendung zu sein . In der Moving Picture Experts Group wurden auch einige Referenz - Hardware - Designarbeiten durchgeführt . Die oben genannten Aspekte beinhalten Funktionen in allen Profilen von H.264. Ein Profil für einen Codec ist ein Satz von Merkmalen dieses Codecs, der identifiziert wurde, um einen bestimmten Satz von Spezifikationen der beabsichtigten Anwendungen zu erfüllen. Dies bedeutet, dass viele der aufgeführten Funktionen in einigen Profilen nicht unterstützt werden. Im nächsten Abschnitt werden verschiedene Profile von H.264/AVC behandelt.

Profile

Der Standard definiert mehrere Gruppen von Fähigkeiten, die als Profile bezeichnet werden und auf bestimmte Anwendungsklassen abzielen. Diese werden mithilfe eines Profilcodes (profile_idc) und manchmal einer Reihe zusätzlicher Einschränkungen deklariert, die im Encoder angewendet werden. Der Profilcode und die angegebenen Beschränkungen ermöglichen es einem Decoder, die Anforderungen zum Decodieren dieses speziellen Bitstroms zu erkennen. (Und in vielen Systemumgebungen dürfen nur ein oder zwei Profile verwendet werden, sodass Decoder in diesen Umgebungen sich nicht darum kümmern müssen, die weniger häufig verwendeten Profile zu erkennen.) Das mit Abstand am häufigsten verwendete Profil ist das High Profile.

Profile für nicht skalierbare 2D-Videoanwendungen umfassen Folgendes:

Eingeschränktes Basislinienprofil (CBP, 66 mit Einschränkungssatz 1)
In erster Linie für kostengünstige Anwendungen wird dieses Profil am häufigsten in Videokonferenzen und mobilen Anwendungen verwendet. Es entspricht der Teilmenge der Funktionen, die das Baseline-, Main- und High-Profile gemeinsam haben.
Basislinienprofil (BP, 66)
In erster Linie für kostengünstige Anwendungen, die zusätzliche Robustheit bei Datenverlust erfordern, wird dieses Profil in einigen Videokonferenzen und mobilen Anwendungen verwendet. Dieses Profil enthält alle Funktionen, die im Constrained Baseline Profile unterstützt werden, sowie drei zusätzliche Funktionen, die für die Verluststabilität (oder für andere Zwecke wie das Zusammensetzen von Mehrpunkt-Videostreams mit geringer Verzögerung) verwendet werden können. Die Bedeutung dieses Profils hat seit der Definition des Constrained Baseline Profile im Jahr 2009 etwas nachgelassen. Alle Constrained Baseline Profile Bitstreams werden auch als Baseline Profile Bitstreams betrachtet, da diese beiden Profile denselben Profilkennungscodewert teilen.
Erweitertes Profil (XP, 88)
Dieses Profil, das als Streaming-Videoprofil gedacht ist, verfügt über eine relativ hohe Komprimierungsfähigkeit und einige zusätzliche Tricks zur Robustheit gegenüber Datenverlusten und Server-Stream-Umschaltung.
Hauptprofil (MP, 77)
Dieses Profil wird für digitale Standard-Definition-TV-Sendungen verwendet, die das MPEG-4-Format verwenden, wie es im DVB-Standard definiert ist. Es wird jedoch nicht für hochauflösende Fernsehsendungen verwendet, da die Bedeutung dieses Profils nachließ, als das High Profile im Jahr 2004 für diese Anwendung entwickelt wurde.
Hohes Profil (HiP, 100)
Das primäre Profil für Rundfunk- und Disc-Speicheranwendungen, insbesondere für hochauflösende Fernsehanwendungen (dies ist beispielsweise das Profil, das vom Blu-ray Disc- Speicherformat und dem DVB HDTV-Sendedienst übernommen wird).
Progressive High Profile (PHiP, 100 mit Einschränkungssatz 4)
Ähnlich dem High Profile, jedoch ohne Unterstützung von Feldcodierungsfunktionen.
Constrained High Profile (100 mit Constraint Set 4 und 5)
Ähnlich dem Progressive High-Profil, jedoch ohne Unterstützung von B (bi-predictive) Slices.
Hohes 10-Profil (Hi10P, 110)
Dieses Profil geht über die Fähigkeiten typischer Mainstream-Verbraucherprodukte hinaus und baut auf dem High Profile auf und bietet Unterstützung für bis zu 10 Bit pro Abtastung decodierter Bildpräzision.
Hohes 4:2:2-Profil (Hi422P, 122)
Dieses Profil richtet sich in erster Linie an professionelle Anwendungen, die Interlaced-Video verwenden. Es baut auf dem High 10-Profil auf und bietet Unterstützung für das 4:2:2- Chroma-Sampling- Format bei Verwendung von bis zu 10 Bit pro Sample decodierter Bildpräzision.
Hoch 4:4:4 Vorhersageprofil (Hi444PP, 244)
Dieses Profil baut auf dem High 4:2:2 Profile auf und unterstützt bis zu 4:4:4 Chroma-Sampling, bis zu 14 Bit pro Sample und unterstützt zusätzlich eine effiziente verlustfreie Regionscodierung und die Codierung jedes Bildes als drei separate Farben Flugzeuge.

Für Camcorder, Schnitt und professionelle Anwendungen enthält der Standard vier zusätzliche Nur- Intra-Frame- Profile, die als einfache Teilmengen anderer entsprechender Profile definiert sind. Diese sind hauptsächlich für professionelle Anwendungen (z. B. Kamera- und Schnittsysteme) gedacht:

Hohes 10 Intra-Profil (110 mit Einschränkungssatz 3)
Das High-10-Profil beschränkt sich auf die All-Intra-Nutzung.
Hoch 4:2:2 Intra-Profil (122 mit Einschränkungssatz 3)
Das High-4:2:2-Profil ist auf die All-Intra-Nutzung beschränkt.
Hoch 4:4:4 Intra-Profil (244 mit Einschränkungssatz 3)
Das High-4:4:4-Profil beschränkt sich auf die All-Intra-Nutzung.
CAVLC 4:4:4 Intra-Profil (44)
Das hohe 4:4:4-Profil beschränkt sich auf die All-Intra-Verwendung und auf die CAVLC-Entropiecodierung (dh es unterstützt CABAC nicht).

Als Ergebnis der Erweiterung Scalable Video Coding (SVC) enthält der Standard fünf zusätzliche skalierbare Profile , die als Kombination eines H.264/AVC-Profils für die Basisschicht definiert sind (identifiziert durch das zweite Wort im skalierbaren Profilnamen ) und Tools, die die skalierbare Erweiterung erreichen:

Skalierbares Basisprofil (83)
Dieses Profil ist in erster Linie auf Videokonferenz-, Mobil- und Überwachungsanwendungen ausgerichtet und baut auf dem Constrained Baseline-Profil auf, dem die Basisschicht (eine Teilmenge des Bitstreams) entsprechen muss. Für die Skalierbarkeitstools ist eine Teilmenge der verfügbaren Tools aktiviert.
Skalierbares eingeschränktes Basislinienprofil (83 mit Einschränkungssatz 5)
Eine Teilmenge des Scalable Baseline Profile, die hauptsächlich für Echtzeit-Kommunikationsanwendungen gedacht ist.
Skalierbares High-Profile (86)
Dieses Profil ist in erster Linie auf Broadcast- und Streaming-Anwendungen ausgerichtet und baut auf dem H.264/AVC High Profile auf, dem die Basisschicht entsprechen muss.
Skalierbares eingeschränktes hohes Profil (86 mit Einschränkungssatz 5)
Eine Teilmenge des Scalable High Profile, die hauptsächlich für Echtzeitkommunikationsanwendungen gedacht ist.
Skalierbares hohes Intra-Profil (86 mit Einschränkungssatz 3)
Dieses Profil zielt hauptsächlich auf Produktionsanwendungen ab und ist das skalierbare High-Profile, das auf die Verwendung im gesamten Intra-Bereich beschränkt ist.

Aufgrund der Erweiterung Multiview Video Coding (MVC) enthält der Standard zwei Multiview-Profile :

Stereo-High-Profile (128)
Dieses Profil zielt auf stereoskopisches 3D-Video mit zwei Ansichten ab und kombiniert die Tools des High-Profils mit den Inter-View-Vorhersagefunktionen der MVC-Erweiterung.
Multiview-High-Profile (118)
Dieses Profil unterstützt zwei oder mehr Ansichten, die sowohl Inter-Picture (temporal) als auch MVC-Inter-View-Vorhersage verwenden, unterstützt jedoch keine Halbbildbilder und Makroblock-adaptive Vollbild-Halbbild-Codierung.

Die Multi-Resolution Frame-Compatible (MFC)-Erweiterung fügte zwei weitere Profile hinzu:

MFC-High-Profile (134)
Ein Profil für die stereoskopische Codierung mit zweischichtiger Auflösungsverbesserung.
MFC-Tiefe mit hohem Profil (135)

Die 3D-AVC-Erweiterung fügte zwei weitere Profile hinzu:

Multiview-Tiefe High Profile (138)
Dieses Profil unterstützt die gemeinsame Codierung von Tiefenkarten- und Videotexturinformationen für eine verbesserte Komprimierung von 3D-Videoinhalten.
Verbesserte Multiview-Tiefe High Profile (139)
Ein verbessertes Profil für kombinierte Multiview-Codierung mit Tiefeninformationen.

Funktionsunterstützung in bestimmten Profilen

Besonderheit CBP BP XP MP ProHiP Hüfte Hi10P Hi422P Hi444PP
I- und P-Scheiben Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl
Bittiefe (pro Sample) 8 8 8 8 8 8 8 bis 10 8 bis 10 8 bis 14
Chroma- Formate 4:2:0

 
4:2:0

 
4:2:0

 
4:2:0

 
4:2:0

 
4:2:0

 
4:2:0

 
4:2:0/
4:2:2
 
4:2:0/
4:2:2/
4:4:4
Flexible Makroblockbestellung (FMO) Nein Jawohl Jawohl Nein Nein Nein Nein Nein Nein
Beliebige Slice-Anordnung (ASO) Nein Jawohl Jawohl Nein Nein Nein Nein Nein Nein
Redundante Scheiben (RS) Nein Jawohl Jawohl Nein Nein Nein Nein Nein Nein
Datenpartitionierung Nein Nein Jawohl Nein Nein Nein Nein Nein Nein
SI- und SP-Scheiben Nein Nein Jawohl Nein Nein Nein Nein Nein Nein
Interlaced-Codierung (PicAFF, MBAFF) Nein Nein Jawohl Jawohl Nein Jawohl Jawohl Jawohl Jawohl
B-Scheiben Nein Nein Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl
Mehrere Referenzrahmen Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl
In-Loop-Deblocking-Filter Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl
CAVLC-Entropiecodierung Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl
CABAC-Entropiecodierung Nein Nein Nein Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl
4:0:0 ( Monochrom ) Nein Nein Nein Nein Jawohl Jawohl Jawohl Jawohl Jawohl
8×8 vs. 4×4 Transformationsanpassung Nein Nein Nein Nein Jawohl Jawohl Jawohl Jawohl Jawohl
Quantisierungsskalierungsmatrizen Nein Nein Nein Nein Jawohl Jawohl Jawohl Jawohl Jawohl
Separate C B- und C R- QP-Steuerung Nein Nein Nein Nein Jawohl Jawohl Jawohl Jawohl Jawohl
Separate Farbebenencodierung Nein Nein Nein Nein Nein Nein Nein Nein Jawohl
Prädiktive verlustfreie Codierung Nein Nein Nein Nein Nein Nein Nein Nein Jawohl

Ebenen

Wie der Begriff im Standard verwendet wird, ist ein " Level " ein spezifizierter Satz von Beschränkungen, die einen Grad der erforderlichen Decoderleistung für ein Profil angeben. Beispielsweise gibt eine Unterstützungsstufe innerhalb eines Profils die maximale Bildauflösung, Bildrate und Bitrate an, die ein Decoder verwenden kann. Ein Decoder, der einer gegebenen Ebene entspricht, muss in der Lage sein, alle Bitströme zu decodieren, die für diese Ebene und alle niedrigeren Ebenen codiert sind.

Ebenen mit maximalen Eigenschaftswerten
Niveau
Maximale
Dekodierungsgeschwindigkeit
(Makroblöcke/s)
Maximale
Framegröße
(Makroblöcke)
Maximale
Videobitrate für
Videocodierschicht (VCL)
(Constrained Baseline,
Baseline, Extended
und Main Profile)
(kbits/s)
Beispiele für hohe Auflösung
bei höchster Bildrate
(maximal gespeicherte Bilder)
Weitere Details umschalten

1 1.485 99 64
128×96@30,9 (8)
176×144@15,0 (4)
1b 1.485 99 128
128×96@30,9 (8)
176×144@15,0 (4)
1.1 3.000 396 192
176
× 144 @ 30,3 (9) 320 × 240 @ 10,0 (3)
352×288@7,5 (2)
1,2 6.000 396 384
320×240@20.0 (7)
352×288@15,2 (6)
1.3 11.880 396 768
320×240@36,0 (7)
352×288@30.0 (6)
2 11.880 396 2.000
320×240@36,0 (7)
352×288@30.0 (6)
2.1 19.800 792 4.000
352×480@30.0 (7)
352×576@25,0 (6)
2.2 20.250 1.620 4.000
352
× 480 @ 30,7 (12) 352 × 576 @ 25,6 (10)
720 × 480 @ 15,0 (6)
720×576@12,5 (5)
3 40.500 1.620 10.000
352
× 480 @ 61,4 (12) 352 × 576 @ 51,1 (10)
720 × 480 @ 30,0 (6)
720×576@25,0 (5)
3.1 108.000 3.600 14.000
720
× 480 @ 80,0 (13) 720 × 576 @ 66,7 (11)
1.280×720@30,0 (5)
3.2 216.000 5.120 20.000
1.280×720@60,0 (5)
1.280×1.024@42,2 (4)
4 245.760 8.192 20.000
1.280×720@68,3 (9)
1.920×1.080@30,1 (4)
2.048×1.024@30,0 (4)
4.1 245.760 8.192 50.000
1.280×720@68,3 (9)
1.920×1.080@30,1 (4)
2.048×1.024@30,0 (4)
4.2 522.240 8.704 50.000
1.280 × 720 @ 145,1 (9)
1.920 × 1.080 @ 64,0 (4)
2.048×1.080@60,0 (4)
5 589.824 22.080 135.000
1.920×1.080@72,3 (13)
2.048×1.024@72,0 (13)
2.048×1.080@67,8 (12)
2.560×1.920@30,7 (5)
3.672×1.536@26,7 (5)
5.1 983.040 36.864 240.000
1.920×1.080@120,5 (16)
2.560×1.920@51,2 (9)
3.840×2.160@31,7 (5)
4.096×2.048@30,0 (5)
4.096×2.160@28,5 (5)
4.096×2.304@26,7 (5)
5.2 2.073.600 36.864 240.000
1.920×1.080@172,0 (16)
2.560×1.920@108,0 (9)
3.840×2.160@66,8 (5)
4.096×2.048@63,3 (5)
4.096×2.160@60,0 (5)
4.096×2.304@56,3 (5)
6 4.177.920 139.264 240.000
3.840 × 2.160 @ 128,9 (16)
7.680 × 4.320 @ 32,2 (5)
8.192×4.320@30,2 (5)
6.1 8.355.840 139.264 480.000
3.840×2.160@257,9 (16)
7.680×4.320@64,5 (5)
8.192×4.320@60,4 (5)
6.2 16.711.680 139.264 800.000
3.840×2.160@300,0 (16)
7.680×4.320@128,9 (5)
8.192×4.320@120,9 (5)

Die maximale Bitrate für das High Profile beträgt das 1,25-fache der von Constrained Baseline, Baseline, Extended und Main Profile; 3-mal für Hi10P und 4-mal für Hi422P/Hi444PP.

Die Anzahl der Luma-Abtastwerte beträgt 16 × 16 = das 256-fache der Anzahl der Makroblöcke (und die Anzahl der Luma-Abtastwerte pro Sekunde beträgt das 256-fache der Anzahl der Makroblöcke pro Sekunde).

Dekodierte Bildpufferung

Zuvor codierte Bilder werden von H.264/AVC-Codierern verwendet, um Vorhersagen der Werte von Samples in anderen Bildern zu liefern. Dies ermöglicht es dem Codierer, effiziente Entscheidungen über die beste Art und Weise zu treffen, ein gegebenes Bild zu codieren. Beim Decoder werden solche Bilder in einem virtuellen Puffer für decodierte Bilder (DPB) gespeichert . Die maximale Kapazität des DPB, in Einheiten von Frames (oder Paaren von Feldern), wie in Klammern in der rechten Spalte der obigen Tabelle angegeben, kann wie folgt berechnet werden:

DpbCapacity = min(floor( MaxDpbMbs / ( PicWidthInMbs * FrameHeightInMbs )), 16)

Wobei MaxDpbMbs ein konstanter Wert ist, der in der folgenden Tabelle als Funktion der Ebenennummer angegeben ist , und PicWidthInMbs und FrameHeightInMbs die Bildbreite und Framehöhe für die codierten Videodaten sind, ausgedrückt in Einheiten von Makroblöcken (auf Ganzzahlwerte aufgerundet und Beschneidung berücksichtigt). und Makroblock-Paarung, falls zutreffend). Diese Formel ist in den Abschnitten A.3.1.h und A.3.2.f der Ausgabe 2017 der Norm spezifiziert.

Niveau
1
1b
1.1
1,2
1.3
2
2.1
2.2
3
3.1
3.2
4
4.1
4.2
5
5.1
5.2
6
6.1
6.2
MaxDpbMbs
396
396
900
2.376
2.376
2.376
4.752
8.100
8.100
18.000
20.480
32.768
32.768
34.816
110.400
184.320
184.320
696.320
696.320
696.320

Für ein HDTV-Bild mit einer Breite von 1.920 Samples (PicWidthInMbs = 120) und einer Höhe von 1.080 Samples (FrameHeightInMbs = 68) hat ein Level-4-Decoder beispielsweise eine maximale DPB-Speicherkapazität von floor(32768/(120*68)) = 4 Rahmen (oder 8 Felder). So wird in der obigen Tabelle in der rechten Spalte der Zeile für Level 4 mit der Bildgröße 1920×1080 der Wert 4 in Klammern angezeigt.

Es ist wichtig zu beachten, dass das aktuell decodierte Bild nicht in die Berechnung der DPB-Fülle eingeht (es sei denn, der Codierer hat angegeben, dass es als Referenz zum Decodieren anderer Bilder oder für verzögertes Ausgabetiming gespeichert werden soll). Somit muss ein Decoder tatsächlich über ausreichend Speicher verfügen, um (mindestens) einen Frame mehr als die oben berechnete maximale Kapazität des DPB zu verarbeiten.

Implementierungen

Im Jahr 2009 wurde die HTML5-Arbeitsgruppe zwischen Anhängern von Ogg Theora , einem freien Videoformat, von dem angenommen wird, dass es nicht durch Patente belastet ist, und H.264, das eine patentierte Technologie enthält, aufgeteilt. Noch im Juli 2009 wurde gesagt, dass Google und Apple H.264 unterstützen, während Mozilla und Opera Ogg Theora unterstützen (jetzt unterstützen Google, Mozilla und Opera alle Theora und WebM mit VP8 ). Microsoft hat mit der Veröffentlichung von Internet Explorer 9 Unterstützung für HTML-5-Video hinzugefügt, das mit H.264 codiert ist. Auf dem Gartner Symposium/ITXpo im November 2010 beantwortete Microsoft-CEO Steve Ballmer die Frage "HTML 5 oder Silverlight ?" indem Sie sagen: "Wenn Sie etwas Universelles tun möchten, steht die Welt außer Frage auf HTML5." Im Januar 2011 gab Google bekannt, dass sie die Unterstützung für H.264 aus ihrem Chrome-Browser ziehen und sowohl Theora als auch WebM / VP8 unterstützen , um nur offene Formate zu verwenden.

Am 18. März 2012 kündigte Mozilla die Unterstützung von H.264 in Firefox auf Mobilgeräten aufgrund der Verbreitung von H.264-codierten Videos und der erhöhten Energieeffizienz durch die Verwendung dedizierter H.264-Decoder-Hardware an, die auf solchen Geräten üblich ist. Am 20. Februar 2013 hat Mozilla in Firefox die Unterstützung für die Dekodierung von H.264 unter Windows 7 und höher implementiert. Diese Funktion basiert auf den integrierten Decodierungsbibliotheken von Windows. Firefox 35.0, veröffentlicht am 13. Januar 2015, unterstützt H.264 unter OS X 10.6 und höher.

Am 30. Oktober 2013 kündigte Rowan Trollope von Cisco Systems an, dass Cisco sowohl Binärdateien als auch den Quellcode eines H.264-Videocodecs namens OpenH264 unter der vereinfachten BSD-Lizenz veröffentlichen und alle Lizenzgebühren für seine Nutzung an MPEG LA für alle Softwareprojekte zahlen wird die Ciscos vorkompilierte Binärdateien verwenden, wodurch die OpenH264- Binärdateien von Cisco kostenlos verwendet werden können. Alle Softwareprojekte, die den Quellcode von Cisco anstelle der Binärdateien verwenden, wären jedoch rechtlich dafür verantwortlich, alle Lizenzgebühren an MPEG LA zu zahlen. Ziel-CPU-Architekturen umfassen x86 und ARM, und Zielbetriebssysteme umfassen Linux, Windows XP und höher, Mac OS X und Android; iOS fehlte in dieser Liste insbesondere, da es Anwendungen nicht erlaubt, Binärmodule aus dem Internet abzurufen und zu installieren. Ebenfalls am 30. Oktober 2013 schrieb Brendan Eich von Mozilla , dass es Ciscos Binärdateien in zukünftigen Versionen von Firefox verwenden würde, um Unterstützung für H.264 zu Firefox hinzuzufügen, wo Plattform-Codecs nicht verfügbar sind. Cisco hat den Quellcode zu OpenH264 am 9. Dezember 2013 veröffentlicht.

Obwohl iOS von der Cisco-Softwareversion 2013 nicht unterstützt wurde, hat Apple sein Video Toolbox Framework mit iOS 8 (veröffentlicht im September 2014) aktualisiert , um direkten Zugriff auf hardwarebasierte H.264/AVC-Videocodierung und -decodierung zu ermöglichen.

Software-Encoder

AVC-Softwareimplementierungen
Besonderheit Schnelle Zeit Nero OpenH264 x264 Main-
Konzept
Elecard  TSE  Pro-
Coder
Avivo Elementar  IPP 
B-Scheiben Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Nein Jawohl Jawohl
Mehrere Referenzrahmen Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Nein Jawohl Jawohl
Interlaced-Codierung (PicAFF, MBAFF) Nein MBAFF MBAFF MBAFF Jawohl Jawohl Nein Jawohl MBAFF Jawohl Nein
CABAC-Entropiecodierung Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Nein Jawohl Jawohl
8×8 vs. 4×4 Transformationsanpassung Nein Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Jawohl Nein Jawohl Jawohl
Quantisierungsskalierungsmatrizen Nein Nein Jawohl Jawohl Jawohl Nein Nein Nein Nein Nein Nein
Separate C B- und C R- QP-Steuerung Nein Nein Jawohl Jawohl Jawohl Jawohl Nein Nein Nein Nein Nein
Erweiterte Chroma-Formate Nein Nein Nein 4:0:0
4:2:0
4:2:2
4:4:4  
4:2:2 4:2:2 4:2:2 Nein Nein 4:2:0
4:2:2
Nein
Größte Sample-Tiefe (Bit) 8 8 8 10 10 8 8 8 8 10 12
Prädiktive verlustfreie Codierung Nein Nein Nein Jawohl Nein Nein Nein Nein Nein Nein Nein

Hardware

Da die H.264-Kodierung und -Dekodierung bei bestimmten Arten von arithmetischen Operationen erhebliche Rechenleistung erfordert, sind Softwareimplementierungen, die auf Allzweck-CPUs ausgeführt werden, in der Regel weniger energieeffizient. Die neuesten Quad-Core-Allzweck-x86-CPUs verfügen jedoch über ausreichend Rechenleistung, um SD- und HD-Encoding in Echtzeit durchzuführen. Die Komprimierungseffizienz hängt von den Implementierungen des Videoalgorithmus ab, nicht davon, ob eine Hardware- oder Softwareimplementierung verwendet wird. Daher liegt der Unterschied zwischen hardware- und softwarebasierter Implementierung eher in Energieeffizienz, Flexibilität und Kosten. Um die Leistungseffizienz zu verbessern und den Hardware-Formfaktor zu reduzieren, kann Spezialhardware verwendet werden, entweder für den vollständigen Kodierungs- oder Dekodierungsvorgang oder zur Beschleunigungsunterstützung innerhalb einer CPU-gesteuerten Umgebung.

CPU-basierte Lösungen sind bekanntermaßen viel flexibler, insbesondere wenn die Codierung gleichzeitig in mehreren Formaten, mehreren Bitraten und Auflösungen ( Multi-Screen-Video ) und möglicherweise mit zusätzlichen Funktionen zur Unterstützung von Containerformaten, erweiterten integrierten Werbefunktionen usw Eine CPU-basierte Softwarelösung erleichtert im Allgemeinen die Lastverteilung mehrerer gleichzeitiger Codierungssitzungen innerhalb derselben CPU.

Die auf der CES ( Consumer Electronics Show ) im Januar 2011 vorgestellten Intel " Sandy Bridge " Core i3/i5/i7- Prozessoren der zweiten Generation bieten einen integrierten Hardware-Full-HD-H.264-Encoder, der als Intel Quick Sync Video bekannt ist .

Ein Hardware-H.264-Encoder kann ein ASIC oder ein FPGA sein .

ASIC-Encoder mit H.264-Encoder-Funktionalität sind von vielen verschiedenen Halbleiterunternehmen erhältlich, aber das im ASIC verwendete Kerndesign wird normalerweise von einem der wenigen Unternehmen wie Chips&Media , Allegro DVT, On2 (ehemals Hantro, erworben von Google) lizenziert. Imaginationstechnologien , NGCodec. Einige Unternehmen bieten sowohl FPGA- als auch ASIC-Produktangebote an.

Texas Instruments stellt eine Reihe von ARM + DSP-Kernen her, die eine DSP H.264 BP-Codierung von 1080p bei 30 fps ausführen. Dies ermöglicht Flexibilität in Bezug auf Codecs (die als hochoptimierter DSP-Code implementiert sind) und ist gleichzeitig effizienter als Software auf einer generischen CPU.

Lizenzierung

In Ländern, in denen Patente auf Softwarealgorithmen aufrechterhalten werden, wird von Anbietern und gewerblichen Nutzern von Produkten, die H.264/AVC verwenden, erwartet, dass sie Lizenzgebühren für die patentierte Technologie ihrer Produkte zahlen. Dies gilt auch für das Baseline-Profil.

Eine private Organisation namens MPEG LA , die in keiner Weise mit der MPEG-Standardisierungsorganisation verbunden ist, verwaltet die Lizenzen für Patente, die sich auf diesen Standard beziehen, sowie andere Patentpools , wie zum Beispiel für MPEG-4 Part 2 Video, HEVC und MPEG-DASH. Zu den Patentinhabern gehören Fujitsu , Panasonic , Sony , Mitsubishi , Apple , Columbia University , KAIST , Dolby , Google , JVC Kenwood , LG Electronics , Microsoft , NTT Docomo , Philips , Samsung , Sharp , Toshiba und ZTE , obwohl die Mehrheit der Patente in der Pool wird von Panasonic (1.197 Patente), Godo Kaisha IP Bridge (1.130 Patente) und LG Electronics (990 Patente) gehalten.

Am 26. August 2010 gab MPEG LA bekannt, dass für H.264-codierte Internetvideos, die für Endbenutzer kostenlos sind, keine Lizenzgebühren erhoben werden. Alle anderen Lizenzgebühren bleiben bestehen, wie etwa Lizenzgebühren für Produkte, die H.264-Videos dekodieren und kodieren, sowie an Betreiber von kostenlosen Fernseh- und Abonnementkanälen. Die Lizenzbedingungen werden in 5-Jahres-Blöcken aktualisiert.

Da die erste Version des Standards im Mai 2003 fertiggestellt wurde (vor 18 Jahren) und das am häufigsten verwendete Profil (das High Profile) wurde im Juni 2004 fertiggestellt (vor 17 Jahren) ist eine beträchtliche Anzahl der ursprünglich auf den Standard angewendeten Patente ausgelaufen, obwohl eines der US-Patente im MPEG LA H.264-Pool mindestens bis 2027 gilt.

2005 verklagte Qualcomm Broadcom vor dem US-Bezirksgericht und behauptete, Broadcom habe zwei seiner Patente verletzt, indem es Produkte herstellte, die dem Videokomprimierungsstandard H.264 entsprachen. Im Jahr 2007 stellte das Bezirksgericht fest, dass die Patente nicht durchsetzbar waren, da Qualcomm sie vor der Veröffentlichung des H.264-Standards im Mai 2003 dem JVT nicht offengelegt hatte. Im Dezember 2008 bestätigte das US-Berufungsgericht für den Bundesbezirk die Entscheidung des Bezirksgerichts, dass die Patente nicht durchsetzbar sind, aber an das Bezirksgericht zurückverwiesen wird, mit der Anweisung, den Umfang der Nichtdurchsetzbarkeit auf H.264-konforme Produkte zu beschränken.

Siehe auch

Verweise

Weiterlesen

Externe Links