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/m2 auf 1.000 cd/m2) 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.
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, 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/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 minimalen Luminanzdaten des Inhalts in cd/cd/m2 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:
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 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:
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 (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 | HEVCProfilHaupt10HDR10 | 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 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:
- 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. - Konvertieren Sie alle Ebenen in den gemeinsamen Farbraum.
- Führen Sie die Überblendung aus.
- Bei Verwendung über HDMI:
- Bestimmen Sie die Farbe, das Mastering und potenzielle dynamische Metadaten für die kombinierte Szene.
- Konvertieren Sie das Ergebnis der zusammengeführten Szene in den abgeleiteten Farbraum bzw. das abgeleitete Volumen.
- 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
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
- Bewirb ein unterstütztes HDR-Decoderprofil und einen unterstützten OMX-Level-Typ. Beispiel:
OMX_VIDEO_HEVCProfileMain10HDR10
(undMain10
) - Unterstützung für den Index „
OMX.google.android.index.describeHDRColorInfo
“ implementieren - Unterstützung für den Index „
OMX.google.android.index.describeColorAspects
“ implementieren - Unterstützung für das SEI-Parsing von Mastering-Metadaten implementieren
Dolby Vision-Decoderpipeline
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.
- 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:
- 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
- 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).
- Definieren Sie die Paketerstellung für CSD für den abstrakten Dolby-Decoder.
Anbieteraktionen
- Implementieren Sie Dolby-Extraktor. Das kann auch Dolby übernehmen.
- DolbyExtractor in das Framework einbinden. Der Einstiegspunkt ist
frameworks/av/media/libstagefright/MediaExtractor.cpp
. - Deklariere das HDR-Decoderprofil und den OMX-Level-Typ. Beispiel:
OMX_VIDEO_DOLBYPROFILETYPE
undOMX_VIDEO_DOLBYLEVELTYP
. - Unterstützung für „index:
'OMX.google.android.index.describeColorAspects
“ implementieren - Ü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
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:
- 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
- Implementieren Sie die Unterstützung für den Index:
OMX.google.android.index.describeHDRColorInfo
- Implementieren Sie die Unterstützung für den Index:
OMX.google.android.index.describeColorAspects
- Statische HDR-Metadaten weitergeben