Riproduzione video HDR

I video HDR (High Dynamic Range) rappresentano la frontiera successiva della decodifica video di alta qualità, offrendo una qualità di riproduzione delle scene senza precedenti. Lo fa aumentando notevolmente la gamma dinamica del componente di luminanza (dagli attuali 100 cd/m² a migliaia di cd/m²) e utilizzando un spazio di colore molto più ampio (BT 2020). Ora è un elemento centrale dell'evoluzione del 4K UHD nel settore TV.

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 i dati decodificati insieme ai metadati statici/dinamici in modalità non in tunnel. Per HDR10 e VP9Profile2 che utilizzano metadati statici, questi vengono riportati nel formato di output con la chiave KEY_HDR_STATIC_INFO. Per HDR10+ che utilizza metadati dinamici, questi vengono registrati con la chiave KEY_HDR10_PLUS_INFO nel formato di output e possono cambiare per ogni frame di output. Per saperne di più, consulta la sezione Tunneling multimediale.

A partire da Android 7.0, il supporto HDR iniziale 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 utilizzando decodificatori 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 di Log-Gamma ibrido.
• 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/m² per questo display.
• float getDesiredMaxLuminance()
  Restituisce i dati sulla luminatanza massima dei contenuti desiderati in cd/cd/m² per questo display.
• float getDesiredMinLuminance()
  Restituisce i dati sulla luminanza minima dei contenuti desiderati in cd/m² per questo display.
• int[] getSupportedHdrTypes()
  Restituisce i tipi di HDR supportati da questo display (vedi le 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 decodificatore compatibile con l'HDR, deve supportare anche un'estrazione compatibile con l'HDR.

Solo i decodificatori in tunnel garantiscono la riproduzione di 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

La piattaforma non supporta la rilevazione dell'eventuale necessità di supporto HDR per una traccia (di un file). 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 HDR supportato (display)	HDR_TYPE_DOLBY_VISION	HDR_TYPE_HDR10	HDR_TYPE_HLG	HDR_TYPE_HDR10
Container (estrattore)	MP4	MP4	WebM	WebM
Decoder	MIMETYPE_VIDEO_DOLBY_VISION	MIMETYPE_VIDEO_HEVC	MIMETYPE_VIDEO_VP9	MIMETYPE_VIDEO_VP9
Profilo (decodificatore)	Uno dei profili Dolby	HEVCProfileMain10HDR10	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 aver verificato il supporto della riproduzione HDR, un'applicazione può riprodurre contenuti HDR quasi nello stesso modo in cui riproduce contenuti non HDR, con le seguenti limitazioni:

• Per Dolby Vision, non è immediatamente disponibile la verifica se un determinato file/canale multimediale richiede o meno un decodificatore 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 prende in considerazione se la funzionalità di decodificatore in tunnel è necessaria per supportare un profilo di questo tipo.

Attivare 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 l'unione di contenuti HDR con contenuti non HDR. Le operazioni e le caratteristiche di miscelazione esatte non sono definite da Android a partire dalla versione 7.0, ma il processo in genere segue questi passaggi:

1. Determina uno spazio/volume di colore lineare contenente tutti i livelli da compositare in base al colore, al mastering 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 di colore comune.
3. Esegui l'unione.
4. Se la visualizzazione avviene tramite HDMI:
   1. Determina il colore, il mastering e i potenziali metadati dinamici per la scena mista.
   2. Converti la scena combinata risultante nello spazio/volume di colore derivato.
5. Se la visualizzazione avviene direttamente sul display, converti la scena mista risultante negli indicatori di visualizzazione richiesti per produrla.

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 un modo per 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:
  • Gamma tradizionale ET_0 - Intervallo di luminanza SDR: non mappato a nessun tipo HDR
  • ET_1 Gamma tradizionale - Gamma di luminanza HDR: non mappata a nessun tipo di HDR
  • ET_2 SMPTE ST 2084 - mappato al tipo HDR HDR10
• L'indicazione del supporto di Dolby Vision o HLG tramite HDMI viene eseguita come definito dagli organismi competenti.
• Tieni presente che l'API HWC2 utilizza valori di illuminazione desiderati in formato float, pertanto i valori EDID di 8 bit devono essere tradotti in 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:

• Supporta la decodifica in 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 decodificatori devono:

• Supporta il tipo MIME "video/dolby-vision".
• Pubblicizza i profili/livelli Dolby Vision supportati.
• Accetta unità di accesso che contengono le unità di accesso secondarie di tutti i livelli come definito da Dolby.
• Accettare 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.

Durante la configurazione del decoder, il profilo Dolby effettivo non viene comunicato al codec. Questo viene fatto solo tramite dati specifici del codec dopo l'avvio del decoder. 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 decodificatore che supporti il profilo Vision come definito da Dolby.

Supporto del decodificatore HDR10

Per supportare HDR10, le piattaforme devono aggiungere un decodificatore OMX compatibile con HDR10. Di solito si tratta di un decodificatore HEVC in tunnel che supporta anche l'analisi e la gestione dei metadati relativi all'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. In genere si tratta di un decodificatore VP9 in tunnel che supporta anche la gestione dei metadati relativi all'HDMI. Questi decodificatori (oltre al supporto generale dei decodificatori 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. È quindi necessario un estrattore Dolby speciale per estrarre i dati dal file.
• L'estrattore Dolby deve esporre da 1 a 2 tracce per ogni traccia video Dolby (gruppo):
  • Una traccia HDR Dolby Vision con il tipo "video/dolby-vision" per lo stream Dolby combinato a 2/3 livelli. 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 Dolby Vision contiene un livello di 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 standard per questa traccia.
  • La traccia BL deve avere lo stesso ID traccia univoco ("ID traccia") 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 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 l'estrattore 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 flusso di dati VP9 PQ, in modo che vengano trasmessi al decodificatore VP9 PQ e al display 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/del livello per il decodificatore DV.
• Supporta l'esposizione del profilo/del livello DV per le tracce DV HDR.

Dettagli di implementazione specifici della tecnologia

Pipeline del decodificatore HDR10

Figura 1. Pipeline HDR10

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

• MPEG4 Extractor
  I bitstream HDR10 vengono riconosciuti come un normale stream HEVC da MPEG4Extractor e la traccia HDR con il tipo "video/HEVC" verrà 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 comunica all'applicazione che sta decodificando un video HDR. Le informazioni HDR vengono raggruppate nel formato di output del decodificatore, che viene poi propagato alla superficie.

Azioni del fornitore

1. Pubblicizza il tipo OMX del profilo e del livello del decodificatore HDR supportati. Esempio:
   OMX_VIDEO_HEVCProfileMain10HDR10 (e Main10)
2. Implementare il supporto per l'indice: 'OMX.google.android.index.describeHDRColorInfo'
3. Implementare 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 bitstream Dolby vengono pacchettizzati in contenitori MP4 come definito da Dolby. In teoria, le applicazioni potrebbero utilizzare un normale estrattore MP4 per estrarre indipendentemente 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 bitstream Dolby vengono riconosciuti da un DolbyExtractor, che espone i vari livelli come 1-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 livelli. 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 decodificatore MediaCodec normale, ad esempio il decodificatore AVC/HEVC. L'estrattore deve fornire unità di accesso AVC/HEVC regolari 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 solo frame CSD.

Azioni Dolby

1. Definisci il packaging delle unità di accesso per i vari schemi di contenitori Dolby (ad es. BL+EL+MD) per il decodificatore Dolby astratto (ovvero il formato del buffer previsto dal decodificatore 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. Integra DolbyExtractor nel framework. Il punto di ingresso è frameworks/av/media/libstagefright/MediaExtractor.cpp.
3. Dichiara il tipo OMX del profilo e del livello del decodificatore HDR. Esempio: OMX_VIDEO_DOLBYPROFILETYPE e OMX_VIDEO_DOLBYLEVELTYP.
4. Implementare il supporto per l'indice: 'OMX.google.android.index.describeColorAspects'
5. Propaga i metadati HDR dinamici all'app e alla superficie in ogni frame. In genere, queste informazioni devono essere inserite nel frame decodificato come definito da Dolby, perché lo standard HDMI non fornisce un modo per trasmetterle al display.

Pipeline del decodificatore VP9

Figura 3. Pipeline VP9-PQ

I bitstream VP9 vengono pacchettizzati in contenitori WebM nel 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.

• WebM Extractor:
  • WebM Extractor estrae i metadati HDR e i frame dal contenuto.
• Decodificatore VP9:
  • Il decodificatore riceve i bitstream Profile2 e li decodifica come normali stream VP9.
  • Il decodificatore riceve eventuali 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 per l'indice: OMX.google.android.index.describeHDRColorInfo
2. Implementa il supporto per l'indice: OMX.google.android.index.describeColorAspects
3. Propagare i metadati statici HDR