HDR-Videowiedergabe

HDR-Videos (High Dynamic Range) setzen bei der Videodecodierung in hoher Qualität neue Maßstäbe und bringt unübertroffene Qualitäten bei der Szenenwiedergabe mit sich. Dazu wird der dynamische Bereich der Luminanzkomponente deutlich erhöht (von den aktuellen 100 cd/m² auf 1.000 cd/m²) und ein viel breiterer Farbraum verwendet (BT 2020). Dies ist mittlerweile ein zentraler Bestandteil der Entwicklung von 4K-UHD-Inhalten im TV-Bereich.

Android 10 unterstützt die folgenden HDR-Videos.

• HDR10
• VP9
• HDR10+

Ab Android 9 meldet MediaCodec HDR-Metadaten unabhängig vom Tunnelmodus. Im Modus ohne Tunnel können Sie decodierte Daten zusammen mit statischen/dynamischen Metadaten abrufen. Bei HDR10 und VP9Profile2, die statische Metadaten verwenden, werden diese im Ausgabeformat mit dem Schlüssel KEY_HDR_STATIC_INFO gemeldet. Bei HDR10+, die dynamische Metadaten verwendet, wird dies mit dem Schlüssel KEY_HDR10_PLUS_INFO im Ausgabeformat gemeldet und kann sich für jeden Ausgabeframe ändern. Weitere Informationen finden Sie unter Multimedia-Tunneling.

Seit Android 7.0 umfasst die anfängliche HDR-Unterstützung das Erstellen geeigneter Konstanten für die Suche und Einrichtung von HDR-Videopipelines. Dazu müssen Codec-Typen und Anzeigemodi definiert und angegeben werden, wie HDR-Daten an MediaCodec übergeben und an HDR-Decodierer übergeben werden müssen.

Dieses Dokument soll Anwendungsentwicklern dabei helfen, die Wiedergabe von HDR-Streams zu unterstützen und OEMs und SOCs dabei helfen, die HDR-Funktionen zu aktivieren.

Unterstützte HDR-Technologien

Ab Android 7.0 werden die folgenden HDR-Technologien unterstützt.

In Android 7.0 ist nur die HDR-Wiedergabe über den Tunnelmodus definiert. Geräte können jedoch die Wiedergabe von HDR auf SurfaceViews mithilfe von opaken Videopuffern unterstützen. Mit anderen Worten:

• Es gibt keine standardmäßige Android API, um zu prüfen, ob die HDR-Wiedergabe mit Decoder ohne Tunnel unterstützt wird.
• Tunnelfähige Videodekoder, die die HDR-Wiedergabe unterstützen, müssen die HDR-Wiedergabe bei Verbindung mit HDR-fähigen Displays unterstützen.
• Die GL-Komposition von HDR-Inhalten wird von der AOSP-Version 7.0 von Android nicht unterstützt.

Entdecken

Für die HDR-Wiedergabe ist ein HDR-fähiger Decoder und eine Verbindung zu einem HDR-fähigen Display erforderlich. Optional erfordern einige Technologien einen bestimmten Extraktor.

Anzeige

Anwendungen müssen die neue Display.getHdrCapabilities API verwenden, um die vom angegebenen Display unterstützten HDR-Technologien abzufragen. Dies sind im Wesentlichen die Informationen im EDID-Datenblock für statische Metadaten gemäß CTA-861.3:

• public Display.HdrCapabilities getHdrCapabilities()
  Gibt die HDR-Funktionen des Displays zurück.
• Display.HdrCapabilities
  Umfasst die HDR-Funktionen eines bestimmten Displays. Dazu gehören beispielsweise die unterstützten HDR-Typen und Details zu den gewünschten Leuchtdichtedaten.

Konstanten:

• int HDR_TYPE_DOLBY_VISION
  Unterstützung von Dolby Vision.
• int HDR_TYPE_HDR10
  HDR10-/PQ-Unterstützung.
• int HDR_TYPE_HDR10_PLUS
  Unterstützung von HDR10+.
• int HDR_TYPE_HLG
  Unterstützung für Hybrid Log-Gamma.
• float INVALID_LUMINANCE
  Ungültiger Leuchtdichtewert.

Öffentliche Methoden:

• float getDesiredMaxAverageLuminance()
  Gibt die gewünschten Daten zur maximalen durchschnittlichen Frame-Leuchtkraft in cd/m² für dieses Display zurück.
• float getDesiredMaxLuminance()
  Gibt die gewünschten Daten zur maximalen Leuchtkraft des Inhalts in cd/m² für dieses Display zurück.
• float getDesiredMinLuminance()
  Gibt die gewünschten minimalen Luminanzdaten des Inhalts in cd/cd/m² für diesen Bildschirm zurück.
• int[] getSupportedHdrTypes()
  Erhält die unterstützten HDR-Typen dieses Bildschirms (siehe Konstanten). Gibt ein leeres Array zurück, wenn HDR vom Display nicht unterstützt wird.

Decoder

Anwendungen müssen die vorhandene CodecCapabilities.profileLevels API verwenden, um die Unterstützung der neuen HDR-fähigen Profile zu prüfen:

Dolby Vision

MediaFormat mime-konstante:

String MIMETYPE_VIDEO_DOLBY_VISION

MediaCodecInfo.CodecProfileLevel-Profilkonstanten:

int DolbyVisionProfileDvavPen
int DolbyVisionProfileDvavPer
int DolbyVisionProfileDvheDen
int DolbyVisionProfileDvheDer
int DolbyVisionProfileDvheDtb
int DolbyVisionProfileDvheDth
int DolbyVisionProfileDvheDtr
int DolbyVisionProfileDvheStn

Dolby Vision-Videoebenen und -Metadaten müssen von Videoanwendungen in einem einzigen Zwischenspeicher pro Frames verkettet werden. Dies geschieht automatisch durch den Dolby-Vision-fähigen MediaExtractor.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel-Profilkonstanten:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG und PQ

Konstanten für das MediaCodecInfo.CodecProfileLevel-Profil:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Wenn eine Plattform einen HDR-fähigen Decoder unterstützt, muss sie auch einen HDR-fähigen Extractor unterstützen.

Nur mit getunnelten Decodern können HDR-Inhalte garantiert wiedergegeben werden. Die Wiedergabe mit nicht getunnelten Decodern kann dazu führen, dass die HDR-Informationen verloren gehen und die Inhalte in ein SDR-Farbvolumen umgewandelt werden.

Extraktor

Die folgenden Container werden unter Android 7.0 für die verschiedenen HDR-Technologien unterstützt:

Die Plattform unterstützt nicht, zu ermitteln, ob für einen Titel (einer Datei) HDR-Unterstützung erforderlich ist. Anwendungen können die Codec-spezifischen Daten parsen, um festzustellen, ob ein Titel ein bestimmtes HDR-Profil erfordert.

Zusammenfassung

Die Anforderungen an Komponenten der einzelnen HDR-Technologien sind in der folgenden Tabelle aufgeführt:

Hinweise:

• Dolby Vision-Bitstreams werden auf eine von Dolby definierte Weise in einem MP4-Container verpackt. Anwendungen können eigene Dolby-kompatible Extraktoren implementieren, solange sie die Zugriffseinheiten aus den entsprechenden Schichten in eine einzelne Zugriffseinheit für den Decoder verpacken, wie von Dolby definiert.
• Eine Plattform unterstützt möglicherweise einen HDR-fähigen Extraktor, aber keinen entsprechenden HDR-fähigen Decoder.

Wiedergabe

Nachdem die Unterstützung der HDR-Wiedergabe in einer Anwendung bestätigt wurde, können HDR-Inhalte fast genauso wie nicht-HDR-Inhalte wiedergegeben werden. Es gelten jedoch die folgenden Einschränkungen:

• Bei Dolby-Vision ist nicht sofort verfügbar, ob für eine bestimmte Mediendatei oder einen bestimmten Medientitel ein HDR-fähiger Decoder erforderlich ist. Die Anwendung muss diese Informationen im Voraus haben oder in der Lage sein, diese Informationen abzurufen, indem sie den Codec-spezifischen Datenabschnitt des MediaFormat analysiert.
• CodecCapabilities.isFormatSupported berücksichtigt nicht, ob die getunnelte Decoderfunktion zur Unterstützung eines solchen Profils erforderlich ist.

Unterstützung der HDR-Plattform aktivieren

SoC-Anbieter und OEMs müssen zusätzliche Arbeiten ausführen, um die HDR-Plattformunterstützung für ein Gerät zu aktivieren.

Plattformänderungen in Android 7.0 für HDR

Hier sind einige wichtige Änderungen auf der Plattform (App-/native Ebene), die OEMs und SOCs kennen sollten.

Anzeige

Hardwarezusammensetzung

HDR-fähige Plattformen müssen das Mischen von HDR-Inhalten mit nicht HDR-Inhalten unterstützen. Die genauen Zusammenführungsmerkmale und -vorgänge werden von Android ab Version 7.0 nicht definiert, aber der Prozess folgt im Allgemeinen den folgenden Schritten:

1. Bestimmen Sie basierend auf der Farbe, dem Mastering und potenziellen dynamischen Metadaten der Ebenen einen linearen Farbraum bzw. ein lineares Volumen, der alle zu erstellenden Ebenen enthält.
   Beim direkten Zusammensetzen auf einem Display könnte es sich um den linearen Bereich handeln, der dem Farbvolumen des Displays entspricht.
2. Konvertieren Sie alle Ebenen in den gemeinsamen Farbraum.
3. Führen Sie die Überblendung aus.
4. Bei Verwendung über HDMI:
   1. Bestimmen Sie die Farbe, das Mastering und potenzielle dynamische Metadaten für die kombinierte Szene.
   2. Konvertieren Sie das Ergebnis der zusammengeführten Szene in den abgeleiteten Farbraum bzw. das abgeleitete Volumen.
5. Wenn die Ausgabe direkt auf dem Display erfolgt, wandeln Sie die resultierende gemischte Szene in die erforderlichen Displaysignale um, um diese Szene zu erstellen.

Auffindbarkeit im Displaynetzwerk

HDR-Displayerkennung wird nur über HWC2 unterstützt. Geräteimplementierer müssen den HWC2-Adapter, der mit Android 7.0 veröffentlicht wird, selektiv aktivieren, damit diese Funktion funktioniert. Daher müssen Plattformen Unterstützung für HWC2 hinzufügen oder das AOSP-Framework erweitern, um diese Informationen bereitzustellen. HWC2 stellt eine neue API zur Verfügung, um statische HDR-Daten an das Framework und die Anwendung zu übertragen.

HDMI

• Ein angeschlossener HDMI-Bildschirm bewirbt seine HDR-Fähigkeit über HDMI-EDID, wie in CTA-861.3, Abschnitt 4.2. definiert.
• Die folgende EOTF-Zuordnung ist zu verwenden:
  • ET_0 – Traditionelles Gamma – SDR-Leuchtdichtebereich: keinem HDR-Typ zugeordnet
  • ET_1 (traditionell) Gamma – HDR-Helligkeitsbereich: keinem HDR-Typ zugeordnet
  • ET_2 SMPTE ST 2084 – HDR10 zugeordnet
• Die Signalisierung der Dolby Vision- oder HLG-Unterstützung über HDMI erfolgt gemäß den entsprechenden Richtlinien.
• Die HWC2 API verwendet Gleitkommawerte. Daher müssen die 8-Bit-EDID-Werte in eine geeignete Weise übersetzt werden.

Decodierer

Die Plattformen müssen HDR-fähige Tunnel-Decoder hinzufügen und für ihre HDR-Unterstützung werben. HDR-fähige Decoder müssen in der Regel:

• Unterstützung für die getunnelte Dekodierung (FEATURE_TunneledPlayback)
• Unterstützung für statische HDR-Metadaten (OMX.google.android.index.describeHDRColorInfo) und deren Weitergabe an die Display-/Hardwarezusammensetzung. Für HLG müssen entsprechende Metadaten an das Display gesendet werden.
• Unterstützung für die Farbbeschreibung (OMX.google.android.index.describeColorAspects) und deren Weitergabe auf die Display-/Hardware-Zusammensetzung.
• Unterstützung von eingebetteten HDR-Metadaten gemäß dem entsprechenden Standard.

Unterstützung für Dolby Vision-Decoder

Zur Unterstützung von Dolby Vision müssen Plattformen einen Dolby Vision-kompatiblen HDR-OMX-Decoder hinzufügen. Aufgrund der Besonderheiten von Dolby Vision ist dies normalerweise ein Wrapper-Decoder um einen oder mehrere AVC- und/oder HEVC-Decoder sowie einen Compositor. Solche Decodierer müssen:

• Unterstützt den MIME-Typ „video/dolby-vision“.
• Unterstützte Dolby Vision-Profile/-Stufen angeben
• Akzeptiere Zugriffseinheiten, die die Unterzugriffseinheiten aller Ebenen gemäß der Definition von Dolby enthalten.
• Akzeptieren von Codec-spezifischen Daten, die von Dolby definiert wurden. Zum Beispiel Daten, die das Dolby Vision-Profil bzw. die Dolby Vision-Profilebene und möglicherweise die Codec-spezifischen Daten für die internen Decoder enthalten.
• Den adaptiven Wechsel zwischen Dolby Vision-Profilen/-Ebenen unterstützen, wenn Dolby erforderlich ist.

Beim Konfigurieren des Decoders wird das tatsächliche Dolby-Profil nicht an den Codec übermittelt. Dies erfolgt nur über Codec-spezifische Daten, nachdem der Decoder gestartet wurde. Eine Plattform könnte mehrere Dolby Vision-Decoder auswählen: einen für AVC-Profile und einen für HEVC-Profile, um zugrunde liegende Codecs während der Konfiguration zu initialisieren. Wenn ein einzelner Dolby Vision-Decoder beide Profiltypen unterstützt, muss auch der dynamische und adaptive Wechsel zwischen diesen Profilen möglich sein.

Wenn eine Plattform zusätzlich zur allgemeinen Unterstützung für HDR-Decoder einen Dolby-Vision-fähigen Decoder bietet, muss sie:

• Stelle einen Dolby Vision-kompatiblen Extractor bereit, auch wenn er die HDR-Wiedergabe nicht unterstützt.
• Stellen Sie einen Decoder bereit, der das von Dolby definierte Vision-Profil unterstützt.

Unterstützung für HDR10-Decoder

Zur Unterstützung von HDR10 müssen Plattformen einen HDR10-fähigen OMX-Decoder hinzufügen. Dies ist normalerweise ein getunnelter HEVC-Decoder, der auch das Parsen und Verarbeiten von HDMI-bezogenen Metadaten unterstützt. Ein solcher Decoder muss (neben der allgemeinen HDR-Decoder-Unterstützung) folgende Anforderungen erfüllen:

• Der MIME-Typ „video/hevc“ wird unterstützt.
• Unterstützte HEVCMain10HDR10-Streams angeben Für die Unterstützung des HEVCMain10HRD10-Profils muss auch das HEVCMain10-Profil unterstützt werden, was wiederum die Unterstützung des HEVCMain-Profils auf denselben Ebenen erfordert.
• Unterstützung für das Parsen der SEI-Blöcke für Mastering-Metadaten sowie anderer HDR-bezogener Informationen in SPS.

VP9-Decoderunterstützung

Zur Unterstützung von VP9 HDR müssen Plattformen einen HDR-OMX-Decodierer mit VP9-Profil 2 hinzufügen. Dies ist normalerweise ein getunnelter VP9-Decoder, der auch die Verarbeitung von HDMI-bezogenen Metadaten unterstützt. Zusätzlich zur allgemeinen Unterstützung von HDR-Decodern müssen diese Decoder:

• Der MIME-Typ „video/x-vnd.on2.vp9“ wird unterstützt.
• Unterstütztes VP9Profile2-HDR-Video bewerben. Für die Unterstützung von VP9Profile2-HDR-Profilen muss auch das Profil VP9Profile2 auf derselben Ebene unterstützt werden.

Extraktoren

Unterstützung für Dolby Vision-Extraktor

Plattformen, die Dolby Vision-Decoder unterstützen, müssen die Unterstützung für Dolby Extractor (Dolby Extractor) für Dolby Video-Inhalte hinzufügen.

• Ein normaler MP4-Extractor kann nur die Basisebene aus einer Datei extrahieren, aber nicht die Ebenen für Verbesserungen oder Metadaten. Zum Extrahieren der Daten aus der Datei ist also ein spezieller Dolby-Extraktor erforderlich.
• Der Dolby-Extractor muss für jeden Dolby-Videotrack (-gruppe) ein bis zwei Tracks bereitstellen:
  • Ein Dolby Vision-HDR-Track vom Typ „video/dolby-vision“ für den kombinierten 2/3-Schichten-Dolby-Stream. Das Format der Zugriffseinheiten des HDR-Tracks, das definiert, wie die Zugriffseinheiten aus den Basis-/Optimierungs-/Metadatenebenen in einen einzelnen Zwischenspeicher verpackt werden, der in einen einzelnen HDR-Frame decodiert wird, wird von Dolby definiert.
  • Wenn ein Dolby Vision-Videotrack eine separate (rückwärtskompatible) Basisebene (BL) enthält, muss der Extractor diese auch als separaten „video/avc“- oder „video/hevc“-Track bereitstellen. Der Extraktor muss reguläre AVC/HEVC-Zugriffseinheiten für diesen Track bereitstellen.
  • Der BL-Track muss dieselbe eindeutige Track-ID („track-ID“) wie der HDR-Track haben, damit die App erkennt, dass es sich um zwei Codierungen desselben Videos handelt.
  • Die Anwendung kann dann basierend auf der Funktion der Plattform entscheiden, welche Version sie wählen soll.
• Das Dolby Vision-Profil bzw. die Dolby Vision-Ebene muss im Track-Format des HDR-Titels bereitgestellt werden.
• Wenn eine Plattform einen Dolby-Vision-fähigen Decoder bietet, muss sie auch einen Dolby-Vision-fähigen Extraktor bereitstellen, auch wenn sie die HDR-Wiedergabe nicht unterstützt.

Unterstützung für HDR10- und VP9-HDR-Extractor

Für die Unterstützung von HDR10 oder VP9 HLG gelten keine zusätzlichen Extraktoren. Plattformen müssen den MP4-Extractor so erweitern, dass er VP9 PQ in MP4 unterstützt. Statische HDR-Metadaten müssen im VP9 PQ-Bitstream weitergegeben werden, damit sie über die normale MediaExtractor => MediaCodec-Pipeline an den VP9 PQ-Decoder und an das Display übergeben werden.

Stagefright-Erweiterungen zur Unterstützung von Dolby Vision

Plattformen müssen Stagefright-Unterstützung für das Dolby Vision-Format hinzufügen:

• Unterstützung für Abfrage der Portdefinition für komprimierten Port
• Unterstützung der Profil-/Ebenenumerierung für DV-Decoder.
• Die Anzeige des DV-Profils bzw. der DV-Ebene für DV-HDR-Titel wird unterstützt.

Technologiespezifische Implementierungsdetails

HDR10-Decoderpipeline

Abbildung 1. HDR10-Pipeline

HDR10-Bitstreams werden in MP4-Containern verpackt. Anwendungen verwenden einen regulären MP4-Extraktor, um die Framedaten zu extrahieren und an den Decoder zu senden.

• MPEG4-Extractor
  HDR10-Bitstreams werden von einem MPEG4-Extractor als normaler HEVC-Stream erkannt und der HDR-Track vom Typ „video/HEVC“ wird extrahiert. Das Framework wählt einen HEVC-Videodecoder aus, der das Profil Main10 HDR10 unterstützt, um diesen Track zu decodieren.
• HEVC-Decoder
  HDR-Informationen sind entweder in SEI oder SPS verfügbar. Der HEVC-Decoder empfängt zuerst Frames, die die HDR-Informationen enthalten. Der Decoder extrahiert dann die HDR-Informationen und benachrichtigt die Anwendung, dass ein HDR-Video decodiert wird. HDR-Informationen werden im Decoder-Ausgabeformat gebündelt, das später an die Oberfläche übertragen wird.

Aktionen der Anbieter

1. Bewirb ein unterstütztes HDR-Decoderprofil und einen unterstützten OMX-Level-Typ. Beispiel:
   OMX_VIDEO_HEVCProfileMain10HDR10 (und Main10)
2. Unterstützung für den Index „OMX.google.android.index.describeHDRColorInfo“ implementieren
3. Unterstützung für den Index „OMX.google.android.index.describeColorAspects“ implementieren
4. Unterstützung für das SEI-Parsing von Mastering-Metadaten implementieren

Dolby Vision-Decoderpipeline

Abbildung 2. Dolby Vision-Pipeline

Dolby-Bitstreams werden in MP4-Containern verpackt, wie von Dolby definiert. Theoretisch könnten Anwendungen einen regulären MP4-Extractor verwenden, um die Basisebene, die Erweiterungsebene und die Metadatenebene unabhängig voneinander zu extrahieren. Dies entspricht jedoch nicht dem aktuellen Android MediaExtractor/MediaCodec-Modell.

• DolbyExtractor:
  • Dolby-Bitstreams werden von einem DolbyExtractor erkannt, der die verschiedenen Ebenen für jeden Dolby-Videotrack (Gruppe) als ein bis zwei Tracks verfügbar macht:
    • Ein HDR-Track vom Typ „video/dolby-vision“ für den kombinierten 2/3-Schichten-Dolby-Stream. Das Zugriffseinheitenformat des HDR-Tracks, das definiert, wie die Zugriffseinheiten aus den Basis-/Optimierungs-/Metadatenebenen in einem einzigen Puffer verpackt werden, der in einen einzelnen HDR-Frame decodiert wird, wird von Dolby definiert.
    • Optional, nur wenn BL abwärtskompatibel ist Der Extraktor sollte reguläre AVC/HEVC-Zugriffseinheiten für diesen Track bereitstellen. Dieser BL-Track muss dieselbe Track-ID ("Track-ID") wie der Dolby-Track haben, damit die Anwendung erkennt, dass es sich um zwei Codierungen desselben Videos handelt.
  • Die Anwendung kann anhand der Funktionen der Plattform entscheiden, welchen Track sie auswählt.
  • Da ein HDR-Titel einen bestimmten HDR-Typ hat, wählt das Framework einen Dolby-Videodecoder aus, um diesen Track zu decodieren. Der BL-Track wird von einem normalen AVC/HEVC-Videodecoder decodiert.
• DolbyDecoder:
  • Das DolbyDecoder erhält Zugriffseinheiten, die die erforderlichen Zugriffseinheiten für alle Ebenen enthalten (EL+BL+MD oder BL+MD).
  • CSD-Informationen (Codec-spezifische Daten wie SPS + PPS + VPS) für die einzelnen Ebenen können in einen CSD-Frame gepackt werden, der von Dolby definiert wird. Es ist ein einzelner CSD-Frame erforderlich.

Dolby-Aktionen

1. Definiere die Verpackung von Zugriffseinheiten für die verschiedenen Dolby-Containerschemata (z. B. BL+EL+MD) für den abstrakten Dolby-Decoder (d. h. das vom HDR-Decoder erwartete Pufferformat).
2. Definieren Sie die Paketerstellung für CSD für den abstrakten Dolby-Decoder.

Anbieteraktionen

1. Implementieren Sie Dolby-Extraktor. Das kann auch Dolby übernehmen.
2. DolbyExtractor in das Framework einbinden. Der Einstiegspunkt ist frameworks/av/media/libstagefright/MediaExtractor.cpp.
3. Deklariere das HDR-Decoderprofil und den OMX-Level-Typ. Beispiel: OMX_VIDEO_DOLBYPROFILETYPE und OMX_VIDEO_DOLBYLEVELTYP.
4. Unterstützung für „index:'OMX.google.android.index.describeColorAspects“ implementieren
5. Übertragen Sie die dynamischen HDR-Metadaten in jedem Frame an die App und die Oberfläche. In der Regel müssen diese Informationen in den von Dolby definierten decodierten Frame gepackt werden, da der HDMI-Standard keine Möglichkeit bietet, sie an den Bildschirm zu übergeben.

VP9-Decodierungspipeline

Abbildung 3 VP9-PQ-Pipeline

VP9-Bitstreams werden vom WebM-Team in WebM-Containern verpackt. Anwendungen müssen einen WebM-Extractor verwenden, um HDR-Metadaten aus dem Bitstream zu extrahieren, bevor Frames an den Decoder gesendet werden.

• WebM Extractor:
  • WebM Extractor extrahiert die HDR-Metadaten und die Frames aus dem Container.
• VP9-Decoder:
  • Decoder empfängt Profile2-Bitstreams und decodiert sie als normale VP9-Streams.
  • Der Decoder empfängt alle statischen HDR-Metadaten vom Framework.
  • Der Decoder empfängt statische Metadaten über die Bitstream-Zugriffseinheiten für VP9-PQ-Streams.
  • Der VP9-Decoder muss die statischen/dynamischen HDR-Metadaten an das Display übertragen können.

Anbieteraktionen

1. Implementieren Sie die Unterstützung für den Index: OMX.google.android.index.describeHDRColorInfo
2. Implementieren Sie die Unterstützung für den Index: OMX.google.android.index.describeColorAspects
3. Statische HDR-Metadaten weitergeben