Wideo o wysokim zakresie dynamiki (HDR) to kolejny krok w dziedzinie dekodowania wideo wysokiej jakości, zapewniający niezrównaną jakość odtwarzania scen. Dzieje się tak poprzez znaczne zwiększenie zakresu dynamicznego składowej luminancji (z obecnych 100 cd/m 2 do 1000 cd/m 2 ) oraz wykorzystanie znacznie szerszej przestrzeni barw (BT 2020). Jest to obecnie centralny element ewolucji 4K UHD w przestrzeni telewizyjnej.
Android 10 obsługuje następujące filmy HDR.
- HDR10
- VP9
- HDR10+
Począwszy od Androida 9 i nowszych wersji, MediaCodec raportuje metadane HDR niezależnie od trybu tunelowanego. Możesz uzyskać zdekodowane dane wraz ze statycznymi/dynamicznymi metadanymi w trybie nietunelowanym. W przypadku HDR10 i VP9Profile2, które wykorzystują statyczne metadane, są one raportowane w formacie wyjściowym z kluczem KEY_HDR_STATIC_INFO
. W przypadku HDR10+, który wykorzystuje dynamiczne metadane, jest to zgłaszane za pomocą klucza KEY_HDR10_PLUS_INFO
w formacie wyjściowym i może się zmieniać dla każdej klatki wyjściowej. Aby uzyskać więcej informacji, zobacz Tunelowanie multimediów .
Od wersji Androida 7.0 początkowa 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 muszą być przekazywane do MediaCodec i dostarczane do dekoderów HDR.
Celem tego dokumentu jest pomoc twórcom aplikacji w obsłudze odtwarzania strumieniowego HDR oraz pomoc producentom OEM i SOC w włączeniu funkcji HDR.
Obsługiwane technologie HDR
Od wersji Androida 7.0 i nowszych obsługiwane są następujące technologie HDR.
Technologia | Dolby Vision | HDR10 | VP9-HLG | VP9-PQ |
---|---|---|---|---|
Kodek | AVC/HEVC | HEVC | VP9 | VP9 |
Funkcja przenoszenia | ST-2084 | ST-2084 | GWS | ST-2084 |
Typ metadanych HDR | Dynamiczny | Statyczny | Nic | Statyczny |
W systemie Android 7.0 zdefiniowano tylko odtwarzanie HDR w trybie tunelowym , ale urządzenia mogą dodać obsługę odtwarzania HDR na urządzeniach SurfaceView przy użyciu nieprzezroczystych buforów wideo. Innymi słowy:
- Nie ma standardowego interfejsu API systemu Android umożliwiającego sprawdzenie, czy odtwarzanie HDR jest obsługiwane przy użyciu dekoderów nietunelowanych.
- Tunelowane dekodery wideo reklamujące możliwość 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 Android 7.0.
Odkrycie
Odtwarzanie HDR wymaga dekodera obsługującego HDR i połączenia z wyświetlaczem obsługującym HDR. Opcjonalnie niektóre technologie wymagają określonego ekstraktora.
Wyświetlacz
Aplikacje będą używać nowego interfejsu API Display.getHdrCapabilities
do wysyłania zapytań o technologie HDR obsługiwane przez określony wyświetlacz. Zasadniczo są to informacje zawarte w bloku danych statycznych metadanych EDID zgodnie z definicją w CTA-861.3:
-
public Display.HdrCapabilities getHdrCapabilities()
Zwraca możliwości HDR wyświetlacza. -
Display.HdrCapabilities
Hermetyzuje możliwości HDR danego wyświetlacza. Na przykład obsługiwane typy HDR i szczegółowe informacje na temat żądanych danych dotyczących 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 hybrydowej log-gamma. -
float INVALID_LUMINANCE
Nieprawidłowa wartość luminancji.
Metody publiczne:
-
float getDesiredMaxAverageLuminance()
Zwraca żądane dane dotyczące maksymalnej średniej luminancji klatki w cd/cd/m 2 dla tego wyświetlacza. -
float getDesiredMaxLuminance()
Zwraca żądane dane dotyczące maksymalnej luminancji treści w cd/cd/m 2 dla tego wyświetlacza. -
float getDesiredMinLuminance()
Zwraca żądane dane dotyczące minimalnej luminancji treści w cd/cd/m 2 dla tego wyświetlacza. -
int[] getSupportedHdrTypes()
Pobiera obsługiwane typy HDR tego ekranu (zobacz stałe). Zwraca pustą tablicę, jeśli wyświetlacz nie obsługuje HDR.
Dekoder
Aplikacje będą korzystać z istniejącego interfejsu API CodecCapabilities.profileLevels
w celu sprawdzenia obsługi nowych profili obsługujących HDR:
Dolby Vision
Stała mime MediaFormat
:
String MIMETYPE_VIDEO_DOLBY_VISION
Stałe profilu MediaCodecInfo.CodecProfileLevel
:
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. Odbywa się to automatycznie przez MediaExtractor obsługujący Dolby-Vision.
HEVC HDR10
Stałe profilu MediaCodecInfo.CodecProfileLevel
:
int HEVCProfileMain10HDR10 int HEVCProfileMain10HDR10Plus
VP9 HLG i PQ
Stałe profilu MediaCodecInfo.CodecProfileLevel
:
int VP9Profile2HDR int VP9Profile2HDR10Plus int VP9Profile3HDR int VP9Profile3HDR10Plus
Jeśli platforma obsługuje dekoder obsługujący HDR, powinna również obsługiwać ekstraktor obsługujący HDR.
Tylko dekodery tunelowe gwarantują odtwarzanie treści HDR. Odtwarzanie przez dekodery nietunelowane może spowodować utratę informacji HDR i spłaszczenie treści do objętości kolorów SDR.
Ekstraktor
Następujące kontenery są obsługiwane dla różnych technologii HDR w systemie Android 7.0:
Technologia | Dolby Vision | HDR10 | VP9-HLG | VP9-PQ |
---|---|---|---|---|
Pojemnik | 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 utwór wymaga określonego profilu HDR.
Streszczenie
Wymagania dotyczące komponentów dla każdej technologii HDR przedstawiono w poniższej tabeli:
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 kontenerze MP4 w sposób zdefiniowany przez Dolby. Aplikacje mogą implementować własne ekstraktory obsługujące Dolby, o ile spakują 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 może obsługiwać odpowiadającego mu dekodera obsługującego HDR.
Odtwarzanie nagranego dźwięku
Gdy aplikacja potwierdzi obsługę odtwarzania w formacie HDR, może odtwarzać zawartość HDR niemal w taki sam sposób, w jaki odtwarza zawartość inną niż HDR, z następującymi zastrzeżeniami:
- W przypadku Dolby-Vision informacja o tym, czy określony plik/ścieżka multimedialna wymaga dekodera obsługującego HDR, nie jest od razu dostępna. Aplikacja musi posiadać te informacje z wyprzedzeniem lub mieć możliwość uzyskania tych informacji poprzez analizę sekcji danych specyficznych dla kodeków w formacie MediaFormat.
-
CodecCapabilities.isFormatSupported
nie uwzględnia, czy do obsługi takiego profilu wymagana jest funkcja dekodera tunelowego.
Włącz obsługę platformy HDR
Dostawcy SoC i producenci OEM muszą wykonać dodatkową pracę, aby umożliwić obsługę platformy HDR dla urządzenia.
Zmiany platformy w Androidzie 7.0 dla HDR
Oto kilka kluczowych zmian na platformie (warstwa aplikacji/natywna), o których muszą wiedzieć producenci OEM i SOC.
Wyświetlacz
Skład sprzętu
Platformy obsługujące HDR muszą obsługiwać łączenie treści HDR z treściami innymi niż HDR. Dokładne właściwości i operacje mieszania nie są zdefiniowane w systemie Android w wersji 7.0, ale proces zazwyczaj przebiega według następujących kroków:
- Określ liniową przestrzeń/objętość kolorów zawierającą wszystkie warstwy, które mają zostać złożone, w oparciu o kolor warstw, mastering i potencjalne dynamiczne metadane.
W przypadku komponowania bezpośrednio na wyświetlaczu może to być przestrzeń liniowa odpowiadająca głośności kolorów wyświetlacza. - Konwertuj wszystkie warstwy na wspólną przestrzeń kolorów.
- Wykonaj miksowanie.
- W przypadku wyświetlania przez HDMI:
- Określ kolor, mastering i potencjalne dynamiczne metadane dla mieszanej sceny.
- Konwertuj powstałą mieszaną scenę na pochodną przestrzeń/objętość kolorów.
- W przypadku wyświetlania bezpośrednio na wyświetlaczu przekonwertuj powstałą zmieszaną scenę na wymagane sygnały wyświetlacza, aby wytworzyć tę scenę.
Wyświetl odkrycie
Wykrywanie wyświetlacza HDR jest obsługiwane tylko przez HWC2. Aby ta funkcja działała, osoby wdrażające urządzenia muszą selektywnie włączyć adapter HWC2 wydany z systemem Android 7.0. Dlatego platformy muszą dodać obsługę HWC2 lub rozszerzyć platformę AOSP, aby umożliwić dostarczanie tych informacji. HWC2 udostępnia nowy interfejs API do propagowania danych statycznych HDR do platformy i aplikacji.
HDMI
- Podłączony wyświetlacz HDMI reklamuje swoją funkcję HDR poprzez HDMI EDID zgodnie z definicją w CTA-861.3, sekcja 4.2.
- Stosuje się następujące mapowanie EOTF:
- ET_0 Tradycyjna gamma – zakres luminancji SDR: niemapowany do żadnego typu HDR
- ET_1 Tradycyjna gamma – zakres luminancji HDR: niemapowany do żadnego typu HDR
- ET_2 SMPTE ST 2084 - odwzorowany na typ HDR HDR10
- Sygnalizacja obsługi Dolby Vision lub HLG przez HDMI odbywa się zgodnie z definicją odpowiednich organów.
- Należy zauważyć, że interfejs API HWC2 wykorzystuje żądane wartości luminancji typu float, więc 8-bitowe wartości EDID muszą zostać przetłumaczone w odpowiedni sposób.
Dekodery
Platformy muszą dodawać dekodery tunelowe obsługujące HDR i reklamować obsługę HDR. Ogólnie rzecz biorąc, dekodery obsługujące HDR muszą:
- Obsługa dekodowania tunelowego (
FEATURE_TunneledPlayback
). - Obsługa statycznych metadanych HDR (
OMX.google.android.index.describeHDRColorInfo
) i ich propagacja do składu wyświetlacza/sprzętu. W przypadku grupy HLG do wyświetlacza należy przesłać odpowiednie metadane. - Obsługa opisu kolorów (
OMX.google.android.index.describeColorAspects
) i jego propagacji do składu wyświetlacza/sprzętu. - Obsługuje osadzone metadane HDR zgodnie z definicją w odpowiedniej normie.
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 otaczający jeden lub więcej dekoderów AVC i/lub HEVC, a także kompozytor. Takie dekodery muszą:
- Obsługa typu MIME „video/dolby-vision”.
- Reklamuj obsługiwane profile/poziomy Dolby Vision.
- Akceptuj jednostki dostępu, które zawierają podjednostki dostępu wszystkich warstw zgodnie z definicją Dolby.
- Akceptuj dane specyficzne dla kodeka zdefiniowane przez Dolby. Na przykład dane zawierające profil/poziom Dolby Vision i ewentualnie dane specyficzne dla kodeka dla wewnętrznych dekoderów.
- Obsługa adaptacyjnego przełączania pomiędzy profilami/poziomami Dolby Vision zgodnie z wymaganiami Dolby.
Podczas konfigurowania dekodera rzeczywisty profil Dolby nie jest przekazywany do kodeka. Odbywa się to wyłącznie poprzez dane specyficzne 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 inicjować podstawowe kodeki w czasie konfiguracji. Jeśli pojedynczy dekoder Dolby Vision obsługuje oba typy profili, musi także obsługiwać dynamiczne przełączanie 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 ona:
- Zapewnij ekstraktor obsługujący Dolby-Vision, nawet jeśli nie obsługuje on odtwarzania HDR.
- Zapewnij dekoder obsługujący profil widzenia 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ólnej obsługi dekodera HDR) musi:
- Obsługa typu MIME „video/hevc”.
- Reklamuj obsługiwane HEVCMain10HDR10. Obsługa profilu HEVCMain10HRD10 wymaga również obsługi profilu HEVCMain10, co 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. Zwykle jest to tunelowany dekoder VP9, który obsługuje również 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 VP9Profile2HDR. Obsługa profilu VP9Profile2HDR wymaga również obsługi profilu VP9Profile2 na tym samym poziomie.
Ekstraktory
Obsługa ekstraktora Dolby Vision
Platformy obsługujące dekodery Dolby Vision muszą dodać obsługę ekstraktora Dolby (zwanego Dolby Extractor) dla treści Dolby Video.
- Zwykły ekstraktor MP4 może wyodrębnić tylko warstwę podstawową z pliku, ale nie warstwy ulepszeń ani warstwy metadanych. Dlatego do wyodrębnienia danych z pliku potrzebny jest specjalny ekstraktor Dolby.
- Ekstraktor Dolby musi odsłonić od 1 do 2 ścieżek dla każdej ścieżki wideo Dolby (grupy):
- Ścieżka Dolby Vision HDR z typem „video/dolby-vision” dla połączonego 2/3-warstwowego strumienia Dolby. Format jednostki dostępu ścieżki HDR, który określa sposób pakowania jednostek dostępu z warstw podstawowych/ulepszeń/metadanych w pojedynczy bufor w celu zdekodowania ich w pojedynczą ramkę HDR, ma zostać zdefiniowany przez Dolby.
- Jeśli ścieżka wideo Dolby Vision zawiera oddzielną (kompatybilną wstecz) warstwę podstawową (BL), ekstraktor musi ją również udostępnić jako oddzielną ścieżkę „video/avc” lub „video/hevc”. Ekstraktor musi zapewnić regularne jednostki dostępu AVC/HEVC dla tego toru.
- Ścieżka BL musi mieć ten sam unikalny identyfikator ścieżki („identyfikator ścieżki”) co ścieżka HDR, aby aplikacja zrozumiała, że są to dwa kodowania tego samego wideo.
- Aplikacja może zdecydować, który utwór wybrać w oparciu o możliwości platformy.
- Profil/poziom Dolby Vision musi być naświetlony w formacie ścieżki HDR.
- Jeśli platforma zapewnia dekoder obsługujący Dolby-Vision, musi także zapewniać 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 ekstraktorów obsługujących 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 metadane były przesyłane do dekodera VP9 PQ i do wyświetlacza poprzez normalny potok MediaExtractor => MediaCodec.
Rozszerzenia Stagefright obsługujące Dolby Vision
Platformy muszą dodać obsługę formatu Dolby Vision do Stagefright:
- Obsługa zapytań o definicję portu dla skompresowanego portu.
- Wyliczanie profili/poziomów wsparcia dla dekodera DV.
- Obsługa ujawniania profilu/poziomu DV dla ścieżek DV HDR.
Szczegóły implementacji specyficzne dla technologii
Rurociąg dekodera HDR10
Strumienie bitów HDR10 są pakowane w kontenery MP4. Aplikacje używają zwykłego ekstraktora MP4 do wyodrębniania danych ramki i wysyłania ich do dekodera.
- Ekstraktor MPEG4
Strumienie bitów HDR10 są rozpoznawane przez moduł MPEG4Extractor jako zwykły strumień HEVC, a ścieżka HDR typu „video/HEVC” zostanie wyodrębniona. Struktura wybiera dekoder wideo HEVC obsługujący profil Main10HDR10 w celu zdekodowania tej ścieżki. - Dekoder HEVC
Informacje HDR znajdują się w formacie SEI lub SPS. Dekoder HEVC najpierw odbiera ramki zawierające informacje HDR. Następnie dekoder wyodrębnia informacje HDR i powiadamia aplikację, że dekoduje wideo HDR. Informacje HDR są pakowane w format wyjściowy dekodera, który jest później propagowany na powierzchnię.
Działania dostawcy
- Reklamuj obsługiwany profil dekodera HDR i poziom typu OMX. Przykład:
OMX_VIDEO_HEVCProfileMain10HDR10
(iMain10
) - Zaimplementuj obsługę indeksu: '
OMX.google.android.index.describeHDRColorInfo
' - Zaimplementuj obsługę indeksu: „
OMX.google.android.index.describeColorAspects
” - Zaimplementuj obsługę analizowania metadanych masteringowych SEI.
Rurociąg dekodera Dolby Vision
Strumienie bitów Dolby są pakowane w kontenery MP4 zgodnie z definicją Dolby. Aplikacje mogłyby teoretycznie używać zwykłego ekstraktora MP4 do niezależnego wyodrębniania warstwy podstawowej, warstwy ulepszeń i warstwy metadanych; jednak nie pasuje to do bieżącego modelu Android MediaExtractor/MediaCodec.
- Ekstraktor Dolby:
- Strumienie bitów Dolby są rozpoznawane przez moduł DolbyExtractor, który udostępnia różne warstwy jako od 1 do 2 ścieżek dla każdej ścieżki wideo Dolby (grupy):
- Ścieżka HDR typu „video/dolby-vision” dla połączonego 2/3-warstwowego strumienia Dolby. Format jednostki dostępu ścieżki HDR, który określa sposób pakowania jednostek dostępu z warstw podstawowych/ulepszeń/metadanych w pojedynczy bufor w celu zdekodowania ich w pojedynczą ramkę HDR, ma zostać zdefiniowany przez Dolby.
- (Opcjonalnie, tylko jeśli BL jest kompatybilny wstecz) Ścieżka BL zawiera tylko warstwę bazową, która musi być dekodowana przez zwykły dekoder MediaCodec, na przykład dekoder AVC/HEVC. Ekstraktor powinien zapewniać regularne jednostki dostępu AVC/HEVC dla tego toru. Ta ścieżka BL musi mieć ten sam unikalny identyfikator ścieżki („identyfikator ścieżki”) co ścieżka Dolby, aby aplikacja zrozumiała, że są to dwa kodowania tego samego wideo.
- Aplikacja może zdecydować, który utwór wybrać w oparciu o możliwości platformy.
- Ponieważ ścieżka HDR ma określony typ HDR, platforma wybierze dekoder wideo Dolby do zdekodowania tej ścieżki. Ścieżka BL zostanie zdekodowana za pomocą zwykłego dekodera wideo AVC/HEVC.
- Strumienie bitów Dolby są rozpoznawane przez moduł DolbyExtractor, który udostępnia różne warstwy jako od 1 do 2 ścieżek dla każdej ścieżki wideo Dolby (grupy):
- Dekoder Dolby:
- DolbyDecoder odbiera 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 zdefiniowaną przez Dolby. Wymagane jest posiadanie pojedynczej ramki CSD.
Działania Dolby
- Zdefiniuj opakowanie jednostek dostępu dla różnych schematów kontenerów Dolby (np. BL+EL+MD) dla abstrakcyjnego dekodera Dolby (tj. formatu bufora oczekiwanego przez dekoder HDR).
- Zdefiniuj opakowanie CSD dla abstrakcyjnego dekodera Dolby.
Działania dostawcy
- Zaimplementuj ekstraktor Dolby. Można to również zrobić za pomocą Dolby.
- Zintegruj DolbyExtractor ze strukturą. Punktem wejścia jest
frameworks/av/media/libstagefright/MediaExtractor.cpp
. - Zadeklaruj profil dekodera HDR i typ poziomu OMX. Przykład:
OMX_VIDEO_DOLBYPROFILETYPE
iOMX_VIDEO_DOLBYLEVELTYP
. - Zaimplementuj obsługę indeksu:
'OMX.google.android.index.describeColorAspects
” - Propaguj dynamiczne metadane HDR do aplikacji i wyświetlaj je w każdej klatce. Zazwyczaj informacje te muszą być spakowane w zdekodowaną ramkę zgodnie z definicją Dolby, ponieważ standard HDMI nie zapewnia sposobu przekazania ich do wyświetlacza.
Rurociąg dekodera VP9
Strumienie bitów VP9 są pakowane w kontenery WebM w sposób zdefiniowany przez zespół WebM. Aplikacje muszą używać ekstraktora WebM do wyodrębniania metadanych HDR ze strumienia bitów przed wysłaniem klatek do dekodera.
- Ekstraktor WebM:
- Dekoder VP9:
- Dekoder odbiera strumienie bitów Profile2 i dekoduje je jako normalne strumienie VP9.
- Dekoder odbiera wszelkie statyczne metadane HDR ze struktury.
- Dekoder odbiera statyczne metadane za pośrednictwem jednostek dostępu do strumienia bitów dla strumieni VP9 PQ.
- Dekoder VP9 musi być w stanie propagować statyczne/dynamiczne metadane HDR na wyświetlaczu.
Działania dostawcy
- Zaimplementuj obsługę indeksu:
OMX.google.android.index.describeHDRColorInfo
- Zaimplementuj obsługę indeksu:
OMX.google.android.index.describeColorAspects
- Propaguj statyczne metadane HDR