Riproduzione video HDR

Il formato video HDR (High Dynamic Range) è la prossima frontiera della decodifica video in alta qualità e offre qualità di riproduzione delle scene senza pari. Lo fa aumentando notevolmente la gamma dinamica della componente di luminanza (dagli attuali 100 cd/m2 a migliaia di cd/m2) e utilizzando un spazio di colore molto più ampio (BT 2020). Questo è un elemento centrale dell'evoluzione del 4K UHD nello spazio televisivo.

Android 10 supporta i seguenti video HDR.

  • HDR10
  • VP9
  • HDR10+

A partire da Android 9 e versioni successive, MediaCodec segnala i metadati HDR indipendentemente dalla modalità in tunnel. Puoi ottenere dati decodificati insieme a metadati statici/dinamici in modalità non in tunnel. Per HDR10 e VP9Profile2 che utilizzano metadati statici, questi vengono riportati nel formato di output con chiave KEY_HDR_STATIC_INFO. Per HDR10+ che utilizza metadati dinamici, questo valore viene riportato con il tasto KEY_HDR10_PLUS_INFO nel formato di output e può cambiare per ogni frame di output. Per ulteriori informazioni, consulta la sezione Tunnel multimediale.

A partire da Android 7.0, il supporto iniziale per HDR include la creazione di costanti appropriate per il rilevamento e la configurazione delle pipeline video HDR. Ciò significa definire i tipi di codec e le modalità di visualizzazione e specificare come i dati HDR devono essere trasmessi a MediaCodec e forniti ai decodificatori HDR.

Lo scopo di questo documento è aiutare gli sviluppatori di applicazioni a supportare la riproduzione di stream HDR e aiutare OEM e SOC a attivare le funzionalità HDR.

Tecnologie HDR supportate

A partire da Android 7.0 e versioni successive, sono supportate le seguenti tecnologie HDR.

Tecnologia Dolby Vision HDR10 VP9-HLG VP9-PQ
Codec AVC/HEVC HEVC VP9 VP9
Funzione di trasferimento ST-2084 ST-2084 HLG ST-2084
Tipo di metadati HDR Dinamico Statico Nessuno Statico

In Android 7.0, è definita solo la riproduzione HDR tramite la modalità tunnel, ma i dispositivi possono aggiungere il supporto per la riproduzione di HDR su SurfaceView utilizzando buffer video opachi. In altre parole:

  • Non esiste un'API Android standard per verificare se la riproduzione HDR è supportata tramite decoder non in tunnel.
  • I decodificatori video in tunnel che pubblicizzano la funzionalità di riproduzione HDR devono supportare la riproduzione HDR quando sono collegati a display compatibili con HDR.
  • La composizione GL dei contenuti HDR non è supportata dalla release AOSP Android 7.0.

Scoperta

La riproduzione HDR richiede un decodificatore compatibile con HDR e una connessione a un display compatibile con HDR. Facoltativamente, alcune tecnologie richiedono un'estrazione specifica.

Display

Le applicazioni devono utilizzare la nuova API Display.getHdrCapabilities per eseguire query sulle tecnologie HDR supportate dal display specificato. Si tratta principalmente delle informazioni nel blocco di dati dei metadati statici EDID come definito nel CTA-861.3:

  • public Display.HdrCapabilities getHdrCapabilities()
    Restituisce le funzionalità HDR del display.
  • Display.HdrCapabilities
    Incapsula le funzionalità HDR di un determinato display. Ad esempio, i tipi di HDR supportati e i dettagli sui dati di luminanza desiderati.

Costanti:

  • int HDR_TYPE_DOLBY_VISION
    Supporto Dolby Vision.
  • int HDR_TYPE_HDR10
    Supporto HDR10 / PQ.
  • int HDR_TYPE_HDR10_PLUS
    Supporto HDR10+.
  • int HDR_TYPE_HLG
    Supporto ibrido Log-Gamma.
  • float INVALID_LUMINANCE
    Valore di luminanza non valido.

Metodi pubblici:

  • float getDesiredMaxAverageLuminance()
    Restituisce i dati sulla luminazia media massima dei frame dei contenuti desiderati in cd/m2 per questo display.
  • float getDesiredMaxLuminance()
    Restituisce i dati sulla luminatanza massima dei contenuti desiderati in cd/m2 per questo display.
  • float getDesiredMinLuminance()
    Restituisce i dati sulla luminanza minima dei contenuti desiderati in cd/m2 per questo display.
  • int[] getSupportedHdrTypes()
    Recupera i tipi HDR supportati di questo display (vedi costanti). Restituisce un array vuoto se l'HDR non è supportato dal display.

Decoder

Le applicazioni devono utilizzare l'API CodecCapabilities.profileLevels esistente per verificare il supporto dei nuovi profili compatibili con l'HDR:

Dolby-Vision

MediaFormat costante mime:

String MIMETYPE_VIDEO_DOLBY_VISION

Costanti del profilo MediaCodecInfo.CodecProfileLevel:

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

I livelli video e i metadati Dolby Vision devono essere concatenati in un singolo buffer per frame dalle applicazioni video. Questa operazione viene eseguita automaticamente da MediaExtractor compatibile con Dolby Vision.

HEVC HDR 10

Costanti del profilo MediaCodecInfo.CodecProfileLevel:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG e PQ

Costanti del profilo MediaCodecInfo.CodecProfileLevel:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Se una piattaforma supporta un decoder compatibile con HDR, deve supportare anche un estrattore compatibile con HDR.

Solo i decoder in tunnel riproducono i contenuti HDR. La riproduzione da parte di decodificatori non in tunnel potrebbe comportare la perdita delle informazioni HDR e l'appiattimento dei contenuti in un volume di colore SDR.

Estrattore

I seguenti contenitori sono supportati per le varie tecnologie HDR su Android 7.0:

Tecnologia Dolby Vision HDR10 VP9-HLG VP9-PQ
Container MP4 MP4 WebM WebM

Il rilevamento se una traccia (di un file) richiede il supporto HDR non è supportato dalla piattaforma. Le applicazioni possono analizzare i dati specifici del codec per determinare se una traccia richiede un profilo HDR specifico.

Riepilogo

I requisiti dei componenti per ogni tecnologia HDR sono riportati nella tabella seguente:

Tecnologia Dolby Vision HDR10 VP9-HLG VP9-PQ
Tipo di HDR supportato (display) HDR_TYPE_DOLBY_VISION HDR10 HDR_TYPE_HLG HDR10
Container (estrattore) MP4 MP4 WebM WebM
Decodificatore MIMETYPE_VIDEO_DOLBY_VISION MIMETYPE_VIDEO_HEVC MIMETYPE_VIDEO_VP9 MIMETYPE_VIDEO_VP9
Profilo (decodificatore) Uno dei profili Dolby HEVCProfiloMain10HDR10 VP9Profile2HDR o VP9Profile3HDR VP9Profile2HDR o VP9Profile3HDR

Note:

  • I bitstream Dolby Vision vengono pacchettizzati in un contenitore MP4 nel modo definito da Dolby. Le applicazioni possono implementare i propri estrattori compatibili con Dolby, a condizione che pacchettino le unità di accesso dei livelli corrispondenti in un'unica unità di accesso per il decodificatore come definito da Dolby.
  • Una piattaforma potrebbe supportare un'estrazione HDR, ma non un decodificatore HDR corrispondente.

Riproduzione

Dopo che un'applicazione ha verificato il supporto della riproduzione HDR, può riprodurre i contenuti HDR quasi allo stesso modo di quelli non HDR, con le seguenti avvertenze:

  • Per Dolby-Vision, non è immediatamente disponibile se un file/una traccia multimediale specifica richiede o meno un decoder compatibile con HDR. L'applicazione deve avere queste informazioni in anticipo o essere in grado di ottenerle analizzando la sezione dei dati specifici del codec di MediaFormat.
  • CodecCapabilities.isFormatSupported non valuta se la funzionalità di decodifica con tunnel è necessaria per supportare un profilo di questo tipo.

Attiva il supporto della piattaforma HDR

I fornitori di SoC e gli OEM devono eseguire ulteriori operazioni per attivare il supporto della piattaforma HDR per un dispositivo.

Modifiche alla piattaforma in Android 7.0 per l'HDR

Di seguito sono riportate alcune modifiche chiave della piattaforma (livello app/nativo) di cui OEM e SOC devono essere a conoscenza.

Display

Composizione hardware

Le piattaforme compatibili con HDR devono supportare la combinazione di contenuti HDR e non HDR. Le caratteristiche e le operazioni di combinazione esatte non sono definite da Android a partire dalla release 7.0, ma la procedura in genere si svolge nei seguenti passaggi:

  1. Stabilisci uno spazio colore/volume lineare che contenga tutti i livelli da comporre, in base al colore, alla masterizzazione e ai potenziali metadati dinamici dei livelli.
    Se la composizione viene eseguita direttamente su un display, potrebbe trattarsi dello spazio lineare corrispondente al volume di colore del display.
  2. Converti tutti i livelli nello spazio colore comune.
  3. Esegui la combinazione.
  4. Se la visualizzazione avviene tramite HDMI:
    1. Determina il colore, la masterizzazione e i potenziali metadati dinamici per la scena combinata.
    2. Converti la scena combinata risultante nello spazio/volume di colore derivato.
  5. Se la visualizzi direttamente sul display, converti la scena mista risultante nei segnali del display necessari per produrre quella scena.

Rilevamento del display

Il rilevamento dei display HDR è supportato solo tramite HWC2. Per il funzionamento di questa funzionalità, gli implementatori dei dispositivi devono attivare in modo selettivo l'adattatore HWC2 rilasciato con Android 7.0. Pertanto, le piattaforme devono aggiungere il supporto per HWC2 o estendere il framework AOSP per consentire di fornire queste informazioni. HWC2 espone una nuova API per propagare i dati statici HDR al framework e all'applicazione.

HDMI

  • Un display HDMI collegato pubblicizza la sua funzionalità HDR tramite EDID HDMI come definito nella sezione 4.2 di CTA-861.3.
  • Deve essere utilizzata la seguente mappatura EOTF:
    • ET_0 Gamma tradizionale - Intervallo di luminanza SDR: non mappato ad alcun tipo HDR
    • ET_1 Gamma tradizionale - Gamma di luminanza HDR: non mappata a nessun tipo di HDR
    • ET_2 SMPTE ST 2084 - mappata su HDR di tipo HDR10
  • La segnalazione del supporto Dolby Vision o HLG tramite HDMI avviene in base a quanto definito dall'ente pertinente.
  • Tieni presente che l'API HWC2 utilizza valori di luminanza desiderati in virgola mobile, quindi i valori EDID a 8 bit devono essere tradotti in un modo appropriato.

Decoder

Le piattaforme devono aggiungere decodificatori in tunnel compatibili con HDR e pubblicizzare il loro supporto HDR. In genere, i decoder compatibili con HDR devono:

  • Supporto della decodifica con tunnel (FEATURE_TunneledPlayback).
  • Supporta i metadati statici HDR (OMX.google.android.index.describeHDRColorInfo) e la loro propagazione alla composizione del display/dell'hardware. Per HLG, è necessario inviare al display i metadati appropriati.
  • Supporta la descrizione del colore (OMX.google.android.index.describeColorAspects) e la sua propagazione alla composizione del display/dell'hardware.
  • Supporta i metadati incorporati HDR come definito dallo standard pertinente.

Supporto del decoder Dolby Vision

Per supportare Dolby Vision, le piattaforme devono aggiungere un decodificatore OMX HDR compatibile con Dolby Vision. Date le specifiche di Dolby Vision, in genere si tratta di un decodificatore wrapper che include uno o più decodificatori AVC e/o HEVC, nonché un compositore. Questi decoder devono:

  • Supporta il tipo MIME "video/dolby-vision".
  • Pubblicizza profili/livelli Dolby Vision supportati.
  • Accetta unità di accesso che contengono le unità di accesso secondarie di tutti i livelli come definito da Dolby.
  • Accetta dati specifici del codec definiti da Dolby. Ad esempio, dati contenenti il profilo/livello Dolby Vision e, eventualmente, i dati specifici del codec per i decodificatori interni.
  • Supporto del passaggio adattivo tra i profili/livelli Dolby Vision come richiesto da Dolby.

Quando si configura il decoder, il profilo Dolby effettivo non viene comunicato al codec. Questo viene fatto solo tramite dati specifici del codec dopo che il decoder è stato avviato. Una piattaforma potrebbe scegliere di supportare più decodificatori Dolby Vision: uno per i profili AVC e un altro per i profili HEVC per poter inizializzare i codec sottostanti durante la configurazione. Se un singolo decodificatore Dolby Vision supporta entrambi i tipi di profili, deve supportare anche il passaggio da uno all'altro in modo dinamico e adattativo.

Se una piattaforma fornisce un decodificatore compatibile con Dolby Vision oltre al supporto generale del decodificatore HDR, deve:

  • Fornisci un'app di estrazione compatibile con Dolby Vision, anche se non supporta la riproduzione HDR.
  • Fornisci un decoder che supporti il profilo visivo come definito da Dolby.

Supporto decoder HDR10

Per supportare la tecnologia HDR10, le piattaforme devono aggiungere un decodificatore OMX compatibile con HDR10. In genere si tratta di un decoder HEVC con tunnel che supporta anche l'analisi e la gestione dei metadati correlati a HDMI. Un decodificatore di questo tipo (oltre al supporto generale del decodificatore HDR) deve:

  • Supporta il tipo MIME "video/hevc".
  • Pubblicizza HEVCMain10HDR10 supportato. Il supporto del profilo HEVCMain10HRD10 richiede anche il supporto del profilo HEVCMain10, che richiede il supporto del profilo HEVCMain agli stessi livelli.
  • Supporta l'analisi dei blocchi SEI dei metadati di masterizzazione, nonché altre informazioni relative all'HDR contenute in SPS.

Supporto del decodificatore VP9

Per supportare VP9 HDR, le piattaforme devono aggiungere un decodificatore OMX HDR compatibile con VP9 profilo 2. Di solito si tratta di un decodificatore VP9 in tunnel che supporta anche la gestione dei metadati relativi all'HDMI. Questi decoder (oltre al supporto generale dei decoder HDR) devono:

  • Supporta il tipo MIME "video/x-vnd.on2.vp9".
  • Pubblicizza VP9Profile2HDR supportato. Il supporto del profilo VP9Profile2HDR richiede anche il supporto del profilo VP9Profile2 allo stesso livello.

Estrattori

Supporto dell'estrattore Dolby Vision

Le piattaforme che supportano i decodificatori Dolby Vision devono aggiungere il supporto dell'estrattore Dolby (chiamato Dolby Extractor) per i contenuti Dolby Video.

  • Un normale estrattore MP4 può estrarre solo il livello di base da un file, ma non i livelli di miglioramento o dei metadati. Serve quindi uno speciale estrattore Dolby per estrarre i dati dal file.
  • L'estrattore Dolby deve esporre da 1 a 2 tracce per ogni traccia video Dolby (gruppo):
    • Una traccia Dolby Vision HDR con il tipo "video/dolby-vision" per lo stream combinato Dolby a 2/3 strati. Il formato dell'unità di accesso della traccia HDR, che definisce come imballare le unità di accesso dai livelli di base/miglioramento/metadati in un unico buffer da decodificare in un singolo frame HDR, deve essere definito da Dolby.
    • Se una traccia video in Dolby Vision contiene un livello base (BL) separato (compatibile con le versioni precedenti), l'estrattore deve esporlo anche come traccia "video/avc" o "video/hevc" separata. L'estrattore deve fornire unità di accesso AVC/HEVC normali per questa traccia.
    • La traccia BL deve avere lo stesso ID univoco della traccia ("track-ID") della traccia HDR, in modo che l'app capisca che si tratta di due codifiche dello stesso video.
    • L'applicazione può decidere quale canale scegliere in base alle funzionalità della piattaforma.
  • Il profilo/livello Dolby Vision deve essere esposto nel formato della traccia della traccia HDR.
  • Se una piattaforma fornisce un decodificatore compatibile con Dolby Vision, deve fornire anche un'estrazione compatibile con Dolby Vision, anche se non supporta la riproduzione HDR.

Supporto dell'estrattore HDR10 e VP9 HDR

Non sono previsti requisiti aggiuntivi per gli estrattori per supportare HDR10 o VP9 HLG. Le piattaforme devono estendere l'estrattore MP4 per supportare VP9 PQ in MP4. I metadati statici HDR devono essere propagati nel bitstream VP9 PQ, in modo che questi metadati vengano passati al decodificatore VP9 PQ e alla visualizzazione tramite la normale pipeline MediaExtractor => MediaCodec.

Estensioni Stagefright per il supporto di Dolby Vision

Le piattaforme devono aggiungere il supporto del formato Dolby Vision a Stagefright:

  • Supporto per la query di definizione della porta per la porta compressa.
  • Supporta l'enumerazione del profilo/livello per il decoder DV.
  • Supporto dell'esposizione del profilo/livello DV per le tracce HDR DV.

Dettagli di implementazione specifici per tecnologia

Pipeline del decodificatore HDR10

Figura 1. Pipeline HDR10

I bitstream HDR10 sono pacchettizzati in container MP4. Le applicazioni utilizzano un normale estrattore MP4 per estrarre i dati dei frame e inviarli al decodificatore.

  • MPEG4 Extractor
    I bitstream HDR10 sono riconosciuti come un normale stream HEVC da un MPEG4Extractor e la traccia HDR con il tipo "video/HEVC" viene estratta. Il framework sceglie un decodificatore video HEVC che supporta il profilo Main10HDR10 per decodificare la traccia.
  • Decodificatore HEVC
    Le informazioni HDR sono in SEI o SPS. Il decodificatore HEVC riceve innanzitutto i frame che contengono le informazioni HDR. Il decoder estrae quindi le informazioni HDR e notifica all'applicazione che sta decodificando un video HDR. Le informazioni HDR vengono raggruppate nel formato di output del decoder, che viene propagata alla superficie in un secondo momento.

Azioni del fornitore

  1. Pubblicizza il profilo e il tipo OMX di livello del decodificatore HDR supportato. Esempio:
    OMX_VIDEO_HEVCProfileMain10HDR10 (e Main10)
  2. Implementare il supporto per l'indice: 'OMX.google.android.index.describeHDRColorInfo'
  3. Implementa il supporto per l'indice: "OMX.google.android.index.describeColorAspects"
  4. Implementazione del supporto per l'analisi SEI dei metadati di mastering.

Pipeline del decoder Dolby Vision

Figura 2. Pipeline Dolby Vision

I Dolby-bitstream sono pacchettizzati in container MP4 come definito da Dolby. In teoria, le applicazioni potrebbero utilizzare un normale estrattore MP4 per estrarre in modo indipendente il livello di base, il livello di miglioramento e il livello di metadati. Tuttavia, questo non è compatibile con l'attuale modello MediaExtractor/MediaCodec di Android.

  • DolbyExtractor:
    • I flussi di dati Dolby-bitstream sono riconosciuti da un DolbyExtractor, che espone i vari livelli come 1 o 2 tracce per ogni traccia video dolby (gruppo):
      • Una traccia HDR con il tipo "video/dolby-vision" per lo stream dolby combinato a 2/3 strati. Il formato dell'unità di accesso della traccia HDR, che definisce come imballare le unità di accesso dai livelli di base/miglioramento/metadati in un unico buffer da decodificare in un singolo frame HDR, deve essere definito da Dolby.
      • (Facoltativo, solo se il BL è compatibile con le versioni precedenti) Una traccia BL contiene solo il livello di base, che deve essere decodificabile dal normale decoder MediaCodec, ad esempio il decoder AVC/HEVC. L'estrattore deve fornire unità di accesso AVC/HEVC normali per questa traccia. Questo canale BL deve avere lo stesso ID traccia unico ("track-ID") del canale Dolby in modo che l'applicazione capisca che si tratta di due codificazioni dello stesso video.
    • L'applicazione può decidere quale canale scegliere in base alle funzionalità della piattaforma.
    • Poiché una traccia HDR ha un tipo HDR specifico, il framework sceglierà un decodificatore video Dolby per decodificarla. La traccia BL verrà decodificata da un normale decodificatore video AVC/HEVC.
  • DolbyDecoder:
    • DolbyDecoder riceve unità di accesso contenenti le unità di accesso richieste per tutti i livelli (EL+BL+MD o BL+MD)
    • Le informazioni CSD (codec specific data, come SPS+PPS+VPS) per i singoli livelli possono essere pacchettizzate in un frame CSD da definire da Dolby. È necessario avere un singolo frame CSD.

Azioni Dolby

  1. Definisci la pacchettizzazione delle unità di accesso per i vari schemi di container Dolby (ad es. BL+EL+MD) per il decoder Dolby astratto (ovvero il formato di buffer previsto dal decoder HDR).
  2. Definisci il packaging del CSD per il decodificatore Dolby astratto.

Azioni del fornitore

  1. Implementa l'estrattore Dolby. Questa operazione può essere eseguita anche da Dolby.
  2. Integrare DolbyExtractor nel framework. Il punto di ingresso è frameworks/av/media/libstagefright/MediaExtractor.cpp.
  3. Dichiara il profilo del decoder HDR e il tipo di livello OMX. Esempio: OMX_VIDEO_DOLBYPROFILETYPE e OMX_VIDEO_DOLBYLEVELTYP.
  4. Implementa il supporto per l'indice: 'OMX.google.android.index.describeColorAspects"
  5. Propaga i metadati HDR dinamici all'app e all'area in ogni frame. In genere queste informazioni devono essere racchiuse nel frame decodificato come definito da Dolby, perché lo standard HDMI non consente di trasmetterle al display.

Pipeline decoder VP9

Figura 3. Pipeline VP9-PQ

I bitstream VP9 sono pacchettizzati in container WebM in un modo definito dal team WebM. Le applicazioni devono utilizzare un'apposita app per estrarre i metadati HDR dal flusso di dati prima di inviare i frame al decodificatore.

  • Estrattore WebM:
  • Decodificatore VP9:
    • Il decodificatore riceve i bitstream Profile2 e li decodifica come normali stream VP9.
    • Il decodificatore riceve tutti i metadati statici HDR dal framework.
    • Il decodificatore riceve i metadati statici tramite le unità di accesso al flusso di bit per gli stream VP9PQ.
    • Il decodificatore VP9 deve essere in grado di propagare i metadati HDR statici/dinamici al display.

Azioni del fornitore

  1. Implementa il supporto dell'indice: OMX.google.android.index.describeHDRColorInfo
  2. Implementa il supporto per l'indice: OMX.google.android.index.describeColorAspects
  3. Propagare i metadati statici HDR