Erweiterte Videocodierung

"Avc1" leitet hier weiter. Nicht zu verwechseln mit AV1 oder VC-1.
Erweiterte Videocodierung / H.264 / MPEG-4 Teil 10
Erweiterte Videocodierung für generische audiovisuelle Dienste
H.264, MPEG-4 AVC logo.svg
Status In voller Stärke
Jahr begann 2003
Erstmals veröffentlicht 17. August 2004
Letzte Version 14.0
22. August 2021
Organisation Itu-t, ISO, IEC
Komitee SG16 (Vceg), MPEG
Grundstandards H.261, H.262 (AKA MPEG-2-Video), H.263, MPEG-1
Verwandte Standards H.265 (AKA HEVC), H.266 (AKA VVC)
Domain Video-Kompression
Lizenz Mpeg la[1]
Webseite https://www.itu.int/rec/t-rec-h.264
Blockdiagramm der Videocodierungsschicht des H.264 -Encoders mit Wahrnehmungsqualitätsbewertung

Erweiterte Videocodierung (AVC), auch bezeichnet als H.264 oder MPEG-4 Teil 10, ist ein Videokomprimierungsstandard Basierend auf blockorientiertem, Bewegung kompensiert Codierung.[2] Es ist bei weitem das am häufigsten verwendete Format für die Aufzeichnung, Komprimierung und Verteilung von Videoinhalten, die ab September 2019 von 91% der Entwickler der Videbranche verwendet werden.[3][4] Es unterstützt die Resolutionen bis hin zu und einschließlich 8K UHD.[5][6]

Die Absicht des H.264/AVC Bitraten als frühere Standards (d. H. Hälfte oder weniger die Bitrate von MPEG-2, H.263, oder MPEG-4 Teil 2) ohne die Komplexität des Designs so sehr zu erhöhen, dass es unpraktisch oder übermäßig teuer wäre. Dies wurde mit Merkmalen wie einer Ganzzahl der reduzierten Komplexität erreicht Diskrete Cosinus -Transformation (Ganzzahl DCT),[6][7][8] variable blockgroße Segmentierung und Mehrfachbild Inter-Picture-Vorhersage. Ein zusätzliches 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, niedriges und hohe Auflösung Video. Übertragung, DVD Lagerung, RTP/IP Paketnetzwerke und Itu-t Multimedia Telefonie Systeme. Der H.264 -Standard kann als "Familie von Standards" angesehen werden, die aus verschiedenen Profilen bestehen, obwohl sein "Hochkörper" bei weitem das häufig häufig verwendete Format ist. Ein bestimmter Decoder decodiert mindestens eine, aber nicht unbedingt alle Profile. Der Standard beschreibt das Format der codierten Daten und die Art und Weise, wie die Daten dekodiert werden, aber es gibt keine Algorithmen für die Codierung von Videos an - dies wird für Encoder -Designer für sich selbst offen gelassen, und eine Vielzahl von Codierungsschemata war aufgetreten. H.264 wird normalerweise für verwendet Verlustige Komprimierung, obwohl es auch möglich ist, wirklich zu erschaffen Verlustlos codiert Regionen in verlustkodierten Bildern oder um seltene Anwendungsfälle zu unterstützen, für die die gesamte Codierung verlustlos ist.

H.264 wurde durch die standardisiert Itu-t Videocodierungsexperten Gruppe (Vceg) von Studiengruppe 16 zusammen mit dem ISO/IEC JTC1 Experten für bewegte Bildexperten (MPEG). Die Projektpartnerschaftsanstrengungen werden als Joint Video Team (JVT) bezeichnet. Der itu-t H.264-Standard und der ISO/IEC MPEG-4AVC-Standard (formal ISO/IEC 14496-10-MPEG-4 Teil 10, Fortgeschrittene Videocodierung) werden gemeinsam aufrechterhalten, damit sie identische technische Inhalte haben. Die endgültigen Auszeichnungsarbeiten an der ersten Version des Standards wurden im Mai 2003 abgeschlossen, und in den folgenden Ausgaben wurden verschiedene Erweiterungen seiner Fähigkeiten hinzugefügt. Hocheffizienz Videocodierung (HEVC), A.K.A. H.265 und MPEG-H Part 2 sind Nachfolger von H.264/MPEG-4 AVC, das von denselben Organisationen entwickelt wurde, während frühere Standards immer noch gemeinsam verwendet werden.

H.264 ist vielleicht am häufigsten als am häufigsten verwendeten Video -Codierungsformat bekannt Blu-ray-Discs. Es wird auch häufig durch Streaming von Internetquellen verwendet, wie z. B. Videos von Netflix, Hulu, Amazon Prime Video, Vimeo, Youtube, und die iTunes Store, Websoftware wie die Adobe Flash Player und Microsoft Silverlightund auch verschiedene HDTV Sendungen über terrestrisch (Atsc, Isdb-t, DVB-T oder DVB-T2), Kabel (DVB-C) und Satellit (DVB-S und DVB-S2) Systeme.

H.264 ist eingeschränkt durch Patente im Besitz verschiedener Parteien. Eine Lizenz, die die meisten (aber nicht alle) Patente abdecken, die für H.264 unerlässlich sind, wird von a verwaltet Patentpool Verwaltet von Mpeg la.[9]

Die kommerzielle Verwendung 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 zum Streaming von Internetvideos ermöglicht, die für Endbenutzer kostenlos sind, und Cisco -Systeme zahlt Lizenzgebühren an MPEG LA im Namen der Nutzer von Binärdateien für seine Open Source H.264 -Encoder.

Benennung

Der H.264 -Name folgt dem Itu-t Namenskonvention, wobei der Standard ein Mitglied der H.26X -Linie von ist Vceg Videocodierungsstandards; Der MPEG-4-AVC-Name bezieht sich auf die Namenskonvention in ISO/IEC MPEG, wo der Standard Teil 10 von ISO/IEC 14496 ist, was die als MPEG-4 bekannte Standards ist. Der Standard wurde gemeinsam in einer Partnerschaft von VCEG und MPEG nach früheren Entwicklungsarbeiten in der ITU-T als VCEG-Projekt namens H.26L entwickelt. Es ist daher üblich, sich auf den Standard mit Namen wie H.264/AVC, AVC/H.264, H.264/MPEG-4 AVC oder MPEG-4/H.264 AVC zu beziehen, um das gemeinsame Erbe hervorzuheben. Gelegentlich wird es auch als "JVT Codec" bezeichnet, in Bezug auf die gemeinsame Organisation für gemeinsame Videenteams (JVT), die es entwickelt hat. (Eine solche Partnerschaft und mehrere Namensnamen sind beispielsweise nicht ungewöhnlich. Der als MPEG-2 bekannte Videokomprimierungsstandard entstanden ebenfalls aus der Partnerschaft zwischen MPEG und das ITU-T, wo MPEG-2-Video der ITU-T-Community als H.262 bekannt ist.[10]) Einige Softwareprogramme (wie z. VLC Media Player) Identifizieren Sie diesen Standard intern als AVC1.

Geschichte

Gesamtgeschichte

Anfang 1998 die Videocodierungsexperten Gruppe (VCEG-ITU-T SG16 Q.6) gab einen Aufruf für Vorschläge für ein Projekt namens H.26L heraus, wobei das Ziel die Codierungseffizienz (was bedeutet, die für ein gegebene Treue erforderliche Bitrate zu halbieren) im Vergleich zu Alle anderen vorhandenen Videocodierungsstandards für eine Vielzahl von Anwendungen. Vceg wurde von vorgeleitet von Gary Sullivan (Microsoftfrüher Picturetel, UNS.). Der erste Entwurfsentwurf für diesen neuen Standard wurde im August 1999 übernommen. Im Jahr 2000,, Thomas Wiegand (Heinrich Hertz Institute, Deutschland) wurde VCEG-Co-Vorsitzender.

Im Dezember 2001, VCEG und The Moving Picture Experts Group (MPEG- - ISO/IEC JTC 1/SC 29/WG 11) bildete ein gemeinsames Video -Team (JVT) mit der Charta, um den Video -Codierungsstandard abzuschließen.[11] Die formelle Genehmigung der Spezifikation kam im März 2003. Die JVT wurde (ist) unter dem Vorsitz von Gary Sullivan, Thomas Wiegandund ajay luthra (Motorola, USA: später Arris, UNS.). Im Juli 2004 wurde das Projekt der Fidelity Range Extensions (Fext) abgeschlossen. Von Januar 2005 bis November 2007 arbeitete die JVT an einer Erweiterung von H.264/AVC in Richtung Skalierbarkeit durch einen Anhang (g) namens Skalierbare Videocodierung (SVC). Das JVT-Managementteam wurde von Jens-Rainer Ohm (erweitertRWTH Aachen University, Deutschland). Von Juli 2006 bis November 2009 arbeitete die JVT an Multiview Video Coding (MVC), eine Erweiterung von H.264/AVC in Richtung 3D -Fernseher und begrenzter Bereich Free-Viewpoint-Fernsehen. Diese Arbeit beinhaltete die Entwicklung von zwei neuen Profilen des Standards: das hochkarätige Multiview -Hochprofil und das hochkarätige Stereo.

Während der Entwicklung des Standards wurden zusätzliche Nachrichten für die Eindämmung von Zusatzinformationen (SEI) entwickelt. SEI -Nachrichten können verschiedene Arten von Daten enthalten, die das Timing der Videobilder anzeigen oder verschiedene Eigenschaften des codierten Videos beschreiben oder wie es verwendet oder verbessert werden kann. SEI-Nachrichten sind auch definiert, die beliebige benutzerdefinierte Daten enthalten können. SEI-Nachrichten beeinflussen keinen Einfluss auf den Kerndecodierungsprozess, können jedoch angeben, wie das Video empfohlen wird, postbearbeitet oder angezeigt zu werden. Einige andere hochrangige Eigenschaften des Videoinhalts werden in Video Usability Information (VUI) vermittelt, wie z. B. die Anzeige der Farbraum zur Interpretation des Videoinhalts. Als neue Farbräume entwickelt wurden, z. B. für Hoher Dynamikbereich und breites Farbumfang Video wurden zusätzliche VUI -Kennungen hinzugefügt, um sie anzuzeigen.

Zulassungen und professionelle Profile

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 sogenannte Fidelity Range Extensions (FREXT). Diese Erweiterungen ermöglichten eine höhere Videocodierung von höherer Qualität, indem sie eine erhöhte Präzision der Probenbitstiefe und die Farbinformationen mit höherer Auflösung unterstützen, einschließlich der als Stichprobenstrukturen bezeichneten Stichprobenstrukturen Y'cBCR 4: 2: 2 (a.k.a. YUV 4: 2: 2) und 4: 4: 4. Mehrere andere Funktionen wurden ebenfalls im Frext -Projekt enthalten, z. B. das Hinzufügen einer 8 × 8 -Ganzzahl Diskrete Cosinus -Transformation (Ganzzahl DCT) mit adaptivem Umschalten zwischen den 4 × 4- und 8 × 8-Transformationen, von von Encoder spezifizierten Wahrnehmungsbasis quantisierungsbasierten Quantisierungsgewichtungsmatrizen, effizienter inter-impicture-verlustfreies Codieren und Unterstützung zusätzlicher Farbräume. Die Entwurfsarbeiten am Frext -Projekt wurden im Juli 2004 abgeschlossen, und die Entwurfsarbeiten wurden im September 2004 abgeschlossen.

Anschließend wurden fünf weitere neue Profile (siehe Version 7 unten) für professionelle Anwendungen entwickelt. Anschließend wurde der Farbraumunterstützung erweiterten Gamut hinzugefügt, um zusätzliche Seitenverhältnisindikatoren zu definieren, wobei zwei zusätzliche Arten von "ergänzenden Informationen zur Verbesserung" (Post-Filter-Hinweis und Ton festgelegt wurden Mapping) und eine der früheren Fext -Profile (das hohe 4: 4: 4 -Profil) dieses Feedback der Industrie abzubauen[von wem?] angegeben sollte unterschiedlich gestaltet werden.

Skalierbare Videocodierung

Die nächste wichtige Funktion, die dem Standard hinzugefügt wurde, war Skalierbare Videocodierung (SVC). In Anhang G von H.264/AVC angegeben, ermöglicht SVC den Bau von Bitstreams, die enthalten Schichten von Sub-Bitstreams, die auch dem Standard entsprechen, einschließlich eines solchen Bitstreams, der als "Basisschicht" bezeichnet wird, das von einem H.264/AVC dekodiert werden kann Codec Das unterstützt SVC nicht. Für die temporale Bitstream-Skalierbarkeit (d. H. Das Vorhandensein eines Subbitstreams mit einer geringeren zeitlichen Stichprobenrate als der Hauptbitstream) vollständig Zugangseinheiten werden vom Bitstream beim Ableiten des Subbitstreams entfernt. In diesem Fall werden die Syntax- und Interhotionsreferenzbilder im Bitstream entsprechend konstruiert. Andererseits für räumliche und qualitativ hochwertige Bitstream-Skalierbarkeit (d. H. Das Vorhandensein eines Subbitstreams mit geringerer räumlicher Auflösung/Qualität als der Hauptbitstream), das NAL (Netzwerkabstraktionsschicht) wird aus dem Bitstream entfernt, wenn der Subbitstream abgeleitet wird. In diesem Fall wird die Vorhersage zwischen den Schichten (d. H. Die Vorhersage des höheren räumlichen Auflösung/Qualitätssignals aus den Daten der niedrigeren räumlichen Auflösung/Qualitätssignal) typischerweise zur effizienten Codierung verwendet. Das Skalierbare Videocodierung Die Erweiterungen wurden im November 2007 abgeschlossen.

Multiview -Videocodierung

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

3D-AVC- und MFC-stereoskopische Codierung

Später wurden zusätzliche Erweiterungen entwickelt, die die 3D -Videocodierung mit gemeinsamer Codierung von enthielten Tiefenkarten und Textur (als 3D-AVC bezeichnet), multi-auf-rahmenkompatible (MFC) stereoskopisch und 3D-MFC-Codierung, verschiedene zusätzliche Kombinationen von Merkmalen sowie höhere Rahmengrößen und -bildungsraten.

Versionen

Die Versionen des H.264/AVC-Standards umfassen die folgenden abgeschlossenen Revisionen, Corrigenda und Änderungen (Daten sind die endgültigen Zulassungsdaten in ITU-T, während die endgültigen "internationalen Standard" -Nimmiggabentechnik in ISO/IEC etwas unterschiedlich und etwas später in den meisten Fällen sind Fälle). Jede Version stellt Änderungen in Bezug auf die nächste niedrigere Version dar, die in den Text integriert ist.

  • Version 1 (Ausgabe 1): (30. Mai 2003) Erste genehmigte Version von H.264/AVC mit Basis-, Haupt- und erweiterten Profilen.[12]
  • Version 2 (Ausgabe 1.1): (7. Mai 2004) Corrigendum mit verschiedenen kleineren Korrekturen.[13]
  • Version 3 (Ausgabe 2): (1. März 2005) Hauptabschluss, die die erste Änderung enthält, die die Erweiterungen der Treue -Reichweite festlegt (FREXT). Diese Version fügte die High, High 10, High 4: 2: 2 und High 4: 4: 4 Profile hinzu.[14] Nach einigen Jahren wurde das hohe Profil zum am häufigsten verwendeten Profil des Standards.
  • Version 4 (Ausgabe 2.1): (13. September 2005) Corrigendum mit verschiedenen kleineren Korrekturen und Hinzufügen von drei Seitenverhältnissindikatoren.[15]
  • Version 5 (Ausgabe 2.2): (13. Juni 2006) Änderung bestehend aus der Entfernung des vorherigen High 4: 4: 4 -Profils (verarbeitet als Korrigendum in ISO/IEC).[16]
  • Version 6 (Ausgabe 2.2): (13. Juni 2006) Änderung, bestehend aus kleineren Erweiterungen wie dem Farbraumunterstützung für erweitertes Gamut (gebündelt mit oben genannten Seitenverhältnissindikatoren in ISO/IEC).[16]
  • Version 7 (Ausgabe 2.3): (6. April 2007) Änderung, die die Zugabe des hohen 4: 4: 4-Vorhersageprofils und vier intra-Profile (High 10 Intra, High 4: 2: 2 Intra, High 4: 4) enthält : 4 Intra und Cavlc 4: 4: 4 Intra).[17]
  • Version 8 (Ausgabe 3): (22. November 2007) Hauptabbau zu H.264/AVC mit der Änderung für Skalierbare Videocodierung (SVC) mit skalierbaren Basislinien, skalierbarem hohen und skalierbaren hohen Intra -Profilen.[18]
  • Version 9 (Ausgabe 3.1): (13. Januar 2009) Corrigendum mit kleineren Korrekturen.[19]
  • Version 10 (Ausgabe 4): (16. März 2009) Änderung mit Definition eines neuen Profils (das eingeschränkte Basisprofil) mit nur der gemeinsamen Teilmenge der in verschiedenen zuvor angegebenen Profilen unterstützten Funktionen.[20]
  • Version 11 (Ausgabe 4): (16. März 2009) Hauptabbau zu H.264/AVC mit der Änderung für Multiview Video Coding (MVC) Erweiterung, einschließlich des hochkarätigen Multiviews.[20]
  • Version 12 (Ausgabe 5): (9. März 2010) Änderung mit Definition eines neuen MVC-Profils (das Stereo-Hochprofil) für die Zwei-View-Videocodierung mit Unterstützung von Interlaced-Codierungs-Tools und Angabe einer zusätzlichen zusätzlichen Verbesserungsinformationsnachricht (SEI) Bezeichnung der SEI -Nachricht von Frame Packing Arrangement.[21]
  • Version 13 (Ausgabe 5): (9. März 2010) Corrigendum mit kleineren Korrekturen.[21]
  • Version 14 (Ausgabe 6): (29. Juni 2011) Änderung der Änderung der neuen Ebene (Stufe 5.2), die höhere Verarbeitungsraten in Bezug des zuvor angegebenen hochkarätigen.[22]
  • Version 15 (Ausgabe 6): (29. Juni 2011) Corrigendum mit kleineren Korrekturen.[22]
  • Version 16 (Ausgabe 7): (13. Januar 2012) Änderung mit Definition von drei neuen Profilen, die hauptsächlich für Echtzeit-Kommunikationsanwendungen vorgesehen sind: Die eingeschränkte hohe, skalierbare Basislinie und skalierbare, eingeschränkte hohe Profile.[23]
  • Version 17 (Ausgabe 8): (13. April 2013) Änderung mit zusätzlichen SEI -Nachrichtenanzeigen.[24]
  • Version 18 (Ausgabe 8): (13. April 2013) Änderung zum Festlegen der Codierung von Tiefenkartendaten für stereoskopische 3D -Videos, einschließlich eines hochkarätigen Multiview -Tiefens.[24]
  • Version 19 (Ausgabe 8): (13. April 2013) Corrigendum, um einen Fehler im Sub-Bitstream-Extraktionsprozess für Multiview-Video zu korrigieren.[24]
  • Version 20 (Ausgabe 8): (13. April 2013) Änderung zur Angabe zusätzlicher Farbraum Kennungen (einschließlich Unterstützung von ITU-R-Empfehlung BT.2020 zum Uhdtv) und ein zusätzlicher Modelltyp in der Tone Mapping -Informationen SEI -Nachricht.[24]
  • Version 21 (Ausgabe 9): (13. Februar 2014) Änderung zum Festlegen des erweiterten Hochkörper -Tiefens.[25]
  • Version 22 (Ausgabe 9): (13. Februar 2014) Änderung zur Angabe der Mehrauflösungsrahmenverbesserung (MFC) für 3D-stereoskopische Videos, dem hochkarätigen MFC-Hochprofil und der geringfügigen Korrekturen.[25]
  • Version 23 (Ausgabe 10): (13. Februar 2016) Änderung zur Angabe des stereoskopischen MFC-Videos mit Tiefenkarten, dem hohen Profil der MFC-Tiefe, der Mastering-SEI-Nachricht und zusätzlichen farbbezogenen VUI-CodePoint-Kennungen.[26]
  • Version 24 (Ausgabe 11): (14. Oktober 2016) Änderung zur Angabe zusätzlicher Ebenen der Decoder -Fähigkeit, die größere Bildgrößen (Stufen 6, 6.1 und 6.2), die SEI -Nachricht von Green Metadata, die SEI -Nachricht der alternativen Tiefe und zusätzliche Unterstützung festlegen Farbbezogene VUI-CodePoint-Kennungen.[27]
  • Version 25 (Ausgabe 12): (13. April 2017) Änderung zum Angeben des progressiven High 10 -Profils, Hybrid log -gamma (HLG) und zusätzliche farbbezogene VUI-Codepunkte und SEI-Nachrichten.[28]
  • Version 26 (Ausgabe 13): (13. Juni 2019) Änderung zum Angeben zusätzlicher SEI-Nachrichten für Umgebungsumgebung, Inhaltsniveaus Informationen, Inhaltsfarbvolumen, Equirectangular-Projektion, Cubemap-Projektion, Sphere-Rotation, Region-Weise-Packung, Omnidirektionalansicht, Ansichtspflege, Ansichtspflege, Ansichtspflicht, Ansichtspflicht, Ansichtspflege, Ansichtspflege, Ansicht nach Omnidirektion, SEI Manifest und SEI Präfix.[29]
  • Version 27 (Ausgabe 14): (22. August 2021) Änderung zum Festlegen zusätzlicher SEI -Nachrichten für kommentierte Regionen und Verschlussintervallinformationen sowie verschiedene kleinere Korrekturen und Klarstellungen.[30]

Patentinhaber

Weitere Informationen: Mpeg la
Ein Teil dieses Abschnitts ist transkludiert aus Mpeg la. (Bearbeiten | Geschichte)

Die folgenden Organisationen veranstalten ein oder mehrere Patente in MPEG LA's H.264/AVC Patentpool.

H.264/AVC -Patentinhaber (ab November 2020)[31]
Organisation[32] Aktive Patente Abgelaufene Patente Gesamtpatente[31]
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 Society 125 16 141
Google 136 3 139
Ge Video-Kompression 136 0 136
Fujitsu 92 14 106
Mitsubishi Electric 54 50 104
Tagivan II llc 77 0 77
Samsung Electronics 23 40 63
Maxell 51 2 53
Philips 5 39 44
Vidyo 41 2 43
Ericsson 34 0 34
Electronics and Telecommunications Research Institute (Etri) von Korea 32 0 32

Anwendungen

Weitere Informationen: Liste der Videodienste mit H.264/MPEG-4 AVC

Das H.264-Videoformat verfügt über einen sehr breiten Anwendungsbereich, in dem alle Formen digitaler komprimierter Video von Internet-Streaming-Anwendungen mit niedrigem Bitrate bis hin zu HDTV-Rundfunk- und digitalen Kinoanwendungen mit nahezu verlustfreier Codierung abdeckt. Mithilfe von H.264, Bit -Rate -Einsparungen von 50% oder mehr im Vergleich zu MPEG-2 Teil 2 sind gemeldet. Zum Beispiel wurde berichtet, dass H.264 dieselbe digitale Satelliten-TV-Qualität wie aktuelle MPEG-2-Implementierungen mit weniger als der Hälfte des Bitrate ergeben, wobei aktuelle MPEG-2-Implementierungen bei rund 3,5 Mbit/s und H.264 bei nur 1,5 funktionieren Mbit/s.[33] Sony behauptet, dass der 9 -Mbit/S -AVC -Aufzeichnungsmodus der Bildqualität der Bildqualität entspricht HDV Format, das ungefähr 18–25 mbit/s verwendet.[34]

Um die Kompatibilität und problemfreie Einführung von H.264/AVC zu gewährleisten, haben viele Normenkörper ihre Video-bezogenen Standards geändert oder hinzugefügt, damit Benutzer dieser Standards H.264/AVC verwenden können. Beide Blu-Ray Disc Format und jetzt diskontiert HD DVD Das Format umfasst das Hochprofil H.264/AVC als eines von drei obligatorischen Videokomprimierungsformaten. Das digitale Video -Übertragungsprojekt (DVB) Genehmigte die Verwendung von H.264/AVC für Broadcast -Fernsehen Ende 2004.

Das Advanced Television Systems Committee (ATSC) Standards Body in den Vereinigten Staaten genehmigte die Verwendung von H.264/AVC für das Rundfunkfernsehen im Juli 2008, obwohl der Standard für feste ATSC -Sendungen in den USA noch nicht verwendet wird.[35][36] Es wurde auch für die Verwendung mit den neueren genehmigt ATSC-M/H (Mobile/Handheld) Standard, unter Verwendung der AVC- und SVC -Teile von H.264.[37]

Das CCTV (Geschlossenes Schaltkreis -Fernseher) und Videoüberwachung Die Märkte haben die Technologie in vielen Produkten einbezogen.

Viele gemeinsam DSLRS Verwenden Sie H.264 -Videos, die in QuickTime MOV -Container als natives Aufnahmebildformat eingewickelt sind.

Abgeleitete Formate

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

AVC-Intra ist ein Intraframe-Nur Komprimierungsformat, entwickelt von Panasonic.

Xavc ist ein von Sony entworfenes Aufnahmeformat, das Level 5.2 von H.264/MPEG-4 AVC verwendet, das von diesem Videostandard unterstützt wird.[38][39] Xavc kann unterstützen 4K -Auflösung (4096 × 2160 und 3840 × 2160) bei bis zu 60Bilder pro Sekunde (FPS).[38][39] Sony hat angekündigt, dass Kameras, die XAVC unterstützen Cinealta Kameras-der Sony PMW-F55 und Sony PMW-F5.[40] Der Sony PMW-F55 kann XAVC mit einer Auflösung von 4K bei 30 fps bei 300 aufnehmen Mbit/s und 2K -Auflösung bei 30 fps bei 100 mbit/s.[41] XAVC kann eine 4K -Auflösung bei 60 fps mit 4: 2: 2 Chroma -Probenahme bei 600 Mbit/s aufnehmen.[42][43]

Entwurf

Merkmale

Blockdiagramm von H.264

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

  • Multi-Picture Inter-Picture-Vorhersage einschließlich der folgenden Funktionen:
    • Die Verwendung zuvor codierter Bilder als Referenzen in viel flexiblerer Weise als in früheren Maßstäben, sodass in einigen Fällen bis zu 16 Referenzrahmen (oder 32 Referenzfelder bei Interlaced -Codierung) verwendet werden können. In Profilen, die nicht unterstützenIDR Rahmen, die meisten Ebenen geben an, dass eine ausreichende Pufferung verfügbar sein sollte, um mindestens 4 oder 5 Referenzrahmen bei maximaler Auflösung zu ermöglichen. Dies steht im Gegensatz zu früheren Standards, bei denen die Grenze normalerweise eine betrug; oder im Fall von konventionell "B Bilder"(B-Frames), zwei.
    • Variable Blockgröße Bewegungskompensation (VBSMC) mit Blockgrößen von bis zu 16 × 16 und nur 4 × 4, was eine präzise Segmentierung von beweglichen Regionen ermöglicht. Das unterstützte Luma Vorhersageblockgrößen umfassen 16 × 16, 16 × 8, 8 × 16, 8 × 8, 8 × 4, 4 × 8 und 4 × 4, von denen viele in einem einzelnen Makroblock zusammen verwendet werden können. Chroma -Vorhersageblockgrößen sind entsprechend kleiner, wenn Chroma -Subsampling wird genutzt.
    • Die Fähigkeit, mehrere Bewegungsvektoren pro Makroblock (ein oder zwei pro Partition) mit maximal 32 zu verwenden, wenn ein B -Makroblock aus 16 4 × 4 -Partitionen erstellt wurde. Die Bewegungsvektoren für jeden 8 × 8 oder größeren Partitionsbereich können auf verschiedene Referenzbilder hinweisen.
    • Die Möglichkeit, einen Makroblocktyp in zu verwenden B-Frames, einschließlich I-Macroblocks, was bei Verwendung von B-Frames zu viel effizienterer Codierung führt. Diese Funktion wurde besonders ausgelassen MPEG-4 ASP.
    • Sechs-Tap-Filterung zur Ableitung von Halbpel-Luma-Probenvorhersagen für schärfere Subpixelbewegungskompensation. Die Viertelpixelbewegung wird durch lineare Interpolation der Halfpixelwerte abgeleitet, um die Verarbeitungsleistung zu sparen.
    • Viertelpixel Präzision für die Bewegungskompensation, die genaue Beschreibung der Verschiebungen von beweglichen Bereichen ermöglicht. Zum Chroma Die Auflösung wird typischerweise sowohl vertikal als auch horizontal halbiert (siehe 4: 2: 0) Daher verwendet die Bewegungskompensation von Chroma ein Achtel-Chroma-Pixel-Gitter-Einheiten.
    • Gewichtete Vorhersage, die es einem Encoder ermöglicht, die Verwendung einer Skalierung und Offset bei der Durchführung der Bewegungskompensation anzugeben und in besonderen Fällen einen erheblichen Leistungsvorteil zu erzielen-wie Fade to-Black, Fade-In und Cross-Fade-Übergänge. Dies umfasst die implizite gewichtete Vorhersage für B-Frames und explizite gewichtete Vorhersage für P-Frames.
  • Räumliche Vorhersage von den Rändern benachbarter Blöcke für "Intra" Codierung und nicht die "DC"--nur in MPEG-2 Teil 2 gefundene Vorhersage und die in H.263v2 und MPEG-4 Teil 2 gefundene Vorhersage des Transformationskoeffizienten. Dies umfasst LUMA-Vorhersageblockgrößen von 16 × 16, 8 × 8, und 4 × 4 (von denen jeweils nur ein Typ verwendet werden kann Makroblock).
  • Ganze Zahl Diskrete Cosinus -Transformation (Ganzzahl DCT),[6][8][44] Eine Art diskreter Cosinus -Transformation (DCT)[8] wobei die Transformation eine Ganzzahl -Näherung des Standard -DCT ist.[45] Es hat wählbare Blockgrößen[7] und genaue Integer-Berechnung der genauen Match-Match, um die Komplexität zu verringern, einschließlich:
    • Eine Ganzzahl genau 4 × 4 räumliche Blocktransformation, die eine präzise Platzierung von ermöglicht Restwert Signale mit wenig von dem "Klingeln"Oft mit früheren Codec-Designs gefunden. Es ähnelt dem in früheren Standards verwendeten Standard-DCT, verwendet jedoch eine kleinere Blockgröße und eine einfache Ganzzahlverarbeitung. Im Gegensatz zu den in früheren Standards ausgedrückten Kosinus-basierten Formeln und Toleranzen (wie H.261 und MPEG-2), Integer-Verarbeitung liefert ein genau bestimmtes dekodiertes Ergebnis.
    • Eine Ganzzahl genau 8 × 8 räumliche Blocktransformation, wodurch hochkorrelierte Regionen effizienter komprimiert werden können als bei der 4 × 4-Transformation. Dieses Design basiert auf dem Standard -DCT, aber vereinfacht und hergestellt, um genau bestimmte Decodierung zu liefern.
    • Adaptive Encoder -Selektion zwischen 4 × 4 und 8 × 8 -Transformationsblockgrößen für den Integer -Transformationsvorgang.
    • Eine sekundäre Hadamard -Transformation durchgeführt an "DC" -Koeffizienten der primären räumlichen Transformation, die auf Chroma DC -Koeffizienten (und auch Luma in einem Sonderfall) angewendet wird, um noch mehr Komprimierung in glatten Regionen zu erhalten.
  • Verlustlos Makroblock -Codierungsfunktionen einschließlich:
    • Ein verlustfreier "PCM -Makroblock" -Rearationsmodus, in dem Videodatenproben direkt dargestellt werden,[46] Ermöglicht eine perfekte Darstellung bestimmter Regionen und Ermöglichung einer strikten Grenze für die Menge der codierten Daten für jedes Makroblock.
    • Ein verbesserter, verlustfreier Makroblock -Repräsentationsmodus, der eine perfekte Darstellung bestimmter Regionen ermöglicht, während normalerweise wesentlich weniger Bits als der PCM -Modus verwendet werden.
  • Flexibel verschachtelt-Scan -Videocodierungsfunktionen, einschließlich:
    • MBAFF-Codierung (Makroblock-Adaptive Frame-Field) unter Verwendung einer Makroblockpaarstruktur für Bilder, die als Frames codiert sind und 16 × 16 Makroblocks im Feldmodus ermöglichen (im Vergleich zu MPEG-2, wobei die Verarbeitung des Feldmodus in einem Bild, das als Frame codiert wird, codiert wird führt zur Verarbeitung von 16 × 8-Halb-Makroblocks).
    • Bilder-adaptive Frame-Feld-Codierung (PAFF oder PICAFF), die eine frei ausgewählte Mischung von Bildern ermöglichen, die entweder als vollständige Rahmen codiert werden, bei denen beide Felder zur Codierung oder als einzelne einzelne Felder kombiniert werden.
  • Ein Quantisierungsdesign einschließlich:
    • Logarithmische Stufengrößenregelung für das einfachere Bit-Rate-Management durch Encoder und eine vereinfachte Inverse-Quantisierungsskalierung
    • Frequenz-kuddomisierte Quantisierungsskalierungsmatrizen, die vom Encoder für die auf wahrnehmungsbasierte Quantisierungsoptimierung ausgewählt wurden
  • Eine In-Schleife Entblockerfilter Dies verhindert die Blockierungsartefakte, die anderen DCT-basierten Bildkomprimierungstechniken gemeinsam sind, was zu einem besseren visuellen Erscheinungsbild und Komprimierungseffizienz führt
  • Ein Entropie -Codierung Design einschließlich:
    • Kontext-adaptive binäre arithmetische Kodierung (CABAC), ein Algorithmus zur Verlustlosigkeit Syntaxelemente im Videostrom, die die Wahrscheinlichkeiten von Syntaxelementen in einem bestimmten Kontext kennt. CABAC komprimiert Daten effizienter als CAVLC, erfordert jedoch erheblich mehr Verarbeitung, um zu dekodieren.
    • Kontext-adaptive Codierung variabler Länge (CAVLC), eine Alternative mit niedrigerer Komplexität zu CABAC für die Kodierung quantisierter Transformationskoeffizientenwerte. Obwohl CAVLC eine geringere Komplexität als CABAC ist, ist er ausführlicher und effizienter als die Methoden, die typischerweise verwendet werden, um Koeffizienten in anderen früheren Konstruktionen zu codieren.
    • Ein häufiger einfacher und hoch strukturierter Variable Längencodierung (VLC) -Technik für viele der Syntaxelemente, die nicht von CABAC oder CAVLC codiert werden, wie bezeichnet als als Exponential-Golomb-Codierung (oder exp-golomb).
  • Merkmale der Verlustresilienz, einschließlich:
    • A Netzwerkabstraktionsschicht (NAL) Definition, die es ermöglicht, dieselbe Video -Syntax in vielen Netzwerkumgebungen zu verwenden. Ein sehr grundlegendes Designkonzept von H.264 besteht darin, in sich geschlossene Pakete zu generieren, um die Header-Duplikation wie im Header-Erweiterungscode (HEC) von MPEG-4 zu entfernen.[47] Dies wurde durch Entkopplung von Informationen erreicht, die für mehr als eine Sicht aus dem Medienstrom relevant sind. Die Kombination der Parameter höherer Ebene wird als Parametersatz bezeichnet.[47] Die H.264 -Spezifikation enthält zwei Arten von Parametersätzen: Sequence Parameter Set (SPS) und Bildparametersatz (PPS). Ein aktiver Sequenzparametersatz bleibt in einer codierten Videosequenz unverändert, und ein aktiver Bildparametersatz bleibt in einem codierten Bild unverändert. Die Sequenz- und Bildparameter -Set -Strukturen enthalten Informationen wie Bildgröße, optionale Codierungsmodi und Makroblock, um die Gruppenkarte zu schneiden.[47]
    • Flexible Makroblockbestellung (FMO), auch als Slice -Gruppen bekannt, und willkürliche Slice -Bestellung (ASO), die Techniken zur Umstrukturierung der Reihenfolge der Darstellung der Grundregionen sind (Makroblocks) in Bildern. In der Regel als Fehler-/Verlust -Robustheitsfunktion betrachtet, können FMO und ASO auch für andere Zwecke verwendet werden.
    • Data Partitioning (DP), eine Funktion, die die Möglichkeit bietet, wichtigere und weniger wichtige Syntaxelemente in verschiedene Datenpakete zu trennen, wodurch die Anwendung des ungleichen Fehlerschutzes (UEP) und anderen Arten der Verbesserung der Fehler-/Verlustwiedervermögen ermöglicht wird.
    • Redundante Slices (RS), eine Fehler-/Verlust -Robustheit -Funktion, mit der ein Encoder eine zusätzliche Darstellung eines Bildbereichs (normalerweise bei niedrigerer Treue) senden kann, die verwendet werden kann, wenn die primäre Darstellung beschädigt oder verloren geht.
    • Rahmennummerierung, eine Funktion, die die Erstellung von "Subsequenzen" ermöglicht und die zeitliche Skalierbarkeit durch optionale Einbeziehung zusätzlicher Bilder zwischen anderen Bildern sowie die Erkennung und Verschleierung von Verlusten ganzer Bilder ermöglicht, die aufgrund von Netzwerkpaketverlusten oder -kanälen auftreten können Fehler.
  • Schalten Sie Scheiben, die als SP- und Si -Scheiben bezeichnet werden und es einem Encoder ermöglicht, einen Decoder zu leiten, um für Zwecke wie Video -Streaming -Bit -Rate -Switching und "Trick -Modus" -Operationsbetrieb in einen laufenden Video -Stream zu springen. Wenn ein Decoder mit der SP/SI -Funktion in die Mitte eines Videostreams springt, kann er genau zu den dekodierten Bildern an diesem Ort im Video -Stream übereinstimmen Der Schalter.
  • Ein einfacher automatischer Prozess zur Verhinderung der versehentlichen Emulation von Startcodes, die spezielle Sequenzen von Bits in den codierten Daten sind, die einen zufälligen Zugriff auf den Bitstream und die Wiederherstellung der Byte -Ausrichtung in Systemen ermöglichen, die die Byte -Synchronisation verlieren können.
  • Zusätzliche Informationen zur Verbesserung (SEI) und Video Usability -Informationen (VII), die zusätzliche Informationen sind, die für verschiedene Zwecke in den Bitstream eingefügt werden können, z. SEI-Nachrichten können beliebige benutzerdefinierte Metadaten-Nutzlasten oder andere Nachrichten mit Syntax und Semantik im Standard enthalten.
  • Hilfsbilder, die für die Zwecke wie solche Zwecke verwendet werden können Alpha -Kompositing.
  • Unterstützung des Monochroms (4: 0: 0), 4: 2: 0, 4: 2: 2 und 4: 4: 4: 4 Chroma -Probenahme (abhängig vom ausgewählten Profil).
  • Unterstützung der Probenbit -Tiefenpräzision im Bereich von 8 bis 14 Bit pro Probe (abhängig vom ausgewählten Profil).
  • Die Fähigkeit, einzelne Farbebenen als unterschiedliche Bilder mit eigenen Scheibenstrukturen, Makroblockmodi, Bewegungsvektoren usw. zu codieren, sodass Encoder mit einer einfachen Parallelisierungsstruktur ausgelegt werden können (nur in den drei 4: 4: 4: 4-fähigen Profilen unterstützt) .
  • Bildreihenfolge, eine Funktion, die dazu dient, die Bestellung der Bilder und die Werte von Proben in den dekodierten Bildern aus Timing -Informationen isoliert zu halten, sodass Timing -Informationen durch ein System getrennt werden und kontrolliert/geändert werden können, ohne dekodierte Bildinhalte zu beeinflussen.

Diese Techniken helfen zusammen mit mehreren anderen H.264, unter einer Vielzahl von Umständen in einer Vielzahl von Anwendungsumgebungen deutlich besser zu funktionieren als jeder vorherige Standard. H.264 kann häufig radikal besser abschneiden als MPEG-2-Video-und erhalten typisch die gleiche Qualität bei der Hälfte der Bitrate oder weniger, insbesondere bei hohen Bitrate und hohen Videoinhalten.[48]

Wie andere ISO/IEC -MPEG -Videostandards verfügt H.264/AVC über eine Referenzsoftware -Implementierung, die frei heruntergeladen werden kann.[49] Der Hauptzweck ist es, Beispiele für H.264/AVC -Funktionen zu geben, anstatt eine nützliche Anwendung zu sein an sich. Einige Referenz -Hardware -Designarbeiten wurden auch in der durchgeführt Experten für bewegte Bildexperten. Die oben genannten Aspekte enthalten Merkmale in allen Profilen von H.264. Ein Profil für einen Codec ist eine Reihe von Funktionen dieses Codec, das eine bestimmte Reihe von Spezifikationen beabsichtigter Anwendungen erfüllt. Dies bedeutet, dass viele der aufgeführten Funktionen in einigen Profilen nicht unterstützt werden. Verschiedene Profile von H.264/AVC werden im nächsten Abschnitt erörtert.

Profile

Der Standard definiert mehrere Funktionen von Funktionen, die als als bezeichnet werden Profile, zielen auf bestimmte Anwendungsklassen. Diese werden mit einem Profilcode (Profil_IDC) und manchmal einer Reihe zusätzlicher Einschränkungen im Encoder deklariert. Der Profilcode und angegebene Einschränkungen ermöglichen es einem Decoder, die Anforderungen für die Dekodierung dieses spezifischen Bitstream zu erkennen. (Und in vielen Systemumgebungen dürfen nur ein oder zwei Profile verwendet werden, sodass Decoder in diesen Umgebungen nicht mit der Erkennung der weniger häufig verwendeten Profile befasst sein müssen.) Das bei weitem am häufigsten verwendete Profil ist das hohe Profil.

Die Profile für nicht skalierbare 2D-Videoanwendungen enthalten die folgenden:

Eingeschränktes Basisprofil (CBP, 66 mit Einschränkungssatz 1)
In erster Linie für kostengünstige Anwendungen wird dieses Profil in der Regel in Videokonferenzen und mobilen Anwendungen verwendet. Es entspricht der Teilmenge der Merkmale, die zwischen den Basis-, Haupt- und hohen Profilen gemeinsam sind.
Basisprofil (BP, 66)
In erster Linie für kostengünstige Anwendungen, die zusätzliche Datenverlust-Robustheit erfordern, wird dieses Profil in einigen Videokonferenz- und mobilen Anwendungen verwendet. Dieses Profil enthält alle Funktionen, die im eingeschränkten Basisprofil unterstützt werden, sowie drei zusätzliche Funktionen, die für die Robustheit der Verlust verwendet werden können (oder für andere Zwecke, wie z. Die Bedeutung dieses Profils ist seit der Definition des eingeschränkten Basisprofils im Jahr 2009 etwas verblasst. Alle eingeschränkten Basisprofile Bitstreams gelten auch als Basisprofil -Bitstreams, da diese beiden Profile den gleichen Profilkenner -Codewert teilen.
Erweitertes Profil (XP, 88)
Dieses Profil ist als Streaming -Videoprofil vorgesehen und verfügt über eine relativ hohe Komprimierungsfunktion und einige zusätzliche Tricks für die Robustheit gegenüber Datenverlusten und Serverstream -Switching.
Hauptprofil (MP, 77)
Dieses Profil wird für digitale TV-Sendungen für Standarddefinition verwendet, die das MPEG-4-Format wie im DVB-Standard definiert werden.[50] Es wird jedoch nicht für hochauflösende Fernsehsendungen verwendet, da die Bedeutung dieses Profils nach dem Hochprofil im Jahr 2004 für diese Anwendung verblasste.
Hochkarätig (hip, 100)
Das primäre Profil für Rundfunk- und Disc-Speicheranwendungen, insbesondere für hochauflösende Fernsehanwendungen (z. B. ist dies das Profil, das von der angewendet wird Blu-Ray Disc Speicherformat und das DVB HDTV Broadcast Service).
Progressives Hochprofil (PhIP, 100 mit Einschränkung Set 4)
Ähnlich wie das hohe Profil, jedoch ohne Unterstützung von Feldcodierungsfunktionen.
Eingeschränkte Hochkörper (100 mit Einschränkungsatz 4 und 5)
Ähnlich wie das progressive hochkarätige, aber ohne Unterstützung von B (bi-vorhersage) Scheiben.
Hoch 10 Profil (Hi10p, 110)
Dieses Profil über die typischen Mainstream -Konsumgüterproduktfunktionen über dem Hochkörper erstellt.
Hoch 4: 2: 2 Profil (Hi422p, 122)
In erster Linie richtet sich dieses Profil auf professionelle Anwendungen, die Interlaced -Video verwenden. Er baut auf dem hohen 10 -Profil auf und fügt Unterstützung für 4: 2: 2 hinzu Chroma -Probenahme Format bei Verwendung von bis zu 10 Bit pro Probe dekodierter Bildpräzision.
Hoch 4: 4: 4 Vorhersageprofil (HI444PP, 244)
Dieses Profil baut auf dem High 4: 2: 2 -Profil auf und unterstützt bis zu 4: 4: 4 Chroma -Probenahme, bis zu 14 Bit pro Probe und unterstützt zusätzlich eine effiziente, verlustfreie Region -Codierung und die Codierung jedes Bildes als drei separate Farbe Flugzeuge.

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

Hoch 10 Intra -Profil (110 mit Einschränkungssatz 3)
Das hohe 10-Profil, das auf die All-Intra-Verwendung beschränkt ist.
Hoch 4: 2: 2 Intra -Profil (122 mit Einschränkungssatz 3)
Das hohe 4: 2: 2-Profil, das auf die Verwendung der All-Intra-Verwendung beschränkt ist.
Hoch 4: 4: 4 Intra -Profil (244 mit Einschränkung Set 3)
Das hohe 4: 4: 4-Profil, das auf die Verwendung der All-Intra-Verwendung beschränkt ist.
CAVLC 4: 4: 4 Intra -Profil (44)
Das hohe 4: 4: 4-Profil, das auf die Verwendung der All-Intra-Verwendung und die CAVLC-Entropie-Codierung beschränkt ist (d. H. Nicht unterstützende CABAC).

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

Skalierbares Basisprofil (83)
Dieses Profil zielt hauptsächlich auf Videokonferenzen, mobile und Überwachungsanwendungen ab und erstellt oben auf dem eingeschränkten Basisprofil, dem die Basisschicht (eine Teilmenge des Bitstreams) entsprechen muss. Für die Skalierbarkeitstools ist eine Teilmenge der verfügbaren Tools aktiviert.
Skalierbares Basisprofil (83 mit Einschränkungssatz 5)
Eine Teilmenge des skalierbaren Basisprofils, das hauptsächlich für Echtzeit-Kommunikationsanwendungen bestimmt ist.
Skalierbares Hochkörper (86)
Dieses Profil richtet sich hauptsächlich auf Broadcast- und Streaming -Anwendungen ab und erstellt oben auf dem Hochprofil H.264/AVC, dem die Basisschicht entsprechen muss.
Skalierbares, begrenztes Hochprofil (86 mit Einschränkungssatz 5)
Eine Teilmenge des skalierbaren hochkarätigen, hauptsächlich für Echtzeit-Kommunikationsanwendungen vorgesehen.
Skalierbares hohes Intra -Profil (86 mit Einschränkungssatz 3)
Dieses Profil ist in erster Linie die Produktionsanwendungen und ist die skalierbare hochkarätige, die auf die All-Intra-Verwendung beschränkt ist.

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

Stereo hochkarätig (128)
Dieses Profil zielt auf zwei Ansicht stereoskopisch 3D-Video und kombiniert die Tools des Hochkörpers mit den Vorhersagefunktionen der MVC-Erweiterung.
Multiview High Profile (118)
Dieses Profil unterstützt zwei oder mehr Ansichten sowohl mit Inter-Impicture (Temporal) als auch mit MVC-Inter-View-Vorhersage, unterstützt jedoch keine Feldbilder und Makroblock-Adaptive-Frame-Feld-Codierung.

Die MFC-Erweiterung (Multi-Auflösungsrahmenkompatible) fügte zwei weitere Profile hinzu:

MFC High Profil (134)
Ein Profil für die stereoskopische Codierung mit einer Verbesserung der zweischichtigen Auflösung.
MFC -Tiefe Hochprofil (135)

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

Multiview -Tiefe Hochprofil (138)
Dieses Profil unterstützt die gemeinsame Codierung von Tiefenkarte und Video -Texturinformationen für eine verbesserte Komprimierung von 3D -Videoinhalten.
Verbessertes Multiview -Tiefe Hochprofil (139)
Ein erweitertes Profil für die kombinierte Multiview -Codierung mit Tiefeninformationen.

Feature -Unterstützung in bestimmten Profilen

Feature CBP Bp XP MP Prohip Hüfte Hi10p Hi422p Hi444PP
Ich und P Slices Ja Ja Ja Ja Ja Ja Ja Ja Ja
Bitstiefe (pro Probe) 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 Ja Ja Nein Nein Nein Nein Nein Nein
Willkürliche Slice Ordering (ASO) Nein Ja Ja Nein Nein Nein Nein Nein Nein
Redundante Scheiben (Rs) Nein Ja Ja Nein Nein Nein Nein Nein Nein
Datenpartitionierung Nein Nein Ja Nein Nein Nein Nein Nein Nein
SI- und SP -Scheiben Nein Nein Ja Nein Nein Nein Nein Nein Nein
Interlaced Codierung (Picaff, Mbaff) Nein Nein Ja Ja Nein Ja Ja Ja Ja
B Scheiben Nein Nein Ja Ja Ja Ja Ja Ja Ja
Mehrere Referenzrahmen Ja Ja Ja Ja Ja Ja Ja Ja Ja
In-Loop-Entblockerfilter Ja Ja Ja Ja Ja Ja Ja Ja Ja
CAVLC -Entropie -Codierung Ja Ja Ja Ja Ja Ja Ja Ja Ja
CABAC -Entropie -Codierung 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 Transformation Adaptivität Nein Nein Nein Nein Ja Ja Ja Ja Ja
Quantisierungsskalierungsmatrizen Nein Nein Nein Nein Ja Ja Ja Ja Ja
Getrennt cB und CR QP -Kontrolle Nein Nein Nein Nein Ja Ja Ja Ja Ja
Separate Farbebene -Codierung Nein Nein Nein Nein Nein Nein Nein Nein Ja
Prädiktive verlustfreie Codierung Nein Nein Nein Nein Nein Nein Nein Nein Ja

Ebenen

Da der Begriff im Standard verwendet wird, ist a "eben"Ist ein bestimmter Satz von Einschränkungen, die einen Grad der erforderlichen Decoderleistung für ein Profil anzeigen. Beispielsweise gibt ein Unterstützungsniveau innerhalb eines Profils die maximale Bildauflösung, die Bildrate und die Bitrate an, die ein Decoder verwendet. Ein Decoder, das entspricht einem bestimmten Level müssen in der Lage sein, alle für diese Ebene und alle niedrigeren Ebenen codierten Bitstreams zu dekodieren.

Ebenen mit maximalen Eigenschaftswerten[28]
Eben
 Maximal
Decodierungsgeschwindigkeit
(Makroblock/s)		 Maximal
Rahmengröße
(Makroblock)		 Maximales Video
Bitrate für Video
Codierungsschicht (VCL)
(Eingeschränkte Grundlinie,
Grundlinie, erweitert
und Hauptprofile)
(Kbits/s)		 Beispiele für hohe Auflösung
@ höchste Bildrate
(Maximal gespeicherte Frames)
Weitere Details umschalten
1 1.485 99 64 176 x [email protected] (4)
1b 1.485 99 128 176 x [email protected] (4)
1.1 3.000 396 192 352 x [email protected] (2)
1.2 6.000 396 384 352 x [email protected] (6)
1.3 11.880 396 768 352 x [email protected] (6)
2 11.880 396 2.000 352 x [email protected] (6)
2.1 19.800 792 4.000 352 x [email protected] (6)
2.2 20,250 1.620 4.000 720 x [email protected] (5)
3 40.500 1.620 10.000 720 x [email protected] (5)
3.1 108.000 3.600 14.000 1,280 × [email protected] (5)
3.2 216.000 5,120 20.000
1,280 × [email protected] (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 bei 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 bei 30,1 (4)
2.048 × 1.024@30,0 (4)
4.2 522,240 8,704 50.000
1,280 × [email protected] (9)
1.920 × 1.080@64,0 (4)
2.048 × [email protected] (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 × [email protected] (16)
2.560 × 1.920@108,0 (9)
3.840 × 2.160@66,8 (5)
4,096 × 2.048@63,3 (5)
4,096 × [email protected] (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 Hochprofil beträgt das 1,25 -fache der eingeschränkten Basis-, Grundlinien-, erweiterten und Hauptprofile. 3 mal für Hi10p und 4 mal für HI422P/HI444PP.

Die Anzahl der Luma -Proben beträgt 16 × 16 = 256 -mal so viele Makroblocks (und die Anzahl der Luma -Proben pro Sekunde 256 -mal so viele Makroblocks pro Sekunde).

Decodierte Bildpufferung

Zuvor kodierte Bilder werden von H.264/AVC -Encodern verwendet, um Vorhersagen der Werte von Proben in anderen Bildern zu liefern. Auf diese Weise kann der Encoder effiziente Entscheidungen treffen, um ein bestimmtes Bild zu codieren. Im Decoder werden solche Bilder virtuell gespeichert Dekodierter Bildpuffer (DPB). Die maximale Kapazität des DPB in Einheiten von Frames (oder Feldernpaaren), wie in Klammern in der rechten Spalte der obigen Tabelle gezeigt, kann wie folgt berechnet werden:

DPBCapacity = min (Boden (Boden (Boden)Maxdpbmbs / (Picwidthinmbs * Framehohtinmbs)), 16)

Wo Maxdpbmbs ist ein konstanter Wert in der folgenden Tabelle als Funktion der Ebene der Ebene, und Picwidthinmbs und Framehohtinmbs sind die Bildbreite und die Rahmenhöhe für die codierten Videodaten, ausgedrückt in Einheiten von Makroblocks (abgerundet auf Ganzzahlwerte und berücksichtigt, dass die Zuschneiden und Makroblockpaarungen gegebenenfalls zutreffend sind). Diese Formel ist in den Abschnitten A.3.1.h und A.3.2.f der Ausgabe 2017 des Standards angegeben.[28]

Eben 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

Zum Beispiel für ein HDTV -Bild, das 1.920 Proben breit ist (Picwidthinmbs = 120) und 1.080 Proben hoch (FrameHeightInmbs = 68) Ein Decoder der Stufe 4 hat eine maximale DPB -Speicherkapazität von Boden (32768/(120*68)) = 4 Frames (oder 8 Felder). Somit ist der Wert 4 in Klammern in der obigen Tabelle in der rechten Spalte der Zeile für Stufe 4 mit der Rahmengröße 1920 × 1080 dargestellt.

Es ist wichtig zu beachten nicht enthalten In der Berechnung der DPB -Fülle (es sei denn, der Encoder hat angezeigt, dass er als Referenz für die Dekodierung anderer Bilder oder zum verzögerten Ausgangszeitpunkt gespeichert wird). Somit muss ein Decoder tatsächlich genügend Speicher haben, um (zumindest) einen Rahmen zu verarbeiten mehr als die maximale Kapazität des DPB, wie oben berechnet.

Implementierungen

Eine YouTube -Video -Statistik mit AVC (H.264) Video -Codec und Opus Audio Format

Im Jahr 2009 die HTML5 -Arbeitsgruppe wurde zwischen Anhängern von OGG aufgeteilt Theora, ein kostenloses Videoformat, das von Patenten nicht belastet wird, und H.264, das patentierte Technologie enthält. Noch im Juli 2009 haben Google und Apple H.264 unterstützen, während Mozilla und Opera OGG Theora unterstützen (jetzt Google, Mozilla und Opera unterstützen Theora und alle Webm mit VP8).[51] Microsoft hat mit der Veröffentlichung von Internet Explorer 9 Unterstützung für HTML 5 -Video hinzugefügt, die mit H.264 codiert sind. Auf dem Gartner Symposium/ITXPO im November 2010 beantwortete Microsoft -CEO Steve Ballmer die Frage "HTML 5 oder Silberlicht? "Wenn Sie sagen:" Wenn Sie etwas tun wollen, das universell ist, gibt es keine Frage, dass die Welt HTML5 geht. "[52] Im Januar 2011 kündigte Google an, dass sie H.264 von ihrem Chrome -Browser unterstützt und sowohl Theora als auch unterstützt haben Webm/VP8 nur offene Formate verwenden.[53]

Am 18. März 2012, Mozilla Bekannte Unterstützung für H.264 in Firefox auf mobilen Geräten aufgrund der Prävalenz von H.264-kodiertem Video und der erhöhten Leistungseffizienz der Verwendung dedizierter H.264-Decoder-Hardware, die auf solchen Geräten üblich sind.[54] Am 20. Februar 2013 implementierte Mozilla Unterstützung in Firefox für die Dekodierung von H.264 unter Windows 7 und höher. Diese Funktion basiert auf Windows 'integrierten Dekodierungsbibliotheken.[55] Firefox 35.0, veröffentlicht am 13. Januar 2015, unterstützt H.264 unter OS X 10,6 und höher.[56]

Am 30. Oktober 2013, Rowan Trollope aus Cisco -Systeme kündigte an, dass Cisco sowohl Binärdateien als auch Quellcode eines H.264 -Video -Codecs veröffentlichen würde OpenH264 unter dem Vereinfachte BSD -Lizenzund bezahlen alle Lizenzgebühren für seine Verwendung für MPEG LA für alle Softwareprojekte, die die vorkompilierten Binärdateien von Cisco verwenden, wodurch Cisco's OpenH264 erstellt wird Binärdateien frei zu bedienen. Alle Softwareprojekte, die den Quellcode von Cisco anstelle ihrer Binärdateien verwenden, wären jedoch rechtlich dafür verantwortlich, alle Lizenzgebühren an MPEG LA zu zahlen. Zu den Ziel -CPU -Architekturen zählen X86 und ARM sowie Zielbetriebssysteme Linux, Windows XP und später, Mac OS X und Android. IOS war in dieser Liste besonders nicht vorhanden, da die Anwendungen nicht zulässt, dass Binärmodule aus dem Internet abgeholt und installiert werden.[57][58][59] Auch am 30. Oktober 2013, Brendan Eich aus Mozilla schrieb, dass es die Binärdateien von Cisco in zukünftigen Versionen von Firefox verwenden würde, um Firefox zu unterstützen, wo Plattform -Codecs nicht verfügbar sind.[60] Cisco veröffentlichte den Quellcode am 9. Dezember 2013 an OpenH264.[61]

Obwohl iOS nicht von der Cisco -Software -Version 2013 unterstützt wurde, hat Apple sein Video Toolbox Framework aktualisiert iOS 8 (Veröffentlicht im September 2014), um direkten Zugriff auf Hardware-basierte H.264/AVC-Videocodierung und -decodierung zu gewährleisten.[58]

Software -Encoder

AVC -Software -Implementierungen
Feature Schnelle Zeit Nero OpenH264 x264 Hauptsächlich-
Konzept 		Elecard Tse Profi-
Coder 		Avivo Elementar Ipp
B Scheiben Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
Mehrere Referenzrahmen Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
Interlaced Codierung (Picaff, Mbaff) Nein Mbaff Mbaff Mbaff Ja Ja Nein Ja Mbaff Ja Nein
CABAC -Entropie -Codierung Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
8 × 8 vs. 4 × 4 Transformation Adaptivität Nein Ja Ja Ja Ja Ja Ja Ja Nein Ja Ja
Quantisierungsskalierungsmatrizen Nein Nein Ja Ja Ja Nein Nein Nein Nein Nein Nein
Getrennt 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[62]
4: 2: 0
4: 2: 2[63]
4: 4: 4[64]  		 4: 2: 2 4: 2: 2 4: 2: 2 Nein Nein 4: 2: 0
4: 2: 2		 Nein
Größte Probentiefe (Bit) 8 8 8 10[65] 10 8 8 8 8 10 12
Prädiktive verlustfreie Codierung Nein Nein Nein Ja[66] Nein Nein Nein Nein Nein Nein Nein

Hardware

Siehe auch: H.264/MPEG-4 AVC-Produkte und -implementierungen

Da die Codierung und Dekodierung von H.264 in bestimmten Arithmetikoperationen erhebliche Rechenleistung erfordert, sind Software-Implementierungen, die auf CPUs im Allgemeinen ausführen, in der Regel weniger leistungsstark. Allerdings die neuesten[wenn?] Quad-Core-Allzweck-X86-CPUs haben eine ausreichende Rechenleistung, um SD- und HD-Codierung in Echtzeit durchzuführen. Die Komprimierungseffizienz hängt von Videoalgorithmic -Implementierungen ab, nicht davon, ob Hardware- oder Software -Implementierung verwendet wird. Der Unterschied zwischen Hardware und Software-basierter Implementierung betrifft daher mehr auf Stromeffizienz, Flexibilität und Kosten. Um die Energieeffizienz zu verbessern und Hardware-Formfaktor zu reduzieren, kann Sonderhardware entweder für den vollständigen Codierungs- oder Dekodierungsprozess oder zur Beschleunigungsunterstützung in einer von CPU kontrollierten Umgebung verwendet werden.

Es ist bekannt, dass CPU -basierte Lösungen viel flexibler sind, insbesondere wenn die Codierung gleichzeitig in mehreren Formaten, mehreren Bitraten und Auflösungen durchgeführt werden muss (Multi-Screen-Video) und möglicherweise mit zusätzlichen Funktionen für die Unterstützung von Containerformat, erweiterte integrierte Werbefunktionen usw. Die CPU -basierte Softwarelösung erleichtert im Allgemeinen das Laden von mehreren gleichzeitigen Codierungssitzungen in derselben CPU.

Die 2. Generation Intel "Sandy Bridge" Core i3/i5/i7 Verarbeitern auf dem CES Januar 2011 eingeführt (Verbraucher Elektronikmesse) Bieten Sie eine On-Chip-Hardware Full HD H.264-Encoderin, bekannt als bekannt Intel Quick Sync Video.[67][68]

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

ASIC -Encoder mit H.264 -Encoderfunktionen sind von vielen verschiedenen Halbleiterunternehmen erhältlich, aber das Kerndesign, das in der ASIC verwendet wird Chips & Medien, Allegro DVT, On2 (ehemals Hantro, erworben von Google), Imaginationstechnologien, Ngcodec. Einige Unternehmen haben sowohl FPGA- als auch ASIC -Produktangebote.[69]

Texas Instruments stellt eine Reihe von Arm + DSP -Kernen her, die DSP H.264 BP Coding 1080p bei 30 fps durchführen.[70] Dies ermöglicht die Flexibilität in Bezug auf Codecs (die als stark optimierten DSP -Code implementiert werden) und sind gleichzeitig effizienter als die Software in einer generischen CPU.

Lizenzierung

Siehe auch: Microsoft Corp. gegen Motorola Inc. und Qualcomm Inc. gegen Broadcom Corp.

In Ländern wo Patente auf Softwarealgorithmen Werden Anbieter und kommerzielle Benutzer von Produkten, die H.264/AVC verwenden, werden voraussichtlich Patentlizenzgebühren für die patentierte Technologie zahlen, die ihre Produkte verwenden.[71] Dies gilt auch für das Basisprofil.[72]

Eine private Organisation bekannt als als Mpeg la, was in keiner Weise mit der MPEG -Standardisierungsorganisation verbunden ist, verwaltet die Lizenzen für Patente, die sowohl für diesen Standard als auch für andere Standards gelten Patentpools, wie für MPEG-4 Part 2 Video, HEVC und MPEG-Durchmesser. Zu den Patentinhabern gehören Fujitsu, Panasonic, Sony, Mitsubishi, Apfel, Universität von Columbia, Kaist, Dolby, Google, JVC Kenwood, LG -Elektronik, Microsoft, Ntt Docomo, Philips, Samsung, Scharf, Toshiba und ZTE,[73] Obwohl die Mehrheit der Patente im Pool von gehalten wird von Panasonic (1.197 Patente), Godo Kaisha Ip Bridge (1.130 Patente) und LG -Elektronik (990 Patente).[74]

Am 26. August 2010 kündigte MPEG LA an, dass Lizenzgebühren für H.264 -codiertes Internet -Video nicht berechnet werden, das für Endbenutzer kostenlos ist.[75] Alle anderen Lizenzgebühren bleiben bestehen, wie zum Beispiel Lizenzgebühren für Produkte, die H.264 -Video sowie für Betreiber von kostenlosen Fernseh- und Abonnementkanälen entschlüsseln und codieren.[76] Die Lizenzbedingungen werden in 5-Jahres-Blöcken aktualisiert.[77]

Seit der ersten Version des Standards im Mai 2003 abgeschlossen wurde (Vor 19 Jahren) und das am häufigsten verwendete Profil (das Hochkörper) wurde im Juni 2004 (abgeschlossenVor 18 Jahren) ist eine beträchtliche Anzahl der Patente, die ursprünglich auf den Standard angewendet wurden[78] Obwohl eines der US -Patente im MPEG La H.264 Pool mindestens 2027 dauert.[79]

Im Jahr 2005 verklagte Qualcomm Broadcom vor dem US -Bezirksgericht und behauptete, Broadcom habe zwei seiner Patente verletzt, indem er Produkte herstellte, die dem H.264 -Video -Komprimierungsstandard entsprachen.[80] 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 nicht an die JVT offengelegt hatte.[80] Im Dezember 2008 bestätigte das US -Berufungsgericht für den Federal Circuit die Anordnung des Bezirksgerichts, dass die Patente nicht durchsetzbar seien, aber an das Bezirksgericht mit Anweisungen zur Begrenzung des Umfangs der Nichtdurchführung auf H.264 -konforme Produkte zurückverwiesen.[80]

Siehe auch

Verweise

  1. ^ MPEG-4, Erweiterte Videocodierung (Teil 10) (H.264) (Voller Entwurf). Nachhaltigkeit digitaler Formate. Washington, D.C.: Kongressbibliothek. 5. Dezember 2011. Abgerufen 1. Dezember, 2021.
  2. ^ "H.264: Erweiterte Videocodierung für generische audiovisuelle Dienste". www.itu.int. Archiviert Aus dem Original am 31. Oktober 2019. Abgerufen November 22, 2019.
  3. ^ "Video Developer Report 2018" (PDF). Bitmovin. September 2019.
  4. ^ "Video Developer Report 2019". Bitmovin. September 2019.
  5. ^ "8K mit AVC/H.264 liefern". Mysteriöse Schachtel. Abgerufen 23. August, 2017.
  6. ^ a b c Wang, Hanli; Kwong, S.; Kok, C. (2006). "Effizienter Vorhersagealgorithmus der Ganzzahl -DCT -Koeffizienten für H.264/AVC -Optimierung". IEEE -Transaktionen zu Schaltkreisen und Systemen für die Videotechnik. 16 (4): 547–552. doi:10.1109/tcsvt.2006.871390. S2CID 2060937.
  7. ^ a b Thomson, Gavin; Shah, Athar (2017). "Heif und HEVC einführen" (PDF). Apple Inc. Abgerufen 5. August, 2019.
  8. ^ a b c Stanković, Radomir S.; Astola, Jaakko T. (2012). "Erinnerungen an die frühen Arbeiten in DCT: Interview mit K. R. Rao" (PDF). Nachdrucke aus den frühen Tagen der Informationswissenschaften. 60: 17. Abgerufen 13. Oktober, 2019.
  9. ^ "AVC/H.264 FAQ". www.mpegla.com. Archiviert von das Original am 7. Mai 2010. Abgerufen 15. September, 2016.
  10. ^ "H.262: Informationstechnologie - Generisches Codieren von bewegten Bildern und zugehörigen Audioinformationen: Video". Abgerufen 15. April, 2007.
  11. ^ Gemeinsames Videenteam, Itu-t Webseite.
  12. ^ "ITU-T-Empfehlung H.264 (05/2003)". Itu. 30. Mai 2003. Abgerufen 18. April, 2013.
  13. ^ "ITU-T-Empfehlung H.264 (05/2003) Cor. 1 (05/2004)". Itu. 7. Mai 2004. Abgerufen 18. April, 2013.
  14. ^ "ITU-T-Empfehlung H.264 (03/2005)". Itu. 1. März 2005. Abgerufen 18. April, 2013.
  15. ^ "ITU-T-Empfehlung H.264 (2005) Cor. 1 (09/2005)". Itu. 13. September 2005. Abgerufen 18. April, 2013.
  16. ^ a b "ITU-T-Empfehlung H.264 (2005) Amd. 1 (06/2006)". Itu. 13. Juni 2006. Abgerufen 18. April, 2013.
  17. ^ "ITU-T-Empfehlung H.264 (2005) Amd. 2 (04/2007)". Itu. 6. April 2007. Abgerufen 18. April, 2013.
  18. ^ "ITU-T-Empfehlung H.264 (11/2007)". Itu. 22. November 2007. Abgerufen 18. April, 2013.
  19. ^ "ITU-T-Empfehlung H.264 (2007) Cor. 1 (01/2009)". Itu. 13. Januar 2009. Abgerufen 18. April, 2013.
  20. ^ a b "ITU-T-Empfehlung H.264 (03/2009)". Itu. 16. März 2009. Abgerufen 18. April, 2013.
  21. ^ a b "ITU-T-Empfehlung H.264 (03/2010)". Itu. 9. März 2010. Abgerufen 18. April, 2013.
  22. ^ a b "ITU-T-Empfehlung H.264 (06/2011)". Itu. 29. Juni 2011. Abgerufen 18. April, 2013.
  23. ^ "ITU-T-Empfehlung H.264 (01/2012)". Itu. 13. Januar 2012. Abgerufen 18. April, 2013.
  24. ^ a b c d "ITU-T-Empfehlung H.264 (04/2013)". Itu. 12. Juni 2013. Abgerufen 16. Juni, 2013.
  25. ^ a b "ITU-T-Empfehlung H.264 (02/2014)". Itu. 28. November 2014. Abgerufen 28. Februar, 2016.
  26. ^ "ITU-T-Empfehlung H.264 (02/2016)". Itu. 13. Februar 2016. Abgerufen 14. Juni, 2017.
  27. ^ "ITU-T-Empfehlung H.264 (10/2016)". Itu. 14. Oktober 2016. Abgerufen 14. Juni, 2017.
  28. ^ a b c "ITU-T-Empfehlung H.264 (04/2017)". Itu. 13. April 2017. Siehe Tabellen A-1, A-6 und A-7 für die tabellartigen Ebenen abhängige Funktionen. Abgerufen 14. Juni, 2017.
  29. ^ "H.264: Erweiterte Videocodierung für generische audiovisuelle Dienste - Version 26 (Ausgabe 13)". www.itu.int. 13. Juni 2019. Archiviert vom Original am 3. November 2021. Abgerufen 3. November, 2021.
  30. ^ "H.264: Erweiterte Videocodierung für generische audiovisuelle Dienste - Version 27 (Ausgabe 14)". www.itu.int. 22. August 2021. Archiviert vom Original am 3. November 2021. Abgerufen 3. November, 2021.
  31. ^ a b "AVC/H.264 - Patentliste" (PDF). Mpeg la. Abgerufen 6. Juli, 2019.
  32. ^ "AVC/H.264 Lizenzgeber". Mpeg-la. Archiviert von das Original am 30. Mai 2015. Abgerufen 19. Mai, 2013.
  33. ^ Wenger; et al. (Februar 2005). "RFC 3984: RTP -Nutzlastformat für H.264 Video": 2. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  34. ^ "Welcher Aufnahmemodus entspricht der Bildqualität des HDV -Formats (High Definition Video)?". Sony Esupport. Archiviert von das Original am 9. November 2017. Abgerufen 8. Dezember, 2018.
  35. ^ "ATSC Standard A/72 Teil 1: Videosystemeigenschaften von AVC im Digitalfernsehsystem ATSC" (PDF). Archiviert von das Original (PDF) am 7. August 2011. Abgerufen 30. Juli, 2011.
  36. ^ "ATSC Standard A/72 Teil 2: AVC Video Transport Subsystem -Eigenschaften" (PDF). Archiviert von das Original (PDF) am 7. August 2011. Abgerufen 30. Juli, 2011.
  37. ^ "ATSC Standard A/153 Teil 7: AVC- und SVC -Videosystemeigenschaften" (PDF). Archiviert von das Original (PDF) am 26. Juli 2011. Abgerufen 30. Juli, 2011.
  38. ^ a b "Sony führt ein neues XAVC -Aufnahmeformat ein, um die 4K -Entwicklung in den professionellen und Verbrauchermärkten zu beschleunigen". Sony. 30. Oktober 2012. Abgerufen 1. November, 2012.
  39. ^ a b "Sony führt ein neues XAVC -Aufnahmeformat ein, um die 4K -Entwicklung in den professionellen und Verbrauchermärkten zu beschleunigen" (PDF). Sony. 30. Oktober 2012. Abgerufen 1. November, 2012.[Permanent Dead Link]
  40. ^ Steve Dent (30. Oktober 2012). "Sony wird mit PMW-F55 und PMW-F5 Pro Cinealta 4K Super 35mm Sensor Camcorders rot.". Engadget. Abgerufen 5. November, 2012.
  41. ^ "F55 Cinealta 4K Die Zukunft, vor dem Zeitplan" (PDF). Sony. 30. Oktober 2012. archiviert von das Original (PDF) am 19. November 2012. Abgerufen 1. November, 2012.
  42. ^ "Ultra-Schneide" SXS PRO+"Speicherkarten transformieren 4K-Videoaufnahme". Sony. Archiviert von das Original am 8. März 2013. Abgerufen 5. November, 2012.
  43. ^ "Ultra-Schneide" SXS PRO+"Speicherkarten transformieren 4K-Videoaufnahme" (PDF). Sony. Archiviert von das Original (PDF) am 2. April 2015. Abgerufen 5. November, 2012.
  44. ^ Kwon, bald young; Lee, Joo-kyong; Chung, Ki-Dong (2005). "Halbpixelkorrektur für MPEG-2/H.264 Transcoding". Bildanalyse und Verarbeitung - ICIAP 2005. Vorlesungsnotizen in Informatik. Springer Berlin Heidelberg. 3617: 576–583. doi:10.1007/11553595_71. ISBN 978-3-540-28869-5.
  45. ^ Britanak, Vladimir; Yip, Patrick C.; Rao, K. R. (2010). Diskrete Cosinus- und Sinus -Transformationen: Allgemeine Eigenschaften, schnelle Algorithmen und ganzzahlige Näherungen. Elsevier. S. ix, xiii, 1, 141–304. ISBN 9780080464640.
  46. ^ "Der H.264/AVC Advanced Video Coding Standard: Übersicht und Einführung in die Erweiterungen der Treue -Reichweite" (PDF). Abgerufen 30. Juli, 2011.
  47. ^ a b c RFC 3984, S.3
  48. ^ Apple Inc. (26. März 1999). "H.264 FAQ". Apfel. Archiviert von das Original am 7. März 2010. Abgerufen 17. Mai, 2010.
  49. ^ Karsten Suehring. "H.264/AVC JM Reference Software Download". Iphome.hhi.de. Abgerufen 17. Mai, 2010.
  50. ^ "TS 101 154-V1.9.1-Digitales Videoübertragung (DVB); Spezifikation für die Verwendung von Video- und Audiocodierung in Rundfunkanwendungen basierend auf dem MPEG-2-Transportstrom" (PDF). Abgerufen 17. Mai, 2010.
  51. ^ "Dekodierung der HTML 5 Video -Codec -Debatte". ARS Technica. 6. Juli 2009. Abgerufen 12. Januar, 2011.
  52. ^ "Steve Ballmer, CEO Microsoft, interviewt bei Gartner Symposium/ITXPO Orlando 2010". Gartnervideo. November 2010. archiviert von das Original am 30. Oktober 2021. Abgerufen 12. Januar, 2011.
  53. ^ "HTML -Video -Codec -Unterstützung in Chrome". 11. Januar 2011. Abgerufen 12. Januar, 2011.
  54. ^ "Video, Handy und das offene Web". 18. März 2012. Abgerufen 20. März, 2012.
  55. ^ "WEBRTC aktiviert, H.264/MP3 -Support in Win 7 standardmäßig, Metro UI für Windows 8 + More - Firefox Development Highlights". hacks.mozilla.org. Mozilla. 20. Februar 2013. Abgerufen 15. März, 2013.
  56. ^ "Firefox - Notizen (35,0)". Mozilla.
  57. ^ "Open-Sourced H.264 entfernt Barrieren für Webrtc". 30. Oktober 2013. Archiviert von das Original am 6. Juli 2015. Abgerufen 1. November, 2013.
  58. ^ a b "Cisco OpenH264 Projekt FAQ". Abgerufen 26. September, 2021.
  59. ^ "OpenH264 vereinfachte BSD -Lizenz". GitHub. 27. Oktober 2013. Abgerufen 21. November, 2013.
  60. ^ "Die Video -Interoperabilität im Web erhöht einen Schub von Ciscos H.264 Codec". 30. Oktober 2013. Abgerufen 1. November, 2013.
  61. ^ "Aktualisiert Readme · Cisco/OpenH264@59DAE50". GitHub.
  62. ^ "x264 4: 0: 0 (monochrom) codierende Unterstützung", Abgerufen 2019-06-05.
  63. ^ "x264 4: 2: 2 Codierungsunterstützung", Abgerufen 2019-06-05.
  64. ^ "x264 4: 4: 4 codierende Unterstützung", Abgerufen 2019-06-05.
  65. ^ "x264 Unterstützung für 9- und 10-Bit-Codierung", Abgerufen 2011-06-22.
  66. ^ "x264 Ersetzen Sie High 4: 4: 4 Profil verlustlos mit High 4: 4: 4 Predictive", Abgerufen 2011-06-22.
  67. ^ "Schnelle Referenzhandbuch zur Generierung von Intel Core-Prozessor integrierte Bilder". Intel Software -Netzwerk. 1. Oktober 2010. Abgerufen 19. Januar, 2011.
  68. ^ "Intel Quick Sync Video". www.intel.com. 1. Oktober 2010. Abgerufen 19. Januar, 2011.
  69. ^ "Design-reuls.com". Design-rese.com. 1. Januar 1990. Abgerufen 17. Mai, 2010.
  70. ^ "Kategorie: DM6467 - Texas Instruments Embedded Processors Wiki". Processors.wiki.ti.com. 12. Juli 2011. archiviert von das Original am 17. Juli 2011. Abgerufen 30. Juli, 2011.
  71. ^ "Briefing -Portfolio" (PDF). www.mpegla.com.
  72. ^ "OMS Video, ein Projekt der Open Media Commons -Initiative von Sun". Archiviert von das Original am 11. Mai 2010. Abgerufen 26. August, 2008.
  73. ^ "Lizenzgeber, die in der AVC/H.264 -Patentportfolio -Lizenz enthalten sind". Mpeg la. Abgerufen 18. Juni, 2019.
  74. ^ "AVC/H.264 - Patentliste" (PDF). Mpeg la. Abgerufen 6. Juli, 2019.
  75. ^ "Die AVC -Lizenz von MPEG LA wird keine Lizenzgebühren für Internetvideos berechnen, die Endbenutzern durch Lizenzleben kostenlos sind" (PDF). Mpeg la. 26. August 2010. Abgerufen 26. August, 2010.
  76. ^ Hachman, Mark (26. August 2010). "MPEG LA schneidet Lizenzgebühren aus dem kostenlosen Webvideo für immer". pcmag.com. Abgerufen 26. August, 2010.
  77. ^ "AVC FAQ". Mpeg la. 1. August 2002. archiviert von das Original am 7. Mai 2010. Abgerufen 17. Mai, 2010.
  78. ^ "AVC -Anhang 1" (PDF). mpegla.com. Archiviert von das Original (PDF) am 14. Mai 2015. Abgerufen 20. November, 2018.
  79. ^ "US-Patentablauf für MP3, MPEG-2, H.264". osnews.com. 15. Juli 2015. Abgerufen 19. Juli, 2022. Hat ein MPEG LA Patent US 7826532, das am 5. September 2003 eingereicht wurde und eine Verlängerung um 1.546 Tage lang hat. "US -Patent 7.826.532 Nakagawa et al.". US -amerikanisches Patent- und Markenbüro. Abgerufen 19. Juli, 2022. http://www.google.com/patents/about?id=2onyaaaaaaajj[Dead Link]
  80. ^ a b c Sehen Qualcomm Inc. gegen Broadcom Corp., Nr. 2007-1545, 2008-1162 (Fed. Cir. 1. Dezember 2008). Für Artikel in der beliebten Presse siehe Signonsandiego.com, "Qualcomm verliert den Fall der Patentrechte" und "Qualcomms Patentfall geht an die Jury"; und Bloomberg.com "Broadcom gewinnt den ersten Versuch in Qualcomm Patentstreit"

Weitere Lektüre

Externe Links