Odtwarzanie filmów w jakości HDR

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Filmy High Dynamic Range (HDR) to kolejny krok w kierunku wysokiej jakości dekodowania wideo, który zapewnia niezrównaną jakość odtwarzania scen. Dzieje się tak dzięki znacznemu zwiększeniu zakresu dynamicznego komponentu luminancji (z obecnych 100 cd/m² do 1000 cd/m²) oraz zastosowaniu znacznie szerszej przestrzeni barw (BT 2020). Jest to obecnie kluczowy element ewolucji 4K UHD w branży telewizyjnej.

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. Dane zdekodowane wraz z metadanymi statycznymi lub dynamicznymi możesz uzyskać w trybie bez tunelowania. 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 jest raportowany w formacie wyjściowym i może się zmieniać w przypadku każdego wyjściowego obrazu. Więcej informacji znajdziesz w artykule Tunelowanie multimediów.

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 dekoderom 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

Od wersji Android 7.0 i nowszych obsługiwane są te technologie HDR:

W Androidzie 7.0 zdefiniowano tylko odtwarzanie HDR w trybie tunelowania, ale urządzenia mogą dodać obsługę odtwarzania HDR w 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 bez tunelowania.
• 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.
• Wersja AOSP Androida 7.0 nie obsługuje kompozycji GL treści HDR.

Discovery

Odtwarzanie w trybie HDR wymaga dekodera obsługującego HDR oraz połączenia z wyświetlaczem obsługującym HDR. 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
  Opisuje możliwości HDR danego wyświetlacza. Na przykład, jakie typy HDR obsługuje i szczegóły dotyczące pożądanych danych dotyczących luminacji.

Stała:

• 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 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 dane dotyczące maksymalnej luminacji treści w jednostce cd/cd/m² dla tego wyświetlacza.
• float getDesiredMinLuminance()
  Zwraca dane dotyczące minimalnej luminacji treści w jednostce cd/cd/m² dla tego wyświetlacza.
• int[] getSupportedHdrTypes()
  Pobiera obsługiwane typy HDR wyświetlacza (patrz stałe). Zwraca pusty tablicę, jeśli wyświetlacz nie obsługuje HDR.

Dekoder

Aplikacje muszą używać dotychczasowego interfejsu API CodecCapabilities.profileLevels do weryfikacji obsługi nowych profili obsługujących 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

Aplikacje wideo muszą złączać warstwy wideo i metadane Dolby Vision w jeden bufor na klatkę. 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 obsługujący HDR, musi też obsługiwać ekstraktor obsługujący HDR.

Odtwarzanie treści HDR jest gwarantowane tylko w przypadku dekoderów tunelowanych. Odtwarzanie za pomocą dekoderów bez tunelowania może spowodować utratę informacji HDR i spłaszczenie treści do SDR.

Ekstraktor

Na Androidzie 7.0 obsługiwane są następujące kontenery dla różnych technologii HDR:

Platforma nie obsługuje wykrywania, czy ścieżka (plik) wymaga obsługi HDR. Aplikacje mogą analizować dane dotyczące kodeka, aby określić, czy utwór wymaga określonego profilu HDR.

Podsumowanie

Wymagania dotyczące komponentów dla każdej technologii HDR są podane w tabeli poniżej:

Uwagi:

• Strumienie bitowe Dolby Vision są pakowane w kontenerze MP4 w sposób zdefiniowany przez Dolby. Aplikacje mogą stosować własne wyodrębnianie danych z użyciem Dolby, o ile pakują jednostki dostępu z odpowiednich warstw w pojedynczą jednostkę dostępu dla dekodera zgodnie z definicją Dolby.
• Platforma może obsługiwać ekstraktor obsługujący HDR, ale nie ma dekodera obsługującego HDR.

Odtwarzanie

Gdy aplikacja zostanie zweryfikowana pod kątem obsługi odtwarzania w trybie HDR, będzie mogła odtwarzać treści HDR w praktycznie taki sam sposób jak treści bez HDR, z tymi wyjątkami:

• W przypadku Dolby Vision nie można od razu stwierdzić, czy konkretny plik multimedialny lub ścieżka wymaga dekodera obsługującego HDR. Aplikacja musi mieć te informacje z góry lub musi mieć możliwość ich uzyskania przez zanalizowanie sekcji danych dotyczących konkretnego kodeka w formacie MediaFormat.
• CodecCapabilities.isFormatSupported nie uwzględnia, czy funkcja dekodera tunelowanego jest wymagana do obsługi takiego profilu.

Włączanie obsługi HDR

Dostawcy SoC i OEM muszą wykonać dodatkowe czynności, aby umożliwić obsługę HDR na urządzeniu.

Zmiany w platformie w Androidzie 7.0 dotyczące HDR

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

Wyświetlacz

Skład sprzętowy

Platformy obsługujące HDR muszą umożliwiać łączenie treści HDR z treściami bez HDR. Dokładne cechy i operacje mieszania nie są zdefiniowane przez Androida w wersji 7.0, ale proces przebiega zwykle według tych kroków:

1. Określ liniowy gamut/objęt kolorów, który zawiera wszystkie warstwy do złożenia, na podstawie koloru, masteringu i potencjalnych dynamicznych metadanych warstw.
   Jeśli kompozytujesz 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 na wspólną przestrzeń kolorów.
3. Przeprowadź mieszanie.
4. Jeśli wyświetlasz obraz przez HDMI:
   1. Określ kolor, mastering i potencjalne metadane dynamiczne dla zmiksowanej sceny.
   2. Przekształć wynikową zmiksowaną scenę w wyprowadzoną przestrzeń kolorów lub objętość.
5. Jeśli wyświetlanie odbywa się bezpośrednio na ekranie, przekształcaj uzyskaną zmiksowaną scenę w wymagane sygnały wyświetlania, aby wygenerować tę scenę.

Wyświetlanie reklam

Wykrywanie wyświetlacza HDR jest obsługiwane tylko przez HWC2. Aby ta funkcja działała, implementatorzy urządzeń muszą selektywnie włączyć adapter HWC2, który został wydany 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 Traditional gamma - HDR Luminance Range: not mapped to any HDR type
  • ET_2 SMPTE ST 2084 – mapowane na typ HDR HDR10
• Przekazywanie informacji o obsłudze Dolby Vision lub HLG przez HDMI odbywa się zgodnie z definicją odpowiednich podmiotów.
• Pamiętaj, że interfejs HWC2 API używa wartości luminancji docelowej w postaci liczb zmiennoprzecinkowych, więc wartości 8-bitowych ID EDID muszą zostać przekształcone w odpowiednim formacie.

Dekodery

Platformy muszą dodać dekodery tunelowe obsługujące HDR i reklamować obsługę HDR. Ogólnie dekodery obsługujące HDR muszą:

• Obsługa dekodowania tunelowanego (FEATURE_TunneledPlayback).
• Obsługa statycznych metadanych HDR (OMX.google.android.index.describeHDRColorInfo) i ich propagowanie do wyświetlacza lub sprzętu. W przypadku HLG należy przesłać odpowiednie metadane do wyświetlacza.
• Obsługa opisu koloru (OMX.google.android.index.describeColorAspects) i jego propagacji do kompozycji wyświetlacza/sprzętu.
• Obsługa zakodowanych metadanych 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. W przypadku Dolby Vision jest to zwykle dekoder owijający co najmniej 1 dekoder AVC lub HEVC oraz kompozytor. Takie dekodery muszą:

• Obsługa typu MIME „video/dolby-vision”.
• Promuj obsługiwane profile/poziomy Dolby Vision.
• Akceptuj jednostki dostępu, które zawierają podjednostki dostępu wszystkich warstw zdefiniowane przez Dolby.
• akceptować dane specyficzne dla kodeka zdefiniowane przez Dolby. Na przykład dane zawierające profil/poziom Dolby Vision oraz ewentualnie dane dotyczące kodeków dla dekoderów wewnętrznych.
• 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 dla profili AVC i drugi dla profili HEVC, aby umożliwić inicjowanie koderów w czasie konfiguracji. Jeśli jeden dekoder Dolby Vision obsługuje oba typy profili, musi też umożliwiać 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. Jest to zwykle tunelowany dekoder HEVC, który obsługuje też analizowanie i przetwarzanie metadanych związanych z HDMI. Taki dekoder (oprócz ogólnego obsługiwania dekodera HDR) musi:

• Obsługa typu 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 też obsługę metadanych związanych z HDMI. Takie dekodery (oprócz ogólnego obsługiwania dekodera HDR) muszą:

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

Wyodrębnianie

Obsługa ekstraktora Dolby Vision

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

• Zwykły program do wyodrębniania plików MP4 może wyodrębnić tylko warstwę podstawową z pliku, ale nie warstwy ulepszenia ani metadanych. Dlatego do wyodrębnienia danych z pliku potrzebny jest specjalny ekstraktor Dolby.
• Wyodrębniacz Dolby musi udostępnić 1–2 ścieżki dla każdej ścieżki wideo Dolby (grupy):
  • Ścieżka Dolby Vision HDR z typem „video/dolby-vision” dla połączonego strumienia Dolby 2/3 warstw. Format jednostek dostępu ścieżki HDR, który określa sposób pakowania jednostek dostępu z warstw podstawowej, rozszerzenia i metadanych do pojedynczego bufora, który ma zostać zdekodowany do pojedynczego kadru HDR, jest zdefiniowany 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”. Wyodrębniacz musi zapewnić regularne jednostki dostępu AVC/HEVC dla tego utworu.
  • Ścieżka BL musi mieć ten sam identyfikator unikalny dla ścieżki („track-ID”) co ścieżka HDR, aby aplikacja wiedziała, że są to 2 kodowania tego samego filmu.
  • Aplikacja może wybrać ścieżkę na podstawie możliwości platformy.
• Profil lub poziom Dolby Vision musi być dostępny w formacie ścieżki ś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

Aby obsługiwać HDR10 lub VP9 HLG, nie trzeba spełniać żadnych dodatkowych wymagań dotyczących ekstraktora. Platformy muszą rozszerzyć ekstraktor MP4, aby obsługiwał format VP9 PQ w 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.
• Obsługa numeracji profili/poziomów dla dekodera DV.
• Obsługa wyświetlania profilu DV lub poziomu dla ścieżek DV HDR.

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

Przetwarzanie HDR10

Rysunek 1. HDR10

Strumienie bitowe HDR10 są pakowane w kontenerach MP4. Aplikacje używają zwykłego narzędzia do wyodrębniania danych MP4, aby wyodrębnić dane ramki i wysłać je do dekodera.

• MPEG4 Extractor
  Strumienie bitowe HDR10 są rozpoznawane przez MPEG4Extractor jako zwykłe strumienie 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ę.
• Dekodowanie HEVC
  Informacje HDR znajdują się w SEI lub SPS. Dekoder HEVC najpierw odbiera ramki zawierające informacje HDR. Następnie 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 poziomy typu OMX. Przykład:
   OMX_VIDEO_HEVCProfileMain10HDR10 (i Main10)
2. Wdrożyć obsługę indeksu: 'OMX.google.android.index.describeHDRColorInfo'
3. Wdrożyć obsługę indeksu: 'OMX.google.android.index.describeColorAspects'
4. Wdrożyć obsługę parsowania SEI metadanych masteringu.

Dekoder Dolby Vision

Rysunek 2. Przetwarzanie Dolby Vision

Strumienie bitowe Dolby są pakowane w kontenerach MP4 zgodnie z definicją Dolby. Teoretycznie aplikacje mogłyby użyć zwykłego narzędzia do wyodrębniania MP4, aby wyodrębnić warstwę podstawową, warstwę rozszerzenia i warstwę metadanych niezależnie od siebie. Nie pasuje to jednak do obecnego modelu MediaExtractor/MediaCodec na Androida.

• DolbyExtractor:
  • Strumienie bitowe Dolby są rozpoznawane przez DolbyExtractor, który udostępnia różne warstwy jako 1 do 2 ścieżek 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. Wyodrębniacz powinien udostępniać regularne jednostki dostępu AVC/HEVC dla tego utworu. Ta ścieżka BL musi mieć ten sam identyfikator ścieżki („track-ID”) co ścieżka Dolby, aby aplikacja wiedziała, że są to 2 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 zostanie zdekodowana 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) dotyczące poszczególnych warstw można spakować do 1 ramki CSD, którą zdefiniuje Dolby. Wymagane jest posiadanie pojedynczego kadru CSD.

Akcje Dolby

1. Określ pakowanie jednostek dostępu dla różnych schematów kontenera Dolby (np. BL+EL+MD) dla abstrakcyjnego dekodera Dolby (czyli formatu bufora oczekiwanego przez dekoder 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 na poziomie. Przykład: OMX_VIDEO_DOLBYPROFILETYPE i OMX_VIDEO_DOLBYLEVELTYP.
4. Wdrożyć obsługę indeksu: 'OMX.google.android.index.describeColorAspects'
5. Przesyłanie dynamicznych metadanych HDR do aplikacji i wyświetlanie ich w każdym klatku. Zazwyczaj te informacje muszą być zapakowane w odkodowany obraz zgodnie z definicją Dolby, ponieważ standard HDMI nie umożliwia przekazania tych informacji wyświetlaczowi.

Dekoder VP9

Rysunek 3. Potok VP9-PQ

Strumienie bitowe VP9 są pakowane w kontenerach WebM w sposób określony przez zespół ds. WebM. Aplikacje muszą używać narzędzia do wyodrębniania metadanych HDR z bitstremu przed wysłaniem klatek do dekodera.

• Narzędzie do wyodrębniania WebM:
  • Narzędzie WebM Extractor wyodrębnia metadane HDR i klatki z kontenera.
• Dekoder VP9:
  • Dekoder odbiera strumienie danych Profile2 i dekoduje je jako zwykłe strumienie VP9.
  • Dekoder otrzymuje od frameworku wszystkie metadane HDR.
  • Dekoder otrzymuje metadane statyczne za pomocą jednostek dostępu do strumienia bitów w przypadku strumieni VP9PQ.
  • Dekoder VP9 musi mieć możliwość propagowania statycznych/dynamicznych metadanych HDR do wyświetlacza.

Działania dostawcy

1. Wdrożyć obsługę indeksu:OMX.google.android.index.describeHDRColorInfo
2. Wdrożyć obsługę indeksu:OMX.google.android.index.describeColorAspects
3. Propagowanie statycznych metadanych HDR