I video HDR (High Dynamic Range) rappresentano la nuova frontiera della decodifica video di alta qualità, offrendo una riproduzione delle scene senza precedenti. Lo fa aumentando significativamente la gamma dinamica del componente di luminanza (dalle attuali 100 cd/m2 a migliaia di cd/m2) e utilizzando uno spazio colore molto più ampio (BT 2020). Ora è un elemento centrale dell'evoluzione dell'UHD 4K nel settore delle 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à tunnel.
Puoi ottenere i dati decodificati insieme ai metadati statici/dinamici in modalità non sottoposta a 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, questo valore viene segnalato con
la chiave KEY_HDR10_PLUS_INFO
nel formato di output e può 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 l'individuazione e la configurazione di pipeline video HDR. Ciò significa definire i tipi di codec e le modalità di visualizzazione e specificare come i dati HDR devono essere passati a MediaCodec e forniti ai decoder HDR.
Lo scopo di questo documento è aiutare gli sviluppatori di applicazioni a supportare la riproduzione di stream HDR e aiutare gli OEM e i SOC ad 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 HDR su SurfaceView utilizzando buffer video opachi. In altre parole:
- Non esiste un'API Android standard per verificare se la riproduzione HDR è supportata utilizzando decoder non in modalità tunnel.
- I decoder 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 decoder compatibile con HDR e una connessione a un display compatibile con HDR. Facoltativamente, alcune tecnologie richiedono un estrattore specifico.
Visualizzazione
Le applicazioni devono utilizzare la nuova API Display.getHdrCapabilities
per eseguire query sulle tecnologie HDR supportate dal display specificato. Si tratta
essenzialmente delle informazioni nel blocco di dati dei metadati statici EDID come definito
in 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 di Dolby Vision.int HDR_TYPE_HDR10
Supporto HDR10 / PQ.int HDR_TYPE_HDR10_PLUS
Supporto HDR10+.int HDR_TYPE_HLG
Supporto di Hybrid Log-Gamma.float INVALID_LUMINANCE
Valore di luminanza non valido.
Metodi pubblici:
float getDesiredMaxAverageLuminance()
Restituisce i dati di luminanza media dei frame massimi dei contenuti desiderati in cd/m2 per questo display.float getDesiredMaxLuminance()
Restituisce i dati di luminanza massima dei contenuti desiderati in cd/cd/m2 per questo display.float getDesiredMinLuminance()
Restituisce i dati di luminanza minima dei contenuti desiderati in cd/cd/m2 per questo display.int[] getSupportedHdrTypes()
Restituisce i tipi di 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
mime constant:
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 unico 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 l'HDR, deve supportare anche un estrattore compatibile con l'HDR.
Solo i decoder con tunneling garantiscono la riproduzione di contenuti HDR. La riproduzione da parte di decoder non in tunnel può 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 il rilevamento se una traccia (di un file) richiede il supporto HDR. 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 | 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 (decoder) | Uno dei profili Dolby | HEVCProfileMain10HDR10 | VP9Profile2HDR o VP9Profile3HDR | VP9Profile2HDR o VP9Profile3HDR |
Note:
- I bitstream Dolby Vision sono inclusi in un contenitore MP4 in un modo definito da Dolby. Le applicazioni possono implementare i propri estrattori compatibili con Dolby, a condizione che raggruppino 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 estrattore compatibile con l'HDR, ma non un decodificatore compatibile con l'HDR.
Riproduzione
Dopo che un'applicazione ha verificato il supporto della riproduzione HDR, può riprodurre contenuti HDR quasi allo stesso modo in cui riproduce contenuti non HDR, con le seguenti avvertenze:
- Per Dolby Vision, la necessità o meno di un decoder compatibile con HDR per un file/traccia multimediale specifico non è immediatamente disponibile. L'applicazione deve disporre di queste informazioni in anticipo o essere in grado di ottenerle analizzando la sezione dei dati specifici del codec di MediaFormat.
CodecCapabilities.isFormatSupported
non considera se la funzionalità di decodifica in tunnel è necessaria per supportare un profilo di questo tipo.
Attivare il supporto della piattaforma HDR
I fornitori di SoC e gli OEM devono svolgere un lavoro aggiuntivo per abilitare 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 nella piattaforma (livello app/nativo) di cui OEM e SOC devono essere a conoscenza.
Visualizzazione
Composizione dell'hardware
Le piattaforme compatibili con HDR devono supportare la combinazione di contenuti HDR e non HDR. Le caratteristiche e le operazioni di fusione esatte non sono definite da Android a partire dalla versione 7.0, ma il processo in genere segue questi passaggi:
- Determina uno spazio/volume colore 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, questo potrebbe essere lo spazio lineare che corrisponde al volume di colore del display. - Converti tutti i livelli nello spazio colore comune.
- Esegui la fusione.
- Se la visualizzazione avviene tramite HDMI:
- Determina il colore, la masterizzazione e i potenziali metadati dinamici per la scena combinata.
- Converti la scena mista risultante nello spazio/volume colore derivato.
- Se la visualizzazione avviene direttamente sul display, converti la scena mista risultante nei segnali di visualizzazione richiesti per produrre la scena.
Display discovery
Il rilevamento del display HDR è supportato solo tramite HWC2. Per il funzionamento di questa funzionalità, gli implementatori di dispositivi devono attivare selettivamente 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 HDMI EDID 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 su alcun tipo di HDR
- ET_1 Traditional gamma - HDR Luminance Range: not mapped to any HDR type
- ET_2 SMPTE ST 2084 - mapped to HDR type HDR10
- La segnalazione del supporto Dolby Vision o HLG tramite HDMI viene eseguita come definito dai rispettivi enti.
- 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 modo appropriato.
Decoder
Le piattaforme devono aggiungere decoder con tunneling compatibili con HDR e pubblicizzare il 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/hardware. Per HLG, al display devono essere inviati metadati appropriati. - Supporta la descrizione del colore
(
OMX.google.android.index.describeColorAspects
) e la sua propagazione alla composizione del display/hardware. - Supportare i metadati incorporati HDR come definito dallo standard pertinente.
Supporto del decoder Dolby Vision
Per supportare Dolby Vision, le piattaforme devono aggiungere un decoder HDR OMX compatibile con Dolby Vision. Date le specifiche di Dolby Vision, si tratta in genere di un decoder wrapper intorno a uno o più decoder AVC e/o HEVC, nonché di un compositor. Questi decoder devono:
- Supporta il tipo MIME "video/dolby-vision".
- Pubblicizza i profili/livelli Dolby Vision supportati.
- Accetta le 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 possibilmente i dati specifici del codec per i decoder interni.
- Supporto del passaggio adattivo tra profili/livelli Dolby Vision come richiesto da Dolby.
Durante la configurazione del decoder, il profilo Dolby effettivo non viene comunicato al codec. Questa operazione viene eseguita solo tramite dati specifici del codec dopo l'avvio del decoder. Una piattaforma potrebbe scegliere di supportare più decoder 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 decoder Dolby Vision supporta entrambi i tipi di profili, deve anche supportare il passaggio dinamico tra questi in modo adattivo.
Se una piattaforma fornisce un decoder compatibile con Dolby Vision oltre al supporto generale del decoder HDR, deve:
- Fornisci un estrattore compatibile con Dolby Vision, anche se non supporta la riproduzione HDR.
- Fornisci un decoder che supporti il profilo visivo definito da Dolby.
Supporto del decoder HDR10
Per supportare HDR10, le piattaforme devono aggiungere un decoder OMX compatibile con HDR10. Si tratta normalmente di un decoder HEVC in tunnel che supporta anche l'analisi e la gestione dei metadati correlati a HDMI. Un decoder di questo tipo (oltre al supporto generale del decoder HDR) deve:
- Supporta il tipo MIME "video/hevc".
- Pubblicizza HEVCMain10HDR10 supportato. Il supporto del profilo HEVCMain10HRD10 richiede anche il supporto del profilo HEVCMain10, che a sua volta richiede il supporto del profilo HEVCMain agli stessi livelli.
- Supporta l'analisi dei blocchi SEI dei metadati di masterizzazione, nonché di altre informazioni relative all'HDR contenute in SPS.
Supporto del decodificatore VP9
Per supportare VP9 HDR, le piattaforme devono aggiungere un decoder OMX HDR compatibile con VP9 Profile2. Si tratta in genere di un decoder VP9 con tunneling che supporta anche la gestione dei metadati correlati a HDMI. Questi decoder (oltre al supporto generale del decoder HDR) devono:
- Supporto del 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 decoder Dolby Vision devono aggiungere il supporto dell'estrattore Dolby (chiamato Dolby Extractor) per i contenuti video Dolby.
- Un estrattore MP4 normale può estrarre solo il livello di base da un file, ma non i livelli di miglioramento o metadati. Pertanto, è necessario 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 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 raggruppare le unità di accesso dei livelli base/miglioramento/metadati in un unico buffer da decodificare in un singolo fotogramma HDR, deve essere definito da Dolby.
- Se una traccia video Dolby Vision contiene un base-layer (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 regolari per questa traccia.
- La traccia BL deve avere lo stesso ID univoco traccia ("track-ID") della traccia HDR, in modo che l'app comprenda che si tratta di due codifiche dello stesso video.
- L'applicazione può decidere quale traccia scegliere in base alla funzionalità della piattaforma.
- Il profilo/livello Dolby Vision deve essere esposto nel formato della traccia HDR.
- Se una piattaforma fornisce un decoder compatibile con Dolby Vision, deve fornire anche un estrattore compatibile con Dolby Vision, anche se non supporta la riproduzione HDR.
Supporto per l'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 bitstream VP9 PQ, in modo che questi metadati vengano passati 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 di profili/livelli per il decodificatore DV.
- Supporta l'esposizione del profilo/livello DV per le tracce HDR DV.
Dettagli di implementazione specifici per la tecnologia
Pipeline del decodificatore HDR10
Figura 1. Pipeline HDR10
I bitstream HDR10 sono pacchettizzati in contenitori MP4. Le applicazioni utilizzano un estrattore MP4 standard per estrarre i dati dei frame e inviarli al decodificatore.
- Estrattore MPEG4
I bitstream HDR10 vengono riconosciuti come un normale stream HEVC da un estrattore MPEG4 e la traccia HDR di tipo "video/HEVC" verrà estratta. Il framework sceglie un decoder video HEVC che supporta il profilo Main10HDR10 per decodificare la traccia. - Decodificatore HEVC
Le informazioni HDR si trovano in SEI o SPS. Il decodificatore HEVC riceve prima 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 sono raggruppate nel formato di output del decodificatore, che viene propagato alla superficie in un secondo momento.
Azioni del fornitore
- Pubblicizza il tipo e il livello OMX del profilo del decodificatore HDR supportato. Esempio:
OMX_VIDEO_HEVCProfileMain10HDR10
(eMain10
) - Implementa il supporto per index:
'
OMX.google.android.index.describeHDRColorInfo
' - Implementa il supporto per index:
'
OMX.google.android.index.describeColorAspects
' - Implementa il supporto per l'analisi SEI dei metadati di masterizzazione.
Pipeline del decoder Dolby Vision
Figura 2. Pipeline Dolby Vision
I bitstream Dolby sono inclusi in container MP4 come definito da Dolby. In teoria, le applicazioni potrebbero utilizzare un estrattore MP4 standard per estrarre il livello di base, il livello di miglioramento e il livello di metadati in modo indipendente; tuttavia, questo non è compatibile con l'attuale modello Android MediaExtractor/MediaCodec.
- DolbyExtractor:
- I bitstream Dolby vengono riconosciuti da un DolbyExtractor, che espone
i vari livelli come 1-2 tracce per ogni traccia video (gruppo) Dolby:
- 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 raggruppare le unità di accesso dei livelli di base/miglioramento/metadati in un unico buffer da decodificare in un singolo fotogramma 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 regolari per questa traccia. Questa traccia BL deve avere lo stesso ID univoco della traccia ("track-ID") della traccia Dolby, in modo che l'applicazione comprenda che si tratta di due codifiche dello stesso video.
- L'applicazione può decidere quale traccia scegliere in base alla funzionalità della piattaforma.
- Poiché una traccia HDR ha un tipo HDR specifico, il framework sceglierà un decoder video Dolby per decodificare la traccia. La traccia BL verrà decodificata da un normale decoder video AVC/HEVC.
- I bitstream Dolby vengono riconosciuti da un DolbyExtractor, che espone
i vari livelli come 1-2 tracce per ogni traccia video (gruppo) Dolby:
- DolbyDecoder:
- DolbyDecoder riceve unità di accesso che contengono le unità di accesso richieste per tutti i livelli (EL+BL+MD o BL+MD)
- Le informazioni CSD (dati specifici del codec, ad esempio SPS+PPS+VPS) per i singoli livelli possono essere raggruppate in un unico frame CSD da definire da Dolby. È necessario un singolo frame CSD.
Azioni Dolby
- Definisci il packaging delle unità di accesso per i vari schemi di contenitori Dolby (ad es. BL+EL+MD) per il decoder Dolby astratto (ovvero il formato del buffer previsto dal decoder HDR).
- Definisci il packaging di CSD per il decodificatore Dolby astratto.
Azioni del fornitore
- Implementa l'estrattore Dolby. Puoi anche rivolgerti a Dolby.
- Integra DolbyExtractor nel framework. Il punto di ingresso è
frameworks/av/media/libstagefright/MediaExtractor.cpp
. - Dichiara il profilo e il livello del decodificatore HDR
tipo OMX. Esempio:
OMX_VIDEO_DOLBYPROFILETYPE
eOMX_VIDEO_DOLBYLEVELTYP
. - Implementa il supporto per l'indice:
'OMX.google.android.index.describeColorAspects
' - Propaga i metadati HDR dinamici all'app e alla superficie in ogni frame. In genere, queste informazioni devono essere incluse nel frame decodificato come definito da Dolby, perché lo standard HDMI non prevede un modo per trasmetterle al display.
Pipeline del decodificatore VP9
Figura 3. Pipeline VP9-PQ
I bitstream VP9 vengono pacchettizzati in container WebM in un modo definito dal team WebM. Le applicazioni devono utilizzare un estrattore WebM per estrarre i metadati HDR dal bitstream prima di inviare i frame al decodificatore.
- WebM Extractor:
- VP9 Decoder:
- 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 metadati statici tramite le unità di accesso al bitstream per i flussi PQ VP9.
- Il decodificatore VP9 deve essere in grado di propagare i metadati statici/dinamici HDR al display.
Azioni del fornitore
- Implementa il supporto per l'indice:
OMX.google.android.index.describeHDRColorInfo
- Implementa il supporto per l'indice:
OMX.google.android.index.describeColorAspects
- Propaga i metadati statici HDR