HDR-Videowiedergabe

HDR-Videos (High Dynamic Range) sind die nächste Stufe der hochwertigen Videodecodierung und bieten eine unübertroffene Wiedergabe von Szenen. Dazu wird der dynamische Bereich der Luminanzkomponente erheblich erhöht (von den aktuellen 100 cd/m2 auf Tausende von cd/m2) und ein viel größerer Farbraum (BT 2020) verwendet. Das ist jetzt 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 getunnelten Modus 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 Ausgabeformat 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. Dazu müssen Codec-Typen und Anzeigemodi definiert und angegeben werden, 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.

Technologie Dolby Vision HDR10 VP9-HLG VP9-PQ
Codec AVC/HEVC HEVC VP9 VP9
Übertragungsfunktion ST-2084 ST-2084 HLG ST-2084
HDR-Metadatentyp Dynamisch Statisch Keine Statisch

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. Mit anderen Worten:

  • 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.

Entdecken

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.

Anzeige

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 durchschnittlichen Helligkeit eines Frames in cd/m2 für dieses Display zurück.
  • float getDesiredMaxLuminance()
    Gibt die gewünschten Daten zur maximalen Helligkeit des Inhalts in cd/m2 für dieses Display zurück.
  • float getDesiredMinLuminance()
    Gibt die gewünschten Daten zur Mindesthelligkeit des Inhalts in cd/m2 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.

Decoder

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 erfolgt automatisch durch den Dolby Vision-fähigen 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:

Technologie Dolby Vision HDR10 VP9-HLG VP9-PQ
Container MP4 MP4 WebM WebM

Die Plattform unterstützt nicht die Erkennung, ob ein Track (einer Datei) HDR-Unterstützung erfordert. 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:

Technologie Dolby Vision HDR10 VP9-HLG VP9-PQ
Unterstützter HDR-Typ (Display) HDR_TYPE_DOLBY_VISION HDR_TYPE_HDR10 HDR_TYPE_HLG HDR_TYPE_HDR10
Container (Extractor) MP4 MP4 WebM WebM
Decoder MIMETYPE_VIDEO_DOLBY_VISION MIMETYPE_VIDEO_HEVC MIMETYPE_VIDEO_VP9 MIMETYPE_VIDEO_VP9
Profil (Decoder) Eines der Dolby-Profile HEVCProfileMain10HDR10 VP9Profile2HDR oder VP9Profile3HDR VP9Profile2HDR oder VP9Profile3HDR

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 wiedergeben wie Nicht-HDR-Inhalte. 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.
  • Bei CodecCapabilities.isFormatSupported wird nicht berücksichtigt, 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.

Anzeige

Hardwarezusammensetzung

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

  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 Raum sein, der dem Farbvolumen des Displays entspricht.
  2. Alle Ebenen in den gemeinsamen Farbraum konvertieren
  3. Führen Sie die Zusammenführung durch.
  4. Wenn Sie die Anzeige über HDMI ausgeben:
    1. Bestimme die Farbe, das Mastering und die potenziellen dynamischen Metadaten für die gemischte Szene.
    2. Wandeln Sie die resultierende gemischte Szene in den abgeleiteten Farbraum bzw. das abgeleitete Volumen um.
  5. Wenn die Szene direkt auf dem Display angezeigt werden soll, 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 bietet eine neue API, 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 Traditional gamma - HDR Luminance Range: not mapped to any HDR type
    • ET_2 SMPTE ST 2084 – zugeordnet zum HDR-Typ HDR10
  • 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-/Hardwarekomposition.
  • Unterstützung von eingebetteten HDR-Metadaten gemäß dem entsprechenden 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 normalerweise 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.
  • Akzeptieren Sie codec-spezifische Daten, die von Dolby definiert wurden. Beispielsweise Daten, die das Dolby Vision-Profil/den Dolby Vision-Pegel und möglicherweise die codecspezifischen Daten für die internen Decoder enthalten.
  • 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 codecspezifische Daten. Eine Plattform kann mehrere Dolby Vision-Decoder unterstützen: einen für AVC-Profile und einen für HEVC-Profile, um die zugrunde liegenden 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 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. Normalerweise ist das 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ütze den MIME-Typ „video/hevc“.
  • HEVCMain10HDR10 bewerben Die Unterstützung des HEVCMain10HRD10-Profils erfordert auch die Unterstützung des HEVCMain10-Profils, 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 bewerben. Für die Unterstützung des VP9Profile2HDR-Profils muss auch das VP9Profile2-Profil auf demselben Niveau unterstützt werden.

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 (abwä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 übertragen werden, damit sie ü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 für die Abfrage der 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.

  • MPEG4-Extractor
    HDR10-Bitstreams werden von einem MPEG4-Extractor 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 für 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 aus, um diesen Track zu decodieren. Der BL-Track wird von einem regulären AVC/HEVC-Videodecoder decodiert.
  • DolbyDecoder:
    • Der DolbyDecoder 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. Ein einzelner CSD-Frame ist 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 für Anbieter

  1. Dolby-Extractor implementieren. Das kann auch von Dolby erledigt werden.
  2. DolbyExtractor in das Framework einbinden Der Einstiegspunkt ist frameworks/av/media/libstagefright/MediaExtractor.cpp.
  3. Deklarieren Sie das HDR-Decoderprofil und den OMX-Typ. 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 die Oberfläche 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:
  • 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 für 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 übertragen