H.264

Aus besserwiki.de
Fortgeschrittene Videokodierung / H.264 / MPEG-4 Teil 10 ⓘ
Fortgeschrittene Videocodierung für allgemeine audiovisuelle Dienste
H.264, MPEG-4 AVC logo.svg
StatusIn Kraft
Jahr begonnen2003
Erstmals veröffentlicht17. August 2004
Letzte Fassung14.0
22. August 2021
OrganisationITU-T, ISO, IEC
AusschussSG16 (VCEG), MPEG
Grundlegende NormenH.261, H.262 (auch bekannt als MPEG-2 Video), H.263, MPEG-1
Verwandte StandardsH.265 (auch bekannt als HEVC), H.266 (auch bekannt als VVC)
BereichVideo-Kompression
LizenzMPEG LA
Websitehttps://www.itu.int/rec/T-REC-H.264
Blockdiagramm der Videocodierungsschicht des H.264-Encoders mit Bewertung der Wahrnehmungsqualität ⓘ

Advanced Video Coding (AVC), auch als H.264 oder MPEG-4 Part 10 bezeichnet, ist ein Videokompressionsstandard, der auf einer blockorientierten, bewegungskompensierten Kodierung basiert. Es ist das mit Abstand am häufigsten verwendete Format für die Aufzeichnung, Komprimierung und Verteilung von Videoinhalten und wird von 91 % der Entwickler in der Videobranche verwendet (Stand: September 2019). Es unterstützt Auflösungen bis zu und einschließlich 8K UHD. ⓘ

Ziel des H.264/AVC-Projekts war es, einen Standard zu schaffen, der eine gute Videoqualität bei wesentlich niedrigeren Bitraten als frühere Standards bietet (d. h. die Hälfte oder weniger der Bitrate von MPEG-2, H.263 oder MPEG-4 Part 2), ohne die Komplexität des Designs so stark zu erhöhen, dass es unpraktisch oder übermäßig teuer in der Umsetzung wäre. Erreicht wurde dies durch Funktionen wie eine komplexitätsreduzierte ganzzahlige diskrete Kosinustransformation (Integer DCT), Segmentierung mit variabler Blockgröße und Vorhersage zwischen mehreren Bildern. Ein weiteres Ziel war es, den Standard so flexibel zu gestalten, dass er für eine Vielzahl von Anwendungen in einer Vielzahl von Netzwerken und Systemen eingesetzt werden kann, darunter niedrige und hohe Bitraten, niedrig- und hochauflösendes Video, Rundfunk, DVD-Speicherung, RTP/IP-Paketnetzwerke und ITU-T-Multimedia-Telefoniesysteme. Der H.264-Standard kann als eine "Familie von Standards" betrachtet werden, die aus einer Reihe verschiedener Profile besteht, wobei das "High-Profil" bei weitem das am häufigsten verwendete Format ist. Ein bestimmter Decoder dekodiert mindestens eines, aber nicht unbedingt alle Profile. Die Norm beschreibt das Format der kodierten Daten und wie die Daten dekodiert werden, aber sie legt keine Algorithmen für die Kodierung von Videos fest - dies bleibt den Entwicklern von Kodierern überlassen, die eine Vielzahl von Kodierverfahren entwickelt haben. H.264 wird in der Regel für verlustbehaftete Kompression verwendet, obwohl es auch möglich ist, wirklich verlustfrei kodierte Regionen innerhalb verlustbehafteter Bilder 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 unter der Bezeichnung Joint Video Team (JVT) bekannt. Der ITU-T H.264-Standard und der ISO/IEC MPEG-4 AVC-Standard (formell ISO/IEC 14496-10 - MPEG-4 Part 10, Advanced Video Coding) werden gemeinsam gepflegt, so dass sie den gleichen technischen Inhalt haben. Die endgültige Ausarbeitung der ersten Version der Norm wurde im Mai 2003 abgeschlossen, und in den nachfolgenden Ausgaben wurden verschiedene Erweiterungen der Funktionen 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, der von denselben Organisationen entwickelt wurde, während die früheren Standards noch immer in Gebrauch sind. ⓘ

H.264 ist vielleicht am bekanntesten als das am häufigsten verwendete Videocodierungsformat auf Blu-ray Discs. Es wird auch häufig von Streaming-Internetquellen verwendet, z. B. von Videos von Netflix, Hulu, Amazon Prime Video, Vimeo, YouTube und dem iTunes Store, von Web-Software wie dem Adobe Flash Player und Microsoft Silverlight sowie von verschiedenen HDTV-Übertragungen über terrestrische (ATSC, ISDB-T, DVB-T oder DVB-T2), Kabel- (DVB-C) und Satelliten-Systeme (DVB-S und DVB-S2). ⓘ

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

Die kommerzielle Nutzung der patentierten 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 Streaming von Internet-Videos erlaubt, die für Endnutzer kostenlos sind, und Cisco Systems zahlt im Namen der Nutzer von Binärdateien für seinen Open-Source-H.264-Encoder Lizenzgebühren an MPEG LA. ⓘ

H.264 erreicht typischerweise eine etwa dreimal so hohe Codiereffizienz wie H.262 (MPEG-2) und ist wie auch H.262 für hoch aufgelöste Bilddaten (z. B. HDTV) ausgelegt. Das heißt, vergleichbare Qualität ist bei etwa einem Drittel der MPEG-2-Datenmenge zu erreichen. Allerdings ist der Rechenaufwand auch um den Faktor 2 bis 3 höher. ⓘ

Die für den Standard benutzten FourCCs sind „AVC1“, „DAVC“, „H264“, „x264“ und „VSSH“. Die Matroska-Codec-ID lautet „V_MPEG4/ISO/AVC“. ⓘ

Das standardisierte Dateiformat/Containerformat ist MP4. ⓘ

Namensgebung

Der Name H.264 folgt der ITU-T-Namenskonvention, da der Standard zur H.26x-Reihe der VCEG-Videocodierungsstandards gehört. Der Name MPEG-4 AVC bezieht sich auf die Namenskonvention in ISO/IEC MPEG, wo der Standard Teil 10 von ISO/IEC 14496 ist, der die als MPEG-4 bekannte Normenreihe darstellt. Der Standard wurde gemeinsam in einer Partnerschaft von VCEG und MPEG entwickelt, nachdem er zuvor in der ITU-T als VCEG-Projekt mit der Bezeichnung H.26L entwickelt worden war. Es ist daher üblich, den Standard mit Namen wie H.264/AVC, AVC/H.264, H.264/MPEG-4 AVC oder MPEG-4/H.264 AVC zu bezeichnen, um das gemeinsame Erbe zu betonen. Gelegentlich wird er auch als "der JVT-Codec" bezeichnet, in Anspielung auf die Organisation Joint Video Team (JVT), die ihn entwickelt hat. (Solche Partnerschaften und Mehrfachbenennungen sind nicht unüblich. So ist beispielsweise der Videokompressionsstandard MPEG-2 ebenfalls aus der Partnerschaft zwischen MPEG und der ITU-T hervorgegangen, wobei MPEG-2-Video in der ITU-T-Gemeinschaft als H.262 bekannt ist). Einige Softwareprogramme (z. B. der VLC Media Player) bezeichnen diesen Standard intern als AVC1. ⓘ

Geschichte

Allgemeine Geschichte

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 Kodiereffizienz (d. h. die Halbierung der für ein bestimmtes Maß an Wiedergabetreue erforderlichen Bitrate) im Vergleich zu allen anderen bestehenden Videokodierungsstandards für eine Vielzahl von Anwendungen zu verdoppeln. Den Vorsitz der VCEG hatte Gary Sullivan (Microsoft, ehemals PictureTel, USA) inne. Der erste Entwurf für diese neue Norm wurde im August 1999 angenommen. Im Jahr 2000 wurde Thomas Wiegand (Heinrich-Hertz-Institut, Deutschland) Ko-Vorsitzender der VCEG. ⓘ

Im Dezember 2001 bildeten die VCEG und die Moving Picture Experts Group (MPEG - ISO/IEC JTC 1/SC 29/WG 11) ein Joint Video Team (JVT), das die Aufgabe hatte, die Videocodierungsnorm fertig zu stellen. Die formelle Genehmigung der Spezifikation erfolgte im März 2003. Das JVT wurde (und wird) von Gary Sullivan, Thomas Wiegand und Ajay Luthra (Motorola, USA; später Arris, USA) geleitet. 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 Anhang (G) namens Scalable Video Coding (SVC). Das JVT-Leitungsteam wurde durch 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 in Richtung 3D-Fernsehen und Free-Viewpoint-Fernsehen mit begrenzter Reichweite. Diese Arbeit umfasste die Entwicklung von zwei neuen Profilen des Standards: das Multiview High Profile und das Stereo High Profile. ⓘ

Im Laufe der Entwicklung des Standards wurden zusätzliche Nachrichten entwickelt, die ergänzende Erweiterungsinformationen (SEI) enthalten. SEI-Nachrichten können verschiedene Arten von Daten enthalten, die das Timing der Videobilder angeben oder verschiedene Eigenschaften des kodierten Videos beschreiben oder wie es verwendet oder verbessert werden kann. Es wurden auch SEI-Nachrichten definiert, die beliebige benutzerdefinierte Daten enthalten können. SEI-Meldungen haben keinen Einfluss auf den eigentlichen Dekodierungsprozess, können aber angeben, wie das Video nachbearbeitet oder angezeigt werden sollte. Einige andere hochrangige Eigenschaften des Videoinhalts werden in Video-Usability-Informationen (VUI) übermittelt, wie z. B. die Angabe des Farbraums für die Interpretation des Videoinhalts. Da neue Farbräume entwickelt wurden, z. B. für Videos mit hohem Dynamikbereich und großem Farbumfang, wurden zusätzliche VUI-Kennungen hinzugefügt, um diese anzugeben. ⓘ

Erweiterungen der Farbtreue und professionelle Profile

Die Standardisierung der ersten Version von H.264/AVC wurde im Mai 2003 abgeschlossen. Im Rahmen des ersten Projekts zur Erweiterung des ursprünglichen Standards entwickelte das JVT die so genannten Fidelity Range Extensions (FRExt). Diese Erweiterungen ermöglichten eine qualitativ hochwertigere Videocodierung durch Unterstützung einer höheren Präzision der Abtastbittiefe und höher aufgelöster Farbinformationen, einschließlich der als Y′CBCR 4:2:2 (auch bekannt als YUV 4:2:2) und 4:4:4 bekannten Abtaststrukturen. Das FRExt-Projekt umfasste auch einige andere Funktionen, wie die Hinzufügung einer ganzzahligen diskreten Cosinus-Transformation (Integer DCT) mit adaptiver Umschaltung zwischen der 4×4- und der 8×8-Transformation, vom Encoder spezifizierte Quantisierungsgewichtungsmatrizen auf Wahrnehmungsbasis, effiziente verlustfreie Kodierung zwischen Bildern und Unterstützung zusätzlicher Farbräume. Die Entwurfsarbeiten für das FRExt-Projekt wurden im Juli 2004 abgeschlossen, und die Ausarbeitung der Profile wurde im September 2004 abgeschlossen. ⓘ

Fünf weitere neue Profile (siehe Version 7 unten), die in erster Linie für professionelle Anwendungen bestimmt sind, wurden entwickelt. Sie unterstützen den erweiterten Gamut-Farbraum, definieren zusätzliche Bildseitenverhältnis-Indikatoren, definieren zwei zusätzliche Arten von "ergänzenden Verbesserungsinformationen" (Post-Filter-Hinweis und Tone Mapping) und verwerfen eines der früheren FRExt-Profile (das Profil High 4:4:4), das nach Rückmeldungen aus der Branche anders hätte gestaltet werden sollen. ⓘ

Skalierbare Videocodierung

Die nächste wichtige Funktion, die dem Standard hinzugefügt wurde, war Scalable Video Coding (SVC). SVC ist in Anhang G von H.264/AVC spezifiziert und ermöglicht die Konstruktion von Bitströmen, die Schichten von Sub-Bitströmen enthalten, die ebenfalls dem Standard entsprechen, einschließlich eines solchen Bitstroms, der als "Basisschicht" bezeichnet wird und von einem H.264/AVC-Codec dekodiert werden kann, der SVC nicht unterstützt. Für die zeitliche Skalierbarkeit des Bitstroms (d. h. das Vorhandensein eines Sub-Bitstroms mit einer geringeren zeitlichen Abtastrate als der Haupt-Bitstrom) werden bei der Ableitung des Sub-Bitstroms vollständige Zugriffseinheiten aus dem Bitstrom entfernt. In diesem Fall werden die High-Level-Syntax und die Inter-Prediction-Referenzbilder im Bitstrom entsprechend konstruiert. Andererseits wird für die räumliche und qualitative Skalierbarkeit des Bitstroms (d. h. das Vorhandensein eines Teilbitstroms mit geringerer räumlicher Auflösung/Qualität als der Hauptbitstrom) bei der Ableitung des Teilbitstroms die NAL (Network Abstraction Layer) aus dem Bitstrom entfernt. In diesem Fall wird in der Regel die schichtenübergreifende Vorhersage (d. h. 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) für eine effiziente Codierung verwendet. Die Erweiterungen der skalierbaren Videokodierung wurden im November 2007 abgeschlossen. ⓘ

Multiview-Videocodierung

Die nächste wichtige Funktion, die dem Standard hinzugefügt wurde, war die Multiview-Videocodierung (MVC). MVC ist in Anhang H von H.264/AVC beschrieben und ermöglicht die Erstellung von Bitströmen, die mehr als eine Ansicht einer Videoszene darstellen. Ein wichtiges Beispiel für diese Funktionalität ist die stereoskopische 3D-Videocodierung. Im Rahmen der MVC-Arbeiten wurden zwei Profile entwickelt: Das Profil Multiview High unterstützt eine beliebige Anzahl von Ansichten, und das Profil Stereo High ist speziell für stereoskopische Videos mit zwei Ansichten konzipiert. Die Erweiterungen für Multiview Video Coding wurden im November 2009 abgeschlossen. ⓘ

3D-AVC und stereoskopische MFC-Kodierung

Später wurden zusätzliche Erweiterungen entwickelt, die 3D-Videocodierung mit gemeinsamer Codierung von Tiefenkarten und Textur (3D-AVC), stereoskopische Codierung mit mehreren Auflösungsbildern (MFC) und 3D-MFC-Codierung, verschiedene zusätzliche Kombinationen von Funktionen sowie höhere Bildgrößen und Bildraten umfassen. ⓘ

Versionen

Zu den Versionen des H.264/AVC-Standards gehören die folgenden abgeschlossenen Überarbeitungen, Berichtigungen und Änderungen (die Daten sind die endgültigen Genehmigungsdaten bei der ITU-T, während die endgültigen Genehmigungsdaten für die "Internationale Norm" bei ISO/IEC etwas anders und in den meisten Fällen etwas später sind). Jede Version stellt Änderungen gegenüber der nächst niedrigeren Version dar, die in den Text integriert ist. ⓘ

  • Version 1 (Ausgabe 1): (30. Mai 2003) Erste genehmigte Version von H.264/AVC mit den Profilen Baseline, Main und Extended.
  • Version 2 (Ausgabe 1.1): (7. Mai 2004) Korrigendum mit verschiedenen kleineren Korrekturen.
  • Version 3 (Ausgabe 2): (1. März 2005) Wichtige Ergänzung mit der ersten Änderung, die die Fidelity Range Extensions (FRExt) einführt. Mit dieser Version wurden die Profile High, High 10, High 4:2:2 und High 4:4:4 hinzugefügt. Nach einigen Jahren wurde das Profil High zum am häufigsten verwendeten Profil der Norm.
  • Version 4 (Ausgabe 2.1): (13. September 2005) Korrigendum mit verschiedenen kleineren Korrekturen und Hinzufügung von drei Indikatoren für das Seitenverhältnis.
  • Version 5 (Ausgabe 2.2): (13. Juni 2006) Änderung, die aus der Entfernung des früheren Profils High 4:4:4 besteht (als Korrigendum in ISO/IEC bearbeitet).
  • Version 6 (Ausgabe 2.2): (13. Juni 2006) Änderung, bestehend aus kleineren Erweiterungen wie der Unterstützung des erweiterten Gamut-Farbraums (gebündelt mit den oben erwähnten Seitenverhältnis-Indikatoren in ISO/IEC).
  • Version 7 (Edition 2.3): (6. April 2007) Änderung, die das Profil High 4:4:4 Predictive und vier reine Intra-Profile (High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra und CAVLC 4:4:4 Intra) hinzufügt.
  • Version 8 (Ausgabe 3): (22. November 2007) Wichtige Ergänzung zu H.264/AVC mit der Änderung 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) Korrigendum mit kleineren Korrekturen.
  • Version 10 (Ausgabe 4): (16. März 2009) Änderung, die die Definition eines neuen Profils (das Constrained Baseline-Profil) enthält, das nur die gemeinsame Teilmenge der in verschiedenen zuvor spezifizierten Profilen unterstützten Fähigkeiten enthält.
  • Version 11 (Ausgabe 4): (16. März 2009) Wichtige Ergänzung zu H.264/AVC mit der Änderung für die Multiview Video Coding (MVC)-Erweiterung, einschließlich des Multiview High-Profils.
  • Version 12 (Ausgabe 5): (9. März 2010) Änderung, die die Definition eines neuen MVC-Profils (das Stereo High-Profil) für die Videocodierung in zwei Ansichten mit Unterstützung von Interlaced-Codierungstools enthält und eine zusätzliche SEI-Nachricht (Supplemental Enhancement Information) spezifiziert, die als SEI-Nachricht für die Bildpackungsanordnung bezeichnet wird.
  • Version 13 (Ausgabe 5): (9. März 2010) Korrigendum mit kleineren Korrekturen.
  • Version 14 (Ausgabe 6): (29. Juni 2011) Änderung zur Spezifizierung eines neuen Levels (Level 5.2), der höhere Verarbeitungsraten in Form von maximalen Makroblöcken pro Sekunde unterstützt, und eines neuen Profils (das Progressive High-Profil), das nur die Rahmenkodierungswerkzeuge des zuvor spezifizierten High-Profils unterstützt.
  • Version 15 (Ausgabe 6): (29. Juni 2011) Korrigendum mit kleineren Korrekturen.
  • Version 16 (Ausgabe 7): (13. Januar 2012) Änderung mit der Definition von drei neuen Profilen, die hauptsächlich für Echtzeit-Kommunikationsanwendungen gedacht sind: die Profile Constrained High, Scalable Constrained Baseline und Scalable Constrained High.
  • Version 17 (Ausgabe 8): (13. April 2013) Änderung mit zusätzlichen SEI-Nachrichtenindikatoren.
  • Version 18 (Ausgabe 8): (13. April 2013) Änderung, um die Kodierung von Tiefenkartendaten für stereoskopische 3D-Videos zu spezifizieren, einschließlich eines Multiview Depth High-Profils.
  • Version 19 (Ausgabe 8): (13. April 2013) Korrigendum zur Korrektur eines Fehlers im Sub-Bitstream-Extraktionsprozess für Multiview-Video.
  • Version 20 (Ausgabe 8): (13. April 2013) Änderung zur Angabe zusätzlicher Farbraum-Identifikatoren (einschließlich Unterstützung der ITU-R-Empfehlung BT.2020 für UHDTV) und eines zusätzlichen Modelltyps in der SEI-Nachricht für Tonemapping-Informationen.
  • Version 21 (Edition 9): (13. Februar 2014) Änderung zur Spezifikation des Profils Enhanced Multiview Depth High.
  • Version 22 (Ausgabe 9): (13. Februar 2014) Änderung zur Spezifizierung der MFC-Erweiterung (Multi-Resolution Frame Compatible) für stereoskopische 3D-Videos, des Profils MFC High und kleinere Korrekturen.
  • Version 23 (Ausgabe 10): (13. Februar 2016) Änderung zur Spezifizierung von MFC stereoskopischem Video mit Tiefenkarten, dem MFC Depth High-Profil, der SEI-Meldung für das Mastering-Display-Farbvolumen und zusätzlichen farbbezogenen VUI-Codepoint-Identifikatoren.
  • Version 24 (Edition 11): (14. Oktober 2016) Änderung zur Spezifizierung zusätzlicher Decoderfähigkeitsstufen, die größere Bildgrößen unterstützen (Stufen 6, 6.1 und 6.2), der SEI-Nachricht für grüne Metadaten, der SEI-Nachricht für alternative Tiefeninformationen und zusätzlicher farbbezogener VUI-Codepoint-Identifikatoren.
  • Version 25 (Edition 12): (13. April 2017) Änderung zur Spezifizierung des Profils Progressive High 10, Hybrid Log-Gamma (HLG) und zusätzlicher farbbezogener VUI-Codepunkte und SEI-Nachrichten.
  • Version 26 (Edition 13): (13. Juni 2019) Änderung zur Spezifikation zusätzlicher SEI-Nachrichten für die Umgebungsansicht, Informationen zum Lichtpegel des Inhalts, Farbvolumen des Inhalts, gleichwinklige Projektion, Kubemap-Projektion, Sphärendrehung, regionsweise Verpackung, omnidirektionales Ansichtsfenster, SEI-Manifest und SEI-Präfix.
  • Version 27 (Ausgabe 14): (22. August 2021) Änderung, um zusätzliche SEI-Meldungen für kommentierte Regionen und Verschlussintervallinformationen zu spezifizieren, sowie verschiedene kleinere Korrekturen und Klarstellungen. ⓘ

Patentinhaber

MPEG LA |} ⓘ

Anmeldungen

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-Übertragungen und digitalen Kinoanwendungen mit nahezu verlustfreier Kodierung. Bei der Verwendung von H.264 werden Bitrateneinsparungen von 50 % oder mehr im Vergleich zu MPEG-2 Teil 2 gemeldet. So wird beispielsweise berichtet, dass H.264 die gleiche Qualität des digitalen Satellitenfernsehens wie die aktuellen MPEG-2-Implementierungen mit weniger als der Hälfte der Bitrate liefert, wobei die aktuellen MPEG-2-Implementierungen mit etwa 3,5 Mbit/s und H.264 mit nur 1,5 Mbit/s arbeiten. Sony behauptet, dass der AVC-Aufnahmemodus mit 9 Mbit/s der Bildqualität des HDV-Formats entspricht, das etwa 18-25 Mbit/s verwendet. ⓘ

Um die Kompatibilität und problemlose Einführung von H.264/AVC zu gewährleisten, haben viele Normungsgremien ihre videorelevanten Normen geändert oder ergänzt, damit die Benutzer dieser Normen H.264/AVC verwenden können. Sowohl das Blu-ray Disc-Format als auch das inzwischen eingestellte HD DVD-Format enthalten das H.264/AVC High Profile als eines von drei obligatorischen Videokompressionsformaten. Das Digital Video Broadcast Projekt (DVB) genehmigte Ende 2004 die Verwendung von H.264/AVC für das Rundfunkfernsehen. ⓘ

Das US-amerikanische Normungsgremium Advanced Television Systems Committee (ATSC) genehmigte die Verwendung von H.264/AVC für das Rundfunkfernsehen im Juli 2008, obwohl der Standard noch nicht für feste ATSC-Übertragungen in den Vereinigten Staaten verwendet wird. Er wurde auch für den neueren ATSC-M/H-Standard (Mobile/Handheld) zugelassen, der die AVC- und SVC-Teile von H.264 verwendet. ⓘ

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

Viele gängige DSLRs verwenden H.264-Videos in QuickTime MOV-Containern als natives Aufnahmeformat. ⓘ

Abgeleitete Formate

AVCHD ist ein von Sony und Panasonic entwickeltes High-Definition-Aufnahmeformat, das H.264 verwendet (es entspricht H.264 und fügt zusätzliche anwendungsspezifische Funktionen und Einschränkungen hinzu). ⓘ

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

XAVC ist ein von Sony entwickeltes Aufnahmeformat, das die Stufe 5.2 von H.264/MPEG-4 AVC verwendet, die höchste von diesem Videostandard unterstützte Stufe. XAVC unterstützt eine 4K-Auflösung (4096 × 2160 und 3840 × 2160) mit bis zu 60 Bildern pro Sekunde (fps). 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 mit 300 Mbit/s und 2K-Auflösung bei 30 fps mit 100 Mbit/s aufzeichnen. XAVC kann 4K-Auflösung mit 60 fps mit 4:2:2 Chroma-Sampling bei 600 Mbit/s aufzeichnen. ⓘ

Gestaltung

Merkmale

Blockdiagramm von H.264 ⓘ

H.264/AVC/MPEG-4 Part 10 enthält eine Reihe neuer Funktionen, die eine wesentlich effizientere Videokomprimierung als ältere Standards ermöglichen und mehr Flexibilität für die Anwendung in einer Vielzahl von Netzwerkumgebungen bieten. Zu den wichtigsten Merkmalen gehören unter anderem:

  • Multi-Picture-Inter-Picture-Prediction mit den folgenden Merkmalen:
    • Verwendung von zuvor kodierten Bildern als Referenzen in einer viel flexibleren Art und Weise als in früheren Standards, so dass in einigen Fällen bis zu 16 Referenzrahmen (oder 32 Referenzfelder im Falle der Interlaced-Kodierung) verwendet werden können. In Profilen, die Nicht-IDR-Frames unterstützen, legen die meisten Stufen fest, dass ausreichend Puffer zur Verfügung stehen 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 in der Regel bei einem bzw. im Fall von herkömmlichen "B-Bildern" (B-Frames) bei zwei lag.
    • Variabler Blockgrößen-Bewegungsausgleich (VBSMC) mit Blockgrößen von 16×16 und 4×4, der eine präzise Segmentierung von sich bewegenden Regionen ermöglicht. Zu den unterstützten Luma-Prädiktionsblockgrößen gehören 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. Die Größe der Chroma-Vorhersageblöcke ist entsprechend kleiner, wenn Chroma-Subsampling verwendet wird.
    • Die Möglichkeit, mehrere Bewegungsvektoren pro Makroblock zu verwenden (einen oder zwei pro Partition), mit einem Maximum von 32 im Fall eines B-Makroblocks, der aus 16 4×4-Partitionen besteht. Die Bewegungsvektoren für jede 8×8 oder größere Partitionsregion können auf unterschiedliche Referenzbilder verweisen.
    • Die Möglichkeit, jeden Makroblocktyp in B-Frames zu verwenden, einschließlich I-Makroblocks, was zu einer wesentlich effizienteren Kodierung bei der Verwendung von B-Frames führt. Diese Funktion wurde bei MPEG-4 ASP nicht berücksichtigt.
    • Six-Tap-Filterung zur Ableitung von Halbpixel-Luma-Sample-Vorhersagen für eine schärfere Subpixel-Bewegungskompensation. Viertelpixel-Bewegungen werden durch lineare Interpolation der Halbpixelwerte abgeleitet, um Rechenleistung zu sparen.
    • Viertelpixel-Präzision für den Bewegungsausgleich, was eine genaue Beschreibung der Verschiebungen von sich bewegenden Bereichen ermöglicht. Bei Chroma wird die Auflösung in der Regel sowohl vertikal als auch horizontal halbiert (siehe 4:2:0), so dass für den Bewegungsausgleich von Chroma ein Achtel Chroma-Pixel-Rastereinheiten verwendet werden.
    • Gewichtete Vorhersage, die es einem Encoder ermöglicht, die Verwendung einer Skalierung und eines Offsets bei der Durchführung des Bewegungsausgleichs zu spezifizieren, und die in speziellen Fällen - wie z. B. bei Fade-to-Black-, Fade-In- und Cross-Fade-Übergängen - einen erheblichen Leistungsvorteil bietet. Dazu gehört die implizite gewichtete Vorhersage für B-Frames und die explizite gewichtete Vorhersage für P-Frames.
  • Räumliche Prädiktion aus den Kanten benachbarter Blöcke für "Intra"-Kodierung, anstelle der "DC"-Prädiktion in MPEG-2 Teil 2 und der Transformationskoeffizienten-Prädiktion in H.263v2 und MPEG-4 Teil 2. Dazu gehören Luma-Prädiktionsblöcke in den Größen 16×16, 8×8 und 4×4 (wobei in jedem Makroblock nur ein Typ verwendet werden kann).
  • Ganzzahlige diskrete Kosinustransformation (Integer DCT), eine Art der diskreten Kosinustransformation (DCT), bei der die Transformation eine ganzzahlige Annäherung an die Standard-DCT ist. Sie verfügt über auswählbare Blockgrößen und eine exakt passende ganzzahlige Berechnung, um die Komplexität zu verringern, einschließlich:
    • Eine exakt passende ganzzahlige 4×4 räumliche Blocktransformation, die eine präzise Platzierung von Restsignalen ohne das bei früheren Codec-Designs häufig auftretende "Ringing" ermöglicht. Sie ähnelt der 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) verwendet wurden, liefert die Integer-Verarbeitung ein genau spezifiziertes dekodiertes Ergebnis.
    • Eine exakt passende ganzzahlige 8×8 räumliche Blocktransformation, mit der stark korrelierte Regionen effizienter komprimiert werden können als mit der 4×4-Transformation. Dieses Design basiert auf der Standard-DCT, ist jedoch vereinfacht und bietet eine genau spezifizierte Dekodierung.
    • Adaptive Encoder-Auswahl zwischen den 4×4- und 8×8-Transformationsblockgrößen für die ganzzahlige Transformationsoperation.
    • Eine sekundäre Hadamard-Transformation, die an "DC"-Koeffizienten der primären räumlichen Transformation durchgeführt wird, wird auf Chroma-DC-Koeffizienten (und in einem speziellen Fall auch auf Luma-Koeffizienten) angewendet, um eine noch stärkere Kompression in glatten Regionen zu erreichen.
  • Verlustfreie Makroblock-Codierung mit folgenden Merkmalen:
    • Ein verlustfreier "PCM-Makroblock"-Darstellungsmodus, bei dem Videodaten-Samples direkt dargestellt werden, was eine perfekte Darstellung spezifischer Regionen ermöglicht und eine strikte Begrenzung der Menge kodierter Daten für jeden Makroblock erlaubt.
    • Ein erweiterter verlustfreier Makroblock-Darstellungsmodus, der eine perfekte Darstellung spezifischer Regionen ermöglicht, wobei normalerweise wesentlich weniger Bits als im PCM-Modus verwendet werden.
  • Flexible Interlaced-Scan-Videocodierungsfunktionen, einschließlich:
    • Macroblock-adaptive Frame-Field-Codierung (MBAFF), die eine Macroblock-Paar-Struktur für Bilder verwendet, die als Frames codiert sind, und 16×16 Macroblocks im Field-Mode ermöglicht (im Vergleich zu MPEG-2, wo die Field-Mode-Verarbeitung in einem Bild, das als Frame codiert ist, zur Verarbeitung von 16×8 Halb-Macroblocks führt).
    • Bildadaptive Frame-Field-Codierung (PAFF oder PicAFF), die eine frei wählbare Mischung von Bildern ermöglicht, die entweder als komplette Frames, bei denen beide Felder für die Codierung kombiniert werden, oder als individuelle Einzelfelder codiert werden.
  • Ein Quantisierungsdesign, das Folgendes umfasst:
    • Logarithmische Schrittgrößensteuerung für ein einfacheres Bitratenmanagement durch Encoder und vereinfachte Skalierung der inversen Quantisierung
    • Frequenzangepasste Quantisierungsskalierungsmatrizen, die vom Encoder zur wahrnehmungsbasierten Quantisierungsoptimierung ausgewählt werden
  • Ein In-Loop-Deblocking-Filter, der dazu beiträgt, Blocking-Artefakte zu vermeiden, die bei anderen DCT-basierten Bildkomprimierungstechniken auftreten, was zu einer besseren visuellen Darstellung und Komprimierungseffizienz führt
  • Ein Entropie-Codierungsdesign, das Folgendes umfasst:
    • Context-adaptive binary arithmetic coding (CABAC), ein Algorithmus zur verlustfreien Komprimierung von Syntaxelementen im Videostrom bei Kenntnis der Wahrscheinlichkeiten von Syntaxelementen in einem bestimmten Kontext. CABAC komprimiert die Daten effizienter als CAVLC, erfordert aber einen wesentlich höheren Aufwand bei der Dekodierung.
    • Die kontextadaptive Codierung variabler Länge (CAVLC) ist eine weniger komplexe Alternative zu CABAC für die Codierung von quantisierten Transformationskoeffizientenwerten. Obwohl die Komplexität geringer ist als bei CABAC, ist CAVLC aufwändiger und effizienter als die Methoden, die üblicherweise zur Kodierung von Koeffizienten in anderen früheren Entwürfen verwendet wurden.
    • Eine einfache und hochstrukturierte Technik zur Kodierung variabler Länge (VLC) für viele der Syntaxelemente, die nicht durch CABAC oder CAVLC kodiert werden, wird als Exponential-Golomb-Kodierung (oder Exp-Golomb) bezeichnet.
  • Verlustsicherheitsmerkmale einschließlich:
    • Eine Network Abstraction Layer (NAL)-Definition, die es ermöglicht, die gleiche Videosyntax in vielen Netzwerkumgebungen zu verwenden. Ein sehr grundlegendes Konzept von H.264 besteht darin, in sich geschlossene Pakete zu erzeugen, um die Duplizierung von Headern wie beim Header Extension Code (HEC) von MPEG-4 zu vermeiden. Dies wurde durch die Entkopplung von Informationen, die für mehr als ein Slice relevant sind, vom Medienstrom erreicht. 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 kodierten Videosequenz unverändert, und ein aktiver Bildparametersatz bleibt innerhalb eines kodierten Bildes unverändert. Die Sequenz- und Bildparametersatz-Strukturen enthalten Informationen wie die Bildgröße, optionale Kodierungsmodi und die Zuordnung von Makroblöcken zu Slice-Gruppen.
    • Flexible macroblock ordering (FMO), auch bekannt als slice groups, und arbitrary slice ordering (ASO) sind Techniken zur Umstrukturierung der Anordnung der Darstellung der grundlegenden Regionen (Makroblöcke) in Bildern. FMO und ASO werden in der Regel als ein Merkmal der Fehler-/Verlustrobustheit betrachtet, können aber auch für andere Zwecke verwendet werden.
    • Datenpartitionierung (DP), ein Merkmal, das die Möglichkeit bietet, wichtigere und weniger wichtige Syntaxelemente in verschiedene Datenpakete aufzuteilen, was die Anwendung eines ungleichen Fehlerschutzes (UEP) und andere Arten der Verbesserung der Fehler-/Verlustrobustheit ermöglicht.
    • Redundante Slices (RS), eine Funktion zur Vermeidung von Fehlern/Verlusten, die es einem Encoder ermöglicht, eine zusätzliche Darstellung einer Bildregion (normalerweise mit geringerer Auflösung) zu senden, die verwendet werden kann, wenn die primäre Darstellung beschädigt wird oder verloren geht.
    • Bildnummerierung, eine Funktion, die die Erstellung von "Untersequenzen" ermöglicht, wodurch eine zeitliche Skalierbarkeit durch die optionale Einfügung zusätzlicher Bilder zwischen anderen Bildern und die Erkennung und Verschleierung von Verlusten ganzer Bilder, die aufgrund von Netzwerkpaketverlusten oder Kanalfehlern auftreten können, ermöglicht wird.
  • Umschalt-Slices, genannt SP- und SI-Slices, die es einem Encoder ermöglichen, einen Decoder anzuweisen, in einen laufenden Videostrom zu springen, um beispielsweise die Bitrate des Videostreamings umzuschalten und im "Trickmodus" zu arbeiten. Wenn ein Decoder mit Hilfe der SP/SI-Funktion in die Mitte eines Videostroms springt, kann er eine exakte Übereinstimmung mit den dekodierten Bildern an dieser Stelle im Videostrom erzielen, obwohl vor dem Wechsel andere oder gar keine Bilder als Referenz verwendet wurden.
  • Ein einfaches automatisches Verfahren zur Verhinderung der versehentlichen Emulation von Startcodes, d. h. von speziellen Bitfolgen in den kodierten Daten, die einen zufälligen Zugriff auf den Bitstrom und die Wiederherstellung der Byte-Ausrichtung in Systemen ermöglichen, bei denen die Byte-Synchronisation verloren gehen kann.
  • Supplemental Enhancement Information (SEI) und Video Usability Information (VUI), d. h. zusätzliche Informationen, die zu verschiedenen Zwecken in den Bitstrom eingefügt werden können, z. B. zur Angabe des für den Videoinhalt verwendeten Farbraums oder verschiedener Einschränkungen, die für die Codierung gelten. SEI-Nachrichten können beliebige benutzerdefinierte Metadaten-Payloads oder andere Nachrichten mit einer in der Norm definierten Syntax und Semantik enthalten.
  • Hilfsbilder, die für Zwecke wie Alpha-Compositing verwendet werden können.
  • Unterstützung von monochromem (4:0:0), 4:2:0, 4:2:2 und 4:4:4 Chroma-Sampling (abhängig vom gewählten Profil).
  • Unterstützung einer Bittiefenpräzision von 8 bis 14 Bits pro Abtastung (je nach ausgewähltem Profil).
  • Die Möglichkeit, einzelne Farbebenen als eigene Bilder mit eigenen Slice-Strukturen, Makroblock-Modi, Bewegungsvektoren usw. zu kodieren, wodurch Encoder mit einer einfachen Parallelisierungsstruktur entwickelt werden können (nur in den drei 4:4:4-fähigen Profilen unterstützt).
  • Picture Order Count, eine Funktion, die dazu dient, die Reihenfolge der Bilder und die Werte der Samples in den dekodierten Bildern von den Timing-Informationen zu isolieren, so dass die Timing-Informationen von einem System separat übertragen und gesteuert/geändert werden können, ohne den dekodierten Bildinhalt zu beeinflussen. ⓘ

Diese und andere Techniken tragen dazu bei, dass H.264 unter einer Vielzahl von Umständen in einer Vielzahl von Anwendungsumgebungen deutlich besser abschneidet als alle früheren Standards. H.264 ist oft wesentlich leistungsfähiger als MPEG-2-Video - in der Regel wird die gleiche Qualität bei der Hälfte der Bitrate oder weniger erreicht, insbesondere bei Videoinhalten mit hoher Bitrate und hoher Auflösung. ⓘ

Wie andere ISO/IEC MPEG-Videostandards verfügt auch H.264/AVC über eine Referenzsoftware-Implementierung, die kostenlos heruntergeladen werden kann. Ihr Hauptzweck besteht darin, Beispiele für H.264/AVC-Funktionen zu geben, und nicht darin, eine nützliche Anwendung an sich zu sein. Auch in der Moving Picture Experts Group wurden einige Arbeiten zur Entwicklung von Referenzhardware durchgeführt. Die oben genannten Aspekte sind in allen Profilen von H.264 enthalten. Ein Profil für einen Codec ist eine Reihe von Merkmalen dieses Codecs, die zur Erfüllung bestimmter Spezifikationen der vorgesehenen Anwendungen bestimmt sind. Dies bedeutet, dass viele der aufgelisteten Merkmale in einigen Profilen nicht unterstützt werden. Die verschiedenen Profile von H.264/AVC werden im nächsten Abschnitt behandelt. ⓘ

Profile

Die Norm definiert mehrere Sätze von Fähigkeiten, die als Profile bezeichnet werden und auf bestimmte Klassen von Anwendungen abzielen. Diese werden mit einem Profilcode (profile_idc) und manchmal mit einer Reihe zusätzlicher Einschränkungen, die im Encoder angewendet werden, deklariert. Der Profilcode und die angegebenen Einschränkungen ermöglichen es einem Decoder, die Anforderungen für die Dekodierung dieses spezifischen Bitstroms zu erkennen. (Und in vielen Systemumgebungen dürfen nur ein oder zwei Profile verwendet werden, so dass Decoder in diesen Umgebungen sich nicht um die Erkennung der weniger häufig verwendeten Profile kümmern müssen). Das mit Abstand am häufigsten verwendete Profil ist das High Profile. ⓘ

Zu den Profilen für nicht skalierbare 2D-Videoanwendungen gehören die folgenden:

Constrained Baseline Profile (CBP, 66 mit Constraint Set 1)
Dieses Profil ist in erster Linie für kostengünstige Anwendungen gedacht und wird in der Regel für Videokonferenzen und mobile Anwendungen verwendet. Es entspricht der Untergruppe von Merkmalen, die den Profilen Baseline, Main und High gemeinsam sind.
Grundlegendes Profil (BP, 66)
Dieses Profil eignet sich in erster Linie für kostengünstige Anwendungen, die zusätzliche Robustheit bei Datenverlusten erfordern, und wird in einigen Videokonferenz- und mobilen Anwendungen verwendet. Dieses Profil umfasst alle Funktionen, die im Constrained Baseline Profile unterstützt werden, sowie drei zusätzliche Funktionen, die für die Robustheit bei Datenverlusten (oder für andere Zwecke, wie z. B. die Zusammenstellung von Mehrpunkt-Videoströmen mit geringer Verzögerung) verwendet werden können. Die Bedeutung dieses Profils hat seit der Definition des Constrained Baseline Profile im Jahr 2009 etwas abgenommen. Alle Bitströme des Constrained Baseline Profile werden auch als Bitströme des Baseline Profile betrachtet, da diese beiden Profile denselben Profilidentifizierungscode haben.
Erweitertes Profil (XP, 88)
Dieses Profil ist als Streaming-Videoprofil gedacht und verfügt über eine relativ hohe Komprimierungskapazität und einige zusätzliche Tricks, um Datenverlusten und Server-Stream-Umschaltungen standzuhalten.
Hauptprofil (MP, 77)
Dieses Profil wird für digitale Fernsehsendungen mit Standardauflösung verwendet, die das im DVB-Standard definierte MPEG-4-Format verwenden. Es wird jedoch nicht für hochauflösende Fernsehsendungen verwendet, da die Bedeutung dieses Profils mit der Entwicklung des High Profile im Jahr 2004 für diese Anwendung abnahm.
Hohes Profil (HiP, 100)
Das wichtigste Profil für Rundfunk- und Plattenspeicheranwendungen, insbesondere für hochauflösende Fernsehanwendungen (z. B. ist dies das Profil, das vom Blu-ray-Disc-Speicherformat und dem DVB-HDTV-Sendedienst verwendet wird).
Progressives Hochprofil (PHiP, 100 mit Constraint Set 4)
Ähnlich wie das High-Profil, jedoch ohne Unterstützung von Field Coding Features.
Constrained High Profile (100 mit Constraint Set 4 und 5)
Ähnlich wie das Progressive High-Profil, jedoch ohne Unterstützung von B (bi-predictive) Slices.
Hoch 10-Profil (Hi10P, 110)
Dieses Profil baut auf dem High-Profil auf und unterstützt bis zu 10 Bits pro Abtastung an dekodierter Bildpräzision und geht damit über die typischen Fähigkeiten von Mainstream-Verbraucherprodukten hinaus.
Hoch 4
2:2 Profil (Hi422P, 122): Dieses Profil zielt in erster Linie auf professionelle Anwendungen ab, die Interlaced Video verwenden, und baut auf dem High 10-Profil auf. Es unterstützt das 4:2:2-Chroma-Sampling-Format und verwendet bis zu 10 Bits pro Abtastung für die dekodierte Bildgenauigkeit.
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 Bits pro Abtastung und zusätzlich eine effiziente verlustfreie Regionskodierung und die Kodierung jedes Bildes als drei separate Farbebenen. ⓘ

Für Camcorder, Schnittgeräte und professionelle Anwendungen enthält der Standard vier zusätzliche Intra-Frame-Profile, die als einfache Teilmengen anderer entsprechender Profile definiert sind. Diese sind vor allem für professionelle Anwendungen (z. B. Kamera und Schnittsystem) gedacht:

High 10 Intra Profile (110 mit Einschränkungssatz 3)
Das High 10-Profil, das auf die Verwendung von All-Intra beschränkt ist.
Hoch 4
2:2-Intra-Profil (122 mit Einschränkungssatz 3): Das hohe 4:2:2-Profil mit Beschränkung auf die reine Intra-Nutzung.
Hoch 4
4:4-Intra-Profil (244 mit Einschränkungssatz 3): Das hohe 4:4:4-Profil mit Beschränkung auf die reine Intra-Nutzung.
CAVLC 4
4:4-Intra-Profil (44): Das High 4:4:4-Profil mit Beschränkung auf All-Intra-Nutzung und CAVLC-Entropiecodierung (d. h. ohne Unterstützung von CABAC). ⓘ

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

Skalierbares Basisprofil (83)
Dieses Profil, das in erster Linie auf Videokonferenz-, Mobil- und Überwachungsanwendungen abzielt, baut auf dem Constrained Baseline-Profil auf, dem die Basisschicht (eine Teilmenge des Bitstroms) entsprechen muss. Für die Skalierbarkeitstools wird eine Teilmenge der verfügbaren Tools aktiviert.
Scalable Constrained Baseline Profile (83 mit Constraint Set 5)
Eine Teilmenge des Scalable Baseline Profile, die in erster Linie für Echtzeit-Kommunikationsanwendungen gedacht ist.
Skalierbares Hochprofil (86)
Dieses Profil zielt in erster Linie auf Broadcast- und Streaming-Anwendungen ab und baut auf dem H.264/AVC High Profile auf, dem die Basisschicht entsprechen muss.
Scalable Constrained High Profile (86 mit Constraint Set 5)
Eine Teilmenge des Scalable High Profile, die in erster Linie für Echtzeit-Kommunikationsanwendungen gedacht ist.
Skalierbares hohes Intra-Profil (86 mit Beschränkungssatz 3)
Dieses Profil zielt in erster Linie auf Produktionsanwendungen ab und ist das Scalable High Profile mit Beschränkungen für die reine Intra-Nutzung. ⓘ

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

Stereo High Profile (128)
Dieses Profil zielt auf stereoskopische 3D-Videos mit zwei Ansichten ab und kombiniert die Tools des High-Profils mit den Inter-View-Vorhersagefunktionen der MVC-Erweiterung.
Hochprofil für mehrere Ansichten (118)
Dieses Profil unterstützt zwei oder mehr Ansichten unter Verwendung von Inter-Picture- (temporal) und MVC-Inter-View-Prediction, unterstützt jedoch keine Halbbilder und keine makroblockadaptive Frame-Field-Codierung. ⓘ

Mit der MFC-Erweiterung (Multi-resolution Frame-Compatible) wurden zwei weitere Profile hinzugefügt:

MFC High Profile (134)
Ein Profil für stereoskopische Kodierung mit zweischichtiger Auflösungsverbesserung.
MFC Tiefe Hochprofil (135)

Mit der 3D-AVC-Erweiterung wurden zwei weitere Profile hinzugefügt:

Multiview Depth High Profile (138)
Dieses Profil unterstützt die gemeinsame Kodierung von Tiefenkarten- und Videotexturinformationen für eine verbesserte Komprimierung von 3D-Videoinhalten.
Erweitertes Multiview Depth High Profile (139)
Ein erweitertes Profil für kombinierte Multiview-Kodierung mit Tiefeninformationen. ⓘ

Feature-Unterstützung in bestimmten Profilen

Merkmal CBP BP XP MP ProHiP HiP Hi10P Hi422P Hi444PP ⓘ
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 Makroblock-Anordnung (FMO) Nein Ja Ja Nein Nein Nein Nein Nein Nein
Beliebige Slice-Anordnung (ASO) Nein Ja Ja Nein Nein Nein Nein Nein Nein
Redundante Slices (RS) Nein Ja Ja Nein Nein Nein Nein Nein Nein
Datenpartitionierung Nein Nein Ja Nein Nein Nein Nein Nein Nein
SI- und SP-Slices Nein Nein Ja Nein Nein Nein Nein Nein Nein
Zeilensprungkodierung (PicAFF, MBAFF) Nein Nein Ja Ja Nein Ja Ja Ja Ja
B-Slices Nein Nein Ja Ja Ja Ja Ja Ja Ja
CABAC-Entropie-Kodierung Nein Nein Nein Ja Ja Ja Ja Ja Ja
4:0:0 (einfarbig) Nein Nein Nein Nein Ja Ja Ja Ja Ja
8×8 vs. 4×4 Transformationsadaptivität Nein Nein Nein Nein Ja Ja Ja Ja Ja
Quantisierungs-Skalierungsmatrizen Nein Nein Nein Nein Ja Ja Ja Ja Ja
Getrennte CB- und CR-QP-Kontrolle Nein Nein Nein Nein Ja Ja Ja Ja Ja
Getrennte Kodierung der Farbebene Nein Nein Nein Nein Nein Nein Nein Nein Ja
Prädiktive verlustfreie Kodierung Nein Nein Nein Nein Nein Nein Nein Nein Ja

Ebenen

Wie der Begriff in der Norm verwendet wird, ist eine "Stufe" eine festgelegte Gruppe von Einschränkungen, die einen Grad der erforderlichen Decoderleistung für ein Profil angeben. Eine Unterstützungsstufe innerhalb eines Profils gibt zum Beispiel die maximale Bildauflösung, Bildrate und Bitrate an, die ein Decoder verwenden darf. Ein Decoder, der einer bestimmten Stufe entspricht, muss in der Lage sein, alle Bitströme zu dekodieren, die für diese Stufe und alle niedrigeren Stufen kodiert sind. ⓘ

Stufen mit maximalen Eigenschaftswerten ⓘ
Stufe
 Maximale
Dekodiergeschwindigkeit
(Makroblocks/s) 		Maximale
Frame-Größe
(Makroblöcke) 		Maximale Video
Bitrate für die Video
Kodierungsschicht (VCL)
(Constrained Baseline,
Baseline, Erweitert
und Hauptprofilen)
(kbits/s) 		Beispiele für hohe Auflösung
@ höchste Bildrate
(maximal gespeicherte Bilder)
Umschalten auf zusätzliche Details

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 hohe Profil ist das 1,25-fache der Profile "Constrained Baseline", "Baseline", "Extended" und "Main"; das 3-fache für Hi10P und das 4-fache für Hi422P/Hi444PP. ⓘ

Die Anzahl der Luma-Samples ist 16×16=256 mal die Anzahl der Macroblocks (und die Anzahl der Luma-Samples pro Sekunde ist 256 mal die Anzahl der Macroblocks pro Sekunde). ⓘ

Pufferung dekodierter Bilder

Zuvor kodierte Bilder werden von H.264/AVC-Kodierern verwendet, um Vorhersagen über die Werte von Samples in anderen Bildern zu machen. Auf diese Weise kann der Encoder effizient entscheiden, wie ein bestimmtes Bild am besten zu kodieren ist. Im Decoder werden solche Bilder in einem virtuellen dekodierten Bildpuffer (DPB) gespeichert. Die maximale Kapazität des DPB in Einheiten von Vollbildern (oder Paaren von Halbbildern), wie in Klammern in der rechten Spalte der obigen Tabelle angegeben, kann wie folgt berechnet werden:

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

Dabei ist MaxDpbMbs ein konstanter Wert, der in der nachstehenden Tabelle als Funktion der Pegelnummer angegeben ist, und PicWidthInMbs und FrameHeightInMbs sind die Bildbreite und Bildhöhe für die kodierten Videodaten, ausgedrückt in Einheiten von Makroblöcken (aufgerundet auf ganzzahlige Werte und unter Berücksichtigung von Beschneidung 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 angegeben. ⓘ

Stufe 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 1.080 Samples hoch (BildHöheInMbs = 68), hat ein Level-4-Decoder eine maximale DPB-Speicherkapazität von floor(32768/(120*68)) = 4 Frames (oder 8 Felder). Der Wert 4 ist also in der obigen Tabelle in der rechten Spalte der Zeile für Level 4 mit der Bildgröße 1920×1080 in Klammern angegeben. ⓘ

Es ist wichtig zu beachten, dass das aktuell dekodierte Bild nicht in die Berechnung der DPB-Vollständigkeit einbezogen wird (es sei denn, der Encoder hat angegeben, dass es als Referenz für die Dekodierung anderer Bilder oder für ein verzögertes Ausgabe-Timing gespeichert werden soll). Daher muss ein Decoder tatsächlich über genügend Speicher verfügen, um (mindestens) ein Bild mehr als die oben berechnete maximale Kapazität des DPB zu verarbeiten. ⓘ

Implementierungen

Eine YouTube-Videostatistik mit AVC (H.264) Videocodec und Opus-Audioformat ⓘ

Im Jahr 2009 war die HTML5-Arbeitsgruppe gespalten zwischen den Befürwortern von Ogg Theora, einem freien Videoformat, das als unbelastet von Patenten gilt, und H.264, das patentierte Technologie enthält. Noch im Juli 2009 hieß es, 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 die Unterstützung für HTML 5-Videos, die mit H.264 kodiert sind, hinzugefügt. Auf dem Gartner-Symposium/ITXpo im November 2010 antwortete Microsoft-CEO Steve Ballmer auf die Frage "HTML 5 oder Silverlight?" mit den Worten: "Wenn Sie etwas machen wollen, das universell ist, dann ist es keine Frage, dass die Welt auf HTML5 setzt." Im Januar 2011 kündigte Google an, die Unterstützung für H.264 aus seinem Chrome-Browser zu entfernen und sowohl Theora als auch WebM/VP8 zu unterstützen, um ausschließlich offene Formate zu verwenden. ⓘ

Am 18. März 2012 kündigte Mozilla die Unterstützung von H.264 in Firefox auf mobilen Geräten an, da H.264-kodierte Videos weit verbreitet sind und die Verwendung spezieller H.264-Decoder-Hardware, die auf solchen Geräten üblich ist, den Stromverbrauch senkt. Am 20. Februar 2013 implementierte Mozilla in Firefox Unterstützung für die Dekodierung von H.264 unter Windows 7 und höher. Diese Funktion stützt sich auf die in Windows integrierten Dekodierungsbibliotheken. 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 die Binärdateien als auch den Quellcode eines H.264-Videocodecs namens OpenH264 unter der vereinfachten BSD-Lizenz freigeben und alle Lizenzgebühren für dessen Verwendung an MPEG LA für alle Softwareprojekte zahlen würde, die die vorkompilierten Binärdateien von Cisco verwenden, wodurch die OpenH264-Binärdateien von Cisco kostenlos verwendet werden könnten. Alle Softwareprojekte, die den Quellcode von Cisco anstelle der Binärdateien verwenden, sind jedoch rechtlich dafür verantwortlich, alle Lizenzgebühren an MPEG LA zu zahlen. Zu den Ziel-CPU-Architekturen gehören x86 und ARM, und zu den Ziel-Betriebssystemen gehören Linux, Windows XP und höher, Mac OS X und Android; iOS fehlt in dieser Liste, da es Anwendungen nicht erlaubt, Binärmodule aus dem Internet zu holen und zu installieren. Ebenfalls am 30. Oktober 2013 schrieb Brendan Eich von Mozilla, dass die Binärdateien von Cisco in zukünftigen Versionen von Firefox verwendet werden sollen, um Firefox Unterstützung für H.264 hinzuzufügen, wenn keine Plattform-Codecs verfügbar sind. Cisco veröffentlichte den Quellcode von OpenH264 am 9. Dezember 2013. ⓘ

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

Software-Encoder

AVC-Software-Implementierungen
Merkmal QuickTime Nero OpenH264 x264 Haupt-
Konzept 		Elecard  TSE  Pro-
Kodierer 		Avivo Elementar  IPP  ⓘ
B-Slices Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
Mehrere Referenzrahmen Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
Zeilensprungkodierung (PicAFF, MBAFF) Nein MBAFF MBAFF MBAFF Ja Ja Nein Ja MBAFF Ja Nein
CABAC-Entropie-Kodierung Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
8×8 vs. 4×4 Transformationsadaptivität Nein Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
Quantisierungs-Skalierungsmatrizen Nein Nein Ja Ja Ja Nein Nein Nein Nein Nein Nein
Getrennte CB- und CR-QP-Kontrolle Nein Nein Ja Ja Ja Ja 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 Abtasttiefe (Bit) 8 8 8 10 10 8 8 8 8 10 12
Prädiktive verlustfreie Kodierung Nein Nein Nein Ja Nein Nein Nein Nein Nein Nein Nein

Hardware

Da die H.264-Kodierung und -Dekodierung bei bestimmten Arten von arithmetischen Operationen eine erhebliche Rechenleistung erfordert, sind Software-Implementierungen, die auf Allzweck-CPUs laufen, in der Regel weniger energieeffizient. Die neuesten Quad-Core-x86-CPUs für allgemeine Zwecke verfügen jedoch über eine ausreichende Rechenleistung, um SD- und HD-Codierung in Echtzeit durchzuführen. Die Effizienz der Komprimierung hängt von der Implementierung des Videoalgorithmus ab, nicht davon, ob eine Hardware- oder Software-Implementierung verwendet wird. Der Unterschied zwischen Hardware- und Software-Implementierung liegt daher eher in der Leistungseffizienz, der Flexibilität und den Kosten. Um die Energieeffizienz zu verbessern und den Formfaktor der Hardware zu reduzieren, kann spezielle Hardware eingesetzt werden, entweder für den gesamten Kodierungs- oder Dekodierungsprozess oder zur Unterstützung der Beschleunigung innerhalb einer CPU-gesteuerten Umgebung. ⓘ

CPU-basierte Lösungen sind bekanntermaßen viel flexibler, insbesondere wenn die Codierung gleichzeitig in mehreren Formaten, mit mehreren Bitraten und Auflösungen (Multi-Screen-Video) und möglicherweise mit zusätzlichen Funktionen zur Unterstützung von Containerformaten, erweiterten integrierten Werbefunktionen usw. erfolgen muss. CPU-basierte Softwarelösungen machen es im Allgemeinen viel einfacher, mehrere gleichzeitige Kodierungssitzungen innerhalb derselben CPU auszugleichen. ⓘ

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

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

ASIC-Encoder mit H.264-Encoderfunktionalität sind von vielen verschiedenen Halbleiterunternehmen erhältlich, aber das im ASIC verwendete Kerndesign wird in der Regel von einem der wenigen Unternehmen wie Chips&Media, Allegro DVT, On2 (früher Hantro, von Google übernommen), Imagination Technologies und NGCodec lizenziert. Einige Unternehmen haben sowohl FPGA- als auch ASIC-Produkte im Angebot. ⓘ

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

Lizenzierung

In Ländern, in denen Patente auf Software-Algorithmen aufrechterhalten werden, wird von Anbietern und kommerziellen Nutzern von Produkten, die H.264/AVC verwenden, erwartet, dass sie Patentlizenzgebühren für die patentierte Technologie zahlen, die ihre Produkte nutzen. 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 für diesen Standard gelten, sowie für andere Patentpools, wie 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, wobei die meisten Patente im Pool von Panasonic (1.197 Patente), Godo Kaisha IP Bridge (1.130 Patente) und LG Electronics (990 Patente) gehalten werden. ⓘ

Am 26. August 2010 gab MPEG LA bekannt, dass für H.264-kodierte Internetvideos, die für Endnutzer kostenlos sind, keine Lizenzgebühren erhoben werden. Alle anderen Lizenzgebühren bleiben bestehen, z. B. für Produkte, die H.264-Videos dekodieren und kodieren, sowie für Betreiber von frei empfangbaren Fernseh- und Abonnementkanälen. Die Lizenzbedingungen werden in 5-Jahres-Blöcken aktualisiert. ⓘ

Seit der Fertigstellung der ersten Version des Standards im Mai 2003 (vor 19 Jahren) und der Fertigstellung des am häufigsten verwendeten Profils (des High-Profils) im Juni 2004 (vor 18 Jahren) ist eine beträchtliche Anzahl der Patente, die ursprünglich für den Standard galten, ausgelaufen, obwohl eines der US-Patente im MPEG LA H.264-Pool noch mindestens bis 2027 läuft. ⓘ

Im Jahr 2005 verklagte Qualcomm Broadcom vor dem US-Bezirksgericht und behauptete, dass Broadcom durch die Herstellung von Produkten, die mit dem H.264-Videokomprimierungsstandard kompatibel waren, zwei seiner Patente verletzte. Im Jahr 2007 stellte das Bezirksgericht fest, dass die Patente nicht durchsetzbar waren, weil Qualcomm sie vor der Veröffentlichung des H.264-Standards im Mai 2003 nicht dem JVT mitgeteilt hatte. Im Dezember 2008 bestätigte der US Court of Appeals for the Federal Circuit die Anordnung des Bezirksgerichts, dass die Patente nicht durchsetzbar sind, verwies die Sache jedoch an das Bezirksgericht zurück mit der Anweisung, den Umfang der Nichtdurchsetzbarkeit auf H.264-konforme Produkte zu beschränken. ⓘ

Einsatzgebiete

H.264 wurde nicht auf einen spezifischen Verwendungszweck zugeschnitten, sondern entfaltet seine Leistung in einem recht breiten Spektrum an Anwendungen. Daher sind die momentan aussichtsreichsten Einsatzgebiete auch von sehr verschiedener Gestalt:

HDTV
H.264 ist eines der obligatorischen Videokompressionsverfahren des Blu-ray-Standards und für die hochauflösende Fernsehübertragung mittels DVB-S2 (z. B. HD-1 und Sky HD, sowie ProSieben HD bzw. RTL HD) verpflichtend. Auch der 2008 eingestellte HD-DVD-Standard sah Videokompression gemäß dem H.264-Verfahren vor.
Portable Video
Die konkurrierenden Mobilfernsehstandards DVB-H und DMB verwenden beide (unter anderem) H.264 für die Videokodierung für mobile Endgeräte, wie Mobiltelefone oder PDAs. Auch die PlayStation Portable, die fünfte Generation des Apple iPods, das iPhone und der nur in den USA erhältliche Zune-Player können H.264-Videos abspielen.
Multimedia
Apple liefert sein Multimedia-Framework QuickTime ab Version 7 mit einem H.264-Codec aus.
Videokonferenztechnik
Seit 2005 stehen Anwendern Videokonferenzendsysteme mit H.264-Codecs zur Verfügung. So sind beispielsweise in iChat AV 3.x erstmals Mehrfach-Videokonferenzen möglich.
Video-/Digicams
Eine Reihe von Digitalkameras und Videokameras unterstützen H.264-Kompression für Videoaufzeichnung. ⓘ

Verwandte Verfahren

Während der Spezifizierung von H.264 spalteten sich mehrere kommerzielle Entwicklungspfade ab, die zwar mehr oder weniger direkt auf H.264 aufsetzen, jedoch letztlich eine teilweise inkompatible Einheit darstellen:

  • Sorenson Video 3, ein im Umfeld von QuickTime und im Kontext des *.mov-Dateiformat sehr verbreiteter Codec, der nur in Details von H.264 abweicht.
  • Microsoft Windows Media Video 9 (*.wmv, FourCC: WMV9/wvc1) ist ein Videocodec der Firma Microsoft, welcher auch LoopFiltering einsetzt. Die Variante VC-1 (FourCC: wvc1) (vormals VC-9 nach WMV9) ist ebenfalls einer der Codecs, die in HD DVD und Blu-ray Disc Verwendung finden.
  • VP8, ist ein von der Google-Firma On2 Technologies entwickelter Videocodec. Er baut auf der Entwicklungsreihe TrueMotion auf. ⓘ

Weiterentwicklungen

  • Multiview Video Coding (MVC) für stereoskopische Aufnahmen.
  • High Efficiency Video Coding (HEVC oder H.265), Nachfolger von H.264
  • VP9, ist ein von Google entwickelter Videocodec. Er baut auf VP8 auf und ist im Browser Chrome implementiert.
  • AV1, ist ein von der Alliance for Open Media entwickelter Videocodec. Er baut auf VP9 auf. ⓘ

Level

H.264 definiert wie schon in MPEG-2 verschiedene Level. Diese sind umso höher, je größer die Bitrate des Videos ist. ⓘ

In der folgenden Tabelle sind die zulässigen Grenzwerte der einzelnen Profile angegeben:

Macroblocks pro Beispiele für Videobitrate (VCL) für Profiles ⓘ
Level Frame Sekunde Auflösung/Bildrate
dieses Levels 		Baseline
Extended
Main 		High High 10 High 4:2:2
High 4:4:4
1 99 1 485 128 × 96 / 30
176 × 144 / 15 		64 kbit/s 80 kbit/s 192 kbit/s 256 kbit/s
1b 128 kbit/s 160 kbit/s 384 kbit/s 512 kbit/s
1.1 396 3 000 176 × 144 / 30
320 × 240 / 10
352 × 288 / 7.5 		192 kbit/s 240 kbit/s 576 kbit/s 768 kbit/s
1.2 6 000 176 × 144 / 60
320 × 240 / 20
352 × 288 / 15 		384 kbit/s 480 kbit/s 1152 kbit/s 1536 kbit/s
1.3 11 880 320 × 240 / 40
352 × 288 / 30 		768 kbit/s 960 kbit/s 2304 kbit/s 3072 kbit/s
2 2 Mbit/s 2,5 Mbit/s 6 Mbit/s 8 Mbit/s
2.1 792 19 800 352 × 288 / 50
352 × 576 / 25 		4 Mbit/s 5 Mbit/s 12 Mbit/s 16 Mbit/s
2.2 1 620 20 250 352 × 288 / 50
720 × 480 / 15 		4 Mbit/s 5 Mbit/s 12 Mbit/s 16 Mbit/s
3 40 500 720 × 480 / 30
720 × 576 / 25 		10 Mbit/s 12,5 Mbit/s 30 Mbit/s 40 Mbit/s
3.1 3 600 108 000 720 × 576 / 60
1280 × 720 / 30
 14 Mbit/s 17,5 Mbit/s 42 Mbit/s 56 Mbit/s
3.2 5 120 216 000 1280 × 720 / 60
1280 × 1024 / 42,2 		20 Mbit/s 25 Mbit/s 60 Mbit/s 80 Mbit/s
4 8 192 245 760 1280 × 720 / 68,3
1280 × 1024 / 48
1920 × 1080 / 30 		20 Mbit/s 25 Mbit/s 60 Mbit/s 80 Mbit/s
4.1 50 Mbit/s 62,5 Mbit/s 150 Mbit/s 200 Mbit/s
4.2 8 704 522 240 1280 × 720 / 145
1920 × 1080 / 64
2048 × 1080 / 60 		50 Mbit/s 62,5 Mbit/s 150 Mbit/s 200 Mbit/s
5 22 080 589 824 1920 × 1080 / 72,3
2048 × 1080 / 67,8
3672 × 1536 / 26,7 		135 Mbit/s 168,75 Mbit/s 405 Mbit/s 540 Mbit/s
5.1 36 864 983 040 2048 × 1080 / 112,9
3840 × 2160 / 31,7
4096 × 2160 / 28,5 		240 Mbit/s 300 Mbit/s 720 Mbit/s 960 Mbit/s
5.2 36 864 2 073 600 2048 × 1080 / 172
3840 × 2160 / 66,8
4096 × 2160 / 60 		240 Mbit/s 300 Mbit/s 720 Mbit/s 960 Mbit/s

Tests

In einigen Tests der MSU Graphics & Media Lab (Video Group) hat sich der Codec x264 als führender etabliert. Gegenüber DivX benötigt er nur 2/3 des Datenstroms für das gleiche Ergebnis. Durch die kontinuierliche Weiterentwicklung wurde der Codec stark verbessert in den letzten Jahren für geringeren Datenstrom bei gewünschter Bildqualität. Dies ist sehr wichtig besonders zum Beispiel für Satelliten- und Internetübertragungen mit limitierter Kapazität. ⓘ

Der Bruder-Codec x265 hat im Vergleich H.265 zu H.264 einen 20 % geringeren Datenstrom bei gleicher Bildqualität und ist damit 25 % besser. ⓘ

Wiedergabe am PC

Mit Hilfe von ffdshow lassen sich im H.264 kodierte Videos mit DirectShow-basierten Videoabspielprogrammen wie dem Windows Media Player oder dem Media Player Classic abspielen. ⓘ

Eine Alternative zu DirectShow-basierten Playern ist z. B. mit dem MPlayer oder dem VLC media player gegeben. Beide beherrschen die Decodierung von H.264 und können alle relevanten Container lesen. Zudem sind beide Programme frei verfügbar. Der ffdshow-Filter, MPlayer und der VLC-Player greifen zur Decodierung von H.264 auf die libavcodec-Bibliothek zurück, welche benutzerdefinierte Quantisierungsmatrizen unterstützt. ⓘ

Weiterhin ist Apples QuickTime ab Version 7 in der Lage, H.264 abzuspielen. QuickTime ist für aktuelle Versionen von macOS und Windows verfügbar. Allerdings spielt QuickTime 7 keinen Inhalt, der durch den ffdshow H.264-Kodierer produziert wird, sondern zeigt ein schwarzes Bild. Hilfe bietet hierbei die Erweiterung Perian. ⓘ

Der Apple iPod spielt H.264 in MP4- und .mov-Containern ab. Die Erstellung eines iPod-kompatiblen H.264-Videos kann hierzu entweder mit dem Quicktime-H.264-Encoder oder dem x264 erfolgen. Technisch bedingt, sind den qualitativen Möglichkeiten des Encoders zwar beim iPod engere Grenzen gesetzt, als der Standard H.264 zuließe. In Generation 6 unterstützt der iPod jedoch mit einer Auflösung von bis zu 640 × 480 Pixeln bei 30 Bildern pro Sekunde und einer maximalen Datenrate von 2,5 Mbit/s immerhin eine Low-Complexity-Version des H.264-Baseline-Profils bis zu Level 3.0. ⓘ

Da H.264 nicht an ein bestimmtes Containerformat gebunden ist, können die Videos als MP4-, aber auch als AVI-, Matroska- oder Ogg-Media-Datei vorliegen. Es ist sogar möglich, H.264-Videos als Roh-Daten zu speichern (.264). Solche Rohdaten können dann z. B. mit MP4Box (GPAC) oder mkvmerge in einen geeigneten Container gemultiplext werden. Benötigt werden neben einem Decoder also auch ein Splitter (Demuxer), der das jeweils benutzte Containerformat unterstützt. Unter Windows ist dafür der Haali Media Splitter geeignet, ein Quellenfilter für DirectShow, der nahezu alle relevanten Containerformate beherrscht. ⓘ

Die Wiedergabe über Software-Dekodierung benötigte zum Zeitpunkt des Erscheinens viel CPU-Leistung. Entlastung für die CPU ist mit einer geeigneten Hardware, die in vielen Grafikkarten integriert ist, in Verbindung mit der darauf aufbauenden Dekoder-Software, möglich, z. B. mittels DXVA oder VDPAU. ⓘ

Abgerufen von „http://besserwiki.de/index.php?title=H.264&oldid=45415“