Riproduzione video HDR

Il video HDR (High Dynamic Range) è la prossima frontiera nella decodifica video di alta qualità, offrendo qualità di riproduzione delle scene senza pari. Lo fa aumentando significativamente la gamma dinamica della componente luminanza (dagli attuali 100 cd/m 2 a 1000 cd/m 2 ) e utilizzando uno spazio colore molto più ampio (BT 2020). Questo è ora 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 riporta i metadati HDR indipendentemente dalla modalità tunnel. È possibile ottenere dati decodificati insieme a metadati statici/dinamici in modalità senza 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 viene segnalato con la chiave KEY_HDR10_PLUS_INFO nel formato di output e può cambiare per ciascun fotogramma di output. Per ulteriori informazioni vedere Tunneling multimediale .

A partire da Android 7.0, il supporto HDR iniziale include la creazione di costanti adeguate per il rilevamento 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 flussi HDR e aiutare gli OEM e i SOC ad abilitare 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 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 decoder senza tunnel.
  • I decoder video con 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 versione AOSP Android 7.0.

Scoperta

La riproduzione HDR richiede un decoder compatibile con HDR e una connessione a un display compatibile con HDR. Opzionalmente, alcune tecnologie richiedono un estrattore specifico.

Schermo

Le applicazioni dovranno utilizzare la nuova API Display.getHdrCapabilities per interrogare le tecnologie HDR supportate dal display specificato. Queste sono fondamentalmente le informazioni nel blocco 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, quali tipi di HDR supporta e 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 di luminanza media del fotogramma massimo del contenuto desiderato in cd/cd/m 2 per questo display.
  • float getDesiredMaxLuminance()
    Restituisce i dati di luminanza massima del contenuto desiderato in cd/cd/m 2 per questo display.
  • float getDesiredMinLuminance()
    Restituisce i dati di luminanza minima del contenuto desiderato in cd/cd/m 2 per questo display.
  • int[] getSupportedHdrTypes()
    Ottiene i tipi HDR supportati da questo display (vedi costanti). Restituisce un array vuoto se l'HDR non è supportato dal display.

Decodificatore

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

Dolby Vision

Costante mima MediaFormat :

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 fotogramma dalle applicazioni video. Ciò viene eseguito automaticamente dal MediaExtractor compatibile con Dolby-Vision.

HEVCHDR10

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 con tunnel possono riprodurre contenuti HDR. La riproduzione da parte di decoder senza tunnel potrebbe comportare la perdita delle informazioni HDR e l'appiattimento del contenuto 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
Contenitore MP4 MP4 WebM WebM

La scoperta se una traccia (di un file) richiede il supporto HDR non è supportata 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 ciascuna tecnologia HDR sono mostrati nella tabella seguente:

Tecnologia Dolby Vision HDR10 VP9-HLG VP9-PQ
Tipo HDR supportato (schermo) HDR_TYPE_DOLBY_VISION HDR_TYPE_HDR10 HDR_TYPE_HLG HDR_TYPE_HDR10
Contenitore (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 VP9Profilo2HDR o VP9Profilo3HDR VP9Profilo2HDR o VP9Profilo3HDR

Appunti:

  • I bitstream Dolby-Vision sono confezionati in un contenitore MP4 in un modo definito da Dolby. Le applicazioni possono implementare i propri estrattori compatibili con Dolby purché impacchettano le unità di accesso dagli strati corrispondenti in una singola unità di accesso per il decodificatore come definito da Dolby.
  • Una piattaforma può supportare un estrattore compatibile con HDR, ma nessun decoder compatibile con HDR corrispondente.

Riproduzione

Dopo che un'applicazione ha verificato il supporto per la riproduzione HDR, può riprodurre contenuti HDR quasi nello stesso modo in cui riproduce contenuti non HDR, con le seguenti avvertenze:

  • Per Dolby-Vision, non è immediatamente disponibile se un file/traccia multimediale specifico richieda o meno un decoder compatibile con HDR. L'applicazione deve disporre di queste informazioni in anticipo o essere in grado di ottenerle analizzando la sezione dati specifica del codec di MediaFormat.
  • CodecCapabilities.isFormatSupported non considera se la funzionalità del decodificatore con tunnel è necessaria per supportare tale profilo.

Abilita il supporto della piattaforma HDR

I fornitori di SoC e gli OEM devono svolgere ulteriore lavoro per abilitare il supporto della piattaforma HDR per un dispositivo.

Modifiche alla piattaforma in Android 7.0 per HDR

Ecco alcune modifiche chiave nella piattaforma (livello app/nativo) di cui OEM e SOC devono essere a conoscenza.

Schermo

Composizione dell'hardware

Le piattaforme compatibili con HDR devono supportare la fusione di contenuti HDR con contenuti non HDR. Le esatte caratteristiche e operazioni di fusione non sono definite da Android a partire dalla versione 7.0, ma il processo generalmente segue questi passaggi:

  1. Determina uno spazio colore/volume lineare che contenga tutti i livelli da comporre, in base al colore dei livelli, alla mastering e ai potenziali metadati dinamici.
    Se si esegue la composizione direttamente su un display, questo potrebbe essere lo spazio lineare che corrisponde al volume di colore del display.
  2. Converti tutti i livelli nello spazio colore comune.
  3. Eseguire la miscelazione.
  4. Se si visualizza tramite HDMI:
    1. Determina il colore, la masterizzazione e i potenziali metadati dinamici per la scena miscelata.
    2. Converti la scena miscelata risultante nello spazio colore/volume derivato.
  5. Se si visualizza direttamente sul display, convertire la scena miscelata risultante nei segnali di visualizzazione richiesti per produrre quella scena.

Visualizza la scoperta

Il rilevamento del display HDR è supportato solo tramite HWC2. Affinché questa funzionalità funzioni, gli implementatori del dispositivo devono abilitare 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 propria funzionalità HDR tramite HDMI EDID come definito nella sezione 4.2 di CTA-861.3 .
  • Sarà utilizzata la seguente mappatura EOTF:
    • ET_0 Gamma tradizionale - Gamma di luminanza SDR: non mappata su nessun tipo HDR
    • ET_1 Gamma tradizionale - Gamma di luminanza HDR: non mappata su nessun tipo HDR
    • ET_2 SMPTE ST 2084: mappato sul tipo HDR HDR10
  • La segnalazione del supporto Dolby Vision o HLG su HDMI viene effettuata come definito dai rispettivi organismi competenti.
  • Tieni presente che l'API HWC2 utilizza valori di luminanza desiderati float, quindi i valori EDID a 8 bit devono essere tradotti in modo adeguato.

Decodificatori

Le piattaforme devono aggiungere decoder tunneled compatibili con HDR e pubblicizzare il proprio supporto HDR. In generale, i decoder compatibili con HDR devono:

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

Supporto per decodificatore Dolby Vision

Per supportare Dolby Vision, le piattaforme devono aggiungere un decoder HDR OMX compatibile con Dolby-Vision. Date le specificità di Dolby Vision, si tratta normalmente di un decoder wrapper attorno a uno o più decoder AVC e/o HEVC, nonché di un compositore. Tali decodificatori devono:

  • Supporta il tipo MIME "video/dolby-vision".
  • Pubblicizzare 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.
  • Accetta dati specifici del codec definiti da Dolby. Ad esempio, dati contenenti profilo/livello Dolby Vision ed eventualmente dati specifici del codec per i decoder interni.
  • Supporta il 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. Ciò avviene 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 fase di configurazione. Se un singolo decoder Dolby Vision supporta entrambi i tipi di profili, deve anche supportare il passaggio tra quelli in modo dinamico in modo adattivo.

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

  • Fornire un estrattore compatibile con Dolby-Vision, anche se non supporta la riproduzione HDR.
  • Fornire un decodificatore che supporti il ​​profilo visivo definito da Dolby.

Supporto per decodificatore HDR10

Per supportare HDR10, le piattaforme devono aggiungere un decoder OMX compatibile con HDR10. Normalmente si tratta di un decoder HEVC con tunnel che supporta anche l'analisi e la gestione dei metadati relativi all'HDMI. Tale decoder (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 mastering, nonché altre informazioni relative all'HDR contenute in SPS.

Supporto per decodificatore VP9

Per supportare VP9 HDR, le piattaforme devono aggiungere un decoder OMX HDR compatibile con VP9 Profile2. Normalmente si tratta di un decoder VP9 con tunnel che supporta anche la gestione dei metadati relativi all'HDMI. Tali decodificatori (oltre al supporto generale del decodificatore 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 per estrattore Dolby Vision

Le piattaforme che supportano i decoder Dolby Vision devono aggiungere il supporto Dolby Extractor (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 di metadati. Quindi è necessario uno speciale estrattore Dolby per estrarre i dati dal file.
  • L'estrattore Dolby deve esporre da 1 a 2 tracce per ciascuna traccia video Dolby (gruppo):
    • Una traccia HDR Dolby Vision con il tipo di "video/dolby-vision" per lo streaming Dolby combinato a 2/3 strati. Il formato dell'unità di accesso della traccia HDR, che definisce come impacchettare le unità di accesso dagli strati di base/miglioramento/metadati in un singolo 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 track-ID univoco ("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 alle capacità della piattaforma.
  • Il profilo/livello Dolby Vision deve essere esposto nel formato traccia 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 estrattori HDR10 e VP9 HDR

Non sono previsti requisiti di estrazione aggiuntivi 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 tale che questi metadati vengano passati al decoder VP9 PQ e al display tramite la normale pipeline MediaExtractor => MediaCodec.

Estensioni Stagefright per il supporto 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 decodificatore DV.
  • Supporta l'esposizione del profilo/livello DV per le tracce DV HDR.

Dettagli di implementazione specifici della tecnologia

Pipeline di decodificatore HDR10

Figura 1. Pipeline HDR10

I bitstream HDR10 sono confezionati in contenitori MP4. Le applicazioni utilizzano un normale estrattore MP4 per estrarre i dati del frame e inviarli al decoder.

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

Azioni del venditore

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

Pipeline di decodificatori Dolby Vision

Figura 2. Pipeline Dolby Vision

I flussi di bit Dolby sono confezionati in contenitori MP4 come definito da Dolby. Le applicazioni potrebbero, in teoria, utilizzare un normale estrattore MP4 per estrarre il livello di base, il livello di miglioramento e il livello di metadati in modo indipendente; tuttavia, questo non è adatto all'attuale modello Android MediaExtractor/MediaCodec.

  • DolbyExtractor:
    • I bitstream Dolby vengono riconosciuti da un DolbyExtractor, che espone i vari strati come da 1 a 2 tracce per ciascuna traccia video Dolby (gruppo):
      • Una traccia HDR con il tipo "video/dolby-vision" per il dolby stream combinato a 2/3 strati. Il formato dell'unità di accesso della traccia HDR, che definisce come impacchettare le unità di accesso dagli strati di base/miglioramento/metadati in un singolo buffer da decodificare in un singolo fotogramma HDR, deve essere definito da Dolby.
      • (Facoltativo, solo se 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 dovrebbe fornire unità di accesso AVC/HEVC regolari per questa traccia. Questa traccia BL deve avere lo stesso ID traccia univoco ("ID traccia") 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 alle capacità della piattaforma.
    • Poiché una traccia HDR ha un tipo HDR specifico, il sistema selezionerà un decodificatore video Dolby per decodificare quella traccia. La traccia BL verrà decodificata da un normale decoder video AVC/HEVC.
  • Decodificatore Dolby:
    • Il 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, come SPS+PPS+VPS) per i singoli livelli possono essere raggruppate in 1 frame CSD che sarà definito da Dolby. È necessario disporre di un singolo frame CSD.

Azioni Dolby

  1. Definire il confezionamento delle unità di accesso per i vari schemi contenitore Dolby (ad esempio BL+EL+MD) per il decodificatore Dolby astratto (ovvero il formato buffer previsto dal decodificatore HDR).
  2. Definire il packaging di CSD per il decodificatore Dolby astratto.

Azioni del venditore

  1. Implementa l'estrattore Dolby. Questo può essere fatto anche da Dolby.
  2. Integra DolbyExtractor nel framework. Il punto di ingresso è frameworks/av/media/libstagefright/MediaExtractor.cpp .
  3. Dichiarare 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 nell'app e vengono visualizzati in ogni fotogramma. In genere queste informazioni devono essere inserite nel frame decodificato come definito da Dolby, poiché lo standard HDMI non fornisce un modo per trasmetterle al display.

Pipeline del decodificatore VP9

Figura 3. Conduttura VP9-PQ

I bitstream VP9 sono confezionati in contenitori WebM in un modo definito dal team WebM. Le applicazioni devono utilizzare un estrattore WebM per estrarre i metadati HDR dal flusso di bit prima di inviare frame al decoder.

  • Estrattore WebM:
  • Decodificatore VP9:
    • Il decodificatore riceve i bitstream Profile2 e li decodifica come normali flussi VP9.
    • Il decoder riceve tutti i metadati statici HDR dal framework.
    • Il decodificatore riceve metadati statici tramite le unità di accesso bitstream per flussi VP9 PQ.
    • Il decoder VP9 deve essere in grado di propagare i metadati statici/dinamici HDR sul display.

Azioni del venditore

  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