Empfohlene 8-Bit-YUV-Formate für das Videorendering

Gary Sullivan and Stephen Estrop

Microsoft Corporation

April 2002, aktualisiert November 2008

In diesem Thema werden die 8-Bit-YUV-Farbformate beschrieben, die für das Videorendering im Windows-Betriebssystem empfohlen werden. In diesem Artikel werden Techniken für die Umwandlung zwischen YUV- und RGB-Formaten erläutert und außerdem Techniken für die Hochskalierung von YUV-Formaten bereitgestellt. Dieser Artikel ist für alle Benutzer gedacht, die mit YUV-Videodecodierung oder Rendering in Windows arbeiten.

Einleitung

Zahlreiche YUV-Formate werden in der gesamten Videoindustrie definiert. In diesem Artikel werden die 8-Bit-YUV-Formate beschrieben, die für das Videorendering in Windows empfohlen werden. Decoderanbieter und Anzeigeanbieter werden empfohlen, die in diesem Artikel beschriebenen Formate zu unterstützen. In diesem Artikel werden keine anderen Verwendungen von YUV-Farben behandelt, wie z. B. die Fotografie.

Die in diesem Artikel beschriebenen Formate verwenden alle 8 Bit pro Pixelposition, um den Y-Kanal (auch luma-Kanal genannt) zu codieren, und verwenden Sie 8 Bit pro Beispiel, um jedes U- oder V-Chroma-Beispiel zu codieren. Die meisten YUV-Formate verwenden jedoch durchschnittlich weniger als 24 Bit pro Pixel, da sie weniger Abtastungen von U und V als von Y enthalten. In diesem Artikel werden keine YUV-Formate mit 10-Bit- oder höheren Y-Kanälen behandelt.

Hinweis

Für die Zwecke dieses Artikels entspricht der Begriff U cb, und der Begriff V entspricht Cr.

 

In diesem Artikel werden die folgenden Themen behandelt:

• YUV Sampling. Beschreibt die gängigsten YUV Sampling-Techniken.
• Surface Definitions. Beschreibt die empfohlenen YUV-Formate.
• Farbraum- und Chroma-Abtastraten-Konvertierung. Enthält einige Richtlinien für die Konvertierung zwischen YUV- und RGB-Formaten und für die Konvertierung zwischen verschiedenen YUV-Formaten.
• Identifizieren von YUV-Formaten in Media Foundation. Erläutert, wie SIE YUV-Formattypen in Media Foundation beschreiben.

YUV-Abtastung

Chromakanäle können eine niedrigere Samplingrate als der Luma-Kanal haben, ohne dass dramatische Qualitätseinbußen auftreten. Die "A:B:C"-Notation wird verwendet, um zu beschreiben, wie oft U und V im Verhältnis zu Y abgetastet werden.

• 4:4:4 bedeutet kein Downsampling der Chromakanäle.
• 4:2:2 bedeutet 2:1 horizontale Abtastreduktion, ohne vertikale Abtastreduktion. Jede Scanzeile enthält vier Y-Beispiele für alle zwei U- oder V-Proben.
• 4:2:0 bedeutet 2:1 horizontales Downsampling, mit 2:1 vertikalem Downsampling.
• 4:1:1 bedeutet ein horizontales Downsampling im Verhältnis 4:1, ohne vertikales Downsampling. Jede Scanlinie enthält vier Y-Abtastungen für jede U- und V-Abtastung. 4:1:1 Sampling ist weniger häufig als andere Formate und wird in diesem Artikel nicht ausführlich behandelt.

Die folgenden Diagramme zeigen, wie Chroma für jede der Downsampling-Raten abgetastet wird. Luma-Proben werden durch ein Kreuz dargestellt, und Farbproben werden durch einen Kreis dargestellt.

Die dominante Form der 4:2:2-Probenahme wird in ITU-R Empfehlung BT.601 definiert. Es gibt zwei gängige Varianten von 4:2:0 Sampling. Eines davon wird in MPEG-2-Video verwendet, und die andere wird in MPEG-1 und in ITU-T Empfehlungen H.261 und H.263 verwendet.

Im Vergleich zum MPEG-1-Schema ist es einfacher, zwischen dem MPEG-2-Schema und den Sampling-Rastern zu konvertieren, die für 4:2:2- und 4:4:4-Formate definiert sind. Aus diesem Grund wird das MPEG-2-Schema in Windows bevorzugt und sollte als Standardinterpretation von 4:2:0-Formaten betrachtet werden.

Oberflächendefinitionen

In diesem Abschnitt werden die 8-Bit-YUV-Formate beschrieben, die für das Videorendering empfohlen werden. Diese fallen in mehrere Kategorien:

• 4:4:4 Formate, 32 Bit pro Pixel
• 4:4:4 Formate, 24 Bit pro Pixel
• 4:2:2 Formate, 16 Bit pro Pixel
• 4:2:0 Formate, 16 Bit pro Pixel
• 4:2:0 Formate, 12 Bit pro Pixel

Zunächst sollten Sie sich den folgenden Konzepten bewusst sein, um zu verstehen, was folgt:

• Oberflächen-Ursprung. Für die in diesem Artikel beschriebenen YUV-Formate ist der Ursprung (0,0) immer die obere linke Ecke der Oberfläche.
• Stride. Die Schrittweite einer Fläche, manchmal auch Pitch genannt, ist die Breite der Fläche in Bytes. Wenn der Ursprung der Oberfläche in der oberen linken Ecke liegt, ist der Schritt immer positiv.
• Ausrichtung. Die Ausrichtung einer Oberfläche liegt im Ermessen des Grafikanzeigetreibers. Die Oberfläche muss immer DWORD ausgerichtet sein; d. h. einzelne Linien innerhalb der Oberfläche beginnen garantiert an einer 32-Bit-Grenze (DWORD). Die Ausrichtung kann jedoch je nach Den Anforderungen der Hardware größer als 32 Bit sein.
• Verpacktes Format im Vergleich zum planaren Format. YUV-Formate sind in gepackte Formate und planare Formate unterteilt. In einem gepackten Format werden die Y-, U- und V-Komponenten in einem einzigen Array gespeichert. Pixel sind in Gruppen von Makropixeln angeordnet, deren Layout vom Format abhängt. In einem planaren Format werden die Y-, U- und V-Komponenten als drei separate Ebenen gespeichert.

Jedes der in diesem Artikel beschriebenen YUV-Formate verfügt über einen zugewiesenen FOURCC-Code. Ein FourCC-Code ist eine 32-Bit ganze Zahl ohne Vorzeichen, die durch das Verketten von vier ASCII-Zeichen erstellt wird.

• 4:4:4 (32 bpp)
  • AYUV
• 4:4:4 (24 bpp)
  • I444
• 4:2:2 (16 bpp)
  • YUY2
  • UYVY
  • UI422
• 4:2:0 (16 bpp)
  • IMC1
  • IMC3
• 4:2:0 (12 bpp)
  • IMC2
  • IMC4
  • YV12
  • NV12

4:4:4 Formate, 32 Bit pro Pixel

AYUV

Ein einzelnes 4:4:4-Format wird empfohlen, mit dem FOURCC-Code AYUV. Dies ist ein gepacktes Format, in dem jedes Pixel als vier aufeinander folgende Bytes codiert ist, die in der in der folgenden Abbildung dargestellten Sequenz angeordnet sind.

Die mit A markierten Bytes enthalten Werte für Alpha.

4:4:4 Formate, 24 Bit pro Pixel

I444

Im I444-Format werden alle Y-Beispiele zuerst im Arbeitsspeicher als Array von nicht signierten Zeichenwerten angezeigt. Dieses Array wird unmittelbar von allen U (Cb) Stichproben gefolgt. Die Stride der U-Ebene ist der gleiche Schritt der Y-Ebene; und die U-Ebene enthält dieselbe Anzahl von Zeilen wie die Y-Ebene. Die U-Ebene wird unmittelbar von allen V (Cr)-Proben gefolgt, wobei die gleiche Schrittweite und Anzahl von Zeilen wie bei der U-Ebene verwendet wird. Es gibt keinen Abstand für Y/U/V-Ebenen.

4:2:2 Formate, 16 Bit pro Pixel

Es werden zwei 4:2:2-Formate mit den folgenden FOURCC-Codes empfohlen:

• YUY2
• UYVY

Beide sind gepackte Formate, bei denen jedes Makropixel als vier aufeinanderfolgende Bytes codiert wird. Dies führt zu einem horizontalen Downsampling des Chromas um den Faktor zwei.

YUY2

Im YUY2-Format können die Daten als Array nicht signierter Zeichenwerte behandelt werden, wobei das erste Byte das erste Y-Beispiel enthält, das zweite Byte das erste U (Cb)-Beispiel enthält, das dritte Byte das zweite Y-Beispiel, und das vierte Byte enthält das erste V (Cr)-Beispiel, wie im folgenden Diagramm dargestellt.

Wenn das Bild als Array von wenig endischen WORD-Werten adressiert wird, enthält das erste WORD-Beispiel das erste Y-Beispiel in den am wenigsten signifikanten Bits (LSBs) und das erste U (Cb)-Beispiel in den wichtigsten Bits (MSBs). Das zweite WORD enthält das zweite Y-Beispiel in den LSBs und das erste V (Cr)-Beispiel in den MSBs.

YUY2 ist das bevorzugte 4:2:2-Pixelformat für die Microsoft DirectX Video Acceleration (DirectX VA). Es wird angenommen, dass es sich um eine Anforderung für den mittelfristigen Gebrauch von DirectX VA-Beschleunigern handelt, die 4:2:2-Video unterstützen.

UYVY

Dieses Format ist mit dem YUY2-Format identisch, mit Ausnahme der Bytereihenfolge, d. h., die Chroma- und Lumabytes werden gekippt (Abbildung 4). Wenn das Bild als Array von zwei little-endian WORD-Werten adressiert wird, enthält das erste WORD U in den LSBs und Y0 in den MSBs, und das zweite WORD enthält V in den LSBs und Y1 in den MSBs.

I422

Im I422-Format werden alle Y-Beispiele zuerst im Arbeitsspeicher als Array von nicht signierten Zeichenwerten angezeigt. Dieses Array wird unmittelbar von allen U (Cb) Stichproben gefolgt. Der Stride der U-Ebene ist die Hälfte der Stride der Y-Ebene; und die U-Ebene enthält dieselbe Anzahl von Zeilen wie die Y-Ebene. Der U-Ebene folgen sofort alle V (Cr)-Samples mit derselben Schrittweite und Anzahl von Linien wie die U-Ebene, wie in der folgenden Abbildung dargestellt. Es gibt keinen Innenabstand für die Y/U/V-Ebenen.

4:2:0 Formate, 16 Bit pro Pixel

Zwei 4:2:0 16-Bit-Formate pro Pixel (bpp) werden empfohlen, mit den folgenden FOURCC-Codes:

• IMC1
• IMC3

Beide dieser YUV-Formate sind planare Formate. Die Chroma-Kanäle werden sowohl in der horizontalen als auch in der vertikalen Dimension um den Faktor zwei unterabgetastet.

IMC1

Alle Y-Beispiele werden zuerst im Arbeitsspeicher als Array von nicht signierten Zeichenwerten angezeigt. Darauf folgen alle V (Cr)-Proben und anschließend alle U (Cb)-Proben. Die V- und U-Ebene weisen den gleichen Schritt wie die Y-Ebene auf, was zu nicht genutzten Speicherbereichen führt, wie in Abbildung 5 dargestellt. Die U- und V-Ebenen müssen an Speichergrenzen beginnen, die ein Vielfaches von 16 Zeilen sind. Abbildung 5 zeigt den Ursprung von U und V für ein Videobild von 352 x 240. Die Startadresse der U- und V-Ebenen wird wie folgt berechnet:

BYTE* pV = pY + (((Height + 15) & ~15) * Stride);
BYTE* pU = pY + (((((Height * 3) / 2) + 15) & ~15) * Stride);

dabei ist pY ein Bytezeiger auf den Anfang des Speicherarrays, wie im folgenden Diagramm dargestellt.

IMC3

Dieses Format ist identisch mit IMC1, mit der Ausnahme, dass die U- und V-Ebenen vertauscht sind, wie im folgenden Diagramm dargestellt.

4:2:0 Formate, 12 Bit pro Pixel

Vier 4:2:0 12-bpp-Formate werden mit den folgenden FOURCC-Codes empfohlen:

• IMC2
• IMC4
• YV12
• NV12

Bei all diesen Formaten werden die Chroma-Kanäle sowohl in der horizontalen als auch in der vertikalen Dimension um den Faktor zwei unterabgetastet.

IMC2

Dieses Format ist dasselbe wie IMC1, mit folgender Ausnahme: Die V (Cr)- und U (Cb)-Linien sind an den Grenzen der halben Schrittweite verschachtelt. Mit anderen Worten: Jede Full-Stride-Linie im Chroma-Bereich beginnt mit einer Linie von V-Samples, gefolgt von einer Linie von U-Samples, die an der nächsten Half-Stride-Grenze beginnt (Abbildung 7). Dieses Layout ermöglicht eine effizientere Verwendung des Adressraums als IMC1. Dadurch wird der Farbadressraum halbiert und damit der Gesamtadressraum um 25 Prozent reduziert. Unter 4:2:0-Formaten ist IMC2 nach NV12 das zweitbeste bevorzugte Format. Das folgende Bild zeigt diesen Prozess.

IMC4

Dieses Format ist identisch mit IMC2, außer dass die Linien U (Cb) und V (Cr) ausgetauscht werden, wie in der folgenden Abbildung dargestellt.

YV12

Alle Y-Beispiele werden zuerst im Arbeitsspeicher als Array von nicht signierten Zeichenwerten angezeigt. Auf dieses Array folgen sofort alle V(Cr)-Beispiele. Die Stride der V-Ebene ist die Hälfte der Stride der Y-Ebene; und die V-Ebene enthält halb so viele Linien wie die Y-Ebene. Die V-Ebene wird unmittelbar von allen U(Cb)-Samples gefolgt, mit dem gleichen Stride und der gleichen Anzahl von Linien wie die V-Ebene, wie in der folgenden Abbildung dargestellt.

NV12

Alle Y-Beispiele werden zuerst im Arbeitsspeicher als Array von nicht signierten Zeichenwerten mit einer geraden Anzahl von Zeilen angezeigt. Auf die Y-Ebene folgt sofort ein Array von unsignierten char-Werten, das gepackte U- (Cb) und V (Cr)-Proben enthält. Wenn das kombinierte U-V-Array als Array mit wenig endischen WORD-Werten adressiert wird, enthalten die LSBs die U-Werte, und die MSBs enthalten die V-Werte. NV12 ist das bevorzugte 4:2:0-Pixelformat für DirectX VA. Man erwartet, dass es sich um eine mittelfristige Anforderung für DirectX VA-Beschleuniger handelt, die 4:2:0-Video unterstützen. Die folgende Illustration zeigt die Y-Ebene und das Array, das gepackte U- und V-Stichproben enthält.

Konvertierung von Farbraum und Chroma-Abtastrate

Dieser Abschnitt enthält Richtlinien für die Konvertierung zwischen YUV und RGB und für die Konvertierung zwischen einigen verschiedenen YUV-Formaten. Wir betrachten zwei RGB-Codierungsschemas in diesem Abschnitt: 8-Bit-Computer RGB, auch bekannt als sRGB oder "full-scale" RGB und Studio Video RGB oder "RGB mit Kopfraum und Toe-Raum". Diese sind wie folgt definiert:

• Computer RGB verwendet 8 Bit für jedes Beispiel von Rot, Grün und Blau. Schwarz wird durch R = G = B = 0 dargestellt, und Weiß wird durch R = G = B = 255 dargestellt.
• Studio Video RGB verwendet einige Bits N für jedes Beispiel von Rot, Grün und Blau, wobei N 8 oder mehr ist. Studio Video RGB verwendet einen anderen Skalierungsfaktor als Computer-RGB und hat einen Offset. Schwarz wird durch R = G = B = 16*2^(N-8) dargestellt, und Weiß wird durch R = G = B = 235*2^(N-8) dargestellt. Tatsächliche Werte können jedoch außerhalb dieses Bereichs liegen.

Studio Video RGB ist die bevorzugte RGB-Definition für Video in Windows, während computer RGB die bevorzugte RGB-Definition für Nicht-Videoanwendungen ist. In beiden Formen von RGB sind die Farbkoordinaten wie in ITU-R BT.709 für die Definition der RGB-Farbprimierungen angegeben. Die Koordinaten (x,y) von R, G und B sind (0,64, 0,33), (0,30, 0,60) bzw. (0,15, 0,06). Bezugsweiß ist D65 mit Koordinaten (0,3127, 0,3290). Nominal gamma ist 1/0,45 (ca. 2,2), wobei präzise Gamma im Detail in ITU-R BT.709 definiert ist.

Konvertierung zwischen RGB und 4:4:4 YUV

Wir beschreiben zunächst die Konvertierung zwischen RGB und 4:4:4 YUV. Um 4:2:0 oder 4:2:2 YUV in RGB zu konvertieren, empfehlen wir, die YUV-Daten in 4:4:4 YUV zu konvertieren und dann von 4:4:4 YUV in RGB zu konvertieren. Das AYUV-Format, das ein 4:4:4-Format ist, verwendet jeweils 8 Bit für die Beispiele Y, U und V. YUV kann auch mit mehr als 8 Bit pro Beispiel für einige Anwendungen definiert werden.

Für digitales Video wurden zwei dominante YUV-Konvertierungen aus RGB definiert. Beide basieren auf der Spezifikation, die als ITU-R Empfehlung BT.709 bezeichnet wird. Die erste Konvertierung ist das ältere YUV-Formular, das für die Verwendung mit 50 Hz in BT.709 definiert ist. Es ist identisch mit der in ITU-R Empfehlung BT.601 angegebenen Beziehung, auch bekannt durch seinen älteren Namen CCIR 601. Es sollte als das bevorzugte YUV-Format für die Standarddefinitions-TV-Auflösung (720 x 576) und Video mit niedrigerer Auflösung betrachtet werden. Es zeichnet sich durch die Werte von zwei Konstanten Kr und Kb aus:

Kr = 0.299
Kb = 0.114

Die zweite Konvertierung ist das neuere YUV-Formular, das für die Verwendung von 60 Hz in BT.709 definiert ist, und sollte als das bevorzugte Format für Videoauflösungen über SDTV betrachtet werden. Es zeichnet sich durch unterschiedliche Werte für diese beiden Konstanten aus:

Kr = 0.2126
Kb = 0.0722

Die Umwandlung von RGB zu YUV beginnt mit Folgendem:

L = Kr * R + Kb * B + (1 - Kr - Kb) * G

Die YUV-Werte werden dann wie folgt abgerufen:

Y =                   floor(2^(M-8) * (219*(L-Z)/S + 16) + 0.5)
U = clip3(0, (2^M)-1, floor(2^(M-8) * (112*(B-L) / ((1-Kb)*S) + 128) + 0.5))
V = clip3(0, (2^M)-1, floor(2^(M-8) * (112*(R-L) / ((1-Kr)*S) + 128) + 0.5))

Hierbei gilt:

• M ist die Anzahl der Bits pro YUV-Beispiel (M >= 8).
• Z ist die Variable der schwarzen Ebene. Für den Computer RGB ist Z gleich 0. Für Studio-Video RGB entspricht Z 16*2^(N-8), wobei N die Anzahl der Bits pro RGB-Beispiel (N >= 8) ist.
• S ist die Skalierungsvariable. Für computer RGB ist S gleich 255. Für Studio-Video RGB entspricht S 219*2^(N-8).

Die Funktion floor(x) gibt die größte ganze Zahl zurück, die kleiner oder gleich x ist. Die Funktion clip3(x, y, z) wird folgendermaßen definiert:

clip3(x, y, z) = ((z < x) ? x : ((z > y) ? y : z))

Hinweis

Clip3 sollte anstelle eines Präprozessormakros als Funktion implementiert werden; andernfalls treten mehrere Auswertungen der Argumente auf.

 

Die Y-Komponente stellt die Helligkeit dar, und die U- und V-Komponenten repräsentieren die Farbabweichungen in Richtung Blau bzw. Rot. Der Nennbereich für Y beträgt 16*2^(M-8) bis 235*2^(M-8). Schwarz wird als 16*2^(M-8) dargestellt, und Weiß wird als 235*2^(M-8) dargestellt. Der Nominalbereich für U und V beträgt 16*2^(M-8) bis 240*2^(M-8), wobei der Wert 128*2^(M-8) eine neutrale Farbkomponente darstellt. Tatsächliche Werte können jedoch außerhalb dieser Bereiche liegen.

Für Eingabedaten in Form von Studio-Video-RGB ist der Clip-Vorgang erforderlich, um die U- und V-Werte im Bereich von 0 bis (2^M)-1 zu halten. Wenn die Eingabe Computer-RGB ist, ist das Clippen nicht erforderlich, da die Konvertierungsformel keine Werte außerhalb dieses Bereichs hervorzubringen vermag.

Dies sind die genauen Formeln ohne Annäherung. Alles, was in diesem Dokument folgt, wird von diesen Formeln abgeleitet. In diesem Abschnitt werden die folgenden Konvertierungen beschrieben:

• Konvertieren von RGB888 in YUV 4:4:4
• Konvertieren von 8-Bit-YUV in RGB888
• Konvertieren von 4:2:0 YUV in 4:2:2 YUV
• Konvertieren von 4:2:2 YUV in 4:4:4 YUV
• Konvertieren von 4:2:0 YUV in 4:4:4 YUV

Konvertieren von RGB888 in YUV 4:4:4

Im Falle von RGB-Computereingang und 8-Bit-BT.601-YUV-Ausgang glauben wir, dass die im vorherigen Abschnitt angegebenen Formeln vernünftigerweise durch Folgendes angenähert werden können:

Y = ( (  66 * R + 129 * G +  25 * B + 128) >> 8) +  16
U = ( ( -38 * R -  74 * G + 112 * B + 128) >> 8) + 128
V = ( ( 112 * R -  94 * G -  18 * B + 128) >> 8) + 128

Diese Formeln erzeugen 8-Bit-Ergebnisse mithilfe von Koeffizienten, die nicht mehr als 8 Bit (nicht signierte) Genauigkeit erfordern. Zwischenergebnisse erfordern bis zu 16 Bit Genauigkeit.

Konvertieren von 8-Bit-YUV in RGB888

Von den ursprünglichen RGB-zu-YUV-Formeln kann man die folgenden Beziehungen für BT.601 ableiten.

Y = round( 0.256788 * R + 0.504129 * G + 0.097906 * B) +  16 
U = round(-0.148223 * R - 0.290993 * G + 0.439216 * B) + 128
V = round( 0.439216 * R - 0.367788 * G - 0.071427 * B) + 128

Daher, gegeben:

C = Y - 16
D = U - 128
E = V - 128

die Formeln zum Konvertieren von YUV in RGB können wie folgt abgeleitet werden:

R = clip( round( 1.164383 * C                   + 1.596027 * E  ) )
G = clip( round( 1.164383 * C - (0.391762 * D) - (0.812968 * E) ) )
B = clip( round( 1.164383 * C +  2.017232 * D                   ) )

wobei clip() die Begrenzung auf einen Bereich von [0..255] bezeichnet. Wir glauben, dass diese Formeln in etwa wie folgt angenähert werden können:

R = clip(( 298 * C           + 409 * E + 128) >> 8)
G = clip(( 298 * C - 100 * D - 208 * E + 128) >> 8)
B = clip(( 298 * C + 516 * D           + 128) >> 8)

Diese Formeln verwenden einige Koeffizienten, die mehr als 8 Bit Genauigkeit erfordern, um jedes 8-Bit-Ergebnis zu erzeugen, und Zwischenergebnisse erfordern mehr als 16 Bit Genauigkeit.

Um 4:2:0 oder 4:2:2 YUV in RGB zu konvertieren, empfehlen wir, die YUV-Daten in 4:4:4 YUV zu konvertieren und dann von 4:4:4 YUV in RGB zu konvertieren. In den folgenden Abschnitten werden einige Methoden zum Konvertieren der Formate 4:2:0 und 4:2:2 in 4:4:4 dargestellt.

Konvertieren von 4:2:0 YUV in 4:2:2 YUV

Die Umwandlung von 4:2:0 YUV in 4:2:2 YUV erfordert eine vertikale Hochkonvertierung um den Faktor zwei. In diesem Abschnitt wird eine Beispielmethode zum Ausführen der Upconversion beschrieben. Die Methode geht davon aus, dass die Videobilder progressiv abgetastet sind.

Hinweis

Die Umwandlung von 4:2:0 in 4:2:2 Zeilensprungverfahren wirft untypische Probleme auf und ist schwierig zu realisieren. Dieser Artikel befasst sich nicht mit der Konvertierung des Zeilensprungverfahrens von 4:2:0 in 4:2:2.

 

Lassen Sie jede vertikale Linie von Eingabechromproben ein Array Cin[] sein, das von 0 bis N - 1 reicht. Die entsprechende vertikale Linie im Ausgabebild ist ein Array Cout[] , das zwischen 0 und 2N - 1 liegt. Führen Sie den folgenden Prozess aus, um jede vertikale Linie zu konvertieren:

Cout[0]     = Cin[0];
Cout[1]     = clip((9 * (Cin[0] + Cin[1]) - (Cin[0] + Cin[2]) + 8) >> 4);
Cout[2]     = Cin[1];
Cout[3]     = clip((9 * (Cin[1] + Cin[2]) - (Cin[0] + Cin[3]) + 8) >> 4);
Cout[4]     = Cin[2]
Cout[5]     = clip((9 * (Cin[2] + Cin[3]) - (Cin[1] + Cin[4]) + 8) >> 4);
...
Cout[2*i]   = Cin[i]
Cout[2*i+1] = clip((9 * (Cin[i] + Cin[i+1]) - (Cin[i-1] + Cin[i+2]) + 8) >> 4);
...
Cout[2*N-3] = clip((9 * (Cin[N-2] + Cin[N-1]) - (Cin[N-3] + Cin[N-1]) + 8) >> 4);
Cout[2*N-2] = Cin[N-1];
Cout[2*N-1] = clip((9 * (Cin[N-1] + Cin[N-1]) - (Cin[N-2] + Cin[N-1]) + 8) >> 4);

wobei clip() die Begrenzung auf einen Bereich von [0..255] bezeichnet.

Hinweis

Die Formeln zum Behandeln der Kanten können mathematisch vereinfacht werden. Sie werden in dieser Form gezeigt, um den Klammereffekt an den Rändern des Bilds zu veranschaulichen.

 

In Der Tat berechnet diese Methode jeden fehlenden Wert, indem die Kurve über die vier angrenzenden Pixel interpoliert wird, gewichtet auf die Werte der beiden nächsten Pixel (Abbildung 11). Die in diesem Beispiel verwendete spezifische Interpolationsmethode generiert fehlende Stichproben an halbzahligen Positionen unter Verwendung einer bekannten Methode namens Catmull-Rom Interpolation, die auch als kubische Konvolutionsinterpolation bezeichnet wird.

Im Hinblick auf die Signalverarbeitung sollte die vertikale Aufwärtskonversion idealerweise eine Phasenverschiebungskompensation enthalten, um den vertikalen Offset von einem halben Pixel (relativ zum Ausgaberaster 4:2:2) zwischen den Positionen der 4:2:0-Abtastlinien und den Positionen jeder anderen 4:2:2-Abtastlinie zu berücksichtigen. Die Einführung dieses Offsets würde jedoch die Verarbeitungsmenge erhöhen, die zum Generieren der Proben erforderlich ist, und es unmöglich machen, die ursprünglichen 4:2:0-Proben aus dem upsampled 4:2:2-Bild zu rekonstruieren. Außerdem wäre es unmöglich, Video direkt in 4:2:2-Oberflächen zu decodieren und diese Oberflächen dann als Referenzbilder zum Decodieren nachfolgender Bilder im Stream zu verwenden. Daher berücksichtigt die hier beschriebene Methode nicht die genaue vertikale Ausrichtung der Proben. Dies ist wahrscheinlich bei relativ hohen Bildauflösungen nicht visuell schädlich.

Wenn Sie mit einem 4:2:0-Video beginnen, das das in H.261, H.263 oder MPEG-1-Video definierte Abtastraster verwendet, wird die Phase der ausgegebenen 4:2:2-Chroma-Samples ebenfalls um einen horizontalen Versatz von einem halben Pixel gegenüber dem Abstand auf dem Luma-Abtastraster verschoben (ein Versatz von einem Viertelpixel gegenüber dem Abstand des 4:2:2-Chroma-Abtastrasters). Die MPEG-2-Form von 4:2:0-Video wird jedoch wahrscheinlich häufiger auf PCs verwendet und leidet nicht unter diesem Problem. Darüber hinaus ist die Unterscheidung wahrscheinlich bei relativ hohen Bildauflösungen nicht visuell schädlich. Der Versuch, dieses Problem zu beheben, würden die gleichen Arten von Problemen entstehen lassen, die für den vertikalen Phasenversatz besprochen wurden.

Konvertieren von 4:2:2 YUV in 4:4:4 YUV

Die Umwandlung von 4:2:2 YUV in 4:4:4 YUV erfordert eine horizontale Hochkonvertierung um den Faktor zwei. Die zuvor für die vertikale Frequenzumwandlung beschriebene Methode kann auch auf die horizontale Frequenzumwandlung angewendet werden. Für MPEG-2- und ITU-R BT.601-Video werden mit dieser Methode Proben mit der richtigen Phasenausrichtung erstellt.

Konvertieren von 4:2:0 YUV in 4:4:4 YUV

Um 4:2:0 YUV in 4:4:4 YUV zu konvertieren, können Sie einfach die beiden zuvor beschriebenen Methoden befolgen. Konvertieren Sie das 4:2:0-Bild in 4:2:2, und konvertieren Sie dann das 4:2:2-Bild in 4:4:4. Sie können auch die Reihenfolge der beiden Upconversion-Prozesse wechseln, da die Reihenfolge der Abläufe sich nicht wirklich auf die visuelle Qualität des Ergebnisses auswirkt.

Konvertieren von YUY2 in I422

Für das Farbformat 4:2:2 können einige Decoder standardmäßig MFVideoFormat_YUY2 ausgeben, bei dem es sich um ein verpacktes Format handelt. Viele Encoder erwarten jedoch Eingaben im Planarformat MFVideoFormat_I422. In solchen Fällen kann der Transcodierung Video Prozessor Media Foundation Transform (häufig als „XVP“ bezeichnet) in die Pipeline eingefügt werden, um MFVideoFormat_YUY2 in MFVideoFormat_I422 zu konvertieren. Weitere Informationen finden Sie unter Transcoding Video Processor Media Foundation Transform. In diesem Beispiel wird veranschaulicht, wie XVP zum Ausführen dieser Konvertierung für Codierungsworkflows verwendet wird.

#include <mfapi.h> 
#include <wmcodecdsp.h>  // CLSID_VideoProcessorMFT 

using Microsoft::WRL; 

HRESULT ConvertYUY2toI422WithXVP( 
    _In_ IMFSample* inputSample, 
    _In_ MFT_OUTPUT_DATA_BUFFER* outputBuffer, 
    UINT32 width, 
    UINT32 height)
{ 
    RETURN_HR_IF_NULL(E_INVALIDARG, inputSample);     
    RETURN_HR_IF_NULL(E_INVALIDARG, outputBuffer);     

    ComPtr<IMFTransform> xvp; 
    RETURN_IF_FAILED(CoCreateInstance( 
        CLSID_VideoProcessorMFT, 
        nullptr, 
        CLSCTX_INPROC_SERVER, 
        IID_PPV_ARGS(&xvp))); 

    // Set input type: MFVideoFormat_YUY2 
    ComPtr<IMFMediaType> inputType; 
    RETURN_IF_FAILED(MFCreateMediaType(&inputType)); 
    RETURN_IF_FAILED(inputType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Video)); 
    RETURN_IF_FAILED(inputType->SetGUID(MF_MT_SUBTYPE, MFVideoFormat_YUY2)); 
    RETURN_IF_FAILED(MFSetAttributeSize(inputType.Get(), MF_MT_FRAME_SIZE, width, height)); 
    RETURN_IF_FAILED(spXVP->SetInputType(0, inputType.Get(), 0)); 

    // Set output type: MFVideoFormat_I422 
    ComPtr<IMFMediaType> outputType; 
    RETURN_IF_FAILED(MFCreateMediaType(&outputType)); 
    RETURN_IF_FAILED(outputType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Video)); 
    RETURN_IF_FAILED(outputType->SetGUID(MF_MT_SUBTYPE, MFVideoFormat_I422)); 
    RETURN_IF_FAILED(MFSetAttributeSize(outputType.Get(), MF_MT_FRAME_SIZE, width, height)); 
    RETURN_IF_FAILED(xvp->SetOutputType(0, outputType.Get(), 0)); 

    // Submit input sample 
    RETURN_IF_FAILED(xvp->ProcessInput(0, inputSample, 0)); 

    // Request the converted output sample 
    DWORD status = 0; 
    return xvp->ProcessOutput(0, 1, outputBuffer, &status);
} 

Konvertieren von AYUV in I444

Für das 4:4:4-Farbformat können einige Decoder standardmäßig MFVideoFormat_AYUV ausgeben, bei dem es sich um ein verpacktes Format handelt. Viele Encoder erwarten jedoch Eingaben im Planarformat MFVideoFormat_I444. In solchen Fällen kann der Transcoding-Videoprozessor Media Foundation Transform (XVP) in die Pipeline eingefügt werden, um MFVideoFormat_AYUV in MFVideoFormat_I444 zu konvertieren. In diesem Beispiel wird veranschaulicht, wie XVP zum Ausführen dieser Konvertierung für Codierungsworkflows verwendet wird.

#include <mfapi.h> 
#include <wmcodecdsp.h>  // CLSID_VideoProcessorMFT 

using Microsoft::WRL; 

HRESULT ConvertAYUVtoI444WithXVP( 
    _In_ IMFSample* inputSample, 
    _In_ MFT_OUTPUT_DATA_BUFFER* outputBuffer, 
    UINT32 width, 
    UINT32 height) 
{ 
    RETURN_HR_IF_NULL(E_INVALIDARG, inputSample);     
    RETURN_HR_IF_NULL(E_INVALIDARG, outputBuffer);     

    ComPtr<IMFTransform> xvp; 
    RETURN_IF_FAILED(CoCreateInstance( 
        CLSID_VideoProcessorMFT, 
        nullptr, 
        CLSCTX_INPROC_SERVER, 
        IID_PPV_ARGS(&xvp))); 

    // Set input type: MFVideoFormat_AYUV 
    ComPtr<IMFMediaType> inputType; 
    RETURN_IF_FAILED(MFCreateMediaType(&inputType)); 
    RETURN_IF_FAILED(inputType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Video)); 
    RETURN_IF_FAILED(inputType->SetGUID(MF_MT_SUBTYPE, MFVideoFormat_AYUV)); 
    RETURN_IF_FAILED(MFSetAttributeSize(inputType.Get(), MF_MT_FRAME_SIZE, width, height)); 
    RETURN_IF_FAILED(xvp->SetInputType(0, inputType.Get(), 0)); 

    // Set output type: MFVideoFormat_I444 
    ComPtr<IMFMediaType> outputType; 
    RETURN_IF_FAILED(MFCreateMediaType(&outputType)); 
    RETURN_IF_FAILED(outputType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Video)); 
    RETURN_IF_FAILED(outputType->SetGUID(MF_MT_SUBTYPE, MFVideoFormat_I444)); 
    RETURN_IF_FAILED(MFSetAttributeSize(outputType.Get(), MF_MT_FRAME_SIZE, width, height)); 
    RETURN_IF_FAILED(xvp->SetOutputType(0, outputType.Get(), 0)); 

    // Submit input sample 
    RETURN_IF_FAILED(xvp->ProcessInput(0, inputSample, 0)); 

    // Request the converted output sample 
    DWORD status = 0; 
    return xvp->ProcessOutput(0, 1, outputBuffer, &status); 
} 

Andere YUV-Formate

Einige andere, weniger gängige YUV-Formate umfassen Folgendes:

• AI44 ist ein palettisiertes YUV-Format mit 8 Bit pro Beispiel. Jedes Beispiel enthält einen Index in den 4 wichtigsten Bits (MSBs) und einen Alphawert in den 4 am wenigsten signifikanten Bits (LSBs). Der Index bezieht sich auf ein Array von YUV-Paletteneinträgen, die im Medientyp für das Format definiert werden müssen. Dieses Format wird in erster Linie für Untertitel-Grafiken verwendet.
• NV11 ist ein Planarformat von 4:1:1 mit 12 Bit pro Pixel. Die Y-Samples erscheinen zuerst im Speicher. Auf die Y-Ebene folgt eine Reihe von zusammengefassten U-(Cb)- und V-(Cr)-Abtastwerten. Wenn das kombinierte U-V-Array als Array mit wenig endischen WORD-Werten adressiert wird, sind die U-Beispiele in den LSBs jedes WORD enthalten, und die V-Beispiele sind in den MSBs enthalten. (Dieses Speicherlayout ähnelt NV12, obwohl sich das Farbsampling unterscheidet.)
• Y41P ist ein 4:1:1 gepacktes Format, bei dem U und V jedes vierte Pixel horizontal abgetastet werden. Jedes Makropixel enthält 8 Pixel in drei Byte mit dem folgenden Bytelayout: U0 Y0 V0 Y1 U4 Y2 V4 Y3 Y4 Y5 Y6 Y7
• Y41T ist identisch mit Y41P, mit Ausnahme, dass das am wenigsten signifikante Bit jedes Y-Samples den Chromaschlüssel angibt (0 = transparent, 1 = opak).
• Y42T ist identisch mit UYVY, abgesehen davon, dass das am wenigsten signifikante Bit jeder Y-Probe den Chromaschlüssel angibt (0 = transparent, 1 = undurchsichtig).
• YVYU ist gleichwertig zu YUYV, außer dass die U- und V-Stichproben ausgetauscht werden.

Identifizieren von YUV-Formaten in Media Foundation

Jedes der in diesem Artikel beschriebenen YUV-Formate verfügt über einen zugewiesenen FOURCC-Code. Ein FourCC-Code ist eine 32-Bit ganze Zahl ohne Vorzeichen, die durch das Verketten von vier ASCII-Zeichen erstellt wird.

Es gibt verschiedene C/C++-Makros, die es einfacher machen, FOURCC-Werte im Quellcode zu deklarieren. Zum Beispiel wird das MAKEFOURCC-Makro in Mmsystem.h deklariert, und das FCC-Makro wird in Aviriff.h deklariert. Verwenden Sie sie wie folgt:

DWORD fccYUY2 = MAKEFOURCC('Y','U','Y','2');
DWORD fccYUY2 = FCC('YUY2');

Sie können einen FourCC-Code auch direkt als Zeichenfolgenliteral deklarieren, indem Sie einfach die Reihenfolge der Zeichen umkehren. Beispiel:

DWORD fccYUY2 = '2YUY';  // Declares the FOURCC 'YUY2'

Das Umkehren der Reihenfolge ist erforderlich, da das Windows-Betriebssystem eine wenig endende Architektur verwendet. 'Y' = 0x59, 'U' = 0x55, und '2' = 0x32, daher ist '2YUY' 0x32595559.

In Media Foundation werden Formate durch eine Haupttyp-GUID und eine Untertyp-GUID identifiziert. Der Haupttyp für Computervideoformate ist immer MFMediaType_Video. Der Untertyp kann erstellt werden, indem der FOURCC-Code einer GUID wie folgt zugeordnet wird:

XXXXXXXX-0000-0010-8000-00AA00389B71 

bei XXXXXXXX handelt es sich um den FOURCC-Code. Die Subtyp-GUID für YUY2 lautet also:

32595559-0000-0010-8000-00AA00389B71 

Konstanten für die am häufigsten verwendeten YUV-Format-GUIDs werden in der Headerdatei mfapi.h definiert. Eine Liste dieser Konstanten finden Sie unter "VideoUntertyp-GUIDs".

Zugehörige Themen

Über YUV Video

Video-Medientypen