HDR-Videowiedergabe

HDR-Videos (High Dynamic Range) sind die nächste Stufe bei der hochqualitativen Videodekodierung und bieten eine unvergleichliche Wiedergabequalität. Dazu wird der dynamische Bereich der Leuchtdichtekomponente deutlich erhöht (von den aktuellen 100 cd/m2 auf Tausende von cd/m2) und ein viel größerer Farbraum (BT 2020) verwendet. Dies ist jetzt ein zentrales Element der Entwicklung von 4K UHD im Fernsehbereich.

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+ mit dynamischen Metadaten wird dies mit dem Schlüssel KEY_HDR10_PLUS_INFO im Ausgabeformat angegeben 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. Das bedeutet, dass Codec-Typen und Anzeigemodi definiert und angegeben werden müssen, wie HDR-Daten an MediaCodec übergeben und HDR-Decodern zur Verfügung gestellt werden müssen.

Dieses Dokument soll Anwendungsentwicklern 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.

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 mithilfe von opaken Videopuffern unterstützen. Mit anderen Worten:

  • Es gibt keine standardmäßige Android-API, mit der du prüfen kannst, ob die HDR-Wiedergabe mit nicht getunnelten Decodern 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
    Dolby Vision-Unterstützung.
  • int HDR_TYPE_HDR10
    HDR10-/PQ-Unterstützung.
  • int HDR_TYPE_HDR10_PLUS
    HDR10+-Unterstützung.
  • 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/m2 für dieses Display zurück.
  • float getDesiredMaxLuminance()
    Gibt die gewünschten Daten zur maximalen Leuchtkraft des Inhalts in cd/m2 für dieses Display zurück.
  • float getDesiredMinLuminance()
    Gibt die gewünschten Daten zur minimalen Leuchtkraft des Inhalts in cd/cd/m2 für dieses Display zurück.
  • int[] getSupportedHdrTypes()
    Die unterstützten HDR-Typen dieses Displays (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 einen einzelnen Puffer pro Frame zusammengefügt werden. Dies geschieht automatisch durch den Dolby Vision-kompatiblen MediaExtractor.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel-Profilkonstanten:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG und PQ

Konstanten für MediaCodecInfo.CodecProfileLevel-Profile:

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 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, zu ermitteln, ob für einen Titel (einer Datei) HDR-Unterstützung erforderlich ist. Anwendungen können die codecspezifischen Daten analysieren, um zu ermitteln, 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 (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 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 Extractor, aber keinen entsprechenden HDR-fähigen Decoder.

Wiedergabe

Nachdem die Unterstützung für die 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 ersichtlich, ob für eine bestimmte Mediendatei/einen bestimmten Medientrack ein HDR-fähiger Decoder erforderlich ist. Die Anwendung muss diese Informationen im Voraus haben oder sie durch Parsen des codecspezifischen Datenabschnitts des MediaFormats abrufen können.
  • Bei CodecCapabilities.isFormatSupported wird nicht berücksichtigt, ob die Funktion „Tunneled Decoder“ für die Unterstützung eines solchen Profils erforderlich ist.

Unterstützung für 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 an der Plattform (App-/native Schicht), 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. Der Prozess verläuft jedoch in der Regel so:

  1. Bestimme einen linearen Farbraum/ein lineares Volumen, das alle Ebenen enthält, die zusammengesetzt werden sollen, basierend auf der Farbe, dem Mastering und den potenziellen dynamischen Metadaten der Ebenen.
    Bei der direkten Komposition auf einem Display kann dies der lineare Farbraum sein, der dem Farbvolumen des Displays entspricht.
  2. Konvertieren Sie alle Ebenen in den gemeinsamen Farbraum.
  3. Führen Sie die Überblendung aus.
  4. Wenn die Anzeige über HDMI erfolgt:
    1. Bestimme Farbe, Mastering und mögliche dynamische Metadaten für die zusammengeführte Szene.
    2. Wandeln Sie die resultierende gemischte Szene in den abgeleiteten Farbraum/das abgeleitete Volumen um.
  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.

Display Discovery

Die Erkennung von HDR-Displays wird nur über HWC2 unterstützt. Geräteimplementierer müssen den HWC2-Adapter, der mit Android 7.0 veröffentlicht wurde, 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 bereit, um statische HDR-Daten an das Framework und die Anwendung weiterzuleiten.

HDMI

  • Ein verbundenes HDMI-Display gibt seine HDR-Funktion über HDMI-EDID an, wie in Abschnitt 4.2 der CTA-861.3 definiert.
  • Es muss die folgende EOTF-Zuordnung verwendet werden:
    • ET_0 – Traditionelles Gamma – SDR-Leuchtdichtebereich: keinem HDR-Typ zugeordnet
    • ET_1 Traditional gamma – HDR Luminance Range: nicht einem HDR-Typ zugeordnet
    • ET_2 SMPTE ST 2084 – dem HDR-Typ HDR10 zugeordnet
  • Die Signalisierung der Unterstützung von Dolby Vision oder HLG über HDMI erfolgt gemäß den entsprechenden Richtlinien.
  • Die HWC2 API verwendet Float-Werte für die gewünschte Leuchtkraft. Daher müssen die 8‑Bit-EDID-Werte entsprechend umgewandelt werden.

Decoder

Plattformen müssen HDR-fähige getunnelte Decoder hinzufügen und ihre HDR-Unterstützung bewerben. 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 der Farbbeschreibung (OMX.google.android.index.describeColorAspects) und deren Weitergabe an die Anzeige-/Hardwarezusammensetzung.
  • 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-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. Für diese Dekoder gilt Folgendes:

  • 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. Beispielsweise Daten, die das Dolby Vision-Profil/-Level und möglicherweise die codecspezifischen Daten für die internen Decoder enthalten.
  • Unterstützung für den adaptiven Wechsel zwischen Dolby Vision-Profilen/-Stufen gemäß den Anforderungen von Dolby.

Bei der Konfiguration des Dekoders wird das tatsächliche Dolby-Profil nicht an den Codec gesendet. Dies geschieht erst über codecspezifische Daten, nachdem der Dekoder gestartet wurde. 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 und adaptive Umschalten zwischen diesen unterstützen.

Wenn eine Plattform zusätzlich zur allgemeinen HDR-Decoderunterstützung einen Dolby Vision-fähigen Decoder bereitstellt, muss Folgendes erfüllt sein:

  • Stelle einen Dolby Vision-kompatiblen Extractor bereit, auch wenn er die HDR-Wiedergabe nicht unterstützt.
  • Sie müssen einen Decoder bereitstellen, 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 (zusätzlich zur allgemeinen Unterstützung von HDR-Decodern)

  • Unterstützung des MIME-Typs „video/hevc“
  • 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. Solche Decoder müssen (zusätzlich zur allgemeinen Unterstützung von HDR-Decodern)

  • Unterstützt den MIME-Typ „video/x-vnd.on2.vp9“.
  • Unterstützte VP9Profile2HDR-Streams angeben Für die Unterstützung des VP9Profile2HDR-Profils muss auch das VP9Profile2-Profil auf demselben Niveau unterstützt werden.

Abzugshauben

Unterstützung für Dolby Vision-Extractor

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. 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 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 einzelnen Puffer 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 Extractor muss für diesen Titel reguläre AVC-/HEVC-Zugriffseinheiten 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 anhand der Funktionen der Plattform entscheiden, welchen Track sie auswählt.
  • Das Dolby Vision-Profil/-Level muss im Track-Format 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-Extractor

Für die Unterstützung von HDR10 oder VP9 HLG sind keine zusätzlichen Anforderungen an den Extractor erforderlich. 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 sie über die normale MediaExtractor => MediaCodec-Pipeline an den VP9 PQ-Decoder und an das Display übergeben werden.

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

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

  • Unterstützung für Abfrage der Portdefinition für komprimierten Port
  • Unterstützung der Aufzählung von Profilen/Ebenen für DV-Decoder.
  • Unterstützung für die Freigabe des DV-Profils/-Ebenens für DV-HDR-Tracks.

Technologiespezifische Implementierungsdetails

HDR10-Decoderpipeline

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 vom Typ „video/HEVC“ wird extrahiert. Das Framework wählt einen HEVC-Videodecoder aus, der das Profil „Main10HDR10“ 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 ein HDR-Video decodiert wird. HDR-Informationen werden im Decoder-Ausgabeformat gebündelt, das später an die Oberfläche weitergegeben wird.

Anbieteraktionen

  1. Unterstütztes HDR-Decodierungsprofil und OMX-Ebenentyp angeben. 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. 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 als 1 bis 2 Tracks für jeden Dolby-Videotrack (-Gruppe) anzeigt:
      • 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 die BL abwärtskompatibel ist) Ein BL-Track enthält nur die Basisebene, die von einem regulären MediaCodec-Decoder decodiert werden kann, z. B. einem AVC/HEVC-Decoder. Der Extractor sollte für diesen Titel reguläre AVC-/HEVC-Zugriffseinheiten bereitstellen. Dieser BL-Track muss dieselbe eindeutige 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-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-Videodekoder decodiert.
  • DolbyDecoder:
    • Der DolbyDecoder empfängt 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 einem CSD-Frame verpackt werden, der von Dolby definiert wird. Es ist nur ein 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. Definiere die Verpackung von CSD für den abstrakten Dolby-Decoder.

Anbieteraktionen

  1. Implementiere einen Dolby-Extractor. Dies kann auch von Dolby erfolgen.
  2. DolbyExtractor in das Framework einbinden Der Einstiegspunkt ist frameworks/av/media/libstagefright/MediaExtractor.cpp.
  3. Deklariere das HDR-Dekodierprofil und den OMX-Typ der Ebene. 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. Normalerweise müssen diese Informationen in den decodierten Frame gemäß der Definition von Dolby verpackt werden, da der HDMI-Standard keine Möglichkeit bietet, diese an das Display weiterzuleiten.

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:
  • 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 weitergeben 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