HDR-Videowiedergabe

HDR-Videos (High Dynamic Range) sind die nächste Stufe der hochwertigen Videodecodierung und bieten eine unübertroffene Szenenwiedergabe. Dazu wird der dynamische Bereich der Luminanzkomponente erheblich erhöht (von den aktuellen 100 cd/m² auf Tausende von cd/m²) und ein viel breiterer Farbraum (BT 2020) verwendet. Dies ist mittlerweile ein zentrales Element der 4K‑UHD-Entwicklung im TV-Bereich.

Android 10 unterstützt die folgenden HDR-Videos.

• HDR10
• VP9
• HDR10+

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

Seit Android 7.0 umfasst die erste HDR-Unterstützung die Erstellung geeigneter Konstanten für die Erkennung und Einrichtung von HDR-Videopipelines. Das bedeutet, dass Sie Codec-Typen und Anzeigemodi definieren und angeben müssen, wie HDR-Daten an MediaCodec übergeben und HDR-Decodern bereitgestellt werden müssen.

Dieses Dokument soll Anwendungsentwicklern helfen, die Wiedergabe von HDR-Streams zu unterstützen, und OEMs und SOCs, 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 mit undurchsichtigen Videopuffern unterstützen. Dies bedeutet:

• Es gibt keine Standard-Android-API, mit der geprüft werden kann, ob die HDR-Wiedergabe mit nicht getunnelten Decodern unterstützt wird.
• Getunnelte Videodecoder, die HDR‑Wiedergabe unterstützen, müssen HDR‑Wiedergabe unterstützen, wenn sie mit HDR‑fähigen Displays verbunden sind.
• Die GL-Zusammensetzung von HDR-Inhalten wird von der AOSP-Version von Android 7.0 nicht unterstützt.

Discovery

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

Display

Anwendungen müssen die neue Display.getHdrCapabilities-API verwenden, um die vom angegebenen Display unterstützten HDR-Technologien abzufragen. Dies sind im Grunde die Informationen im EDID Static Metadata Data Block, wie in CTA-861.3 definiert:

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

Konstanten:

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

Öffentliche Methoden:

• float getDesiredMaxAverageLuminance()
  Gibt die gewünschten Daten zur maximalen Durchschnittshelligkeit eines Frames in cd/m² für dieses Display zurück.
• float getDesiredMaxLuminance()
  Gibt die gewünschten Daten zur maximalen Helligkeit des Inhalts in cd/m² für dieses Display zurück.
• float getDesiredMinLuminance()
  Gibt die gewünschten Daten zur Mindesthelligkeit des Inhalts in cd/m² für dieses Display zurück.
• int[] getSupportedHdrTypes()
  Gibt die unterstützten HDR-Typen dieses Displays zurück (siehe Konstanten). Gibt ein leeres Array zurück, wenn HDR vom Display nicht unterstützt wird.

Decodierer

Anwendungen müssen die vorhandene CodecCapabilities.profileLevels-API verwenden, um die Unterstützung für die 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-Videolayer und ‑Metadaten müssen von Videoanwendungen pro Frame in einem einzigen Puffer verkettet werden. Dies geschieht automatisch durch den Dolby Vision-kompatiblen MediaExtractor.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel-Profilkonstanten:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG und PQ

MediaCodecInfo.CodecProfileLevel-Profilkonstanten:

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 getunnelte Decoder können HDR-Inhalte wiedergeben. Bei der Wiedergabe durch nicht getunnelte Decoder können die HDR-Informationen verloren gehen und die Inhalte werden in ein SDR-Farbvolumen umgewandelt.

Extraktor

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

Die Plattform unterstützt nicht die Erkennung, ob für einen Track (einer Datei) HDR-Unterstützung erforderlich ist. Anwendungen können die codecspezifischen Daten parsen, um festzustellen, ob für einen Track ein bestimmtes HDR-Profil erforderlich ist.

Zusammenfassung

Die Komponentenanforderungen für die einzelnen HDR-Technologien sind in der folgenden Tabelle aufgeführt:

Hinweise:

• Dolby Vision-Bitstreams werden in einem MP4-Container verpackt, wie von Dolby definiert. Anwendungen können eigene Dolby-kompatible Extraktoren implementieren, sofern sie die Zugriffseinheiten der entsprechenden Ebenen in einer einzelnen Zugriffseinheit für den Decoder zusammenfassen, wie von Dolby definiert.
• Eine Plattform unterstützt möglicherweise einen HDR-fähigen Extraktor, aber keinen entsprechenden HDR-fähigen Decoder.

Wiedergabe

Nachdem eine Anwendung die Unterstützung für die HDR-Wiedergabe bestätigt hat, kann sie HDR-Inhalte fast genauso wie Nicht-HDR-Inhalte wiedergeben. Es gibt jedoch folgende Einschränkungen:

• Bei Dolby Vision ist nicht sofort ersichtlich, ob für eine bestimmte Mediendatei bzw. einen bestimmten Track ein HDR‑fähiger Decoder erforderlich ist. Die Anwendung muss diese Informationen im Voraus haben oder sie durch Parsen des codec-spezifischen Datenabschnitts des MediaFormat abrufen können.
• CodecCapabilities.isFormatSupported berücksichtigt nicht, ob das Feature „Getunnelter Decoder“ zur Unterstützung eines solchen Profils erforderlich ist.

HDR-Plattformunterstützung aktivieren

SoC-Anbieter und OEMs müssen zusätzliche Schritte 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-/nativ-Ebene), die OEMs und SOCs beachten müssen.

Display

Hardwarezusammensetzung

HDR-fähige Plattformen müssen das Mischen von HDR-Inhalten mit Nicht-HDR-Inhalten unterstützen. Die genauen Mischmerkmale und ‑vorgänge werden von Android ab Version 7.0 nicht definiert. Der Prozess umfasst jedoch in der Regel die folgenden Schritte:

1. Bestimmen Sie einen linearen Farbraum bzw. ein lineares Farbvolumen, das alle zu kombinierenden Ebenen enthält, basierend auf der Farbe, dem Mastering und den potenziellen dynamischen Metadaten der Ebenen.
   Wenn das Compositing direkt auf einem Display erfolgt, kann dies der lineare Farbraum sein, der dem Farbvolumen des Displays entspricht.
2. Alle Ebenen in den gemeinsamen Farbraum konvertieren
3. Führen Sie das Blending durch.
4. Wenn Sie die Präsentation über HDMI anzeigen:
   1. Bestimme die Farbe, das Mastering und die potenziellen dynamischen Metadaten für die gemischte Szene.
   2. Wandeln Sie die resultierende Mischszene in den abgeleiteten Farbraum bzw. das abgeleitete Volumen um.
5. Wenn die Szene direkt auf dem Display angezeigt wird, wandeln Sie die resultierende gemischte Szene in die erforderlichen Displaysignale um.

Display-Discovery

Die Erkennung von HDR-Displays wird nur über HWC2 unterstützt. Gerätehersteller müssen den mit Android 7.0 veröffentlichten HWC2-Adapter 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 bereitstellen zu können. HWC2 stellt eine neue API bereit, um statische HDR-Daten an das Framework und die Anwendung zu übertragen.

HDMI

• Ein angeschlossenes HDMI-Display gibt seine HDR-Fähigkeit über HDMI EDID gemäß CTA-861.3, Abschnitt 4.2, an.
• Die folgende EOTF-Zuordnung muss verwendet werden:
  • ET_0 Traditionelles Gamma – SDR-Helligkeitsbereich: keinem HDR-Typ zugeordnet
  • ET_1 Traditionelles Gamma – HDR-Helligkeitsbereich: keinem HDR-Typ zugeordnet
  • ET_2 SMPTE ST 2084 – zu HDR-Typ HDR10 zugeordnet
• Die Signalisierung der Dolby Vision- oder HLG-Unterstützung über HDMI erfolgt gemäß den Definitionen der entsprechenden Organisationen.
• Die HWC2-API verwendet Gleitkommawerte für die gewünschte Luminanz. Die 8-Bit-EDID-Werte müssen also entsprechend übersetzt werden.

Decoder

Plattformen müssen HDR-fähige getunnelte Decoder hinzufügen und ihre HDR-Unterstützung bewerben. Im Allgemeinen müssen HDR-fähige Decoder folgende Anforderungen erfüllen:

• Unterstützung der getunnelten Decodierung (FEATURE_TunneledPlayback).
• Unterstützung von statischen HDR-Metadaten (OMX.google.android.index.describeHDRColorInfo) und deren Übertragung an die Anzeige/Hardware-Komposition. Für HLG müssen dem Display entsprechende Metadaten übermittelt werden.
• Unterstützung der Farbbeschreibung (OMX.google.android.index.describeColorAspects) und deren Weitergabe an die Anzeige/Hardware-Zusammensetzung.
• Unterstützung von eingebetteten HDR-Metadaten gemäß dem relevanten Standard.

Unterstützung für Dolby Vision-Decoder

Um Dolby Vision zu unterstützen, müssen Plattformen einen Dolby Vision-fähigen HDR-OMX-Decoder hinzufügen. Aufgrund der Besonderheiten von Dolby Vision handelt es sich dabei in der Regel um einen Wrapper-Decoder für einen oder mehrere AVC- und/oder HEVC-Decoder sowie einen Compositor. Solche Decoder müssen:

• Unterstützung des MIME-Typs „video/dolby-vision“.
• Unterstützte Dolby Vision-Profile/-Levels bewerben
• Akzeptieren Sie Zugriffseinheiten, die die Unterzugriffseinheiten aller Ebenen enthalten, wie von Dolby definiert.
• Codec-spezifische Daten akzeptieren, die von Dolby definiert wurden. Beispiel: Daten mit Dolby Vision-Profil/‑Level und möglicherweise den codecspezifischen Daten für die internen Decoder.
• Unterstützung für das adaptive Umschalten zwischen Dolby Vision-Profilen/-Levels gemäß den Anforderungen von Dolby.

Bei der Konfiguration des Decoders wird das tatsächliche Dolby-Profil nicht an den Codec übermittelt. Dies erfolgt erst nach dem Start des Decoders über codec-spezifische Daten. Eine Plattform kann mehrere Dolby Vision-Decoder unterstützen: 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 Arten von Profilen unterstützt, muss er auch das dynamische Umschalten zwischen diesen Profilen auf adaptive Weise unterstützen.

Wenn eine Plattform zusätzlich zur allgemeinen Unterstützung von HDR-Decodern einen Dolby Vision-fähigen Decoder bereitstellt, muss sie Folgendes erfüllen:

• Stelle einen Dolby Vision-fähigen 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 in der Regel ein getunnelter HEVC-Decoder, der auch das Parsen und Verarbeiten von HDMI-bezogenen Metadaten unterstützt. Ein solcher Decoder muss (zusätzlich zur allgemeinen Unterstützung von HDR-Decodern):

• Unterstützung des MIME-Typs „video/hevc“.
• HEVCMain10HDR10 bewerben 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, die in SPS enthalten sind.

VP9-Decoder-Unterstützung

Um VP9 HDR zu unterstützen, müssen Plattformen einen HDR-OMX-Decoder hinzufügen, der VP9 Profil 2 unterstützt. Normalerweise ist das ein getunnelter VP9-Decoder, der auch die Verarbeitung von HDMI-bezogenen Metadaten unterstützt. Solche Decoder müssen zusätzlich zur allgemeinen HDR-Decoderunterstützung Folgendes bieten:

• Unterstützung des MIME-Typs „video/x-vnd.on2.vp9“.
• Unterstützung für VP9Profile2HDR ankündigen. Die Unterstützung des VP9Profile2HDR-Profils erfordert auch die Unterstützung des VP9Profile2-Profils auf demselben Niveau.

Extraktoren

Unterstützung für Dolby Vision-Extraktor

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

• Ein regulärer MP4-Extractor kann nur die Basisebene aus einer Datei extrahieren, nicht die Erweiterungs- oder Metadatenebenen. Daher ist ein spezieller Dolby-Extractor erforderlich, um die Daten aus der Datei zu extrahieren.
• Der Dolby-Extractor muss für jeden Dolby-Videotrack (Gruppe) ein bis zwei Tracks bereitstellen:
  • Ein Dolby Vision-HDR-Track mit dem Typ „video/dolby-vision“ für den kombinierten Dolby-Stream mit 2/3 Ebenen. Das Access-Unit-Format des HDR-Tracks, das definiert, wie die Access Units aus den Basis-, Erweiterungs- und Metadatenebenen in einem einzelnen Puffer verpackt werden, der in einen einzelnen HDR-Frame decodiert werden soll, muss von Dolby definiert werden.
  • Wenn ein Dolby Vision-Videotrack eine separate (rückwärtskompatible) Base-Layer (BL) enthält, muss der Extractor diese auch als separaten Track vom Typ „video/avc“ oder „video/hevc“ verfügbar machen. Der Extractor muss für diesen Track regelmäßig AVC-/HEVC-Zugriffseinheiten bereitstellen.
  • Der BL-Track muss dieselbe „track-ID“ wie der HDR-Track haben, damit die App erkennt, dass es sich um zwei Codierungen desselben Videos handelt.
  • Die Anwendung kann basierend auf den Funktionen der Plattform entscheiden, welcher Track ausgewählt werden soll.
• Das Dolby Vision-Profil bzw. der Dolby Vision-Level muss im Trackformat des HDR-Tracks angegeben werden.
• Wenn eine Plattform einen Dolby Vision-fähigen Decoder bereitstellt, muss sie auch einen Dolby Vision-kompatiblen Extractor bereitstellen, auch wenn sie die HDR-Wiedergabe nicht unterstützt.

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

Es gibt keine zusätzlichen Anforderungen an den Extractor für die Unterstützung von HDR10 oder VP9 HLG. Plattformen müssen den MP4-Extractor erweitern, um VP9 PQ in MP4 zu unterstützen. Statische HDR-Metadaten müssen im VP9-PQ-Bitstream weitergegeben werden, damit diese Metadaten über die normale MediaExtractor->MediaCodec-Pipeline an den VP9-PQ-Decoder und an das Display übergeben werden.

Stagefright-Erweiterungen für Dolby Vision-Unterstützung

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

• Unterstützung von Anfragen zur Portdefinition für komprimierte Ports.
• Unterstützung der Profil-/Level-Aufzählung für den DV-Decoder.
• Unterstützung für die Offenlegung von DV-Profil/‑Level für DV-HDR-Tracks.

Technologiespezifische Implementierungsdetails

HDR10-Decoder-Pipeline

Abbildung 1. HDR10-Pipeline

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

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

Aktionen der Anbieter

1. Gibt den unterstützten HDR-Decoderprofil- und ‑pegel-OMX-Typ an. Beispiel:
   OMX_VIDEO_HEVCProfileMain10HDR10 (und Main10)
2. Unterstützung für index: 'OMX.google.android.index.describeHDRColorInfo' implementieren
3. Unterstützung für index: 'OMX.google.android.index.describeColorAspects' implementieren
4. Implementieren Sie die Unterstützung für das SEI-Parsing von Mastering-Metadaten.

Dolby Vision-Decoder-Pipeline

Abbildung 2: Dolby Vision-Pipeline

Dolby-Bitstreams werden in MP4-Containern verpackt, wie von Dolby definiert. Anwendungen könnten theoretisch 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 als 1 bis 2 Tracks für jeden Dolby-Videotrack (Gruppe) bereitstellt:
    • Ein HDR-Track mit dem Typ „video/dolby-vision“ für den kombinierten Dolby-Stream mit 2/3 Ebenen. Das Access-Unit-Format des HDR-Tracks, das definiert, wie die Access Units aus den Basis-, Erweiterungs- und Metadatenebenen in einem einzigen Puffer verpackt werden, der in einen einzelnen HDR-Frame decodiert werden soll, wird von Dolby definiert.
    • (Optional, nur wenn die BL abwärtskompatibel ist) Ein BL-Track enthält nur die Basisebene, die von einem regulären MediaCodec-Decoder decodiert werden muss, z. B. einem AVC-/HEVC-Decoder. Der Extractor sollte für diesen Track reguläre AVC-/HEVC-Zugriffseinheiten bereitstellen. Dieser BL-Track muss dieselbe „track-ID“ wie der Dolby-Track haben, damit die Anwendung erkennt, dass es sich um zwei Codierungen desselben Videos handelt.
  • Die Anwendung kann basierend auf den Funktionen der Plattform entscheiden, welcher Track ausgewählt werden soll.
  • Da ein HDR-Track einen bestimmten HDR-Typ hat, wählt das Framework einen Dolby-Videodecoder zum Decodieren dieses Tracks aus. Der BL-Track wird von einem regulären AVC-/HEVC-Videodecoder decodiert.
• DolbyDecoder:
  • Der Dolby-Decoder empfängt Zugriffseinheiten, die die erforderlichen Zugriffseinheiten für alle Ebenen (EL+BL+MD oder BL+MD) enthalten.
  • CSD-Informationen (codec-specific data, z. B. SPS+PPS+VPS) für die einzelnen Ebenen können in einem CSD-Frame verpackt werden, der von Dolby definiert wird. Es ist ein einzelner CSD-Frame erforderlich.

Dolby-Aktionen

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

Aktionen der Anbieter

1. Dolby-Extraktor implementieren. Das kann auch von Dolby erledigt werden.
2. DolbyExtractor in das Framework einbinden Der Einstiegspunkt ist frameworks/av/media/libstagefright/MediaExtractor.cpp.
3. HDR-Decoderprofil und ‑Level des OMX-Typs deklarieren. Beispiel: OMX_VIDEO_DOLBYPROFILETYPE und OMX_VIDEO_DOLBYLEVELTYP.
4. Implementiere die Unterstützung für index: 'OMX.google.android.index.describeColorAspects'
5. Die dynamischen HDR-Metadaten werden an die App und in jedem Frame weitergegeben. Normalerweise müssen diese Informationen gemäß Dolby in den decodierten Frame eingebettet werden, da der HDMI-Standard keine Möglichkeit bietet, sie an das Display zu übergeben.

VP9-Decoder-Pipeline

Abbildung 3: VP9-PQ-Pipeline

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

• WebM Extractor:
  • WebM Extractor extrahiert die HDR-Metadaten und Frames aus dem Container.
• VP9-Decoder:
  • Der 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 weiterleiten können.

Aktionen der Anbieter

1. Unterstützung für „index“ implementieren: OMX.google.android.index.describeHDRColorInfo
2. Unterstützung für „index“ implementieren: OMX.google.android.index.describeColorAspects
3. Statische HDR-Metadaten weitergeben