Odtwarzanie filmów w jakości HDR

Wideo High Dynamic Range (HDR) to kolejny krok naprzód w zakresie dekodowania wysokiej jakości filmów, który zapewnia niezrównaną jakość reprodukcji scen. Osiąga to poprzez znaczne zwiększenie zakresu dynamicznego komponentu luminancji (z obecnych 100 cd/m² do 1000 cd/m²) oraz zastosowanie znacznie szerszej przestrzeni barw (BT 2020). Obecnie jest to główny element ewolucji jakości 4K UHD w telewizji.

Android 10 obsługuje te filmy HDR.

• HDR10
• VP9
• HDR10+

Począwszy od Androida 9 lub nowszego MediaCodec przekazuje metadane HDR niezależnie od trybu tunelowania. W trybie bez tunelowania możesz otrzymywać dekodowane dane wraz ze statyczną lub dynamiczną metadanymi. W przypadku HDR10 i VP9Profile2, które używają statycznych metadanych, są one raportowane w formacie wyjściowym z kluczem KEY_HDR_STATIC_INFO. W przypadku HDR10+, który używa dynamicznych metadanych, klucz KEY_HDR10_PLUS_INFO w formacie wyjściowym może się zmieniać w przypadku każdego wyjściowego kadru. Więcej informacji znajdziesz w artykule Tunelowanie multimedialne.

Od Androida 7.0 początkowe wsparcie HDR obejmuje tworzenie odpowiednich stałych wartości na potrzeby wykrywania i konfigurowania ścieżek przesyłania danych wideo HDR. Oznacza to zdefiniowanie typów kodeków i trybów wyświetlania oraz określenie, jak dane HDR mają być przekazywane do MediaCodec i dostarczane dekodrom HDR.

Celem tego dokumentu jest pomoc deweloperom aplikacji w obsługiwaniu odtwarzania strumieni HDR oraz pomoc OEM-om i SOC w włączaniu funkcji HDR.

Obsługiwane technologie HDR

W Androidzie 7.0 i nowszych obsługiwane są wymienione poniżej technologie HDR.

Technologia	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Kodek	AVC/HEVC	HEVC	VP9	VP9
Funkcja transferu	ST-2084,	ST-2084	protokół HLG	ST-2084,
Typ metadanych HDR	Dynamiczne	Statyczny	Brak	Statyczny

W Androidzie 7.0 definiowane jest tylko odtwarzanie HDR w trybie tunelu, ale urządzenia mogą dodawać obsługę odtwarzania HDR w SurfaceView przy użyciu nieprzezroczystych buforów wideo. Krótko mówiąc:

• Nie ma standardowego interfejsu API Androida, który pozwalałby za pomocą dekoderów nietunelowych sprawdzić, czy odtwarzanie HDR jest obsługiwane.
• Dekodery wideo w tunelu, które reklamują obsługę odtwarzania HDR, muszą obsługiwać odtwarzanie HDR po podłączeniu do wyświetlaczy obsługujących HDR.
• Kompozycja GL treści HDR nie jest obsługiwana w wersji AOSP na urządzeniach z Androidem 7.0.

Discovery

Odtwarzanie w jakości HDR wymaga dekodera i połączenia z wyświetlaczem obsługującym ten format. Opcjonalnie niektóre technologie wymagają użycia określonego ekstraktora.

Wyświetlacz

Aplikacje muszą używać nowego interfejsu API Display.getHdrCapabilitiesdo wysyłania zapytań o technologie HDR obsługiwane przez określony wyświetlacz. Są to w podstawie informacje w bloku danych metadanych EDID, zdefiniowane w CTA-861.3:

• public Display.HdrCapabilities getHdrCapabilities()
  Zwraca możliwości HDR wyświetlacza.
• Display.HdrCapabilities
  Określa funkcje HDR na danym wyświetlaczu. Na przykład obsługiwane typy HDR i szczegółowe dane dotyczące luminancji.

Stałe:

• int HDR_TYPE_DOLBY_VISION
  Obsługa usługi Dolby Vision.
• int HDR_TYPE_HDR10
  Obsługa HDR10/PQ.
• int HDR_TYPE_HDR10_PLUS
  Obsługa HDR10+.
• int HDR_TYPE_HLG
  Obsługa hybrydowej krzywej Log-Gamma.
• float INVALID_LUMINANCE
  Nieprawidłowa wartość luminancji.

Metody publiczne:

• float getDesiredMaxAverageLuminance()
  Zwraca dane dotyczące maksymalnej średniej luminacji klatki treści w cd/cd/m² dla tego wyświetlacza.
• float getDesiredMaxLuminance()
  Zwraca odpowiednie dane o maksymalnej luminancji treści w formacie cd/cd/m² dla tego wyświetlacza.
• float getDesiredMinLuminance()
  Zwraca odpowiednie dane dotyczące minimalnej luminancji treści w formacie cd/cd/m² dla tego wyświetlacza.
• int[] getSupportedHdrTypes()
  Pobiera obsługiwane typy HDR wyświetlacza (patrz stałe). Zwraca pustą tablicę, jeśli wyświetlacz nie obsługuje HDR.

Dekoder

Aplikacje będą używać obecnego interfejsu API CodecCapabilities.profileLevels do weryfikowania obsługi nowych profili z obsługą HDR:

Dolby Vision

MediaFormat stała mime:

String MIMETYPE_VIDEO_DOLBY_VISION

MediaCodecInfo.CodecProfileLevel stałe profilu:

int DolbyVisionProfileDvavPen
int DolbyVisionProfileDvavPer
int DolbyVisionProfileDvheDen
int DolbyVisionProfileDvheDer
int DolbyVisionProfileDvheDtb
int DolbyVisionProfileDvheDth
int DolbyVisionProfileDvheDtr
int DolbyVisionProfileDvheStn

Warstwy wideo i metadane Dolby Vision muszą być umieszczone w jednym buforze na klatki przez aplikacje wideo. Jest to wykonywane automatycznie przez program MediaExtractor obsługujący Dolby Vision.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel stałe profilu:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG i PQ

MediaCodecInfo.CodecProfileLevel profilu:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Jeśli platforma obsługuje dekoder HDR, powinien on również obsługiwać wyodrębnianie z obsługą HDR.

Gwarantujemy, że tylko dekodery tunelowe będą odtwarzać treści HDR. Odtwarzanie przez dekodery bez tunelowania może spowodować utratę informacji HDR i spłaszczenie treści do rozmiaru SDR.

Ekstraktor

W Androidzie 7.0 obsługiwane są te kontenery w przypadku różnych technologii HDR:

Technologia	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Kontener	MP4	MP4	WebM	WebM

Platforma nie obsługuje wykrywania, czy ścieżka (plik) wymaga obsługi HDR. Aplikacje mogą analizować dane powiązane z kodkiem, by określić, czy ścieżka wymaga konkretnego profilu HDR.

Podsumowanie

Wymagania dotyczące komponentów dla każdej technologii HDR podano w tej tabeli:

Technologia	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Obsługiwany typ HDR (wyświetlanie)	HDR_TYPE_DOLBY_VISION	HDR_TYPE_HDR10	HDR_TYPE_HLG	HDR_TYPE_HDR10
Kontener (ekstraktor)	MP4	MP4	WebM	WebM
Dekoder	MIMETYPE_VIDEO_DOLBY_VISION	MIMETYPE_VIDEO_HEVC	MIMETYPE_VIDEO_VP9	MIMETYPE_VIDEO_VP9
Profil (dekoder)	Jeden z profili Dolby	HEVCProfileMain10HDR10	VP9Profile2HDR lub VP9Profile3HDR	VP9Profile2HDR lub VP9Profile3HDR

Uwagi:

• Strumieni bitowe Dolby-Vision są spakowane do kontenera MP4 zgodnie z definicją firmy Dolby. W aplikacjach mogą być wdrażane własne moduły wyodrębniania obsługujące Dolby, o ile jednostki dostępu z odpowiednich warstw sparują w jedną jednostkę dostępu dla dekodera zgodnie z definicją Dolby.
• Platforma może obsługiwać wyodrębnianie zgodne z HDR, ale nie odpowiedni dekoder obsługujący HDR.

Odtwarzanie

Po sprawdzeniu, czy aplikacja obsługuje odtwarzanie w technologii HDR, może ona odtwarzać treści HDR niemal tak samo jak w innych formatach, ale z następującymi zastrzeżeniami:

• W przypadku technologii Dolby Vision nie można od razu sprawdzić, czy konkretny plik lub ścieżka multimedialna wymagają dekodera obsługującego HDR. Aplikacja musi udostępnić te informacje z wyprzedzeniem lub mieć możliwość ich uzyskania przez przeanalizowanie sekcji danych konkretnego kodeka w MediaFormat.
• CodecCapabilities.isFormatSupported nie rozpatruje, czy do obsługi takiego profilu wymagana jest funkcja dekodera tunelowego.

Włącz obsługę platformy HDR

Dostawcy SoC i OEM muszą wykonać dodatkowe czynności, aby włączyć obsługę platformy HDR na urządzeniach.

Zmiany dotyczące platform w Androidzie 7.0 na potrzeby HDR

Oto najważniejsze zmiany w platformie (aplikacji/warstwie natywnej), o których powinni wiedzieć OEM-owie i SOC-owie.

Wyświetlacz

Kompozycja sprzętowa

Platformy obsługujące technologię HDR muszą obsługiwać łączenie treści HDR z materiałami w formacie innym niż HDR. Dokładne cechy i operacje mieszania nie są zdefiniowane przez Androida w wersji 7.0, ale proces przebiega zwykle w taki sposób:

1. Określ liniową przestrzeń/objętość kolorów zawierającą wszystkie warstwy do skomponowania na podstawie koloru warstw, masteringu i potencjalnych metadanych dynamicznych.
   Jeśli kompozytowanie odbywa się bezpośrednio na wyświetlaczu, może to być przestrzeń liniowa, która pasuje do objętości kolorów wyświetlacza.
2. Konwertuj wszystkie warstwy do wspólnej przestrzeni barw.
3. Przeprowadź mieszanie.
4. Jeśli wyświetlasz obraz przez HDMI:
   1. Ustal kolor, mastering i potencjalne dynamiczne metadane wmieszanej sceny.
   2. Przekształć wynikową zmiksowaną scenę w wyprowadzoną przestrzeń kolorów lub objętość.
5. W przypadku wyświetlania obrazu bezpośrednio na wyświetlaczu przekonwertuj powstałą mieszaną scenę na wymagane sygnały displayowe, aby ją utworzyć.

Wyświetlanie reklam displayowych

Wykrywanie wyświetlacza HDR jest obsługiwane tylko przez HWC2. Aby ta funkcja działała, twórcy implementujący urządzenia muszą wybiórczo włączać adapter HWC2, który jest dostępny z Androidem 7.0. Dlatego platformy muszą dodać obsługę HWC2 lub rozszerzyć framework AOSP, aby umożliwić podanie tych informacji. HWC2 udostępnia nowy interfejs API do propagowania danych statycznych HDR do frameworku i aplikacji.

HDMI

• Podłączony wyświetlacz HDMI reklamuje swoją obsługę HDR za pomocą HDMI EDID zgodnie z definicją w sekcji 4.2 normy CTA-861.3.
• Należy użyć tego mapowania EOTF:
  • ET_0 Gamma tradycyjna – zakres jasności SDR: nie zmapowany do żadnego typu HDR
  • ET_1 Tradycyjna gamma – zakres luminancji HDR: niezmapowany na żaden typ HDR
  • ET_2 SMPTE ST 2084 – mapowane na typ HDR HDR10
• Sygnalizacja obsługi Dolby Vision lub HLG przez HDMI jest przeprowadzana w sposób określony przez odpowiednie organy.
• Pamiętaj, że interfejs HWC2 API używa wartości luminancji docelowej w postaci liczb zmiennoprzecinkowych, więc wartości 8-bitowych wartości EDID muszą zostać przekształcone w odpowiednim formacie.

Dekodery

Platformy muszą dodać dekodery tunelowe obsługujące HDR i reklamować obsługę HDR. Dekodery obsługujące HDR muszą spełniać następujące wymagania:

• Obsługa dekodowania tunelowanego (FEATURE_TunneledPlayback).
• Obsługuj statyczne metadane HDR (OMX.google.android.index.describeHDRColorInfo) i ich propagację do kompozycji wyświetlacza/sprzętu. W przypadku HLG do wyświetlacza trzeba przesłać odpowiednie metadane.
• Obsługuj opis kolorów (OMX.google.android.index.describeColorAspects) i jego propagację do kompozycji wyświetlacza/sprzętu.
• Obsługuj osadzone metadane HDR zgodnie z definicją danego standardu.

Obsługa dekodera Dolby Vision

Aby obsługiwać Dolby Vision, platformy muszą dodać dekoder HDR OMX obsługujący Dolby Vision. Biorąc pod uwagę specyfikę Dolby Vision, jest to zwykle dekoder typu wrapper z co najmniej jednym dekoderem AVC lub HEVC i kompozytorem. Takie dekodery muszą:

• Obsługuj typ MIME „video/dolby-vision”.
• Reklamuj obsługiwane profile/poziomy Dolby Vision.
• Akceptowanie jednostek dostępu zawierających podjednostki dostępu wszystkich warstw zdefiniowane przez Dolby.
• akceptować dane specyficzne dla kodeka zdefiniowane przez Dolby. Na przykład dane zawierające profil lub poziom Dolby Vision oraz ewentualnie dane dotyczące kodeków dla wewnętrznych dekoderów.
• Obsługa adaptacyjnego przełączania między profilami/poziomami Dolby Vision zgodnie z wymaganiami Dolby.

Podczas konfigurowania dekodera nie przekazuje się do kodeka rzeczywistego profilu Dolby. Dzieje się to tylko za pomocą danych specyficznych dla kodeka po uruchomieniu dekodera. Platforma może obsługiwać kilka dekoderów Dolby Vision: jeden na potrzeby profili AVC i drugi dla profili HEVC, które umożliwiają inicjowanie bazowych kodeków podczas konfiguracji. Jeśli pojedynczy dekoder Dolby Vision obsługuje oba typy profili, musi też obsługiwać dynamiczne przełączanie się między nimi w sposób adaptacyjny.

Jeśli platforma zapewnia dekoder obsługujący Dolby Vision oprócz ogólnej obsługi dekodera HDR, musi:

• Podaj narzędzie do wyodrębniania danych obsługujące Dolby Vision, nawet jeśli nie obsługuje odtwarzania HDR.
• Udostępnij dekoder obsługujący profil Vision zdefiniowany przez Dolby.

Obsługa dekodera HDR10

Aby obsługiwać HDR10, platformy muszą dodać dekoder OMX obsługujący HDR10. Zwykle jest to tunelowany dekoder HEVC, który obsługuje również analizowanie i obsługę metadanych związanych z HDMI. Taki dekoder (oprócz ogólnego obsługiwania dekodera HDR) musi:

• Obsługuj typ MIME „video/hevc”.
• Reklamuj obsługiwany format HEVCMain10HDR10. Obsługa profilu HEVCMain10HRD10 wymaga również obsługi profilu HEVCMain10, który wymaga obsługi profilu HEVCMain na tych samych poziomach.
• Obsługa analizowania bloków SEI metadanych masteringu oraz innych informacji związanych z HDR zawartych w SPS.

Obsługa dekodera VP9

Aby obsługiwać HDR VP9, platformy muszą dodać dekoder HDR OMX obsługujący VP9 Profile 2. Zwykle jest to tunelowany dekoder VP9, który obsługuje również obsługę metadanych związanych z HDMI. Takie dekodery (oprócz ogólnego obsługiwania dekodera HDR) muszą:

• Obsługuj typ MIME „video/x-vnd.on2.vp9”.
• Zaproponuj obsługiwany format VP9Profile2HDR. Obsługa profilu VP9Profile2HDR wymaga też obsługi profilu VP9Profile2 na tym samym poziomie.

Wyciągarki

Obsługa wyodrębniania Dolby Vision

Platformy, które obsługują dekodery Dolby Vision, muszą dodać ekstraktor Dolby (nazywany Dolby Extractor) na potrzeby treści Dolby Video.

• Zwykły ekstraktor MP4 może tylko wyodrębnić warstwę podstawową z pliku, ale nie warstwy ulepszeń ani warstw metadanych. Aby wyodrębnić dane z pliku, potrzebny jest specjalny ekstraktor Dolby.
• Ekstraktor Dolby musi udostępniać od 1 do 2 ścieżek dla każdej ścieżki wideo Dolby (grupa):
  • Ścieżka Dolby Vision HDR typu „video/dolby-vision” dla połączonego strumienia Dolby z 2/3 warstwami. Format jednostki dostępu dla ścieżki HDR, który określa sposób pakowania jednostek dostępu z warstw podstawowych, ulepszeń i metadanych w pojedynczy bufor do zdekodowania w pojedynczą klatkę HDR, zostanie zdefiniowana przez Dolby.
  • Jeśli ścieżka wideo Dolby Vision zawiera oddzielną warstwę podstawową (BL) zgodną wstecz, ekstraktor musi również udostępnić ją jako oddzielną ścieżkę „video/avc” lub „video/hevc”. Ekstraktor musi zapewnić dla tej ścieżki zwykłe jednostki dostępu AVC/HEVC.
  • Ścieżka BL musi mieć ten sam identyfikator track-Unique-ID („track-ID”) co ścieżka HDR, tak by aplikacja rozumieła, że są to dwa różne kodowanie tego samego filmu.
  • Aplikacja może decydować o wyborze ścieżki na podstawie możliwości platformy.
• Profil/poziom Dolby Vision musi być widoczny w formacie ścieżki HDR.
• Jeśli platforma udostępnia dekoder obsługujący Dolby Vision, musi też udostępnić ekstraktor obsługujący Dolby Vision, nawet jeśli nie obsługuje odtwarzania HDR.

Obsługa ekstraktora HDR10 i VP9 HDR

Nie ma żadnych dodatkowych wymagań dotyczących wyodrębniania danych w przypadku technologii HDR10 lub VP9 HLG. Platformy muszą rozszerzyć ekstraktor MP4, aby obsługiwać VP9 PQ w formacie MP4. Metadane statyczne HDR muszą być propagowane w strumieniu bitów VP9 PQ, tak aby były przekazywane dekoderowi VP9 PQ i wyświetlaczowi za pomocą zwykłego kanału MediaExtractor => MediaCodec.

Rozszerzenia Stagefright do obsługi Dolby Vision

Platformy muszą dodać obsługę formatu Dolby Vision do Stagefright:

• Obsługa zapytania dotyczącego definicji portu w przypadku skompresowanego portu.
• Wyliczenie profilu/poziomu dekodera DV.
• Obsługa wyświetlania profilu DV lub poziomu dla ścieżek DV HDR.

Szczegóły implementacji związane z konkretną technologią

Potok dekodera HDR10

Rysunek 1. potok HDR10

Strumienie bitowe HDR10 są spakowane w kontenerach MP4. Aplikacje korzystają ze zwykłego programu wyodrębniania MP4 do wyodrębniania danych klatek i wysyłania ich do dekodera.

• Extractor MPEG4
  Strumienie bitowe HDR10 są rozpoznawane przez MPEG4Extractor jako zwykłe strumienie HEVC, a ścieżka HDR o typie „video/HEVC” zostanie wyekstrahowana. Platforma wybiera dekoder wideo HEVC, który obsługuje profil Main10HDR10 do zdekodowania ścieżki.
• Dekoder HEVC
  Informacje HDR są zapisane w SEI lub SPS. Dekoder HEVC najpierw odbiera klatki z informacjami HDR. Dekoder wyodrębnia informacje HDR i powiadamia aplikację, że dekoduje film HDR. Informacje HDR są umieszczane w formacie wyjściowym dekodera, który jest później propagowany na powierzchnię.

Działania dostawcy

1. Reklamuj obsługiwane profile dekoderów HDR i poziom typu OMX. Przykład:
   OMX_VIDEO_HEVCProfileMain10HDR10 (i Main10)
2. Wdrożyć obsługę indeksu: 'OMX.google.android.index.describeHDRColorInfo'
3. Wdróż obsługę indeksu: „OMX.google.android.index.describeColorAspects”
4. Zaimplementować obsługę analizy SEI metadanych masteringu.

Dekoder Dolby Vision

Rysunek 2. Potok Dolby Vision

Strumienie bitowe Dolby są pakowane w kontenerach MP4 zgodnie z definicją Dolby. W aplikacjach można teoretycznie używać zwykłego ekstraktora MP4 do niezależnego wyodrębniania warstwy podstawowej, warstwy ulepszeń i warstwy metadanych, ale nie pasuje to do obecnego modelu Android MediaExtractor/MediaCodec.

• DolbyExtractor:
  • Strumienie bitowe Dolby są rozpoznawane przez DolbyExtractor, który udostępnia różne warstwy jako 1–2 ścieżki dla każdej ścieżki wideo Dolby (grupy):
    • Ścieżka HDR o typie „video/dolby-vision” dla połączonego strumienia Dolby o 2/3 warstw. Dolby określa format jednostki dostępu ścieżki HDR, który definiuje sposób pakowania jednostek dostępu z warstw podstawowych, warstw rozszerzeń i warstw metadanych do pojedynczego bufora, który ma zostać zdekodowany do pojedynczego kadru HDR.
    • (Opcjonalnie, tylko jeśli ścieżka BL jest zgodna wstecz) Ścieżka BL zawiera tylko warstwę podstawową, która musi być dekodowalna przez zwykły dekoder MediaCodec, na przykład dekoder AVC/HEVC. Ekstraktor powinien zapewniać dla tej ścieżki zwykłe jednostki dostępu AVC/HEVC. Ścieżka BL musi mieć ten sam identyfikator track-Unique-ID („track-ID”) co ścieżka Dolby, tak by aplikacja rozumieła, że są to dwa sposoby kodowania tego samego filmu.
  • Aplikacja może wybrać ścieżkę na podstawie możliwości platformy.
  • Ponieważ ścieżka HDR ma określony typ HDR, framework wybierze dekoder wideo Dolby do jej dekodowania. Ścieżka BL będzie dekodowana przez zwykły dekoder wideo AVC/HEVC.
• DolbyDecoder:
  • DolbyDecoder otrzymuje jednostki dostępu zawierające wymagane jednostki dostępu dla wszystkich warstw (EL+BL+MD lub BL+MD)
  • Informacje CSD (dane specyficzne dla kodeka, takie jak SPS+PPS+VPS) dla poszczególnych warstw mogą zostać spakowane w 1 ramkę CSD, która zostanie zdefiniowana przez Doolby. Musisz mieć jedną ramkę CSD.

Akcje Dolby

1. Zdefiniuj pakiet jednostek dostępu dla różnych schematów kontenerów Dolby (np. BL+EL+MD) dla abstrakcyjnego dekodera Dolby (czyli formatu bufora zgodnego z dekoderem HDR).
2. Określ pakowanie CSD dla abstrakcyjnego dekodera Dolby.

Działania dostawcy

1. Wdrożyć ekstraktor Dolby. Może to zrobić też Dolby.
2. Zintegruj DolbyExtractor z ramówką. Punkt wejścia to frameworks/av/media/libstagefright/MediaExtractor.cpp.
3. Zadeklaruj profil dekodera HDR i typ OMX poziomu. Przykład: OMX_VIDEO_DOLBYPROFILETYPE i OMX_VIDEO_DOLBYLEVELTYP.
4. Włącz obsługę indeksu: 'OMX.google.android.index.describeColorAspects'
5. Rozpowszechnij dynamiczne metadane HDR w aplikacji i wyświetlaj je w każdej klatce. Zazwyczaj te informacje muszą być spakowane w zdekodowaną ramkę zgodnie z definicją Dolby, ponieważ standard HDMI nie umożliwia przekazania ich na wyświetlacz.

Potok dekodera VP9

Rysunek 3. Potok VP9-PQ

Strumienie bitowe VP9 są spakowane w kontenerach WebM w sposób zdefiniowany przez zespół WebM. Przed wysłaniem ramek do dekodera aplikacje muszą korzystać z ekstraktora WebM do wyodrębniania metadanych HDR ze strumienia bitowego.

• WebM Extractor:
  • Narzędzie WebM Extractor wyodrębnia metadane HDR i klatki z kontenera.
• Dekoder VP9:
  • Dekoder odbiera strumienie bitowe Profile2 i dekoduje je jak zwykłe strumienie VP9.
  • Dekoder otrzymuje od frameworku wszystkie metadane HDR.
  • Dekoder odbiera metadane statyczne przez jednostki dostępu do strumieni bitowych dla strumieni VP9.
  • Dekoder VP9 musi mieć możliwość propagowania statycznych/dynamicznych metadanych HDR na wyświetlacz.

Działania dostawcy

1. Wdróż obsługę indeksu: OMX.google.android.index.describeHDRColorInfo
2. Wdrożyć obsługę indeksu:OMX.google.android.index.describeColorAspects
3. Propaguj statyczne metadane HDR