Odtwarzanie filmów HDR

Filmy o wysokim zakresie dynamiki (HDR) to kolejny krok w dekodowaniu wysokiej jakości filmów, który zapewnia niezrównaną jakość odtwarzania scen. Osiąga to dzięki znacznemu zwiększeniu zakresu dynamicznego komponentu luminancji (z obecnych 100 cd/m² do tysięcy cd/m²) i użyciu znacznie szerszej przestrzeni kolorów (BT 2020). Jest to obecnie kluczowy element rozwoju technologii 4K UHD w przypadku telewizorów.

Android 10 obsługuje te filmy HDR:

• HDR10
• VP9
• HDR10+

Od Androida 9 i nowszych wersji interfejs MediaCodec zgłasza metadane HDR niezależnie od trybu tunelowania. W trybie bez tunelowania możesz uzyskać zdekodowane dane wraz z metadanymi statycznymi lub dynamicznymi. W przypadku HDR10 i VP9Profile2, które korzystają ze statycznych metadanych, są one raportowane w formacie wyjściowym z kluczem KEY_HDR_STATIC_INFO. W przypadku HDR10+ korzystającego z dynamicznych metadanych jest to zgłaszane za pomocą klucza KEY_HDR10_PLUS_INFO w formacie wyjściowym i może się zmieniać w przypadku każdej klatki wyjściowej. Więcej informacji znajdziesz w artykule Tunelowanie multimediów.

Od Androida 7.0 wstępna obsługa HDR obejmuje tworzenie odpowiednich stałych na potrzeby wykrywania i konfigurowania potoków wideo HDR. Oznacza to zdefiniowanie typów kodeków i trybów wyświetlania oraz określenie, w jaki sposób dane HDR mają być przekazywane do MediaCodec i dostarczane do dekoderów HDR.

Celem tego dokumentu jest pomoc deweloperom aplikacji w obsłudze odtwarzania strumieni HDR oraz pomoc producentom OEM i układów SOC w udostępnianiu funkcji HDR.

Obsługiwane technologie HDR

W Androidzie 7.0 i nowszym obsługiwane są te technologie HDR:

Technologia	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Kodek	AVC/HEVC	HEVC	VP9	VP9
Funkcja przenoszenia	ST-2084	ST-2084	HLG	ST-2084
Typ metadanych HDR	Dynamiczne	Statyczny	Brak	Statyczny

W Androidzie 7.0 zdefiniowano tylko odtwarzanie HDR w trybie tunelowania, ale urządzenia mogą dodawać obsługę odtwarzania HDR na SurfaceView za pomocą nieprzezroczystych buforów wideo. Krótko mówiąc:

• Nie ma standardowego interfejsu API Androida, który umożliwiałby sprawdzenie, czy odtwarzanie HDR jest obsługiwane przy użyciu dekoderów nietunelowanych.
• Dekodery wideo tunelowane, które reklamują możliwość odtwarzania w trybie HDR, muszą obsługiwać odtwarzanie w trybie HDR po podłączeniu do wyświetlaczy obsługujących ten tryb.
• Wersja AOSP Androida 7.0 nie obsługuje kompozycji GL treści HDR.

Discovery

Odtwarzanie w HDR wymaga dekodera obsługującego HDR i połączenia z wyświetlaczem obsługującym HDR. Opcjonalnie niektóre technologie wymagają specjalnego ekstraktora.

Wyświetlacz

Aplikacje powinny używać nowego interfejsu API Display.getHdrCapabilities do wysyłania zapytań o technologie HDR obsługiwane przez określony wyświetlacz. Są to w zasadzie informacje z bloku danych statycznych metadanych EDID zdefiniowanego w CTA-861.3:

• public Display.HdrCapabilities getHdrCapabilities()
  Zwraca możliwości HDR wyświetlacza.
• Display.HdrCapabilities
  Zawiera informacje o możliwościach wyświetlania obrazu HDR na danym ekranie. Na przykład jakie typy HDR obsługuje i szczegóły dotyczące pożądanych danych o luminancji.

Stałe:

• int HDR_TYPE_DOLBY_VISION
  Obsługa Dolby Vision.
• int HDR_TYPE_HDR10
  Obsługa HDR10 / PQ.
• int HDR_TYPE_HDR10_PLUS
  Obsługa HDR10+.
• int HDR_TYPE_HLG
  Obsługa logarytmicznej funkcji gamma.
• float INVALID_LUMINANCE
  Nieprawidłowa wartość luminancji.

Metody publiczne:

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

Dekoder

Aplikacje powinny używać istniejącego interfejsu API CodecCapabilities.profileLevels do weryfikowania obsługi nowych profili 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ć łączone w jeden bufor na klatkę przez aplikacje wideo. Jest to wykonywane automatycznie przez MediaExtractor obsługujący Dolby Vision.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel stałe profilu:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG i PQ

MediaCodecInfo.CodecProfileLevel stałe profilu:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Jeśli platforma obsługuje dekoder HDR, musi też obsługiwać ekstraktor HDR.

Tylko dekodery tunelowane gwarantują odtwarzanie treści HDR. Odtwarzanie przez dekodery nietunelowe może spowodować utratę informacji HDR i spłaszczenie treści do zakresu kolorów SDR.

Ekstraktor

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

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

Platforma nie obsługuje wykrywania, czy ścieżka (pliku) wymaga obsługi HDR. Aplikacje mogą analizować dane specyficzne dla kodeka, aby określić, czy ścieżka wymaga określonego profilu HDR.

Podsumowanie

Wymagania dotyczące komponentów w przypadku poszczególnych technologii HDR są podane w tabeli poniżej:

Technologia	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Obsługiwany typ HDR (wyświetlacz)	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:

• Strumienie bitów Dolby Vision są pakowane w kontener MP4 w sposób określony przez Dolby. Aplikacje mogą implementować własne ekstraktory obsługujące Dolby, o ile pakują jednostki dostępu z odpowiednich warstw w jedną jednostkę dostępu dla dekodera zgodnie z definicją Dolby.
• Platforma może obsługiwać ekstraktor obsługujący HDR, ale nie dekoder obsługujący HDR.

Odtwarzanie

Gdy aplikacja potwierdzi obsługę odtwarzania w trybie HDR, może odtwarzać treści HDR w niemal taki sam sposób jak treści bez HDR, z tymi zastrzeżeniami:

• W przypadku Dolby Vision nie jest od razu wiadomo, czy dany plik multimedialny lub ścieżka wymaga dekodera obsługującego HDR. Aplikacja musi mieć te informacje z wyprzedzeniem lub być w stanie je uzyskać, analizując sekcję danych specyficznych dla kodeka w obiekcie MediaFormat.
• CodecCapabilities.isFormatSupported nie sprawdza, czy funkcja dekodera tunelowanego jest wymagana do obsługi takiego profilu.

Włącz obsługę platformy HDR

Aby włączyć obsługę platformy HDR na urządzeniu, dostawcy układów SoC i producenci OEM muszą wykonać dodatkowe czynności.

Zmiany na platformie Android 7.0 dotyczące HDR

Oto najważniejsze zmiany na platformie (warstwa aplikacji/natywna), o których muszą pamiętać producenci OEM i SOC.

Wyświetlacz

Składniki sprzętowe

Platformy obsługujące HDR muszą umożliwiać mieszanie treści HDR z treściami bez HDR. Dokładne charakterystyki mieszania i operacje nie są zdefiniowane w Androidzie w wersji 7.0, ale proces ten zwykle przebiega w ten sposób:

1. Określ liniową przestrzeń kolorów lub zakres, który zawiera wszystkie warstwy do połączenia, na podstawie koloru warstw, masteringu i potencjalnych dynamicznych metadanych.
   Jeśli kompozycja jest tworzona bezpośrednio na wyświetlaczu, może to być przestrzeń liniowa odpowiadająca zakresowi kolorów wyświetlacza.
2. Przekonwertuj wszystkie warstwy do wspólnej przestrzeni kolorów.
3. Przeprowadź mieszanie.
4. Jeśli wyświetlasz obraz przez HDMI:
   1. Określ kolor, mastering i potencjalne metadane dynamiczne dla sceny mieszanej.
   2. Przekształć powstałą scenę mieszaną w pochodną przestrzeń kolorów lub objętość.
5. Jeśli obraz jest wyświetlany bezpośrednio na ekranie, przekonwertuj wynikową scenę mieszaną na wymagane sygnały wyświetlania, aby ją odtworzyć.

Wyświetlanie wyników

Wykrywanie wyświetlacza HDR jest obsługiwane tylko w przypadku HWC2. Aby ta funkcja działała, producenci urządzeń muszą selektywnie włączać adapter HWC2, który jest udostępniany w Androidzie 7.0. Dlatego platformy muszą dodać obsługę HWC2 lub rozszerzyć strukturę AOSP, aby umożliwić przekazywanie tych informacji. HWC2 udostępnia nowy interfejs API do przekazywania statycznych danych HDR do platformy i aplikacji.

HDMI

• Podłączony wyświetlacz HDMI informuje o obsłudze HDR przez HDMI EDID zgodnie z sekcją 4.2 standardu CTA-861.3.
• Należy użyć tego mapowania EOTF:
  • ET_0 Tradycyjna gamma – zakres luminancji SDR: nie jest mapowany na żaden typ HDR
  • ET_1 Tradycyjna gamma – zakres luminancji HDR: nie jest zmapowany na żaden typ HDR
  • ET_2 SMPTE ST 2084 – mapowanie na typ HDR10
• Sygnalizacja obsługi Dolby Vision lub HLG przez HDMI odbywa się zgodnie z definicjami odpowiednich organizacji.
• Pamiętaj, że interfejs HWC2 API używa wartości jasności w formacie zmiennoprzecinkowym, więc 8-bitowe wartości EDID muszą zostać odpowiednio przetłumaczone.

Dekodery

Platformy muszą dodać dekodery tunelowane obsługujące HDR i informować o obsłudze HDR. Dekodery obsługujące HDR muszą zwykle:

• Obsługa dekodowania tunelowanego (FEATURE_TunneledPlayback).
• Obsługa statycznych metadanych HDR (OMX.google.android.index.describeHDRColorInfo) i ich propagacja do wyświetlacza lub kompozycji sprzętowej. W przypadku HLG do wyświetlacza należy przesłać odpowiednie metadane.
• Obsługa opisu koloru (OMX.google.android.index.describeColorAspects) i jego przekazywanie do wyświetlacza lub komponentów sprzętowych.
• Obsługuj metadane osadzone HDR zgodnie z odpowiednim standardem.

Obsługa dekodera Dolby Vision

Aby obsługiwać Dolby Vision, platformy muszą dodać dekoder HDR OMX obsługujący Dolby Vision. Ze względu na specyfikę Dolby Vision jest to zwykle dekoder opakowujący co najmniej 1 dekoder AVC lub HEVC, a także kompozytor. Takie dekodery muszą:

• Obsługa typu MIME „video/dolby-vision”.
• Reklamowanie obsługiwanych profili/poziomów Dolby Vision.
• Akceptuj jednostki dostępu zawierające podjednostki dostępu wszystkich warstw zdefiniowanych przez Dolby.
• akceptować dane specyficzne dla kodeka zdefiniowane przez Dolby; Na przykład dane zawierające profil/poziom Dolby Vision i prawdopodobnie dane specyficzne dla kodeka wewnętrznych dekoderów.
• Obsługa adaptacyjnego przełączania między profilami/poziomami Dolby Vision zgodnie z wymaganiami Dolby.

Podczas konfigurowania dekodera rzeczywisty profil Dolby nie jest przekazywany do kodeka. Odbywa się to tylko za pomocą danych specyficznych dla kodeka po uruchomieniu dekodera. Platforma może obsługiwać wiele dekoderów Dolby Vision: jeden dla profili AVC, a drugi dla profili HEVC, aby móc zainicjować bazowe kodeki podczas konfiguracji. Jeśli jeden dekoder Dolby Vision obsługuje oba typy profili, musi też obsługiwać dynamiczne przełączanie między nimi w sposób adaptacyjny.

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

• Zapewnij ekstraktor obsługujący Dolby Vision, nawet jeśli nie obsługuje odtwarzania HDR.
• Zapewnij dekoder, który obsługuje profil wizyjny zdefiniowany przez Dolby.

Obsługa dekodera HDR10

Aby obsługiwać HDR10, platformy muszą dodać dekoder OMX obsługujący HDR10. Jest to zwykle dekoder HEVC z tunelowaniem, który obsługuje też analizowanie i obsługę metadanych związanych z HDMI. Taki dekoder (oprócz ogólnej obsługi dekodera HDR) musi:

• Obsługa typu MIME „video/hevc”.
• Reklamuj obsługiwany format HEVCMain10HDR10. Obsługa profilu HEVCMain10HRD10 wymaga też obsługi profilu HEVCMain10, a ta z kolei wymaga obsługi profilu HEVCMain na tych samych poziomach.
• Obsługa analizowania bloków SEI metadanych masteringu, a także innych informacji związanych z HDR zawartych w SPS.

Obsługa dekodera VP9

Aby obsługiwać VP9 HDR, platformy muszą dodać dekoder HDR OMX obsługujący VP9 Profile2. Jest to zwykle dekoder VP9 z tunelowaniem, który obsługuje też metadane związane z HDMI. Takie dekodery (oprócz ogólnej obsługi dekodera HDR) muszą:

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

Moduły wyodrębniania

Obsługa ekstraktora Dolby Vision

Platformy obsługujące dekodery Dolby Vision muszą dodać obsługę ekstraktora Dolby (zwanego Dolby Extractor) dla treści wideo Dolby.

• Zwykły ekstraktor MP4 może wyodrębnić z pliku tylko warstwę podstawową, ale nie warstwy ulepszeń ani metadanych. Dlatego do wyodrębnienia danych z pliku potrzebny jest specjalny ekstraktor Dolby.
• Ekstraktor Dolby musi udostępniać 1–2 ścieżki dla każdej ścieżki wideo Dolby (grupy):
  • Ścieżka Dolby Vision HDR o typie „video/dolby-vision” dla połączonego strumienia Dolby z 2/3 warstwami. Format jednostki dostępu ścieżki HDR, który określa sposób pakowania jednostek dostępu z warstw podstawowej, ulepszonej i metadanych w pojedynczy bufor do dekodowania w pojedynczą ramkę HDR, jest określany przez Dolby.
  • Jeśli ścieżka wideo Dolby Vision zawiera oddzielną (kompatybilną wstecznie) warstwę podstawową (BL), ekstraktor musi ją również udostępnić jako oddzielną ścieżkę „video/avc” lub „video/hevc”. Ekstraktor musi zapewniać regularny dostęp do jednostek AVC/HEVC w przypadku tej ścieżki.
  • Ścieżka BL musi mieć ten sam identyfikator unikalny ścieżki („track-ID”) co ścieżka HDR, aby aplikacja wiedziała, że są to 2 wersje kodowania tego samego filmu.
  • Aplikacja może wybrać ścieżkę na podstawie możliwości platformy.
• Profil/poziom Dolby Vision musi być widoczny w formacie ścieżki ścieżki HDR.
• Jeśli platforma udostępnia dekoder obsługujący Dolby Vision, musi też udostępniać ekstraktor obsługujący Dolby Vision, nawet jeśli nie obsługuje odtwarzania HDR.

Obsługa ekstraktora HDR10 i VP9 HDR

Nie ma dodatkowych wymagań dotyczących ekstraktora w przypadku obsługi HDR10 lub VP9 HLG. Platformy muszą rozszerzyć ekstraktor MP4, aby obsługiwał VP9 PQ w MP4. Statyczne metadane HDR muszą być propagowane w strumieniu bitów VP9 PQ, tak aby te metadane były przekazywane do dekodera VP9 PQ i na wyświetlacz za pomocą normalnego potoku MediaExtractor => MediaCodec.

Rozszerzenia Stagefright do obsługi Dolby Vision

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

• Obsługa zapytania o definicję portu w przypadku skompresowanego portu.
• Obsługa wyliczania profili/poziomów w dekoderze DV.
• Obsługa udostępniania profilu/poziomu DV w przypadku ścieżek DV HDR.

Szczegóły implementacji dotyczące poszczególnych technologii

Potok dekodera HDR10

Rysunek 1. Potok HDR10

Strumienie bitów HDR10 są pakowane w kontenery MP4. Aplikacje używają zwykłego ekstraktora MP4 do wyodrębniania danych klatek i wysyłania ich do dekodera.

• MPEG4 Extractor
  Strumienie bitów HDR10 są rozpoznawane przez MPEG4Extractor jako zwykły strumień HEVC, a ścieżka HDR o typie „video/HEVC” zostanie wyodrębniona. Framework wybiera dekoder wideo HEVC, który obsługuje profil Main10HDR10, aby zdekodować tę ścieżkę.
• Dekoder HEVC
  Informacje HDR znajdują się w SEI lub SPS. Dekoder HEVC najpierw odbiera klatki zawierające informacje HDR. Dekoder wyodrębnia następnie informacje HDR i powiadamia aplikację, że dekoduje film HDR. Informacje HDR są dołączane do formatu wyjściowego dekodera, który jest później przekazywany do powierzchni.

Działania dostawcy

1. Reklamuj obsługiwany profil dekodera HDR i poziom typu OMX. Przykład:
   OMX_VIDEO_HEVCProfileMain10HDR10 (i Main10)
2. Wdrożenie obsługi indeksu:OMX.google.android.index.describeHDRColorInfo„OMX.google.android.index.describeHDRColorInfo”
3. Wdrożenie obsługi indeksu:OMX.google.android.index.describeColorAspects„OMX.google.android.index.describeColorAspects”
4. Wdrożenie obsługi analizowania informacji SEI o metadanych masteringu.

Ścieżka dekodowania Dolby Vision

Rysunek 2. Proces Dolby Vision

Strumienie bitów Dolby są pakowane w kontenery MP4 zgodnie z definicją Dolby. Aplikacje mogą 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 Androida MediaExtractor/MediaCodec.

• DolbyExtractor:
  • Strumienie bitów 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 z 2/3 warstw. Format jednostki dostępu ścieżki HDR, który określa, jak pakować jednostki dostępu z warstw podstawowej, rozszerzonej i metadanych w jeden bufor, aby można było je dekodować w jedną klatkę HDR, zostanie określony przez Dolby.
    • (Opcjonalnie, tylko jeśli warstwa podstawowa jest wstecznie zgodna) Ścieżka BL zawiera tylko warstwę podstawową, która musi być dekodowana przez zwykły dekoder MediaCodec, np. dekoder AVC/HEVC. Ekstraktor powinien udostępniać regularne jednostki dostępu AVC/HEVC dla tej ścieżki. Ścieżka BL musi mieć ten sam identyfikator track-unique-ID („track-ID”) co ścieżka Dolby, aby aplikacja wiedziała, że są to 2 wersje tego samego filmu.
  • Aplikacja może wybrać ścieżkę na podstawie możliwości platformy.
  • Ścieżka HDR ma określony typ HDR, więc platforma wybierze dekoder wideo Dolby do jej dekodowania. Ścieżka BL będzie dekodowana przez zwykły dekoder wideo AVC/HEVC.
• DolbyDecoder:
  • Dekoder Dolby 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 można spakować w 1 ramkę CSD, która zostanie zdefiniowana przez Dolby. Wymagana jest pojedyncza ramka CSD.

Działania Dolby

1. Określ opakowanie jednostek dostępu dla różnych schematów kontenerów Dolby (np. BL+EL+MD) dla abstrakcyjnego dekodera Dolby (tj. format bufora oczekiwany przez dekoder HDR).
2. Określ sposób pakowania CSD dla abstrakcyjnego dekodera Dolby.

Działania dostawcy

1. Zaimplementuj ekstraktor Dolby. Może to też zrobić firma Dolby.
2. Zintegruj DolbyExtractor z platformą. Punkt wejścia to frameworks/av/media/libstagefright/MediaExtractor.cpp.
3. Deklarowanie profilu i poziomu dekodera HDR typu OMX. Przykład: OMX_VIDEO_DOLBYPROFILETYPE i OMX_VIDEO_DOLBYLEVELTYP.
4. Wdrożenie obsługi indeksu: 'OMX.google.android.index.describeColorAspects
5. Przekazywanie metadanych dynamicznego HDR do aplikacji i na platformę w każdej klatce. Zazwyczaj te informacje muszą być spakowane w dekodowanej ramce zgodnie z definicją Dolby, ponieważ standard HDMI nie umożliwia przekazywania ich do wyświetlacza.

Potok dekodera VP9

Rysunek 3. Potok VP9-PQ

Strumienie bitów VP9 są pakowane w kontenery WebM w sposób określony przez zespół WebM. Aplikacje muszą używać ekstraktora WebM, aby wyodrębniać metadane HDR ze strumienia bitów przed wysłaniem klatek do dekodera.

• Ekstraktor WebM:
  • WebM Extractor wyodrębnia metadane HDR i klatki z kontenera.
• Dekoder VP9:
  • Dekoder odbiera strumienie bitów Profile2 i dekoduje je jako zwykłe strumienie VP9.
  • Dekoder otrzymuje z platformy wszelkie statyczne metadane HDR.
  • Dekoder otrzymuje statyczne metadane za pomocą jednostek dostępu do strumienia bitów dla strumieni VP9 PQ.
  • Dekoder VP9 musi być w stanie przekazywać statyczne i dynamiczne metadane HDR do wyświetlacza.

Działania dostawcy

1. Wdrożenie obsługi indeksu:OMX.google.android.index.describeHDRColorInfo
2. Wdrożenie obsługi indeksu:OMX.google.android.index.describeColorAspects
3. Przekazywanie statycznych metadanych HDR