HDR-Videowiedergabe

High-Dynamic-Range-Videos (HDR) sind die nächste Stufe der hochwertigen Videodekodierung und bieten unübertroffene Szenenwiedergabequalitäten. Dies geschieht durch eine deutliche Vergrößerung des Dynamikbereichs der Luminanzkomponente (von derzeit 100 cd/m 2 auf 1000 cd/m 2 ) und durch die Verwendung eines viel größeren Farbraums (BT 2020). 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 und höher meldet MediaCodec HDR-Metadaten unabhängig vom Tunnelmodus. Sie können dekodierte Daten zusammen mit statischen/dynamischen Metadaten im nicht getunnelten Modus abrufen. Für HDR10 und VP9Profile2, die statische Metadaten verwenden, werden diese im Ausgabeformat mit dem Schlüssel KEY_HDR_STATIC_INFO gemeldet. Für HDR10+, das dynamische Metadaten verwendet, wird dies mit dem Schlüssel KEY_HDR10_PLUS_INFO im Ausgabeformat gemeldet und kann sich für jedes Ausgabebild ändern. Weitere Informationen finden Sie unter Multimedia-Tunneling .

Seit Android 7.0 umfasst die anfängliche HDR-Unterstützung die Erstellung geeigneter Konstanten für die Erkennung und Einrichtung von HDR-Videopipelines. Das bedeutet, Codec-Typen und Anzeigemodi zu definieren und anzugeben, wie HDR-Daten an MediaCodec übergeben und an HDR-Decoder übermittelt werden müssen.

Der Zweck dieses Dokuments besteht darin, Anwendungsentwickler bei der Unterstützung der HDR-Stream-Wiedergabe zu unterstützen und OEMs und SOCs bei der Aktivierung der HDR-Funktionen zu unterstützen.

Unterstützte HDR-Technologien

Ab Android 7.0 und höher 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 Keiner Statisch

In Android 7.0 ist nur die HDR-Wiedergabe im Tunnelmodus definiert , aber Geräte unterstützen möglicherweise die Wiedergabe von HDR auf SurfaceViews mithilfe undurchsichtiger Videopuffer. Mit anderen Worten:

  • Es gibt keine Standard-Android-API, um zu überprüfen, ob die HDR-Wiedergabe mit nicht getunnelten Decodern unterstützt wird.
  • Tunnel-Videodecoder, die die HDR-Wiedergabefähigkeit ankündigen, müssen die HDR-Wiedergabe unterstützen, wenn sie an HDR-fähige Displays angeschlossen sind.
  • Die GL-Komposition von HDR-Inhalten wird von der AOSP-Version Android 7.0 nicht unterstützt.

Entdeckung

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

Anzeige

Anwendungen müssen die neue Display.getHdrCapabilities -API verwenden, um die von der angegebenen Anzeige unterstützten HDR-Technologien abzufragen. Dies sind im Grunde die Informationen im statischen EDID-Metadaten-Datenblock, wie in CTA-861.3 definiert:

  • public Display.HdrCapabilities getHdrCapabilities()
    Gibt die HDR-Fähigkeiten des Displays zurück.
  • Display.HdrCapabilities
    Kapselt die HDR-Funktionen einer bestimmten Anzeige. Zum Beispiel, welche HDR-Typen es unterstützt und Details zu den gewünschten Luminanzdaten.

Konstanten:

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

Öffentliche Methoden:

  • float getDesiredMaxAverageLuminance()
    Gibt die gewünschten maximalen bilddurchschnittlichen Luminanzdaten des Inhalts in cd/cd/m 2 für diese Anzeige zurück.
  • float getDesiredMaxLuminance()
    Gibt die gewünschten Daten zur maximalen Leuchtdichte des Inhalts in cd/cd/m 2 für diese Anzeige zurück.
  • float getDesiredMinLuminance()
    Gibt die gewünschten Daten zur minimalen Luminanz des Inhalts in cd/cd/m 2 für diese Anzeige zurück.
  • int[] getSupportedHdrTypes()
    Ruft die unterstützten HDR-Typen dieser Anzeige ab (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 überprü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 Puffer pro Frame verkettet werden. Dies erfolgt automatisch durch den Dolby-Vision-fähigen MediaExtractor.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel -Profilkonstanten:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG & 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 Extraktor unterstützen.

Nur getunnelte Decoder können HDR-Inhalte garantiert wiedergeben. Die Wiedergabe durch nicht getunnelte Decoder kann dazu führen, dass die HDR-Informationen verloren gehen und der Inhalt auf ein SDR-Farbvolumen reduziert wird.

Extraktor

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

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

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

Zusammenfassung

Die Komponentenanforderungen für jede HDR-Technologie sind in der folgenden Tabelle aufgeführt:

Technologie Dolby-Vision HDR10 VP9-HLG VP9-PQ
Unterstützter HDR-Typ (Anzeige) HDR_TYPE_DOLBY_VISION HDR_TYPE_HDR10 HDR_TYPE_HLG HDR_TYPE_HDR10
Container (Extraktor) 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

Anmerkungen:

  • Dolby-Vision-Bitströme werden auf eine von Dolby definierte Weise in einen MP4-Container verpackt. Anwendungen können ihre eigenen Dolby-fähigen Extraktoren implementieren, solange sie die Zugriffseinheiten aus den entsprechenden Schichten in einer einzigen Zugriffseinheit für den Decoder packen, 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 überprüft hat, kann sie HDR-Inhalte fast auf die gleiche Weise wiedergeben wie Nicht-HDR-Inhalte, mit den folgenden Einschränkungen:

  • Für Dolby-Vision ist nicht sofort verfügbar, ob für eine bestimmte Mediendatei/einen bestimmten Titel ein HDR-fähiger Decoder erforderlich ist. Die Anwendung muss über diese Informationen im Voraus verfügen oder in der Lage sein, diese Informationen durch Parsen des Codec-spezifischen Datenabschnitts des MediaFormats zu erhalten.
  • CodecCapabilities.isFormatSupported berücksichtigt nicht, ob die Tunnel-Decoder-Funktion für die Unterstützung eines solchen Profils erforderlich ist.

Aktivieren Sie die Unterstützung der HDR-Plattform

SoC-Anbieter und OEMs müssen zusätzliche Arbeit leisten, um die HDR-Plattformunterstützung für ein Gerät zu ermöglichen.

Plattformänderungen in Android 7.0 für HDR

Hier sind einige wichtige Änderungen in der Plattform (App/native Ebene), die OEMs und SOCs beachten müssen.

Anzeige

Hardware-Zusammensetzung

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

  1. Bestimmen Sie einen linearen Farbraum/ein lineares Farbvolumen, das alle zusammenzusetzenden Ebenen enthält, basierend auf der Farbe der Ebenen, dem Mastering und potenziellen dynamischen Metadaten.
    Wenn Sie direkt auf einem Display komponieren, könnte dies der lineare Raum sein, der dem Farbvolumen des Displays entspricht.
  2. Konvertieren Sie alle Ebenen in den gemeinsamen Farbraum.
  3. Führen Sie die Mischung durch.
  4. Bei Anzeige über HDMI:
    1. Bestimmen Sie die Farbe, das Mastering und mögliche dynamische Metadaten für die gemischte Szene.
    2. Konvertieren Sie die resultierende gemischte Szene in den abgeleiteten Farbraum/Volumen.
  5. Bei direkter Anzeige auf dem Display wandeln Sie die resultierende gemischte Szene in die erforderlichen Anzeigesignale um, um diese Szene zu erzeugen.

Erkennung anzeigen

Die HDR-Anzeigeerkennung 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 eine Möglichkeit zur Bereitstellung dieser Informationen zu ermöglichen. HWC2 stellt eine neue API zur Weitergabe statischer HDR-Daten an das Framework und die Anwendung bereit.

HDMI

  • Ein angeschlossenes HDMI-Display gibt seine HDR-Fähigkeit über HDMI EDID bekannt, wie in CTA-861.3 Abschnitt 4.2 definiert.
  • Die folgende EOTF-Zuordnung soll verwendet werden:
    • ET_0 Traditionelles Gamma – SDR-Luminanzbereich: keinem HDR-Typ zugeordnet
    • ET_1 Traditionelles Gamma – HDR-Luminanzbereich: keinem HDR-Typ zugeordnet
    • ET_2 SMPTE ST 2084 – zugeordnet zum HDR-Typ HDR10
  • Die Signalisierung der Dolby Vision- oder HLG-Unterstützung über HDMI erfolgt gemäß den Vorgaben der jeweiligen Stellen.
  • Beachten Sie, dass die HWC2-API die gewünschten Float-Luminanzwerte verwendet, sodass die 8-Bit-EDID-Werte auf geeignete Weise übersetzt werden müssen.

Decoder

Plattformen müssen HDR-fähige getunnelte Decoder hinzufügen und ihre HDR-Unterstützung bekannt geben. Im Allgemeinen müssen HDR-fähige Decoder:

  • Unterstützt getunnelte Dekodierung ( FEATURE_TunneledPlayback ).
  • Unterstützt statische HDR-Metadaten ( OMX.google.android.index.describeHDRColorInfo ) und deren Weitergabe an die Display-/Hardware-Komposition. Für HLG müssen entsprechende Metadaten an die Anzeige übermittelt werden.
  • Unterstützt die Farbbeschreibung ( OMX.google.android.index.describeColorAspects ) und deren Weitergabe an die Display-/Hardware-Komposition.
  • Unterstützt eingebettete HDR-Metadaten gemäß der Definition im 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. Angesichts der Besonderheiten von Dolby Vision handelt es sich normalerweise um einen Wrapper-Decoder um einen oder mehrere AVC- und/oder HEVC-Decoder sowie einen Compositor. Solche Decoder müssen:

  • Unterstützt den MIME-Typ „Video/Dolby-Vision“.
  • Kündigen Sie unterstützte Dolby Vision-Profile/-Stufen an.
  • Akzeptieren Sie Zugriffseinheiten, die die von Dolby definierten Unterzugriffseinheiten aller Schichten enthalten.
  • Akzeptieren Sie von Dolby definierte Codec-spezifische Daten. Zum Beispiel Daten, die Dolby Vision-Profil/-Stufe und möglicherweise die Codec-spezifischen Daten für die internen Decoder enthalten.
  • Unterstützt adaptives Umschalten zwischen Dolby Vision-Profilen/-Stufen gemäß den Anforderungen von Dolby.

Bei der Konfiguration des Decoders wird dem Codec nicht das eigentliche Dolby-Profil mitgeteilt. Dies erfolgt erst über Codec-spezifische Daten nach dem Start des Decoders. Eine Plattform könnte sich dafür entscheiden, mehrere Dolby Vision-Decoder zu unterstützen: einen für AVC-Profile und einen anderen für HEVC-Profile, um die zugrunde liegenden Codecs während der Konfigurationszeit initialisieren zu können. Wenn ein einzelner Dolby Vision-Decoder beide Profiltypen unterstützt, muss er auch das dynamische und adaptive Umschalten zwischen diesen unterstützen.

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

  • Stellen Sie einen Dolby-Vision-fähigen Extraktor bereit, auch wenn dieser keine HDR-Wiedergabe unterstützt.
  • Stellen Sie einen Decoder bereit, der das von Dolby definierte Vision-Profil unterstützt.

Unterstützung für HDR10-Decoder

Um HDR10 zu unterstützen, 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 (zusätzlich zur allgemeinen HDR-Decoder-Unterstützung) muss:

  • Unterstützt den MIME-Typ „video/hevc“.
  • Werben Sie für HEVCMain10HDR10. Die Unterstützung des HEVCMain10HRD10-Profils erfordert auch die Unterstützung des HEVCMain10-Profils, was die Unterstützung des HEVCMain-Profils auf denselben Ebenen erfordert.
  • Unterstützt das Parsen der Mastering-Metadaten-SEI-Blöcke sowie anderer HDR-bezogener Informationen, die in SPS enthalten sind.

VP9-Decoder-Unterstützung

Um VP9 HDR zu unterstützen, müssen Plattformen einen VP9 Profile2-fähigen HDR OMX-Decoder hinzufügen. Dies ist normalerweise ein getunnelter VP9-Decoder, der auch die Verarbeitung von HDMI-bezogenen Metadaten unterstützt. Solche Decoder (zusätzlich zur allgemeinen HDR-Decoder-Unterstützung) müssen:

  • Unterstützt den MIME-Typ „video/x-vnd.on2.vp9“.
  • Werbung unterstützt VP9Profile2HDR. Die Unterstützung des VP9Profile2HDR-Profils erfordert auch die Unterstützung des VP9Profile2-Profils auf derselben Ebene.

Extraktoren

Unterstützung für Dolby Vision-Extraktor

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

  • Ein normaler MP4-Extraktor kann nur die Basisebene aus einer Datei extrahieren, nicht jedoch die Erweiterungs- oder Metadatenebenen. Daher ist ein spezieller Dolby-Extraktor erforderlich, um die Daten aus der Datei zu extrahieren.
  • Der Dolby-Extraktor muss 1 bis 2 Spuren für jede Dolby-Videospur (Gruppe) freilegen:
    • Eine Dolby Vision HDR-Spur mit dem Typ „Video/Dolby-Vision“ für den kombinierten 2/3-Schichten-Dolby-Stream. Das Access-Unit-Format des HDR-Tracks, das definiert, wie die Access-Units aus den Basis-/Erweiterungs-/Metadatenschichten in einen einzelnen Puffer gepackt werden, um in einen einzelnen HDR-Frame dekodiert zu werden, muss von Dolby definiert werden.
    • Wenn eine Dolby Vision-Videospur eine separate (abwärtskompatible) Basisschicht (BL) enthält, muss der Extraktor diese auch als separate „video/avc“- oder „video/hevc“-Spur bereitstellen. Der Extraktor muss für diese Spur reguläre AVC/HEVC-Zugriffseinheiten bereitstellen.
    • Die BL-Spur muss dieselbe eindeutige Spur-ID („Spur-ID“) wie die HDR-Spur haben, damit die App erkennt, dass es sich um zwei Kodierungen desselben Videos handelt.
    • Die Anwendung kann basierend auf der Leistungsfähigkeit der Plattform entscheiden, welchen Track sie wählt.
  • Das Dolby Vision-Profil/-Level muss im Spurformat der HDR-Spur belichtet werden.
  • Wenn eine Plattform einen Dolby-Vision-fähigen Decoder bereitstellt, muss sie auch einen Dolby-Vision-fähigen Extraktor bereitstellen, auch wenn sie keine HDR-Wiedergabe unterstützt.

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

Für die Unterstützung von HDR10 oder VP9 HLG sind keine zusätzlichen Extraktoranforderungen erforderlich. Plattformen müssen den MP4-Extraktor erweitern, um VP9 PQ in MP4 zu unterstützen. Statische HDR-Metadaten müssen im VP9 PQ-Bitstrom weitergegeben werden, sodass diese Metadaten über die normale MediaExtractor => MediaCodec-Pipeline an den VP9 PQ-Decoder und an die Anzeige weitergeleitet 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 Portdefinitionsabfrage für komprimierte Ports.
  • Unterstützte Profil-/Level-Aufzählung für DV-Decoder.
  • Unterstützt die Belichtung von DV-Profilen/-Pegeln für DV-HDR-Spuren.

Technologiespezifische Implementierungsdetails

HDR10-Decoder-Pipeline

Abbildung 1. HDR10-Pipeline

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

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

Anbieteraktionen

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

Dolby Vision-Decoder-Pipeline

Abbildung 2. Dolby Vision-Pipeline

Dolby-Bitstreams werden gemäß der Definition von Dolby in MP4-Container verpackt. Anwendungen könnten theoretisch einen normalen MP4-Extraktor verwenden, um die Basisschicht, die Erweiterungsschicht und die Metadatenschicht unabhängig voneinander zu extrahieren. Dies passt jedoch nicht zum aktuellen Android MediaExtractor/MediaCodec-Modell.

  • DolbyExtractor:
    • Dolby-Bitstreams werden von einem DolbyExtractor erkannt, der die verschiedenen Schichten als 1 bis 2 Spuren für jede Dolby-Videospur (Gruppe) bereitstellt:
      • Eine HDR-Spur mit der Art „Video/Dolby-Vision“ für den kombinierten 2/3-Schichten-Dolby-Stream. Das Access-Unit-Format des HDR-Tracks, das definiert, wie die Access-Units aus den Basis-/Erweiterungs-/Metadatenschichten in einen einzelnen Puffer gepackt werden, um in einen einzelnen HDR-Frame dekodiert zu werden, muss von Dolby definiert werden.
      • (Optional, nur wenn die BL abwärtskompatibel ist) Eine BL-Spur enthält nur die Basisschicht, die mit einem regulären MediaCodec-Decoder, beispielsweise einem AVC/HEVC-Decoder, dekodierbar sein muss. Der Extraktor sollte reguläre AVC/HEVC-Zugriffseinheiten für diese Spur bereitstellen. Diese BL-Spur muss dieselbe eindeutige Spur-ID („Spur-ID“) wie die Dolby-Spur haben, damit die Anwendung versteht, dass es sich um zwei Kodierungen desselben Videos handelt.
    • Die Anwendung kann basierend auf der Leistungsfähigkeit der Plattform entscheiden, welchen Track sie wählt.
    • Da eine HDR-Spur einen bestimmten HDR-Typ hat, wählt das Framework einen Dolby-Videodecoder zum Dekodieren dieser Spur aus. Der BL-Track wird von einem regulären AVC/HEVC-Videodecoder dekodiert.
  • DolbyDecoder:
    • Der DolbyDecoder empfängt Zugriffseinheiten, die die erforderlichen Zugriffseinheiten für alle Schichten (EL+BL+MD oder BL+MD) enthalten.
    • CSD-Informationen (Codec-spezifische Daten wie SPS+PPS+VPS) für die einzelnen Schichten können in einen von Dolby zu definierenden CSD-Frame gepackt werden. Es ist ein einzelner CSD-Rahmen erforderlich.

Dolby-Aktionen

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

Anbieteraktionen

  1. Implementieren Sie den Dolby-Extraktor. Dies kann auch durch Dolby erfolgen.
  2. Integrieren Sie DolbyExtractor in das Framework. Der Einstiegspunkt ist frameworks/av/media/libstagefright/MediaExtractor.cpp .
  3. Deklarieren Sie das HDR-Decoderprofil und den Level-OMX-Typ. Beispiel: OMX_VIDEO_DOLBYPROFILETYPE und OMX_VIDEO_DOLBYLEVELTYP .
  4. Implementieren Sie die Unterstützung für den Index: 'OMX.google.android.index.describeColorAspects '
  5. Geben Sie die dynamischen HDR-Metadaten in jedem Frame an die App und die Oberfläche weiter. Normalerweise müssen diese Informationen in den von Dolby definierten dekodierten Frame gepackt werden, da der HDMI-Standard keine Möglichkeit bietet, diese Informationen an das Display weiterzugeben.

VP9-Decoder-Pipeline

Abbildung 3. VP9-PQ-Pipeline

VP9-Bitströme werden auf eine vom WebM-Team definierte Weise in WebM-Container verpackt. Anwendungen müssen einen WebM-Extraktor verwenden, um HDR-Metadaten aus dem Bitstream zu extrahieren, bevor Frames an den Decoder gesendet werden.

  • WebM-Extraktor:
  • VP9-Decoder:
    • Der Decoder empfängt Profile2-Bitstreams und dekodiert 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 in der Lage sein, die statischen/dynamischen HDR-Metadaten an die Anzeige weiterzugeben.

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. Verbreiten Sie statische HDR-Metadaten