Odtwarzanie wideo HDR

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 ² do 1000 cd/m ² ) 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.

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 ² dla tego wyświetlacza.
• float getDesiredMaxLuminance()
  Zwraca żądane dane dotyczące maksymalnej luminancji treści w cd/cd/m ² dla tego wyświetlacza.
• float getDesiredMinLuminance()
  Zwraca żądane dane dotyczące minimalnej luminancji treści w cd/cd/m ² 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:

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:

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:

1. 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.
2. Konwertuj wszystkie warstwy na wspólną przestrzeń kolorów.
3. Wykonaj miksowanie.
4. W przypadku wyświetlania przez HDMI:
   1. Określ kolor, mastering i potencjalne dynamiczne metadane dla mieszanej sceny.
   2. Konwertuj powstałą mieszaną scenę na pochodną przestrzeń/objętość kolorów.
5. 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

Rysunek 1. Potok 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

1. Reklamuj obsługiwany profil dekodera HDR i poziom typu OMX. Przykład:
   OMX_VIDEO_HEVCProfileMain10HDR10 (i Main10 )
2. Zaimplementuj obsługę indeksu: ' OMX.google.android.index.describeHDRColorInfo '
3. Zaimplementuj obsługę indeksu: „ OMX.google.android.index.describeColorAspects ”
4. Zaimplementuj obsługę analizowania metadanych masteringowych SEI.

Rurociąg dekodera Dolby Vision

Rysunek 2. Potok 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.
• 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

1. 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).
2. Zdefiniuj opakowanie CSD dla abstrakcyjnego dekodera Dolby.

Działania dostawcy

1. Zaimplementuj ekstraktor Dolby. Można to również zrobić za pomocą Dolby.
2. Zintegruj DolbyExtractor ze strukturą. Punktem wejścia jest frameworks/av/media/libstagefright/MediaExtractor.cpp .
3. Zadeklaruj profil dekodera HDR i typ poziomu OMX. Przykład: OMX_VIDEO_DOLBYPROFILETYPE i OMX_VIDEO_DOLBYLEVELTYP .
4. Zaimplementuj obsługę indeksu: 'OMX.google.android.index.describeColorAspects ”
5. 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

Rysunek 3. Rurociąg VP9-PQ

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:
  • WebM Extractor wyodrębnia metadane i klatki HDR z kontenera .
• 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

1. Zaimplementuj obsługę indeksu: OMX.google.android.index.describeHDRColorInfo
2. Zaimplementuj obsługę indeksu: OMX.google.android.index.describeColorAspects
3. Propaguj statyczne metadane HDR