Lecture de vidéos HDR

La vidéo HDR (High Dynamic Range) est la prochaine étape du décodage vidéo haute qualité, offrant une qualité de reproduction des scènes inégalée. Pour ce faire, il augmente considérablement la plage dynamique du composant de luminance (de 100 cd/m² actuellement à 1 000 cd/m²) et utilise un espace de couleur beaucoup plus large (BT 2020). Il s'agit désormais d'un élément central de l'évolution de la technologie UHD 4K dans le secteur de la télévision.

Android 10 est compatible avec les vidéos HDR suivantes.

• HDR10
• VP9
• HDR10+

À partir d'Android 9 et versions ultérieures, MediaCodec signale les métadonnées HDR, quel que soit le mode de tunnelisation. Vous pouvez obtenir des données décodées avec des métadonnées statiques/dynamiques en mode non tunnelisé. Pour HDR10 et VP9Profile2 qui utilisent des métadonnées statiques, elles sont indiquées au format de sortie avec la clé KEY_HDR_STATIC_INFO. Pour le HDR10+ qui utilise des métadonnées dynamiques, cela est signalé avec la clé KEY_HDR10_PLUS_INFO sur le format de sortie et peut changer pour chaque frame de sortie. Pour en savoir plus, consultez la section Tunneling multimédia.

Depuis Android 7.0, la prise en charge initiale du HDR inclut la création de constantes appropriées pour la découverte et la configuration des pipelines vidéo HDR. Cela implique de définir des types de codecs et des modes d'affichage, et de spécifier comment les données HDR doivent être transmises à MediaCodec et fournies aux décodeurs HDR.

L'objectif de ce document est d'aider les développeurs d'applications à prendre en charge la lecture de flux HDR, et d'aider les OEM et les SOC à activer les fonctionnalités HDR.

Technologies HDR compatibles

À partir d'Android 7.0, les technologies HDR suivantes sont prises en charge.

Technologie	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Codec	AVC/HEVC	HEVC	VP9	VP9
Fonction de transfert	ST-2084	ST-2084	HLG	ST-2084
Type de métadonnées HDR	Dynamique	Statique	Aucune	Statique

Dans Android 7.0, seule la lecture HDR via le mode tunnel est définie, mais les appareils peuvent prendre en charge la lecture HDR sur SurfaceViews à l'aide de tampons vidéo opaques. Autrement dit :

• Il n'existe aucune API Android standard pour vérifier si la lecture HDR est prise en charge à l'aide de décodeurs non en tunnel.
• Les décodeurs vidéo tunnelisés qui annoncent la fonctionnalité de lecture HDR doivent être compatibles avec la lecture HDR lorsqu'ils sont connectés à des écrans compatibles HDR.
• La composition GL du contenu HDR n'est pas compatible avec la version Android 7.0 d'AOSP.

Découverte

La lecture HDR nécessite un décodeur compatible HDR et une connexion à un écran compatible HDR. Certaines technologies nécessitent éventuellement un extracteur spécifique.

Écran

Les applications doivent utiliser la nouvelle API Display.getHdrCapabilities pour interroger les technologies HDR compatibles avec l'écran spécifié. Il s'agit essentiellement des informations du bloc de données de métadonnées statiques EDID telles que définies dans CTA-861.3:

• public Display.HdrCapabilities getHdrCapabilities()
  Renvoie les fonctionnalités HDR de l'écran.
• Display.HdrCapabilities
  Encapsule les fonctionnalités HDR d'un écran donné. Par exemple, les types de HDR compatibles et les détails sur les données de luminance souhaitées.

Constantes:

• int HDR_TYPE_DOLBY_VISION
  Compatibilité avec Dolby Vision.
• int HDR_TYPE_HDR10
  Compatibilité HDR10 / PQ.
• int HDR_TYPE_HDR10_PLUS
  Compatibilité HDR10+.
• int HDR_TYPE_HLG
  Compatibilité avec la conversion Log-Gamma hybride.
• float INVALID_LUMINANCE
  Valeur de luminance non valide.

Méthodes publiques :

• float getDesiredMaxAverageLuminance()
  Renvoie les données de luminance moyenne de frame maximale du contenu souhaité en cd/cd/m² pour cet écran.
• float getDesiredMaxLuminance()
  Renvoie les données de luminance maximale du contenu souhaité en cd/cd/m² pour cet écran.
• float getDesiredMinLuminance()
  Renvoie les données de luminance minimale du contenu souhaité en cd/cd/m² pour cet écran.
• int[] getSupportedHdrTypes()
  Récupère les types HDR compatibles avec cet écran (voir les constantes). Renvoie un tableau vide si le HDR n'est pas compatible avec l'écran.

Décodeur

Les applications doivent utiliser l'API CodecCapabilities.profileLevels existante pour vérifier la prise en charge des nouveaux profils compatibles avec le HDR :

Dolby Vision

Constante MIME MediaFormat:

String MIMETYPE_VIDEO_DOLBY_VISION

Constantes de profil MediaCodecInfo.CodecProfileLevel :

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

Les couches vidéo et les métadonnées Dolby Vision doivent être concaténées dans un seul tampon par image par les applications vidéo. Cette opération est effectuée automatiquement par MediaExtractor, compatible avec Dolby Vision.

HEVC HDR 10

Constantes de profil MediaCodecInfo.CodecProfileLevel :

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG et PQ

Constantes de profil MediaCodecInfo.CodecProfileLevel:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Si une plate-forme est compatible avec un décodeur compatible avec la technologie HDR, elle doit également être compatible avec un extracteur compatible avec la technologie HDR.

Seuls les décodeurs tunnellisent à lire du contenu HDR. La lecture par des décodeurs non tunnelisés peut entraîner la perte des informations HDR et l'aplatissement du contenu en un volume de couleurs SDR.

Extracteur

Les conteneurs suivants sont compatibles avec les différentes technologies HDR sur Android 7.0:

Technologie	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Conteneur	MP4	MP4	WebM	WebM

La plate-forme ne permet pas de déterminer si un titre (d'un fichier) nécessite la compatibilité HDR. Les applications peuvent analyser les données spécifiques au codec pour déterminer si une piste nécessite un profil HDR spécifique.

Résumé

Les exigences concernant les composants pour chaque technologie HDR sont indiquées dans le tableau suivant :

Remarques :

• Les flux de bits Dolby-Vision sont empaquetés dans un conteneur MP4 de la manière définie par Dolby. Les applications peuvent implémenter leurs propres extracteurs compatibles avec Dolby, à condition de regrouper les unités d'accès des couches correspondantes dans une seule unité d'accès pour le décodeur, comme défini par Dolby.
• Une plate-forme peut prendre en charge un extracteur compatible avec le HDR, mais pas de décodeur compatible avec le HDR correspondant.

Lecture

Une fois qu'une application a vérifié la compatibilité avec la lecture HDR, elle peut lire du contenu HDR quasiment de la même manière que du contenu non HDR, avec les mises en garde suivantes:

• Pour Dolby Vision, il n'est pas immédiatement possible de savoir si un fichier/un titre multimédia spécifique nécessite un décodeur compatible avec le HDR. L'application doit disposer de ces informations à l'avance ou être en mesure de les obtenir en analysant la section de données spécifique au codec du MediaFormat.
• CodecCapabilities.isFormatSupported ne vérifie pas si la fonctionnalité de décodeur en tunnel est requise pour prendre en charge un tel profil.

Activer la compatibilité avec la plate-forme HDR

Les fournisseurs de SoC et les OEM doivent effectuer des tâches supplémentaires pour permettre la prise en charge de la plate-forme HDR sur un appareil.

Modifications apportées à la plate-forme sur Android 7.0 pour la technologie HDR

Voici quelques modifications clés de la plate-forme (couche application/native) que les OEM et les SOC doivent connaître.

Écran

Composition matérielle

Les plates-formes compatibles HDR doivent permettre de mélanger des contenus HDR avec des contenus non HDR. Les caractéristiques et les opérations de mélange exactes ne sont pas définies par Android à partir de la version 7.0, mais le processus suit généralement les étapes suivantes :

1. Déterminez un espace colorimétrique/volume linéaire contenant toutes les couches à composer, en fonction de leur couleur, de leur master et de leurs éventuelles métadonnées dynamiques.
   Si la composition est effectuée directement sur un écran, il peut s'agir de l'espace linéaire correspondant au volume de couleurs de l'écran.
2. Convertissez toutes les couches dans l'espace colorimétrique commun.
3. Effectuez la combinaison.
4. Si l'affichage se fait via HDMI :
   1. Déterminez la couleur, le mastering et les métadonnées dynamiques potentielles de la scène mélangée.
   2. Convertissez la scène fusionnée obtenue en l'espace de couleurs/volume dérivé.
5. Si vous l'affichez directement sur l'écran, convertissez la scène combinée obtenue en signaux d'affichage requis pour produire cette scène.

Détection d'écrans

La découverte d'écrans HDR n'est compatible qu'avec HWC2. Les implémentateurs d'appareils doivent activer de manière sélective l'adaptateur HWC2 fourni avec Android 7.0 pour que cette fonctionnalité fonctionne. Par conséquent, les plates-formes doivent prendre en charge HWC2 ou étendre le framework AOSP pour permettre de fournir ces informations. HWC2 expose une nouvelle API pour propager les données statiques HDR au framework et à l'application.

HDMI

• Un écran HDMI connecté annonce sa capacité HDR via l'EDID HDMI, comme défini dans la section 4.2 de la norme CTA-861.3.
• Le mappage EOTF suivant doit être utilisé :
  • ET_0 Gamme traditionnelle – Plage de luminosité SDR: non mappée sur aucun type de HDR
  • ET_1 Gamme traditionnelle – Plage de luminosité HDR: non mappée sur un type de HDR
  • ET_2 SMPTE ST 2084 : mappé sur le type HDR HDR10
• La signalisation de la compatibilité Dolby Vision ou HLG via HDMI est effectuée comme défini par les organismes compétents.
• Notez que l'API HWC2 utilise les valeurs de luminance souhaitées à virgule flottante. Les valeurs EDID 8 bits doivent donc être traduites de manière appropriée.

Décodeurs

Les plates-formes doivent ajouter des décodeurs en tunnel compatibles avec le HDR et annoncer leur compatibilité avec le HDR. En général, les décodeurs compatibles HDR doivent:

• Prise en charge du décodage en tunnel (FEATURE_TunneledPlayback).
• Prise en charge des métadonnées statiques HDR (OMX.google.android.index.describeHDRColorInfo) et de leur propagation vers la composition de l'écran/du matériel. Pour HLG, des métadonnées appropriées doivent être envoyées à l'écran.
• Prise en charge de la description de la couleur (OMX.google.android.index.describeColorAspects) et de sa propagation vers la composition d'affichage/matériel.
• Prise en charge des métadonnées intégrées HDR telles que définies par la norme applicable.

Compatibilité avec le décodeur Dolby Vision

Pour être compatibles avec Dolby Vision, les plates-formes doivent ajouter un décodeur OMX HDR compatible avec Dolby Vision. Compte tenu des spécificités de Dolby Vision, il s'agit généralement d'un décodeur encapsulant autour d'un ou plusieurs décodeurs AVC et/ou HEVC, ainsi que d'un compositeur. Ces décodeurs doivent:

• Prise en charge du type MIME "video/dolby-vision".
• Annoncez les profils/niveaux Dolby Vision compatibles.
• Acceptez les unités d'accès contenant les sous-unités d'accès de toutes les couches, telles que définies par Dolby.
• Accepte les données spécifiques au codec définies par Dolby. Par exemple, les données contenant le profil/niveau Dolby Vision et éventuellement les données spécifiques au codec pour les décodeurs internes.
• Prise en charge du basculement adaptatif entre les profils/niveaux Dolby Vision, comme l'exige Dolby.

Lors de la configuration du décodeur, le profil Dolby réel n'est pas communiqué au codec. Cela ne se fait que via des données spécifiques au codec après le démarrage du décodeur. Une plate-forme peut choisir de prendre en charge plusieurs décodeur Dolby Vision : un pour les profils AVC et un autre pour les profils HEVC afin de pouvoir initialiser les codecs sous-jacents au moment de la configuration. Si un seul décodeur Dolby Vision est compatible avec les deux types de profils, il doit également pouvoir basculer entre ceux-ci de manière dynamique de manière adaptative.

Si une plate-forme fournit un décodeur compatible avec Dolby Vision en plus de la compatibilité générale du décodeur HDR, elle doit :

• Fournissez un extracteur compatible avec Dolby Vision, même s'il n'est pas compatible avec la lecture HDR.
• Fournissez un décodeur compatible avec le profil Vision tel que défini par Dolby.

Compatibilité avec le décodeur HDR10

Pour être compatibles avec le format HDR10, les plates-formes doivent ajouter un décodeur OMX compatible avec ce format. Il s'agit généralement d'un décodeur HEVC en tunnel qui prend également en charge l'analyse et la gestion des métadonnées liées à HDMI. Un décodeur de ce type (en plus de la prise en charge générale du décodeur HDR) doit:

• Prise en charge du type MIME "video/hevc".
• Annoncez une clé HEVCMain10HDR10 compatible. La prise en charge du profil HEVCMain10HRD10 nécessite également la prise en charge du profil HEVCMain10, qui nécessite la prise en charge du profil HEVCMain aux mêmes niveaux.
• Prise en charge de l'analyse des blocs SEI de métadonnées de masterisation, ainsi que d'autres informations liées au HDR contenues dans le SPS.

Compatibilité avec le décodeur VP9

Pour prendre en charge le VP9 HDR, les plates-formes doivent ajouter un décodeur OMX HDR VP9 compatible Profile2. Il s'agit généralement d'un décodeur VP9 en tunnel qui prend également en charge la gestion des métadonnées liées à HDMI. Ces décodeurs (en plus de la prise en charge générale du décodeur HDR) doivent :

• Prise en charge du type mime "video/x-vnd.on2.vp9."
• Annoncer le VP9Profile2HDR compatible La prise en charge du profil VP9Profile2HDR nécessite également la prise en charge du profil VP9Profile2 de même niveau.

Extracteurs

Compatibilité avec les extracteurs Dolby Vision

Les plates-formes compatibles avec les décodeurs Dolby Vision doivent ajouter la compatibilité avec l'extracteur Dolby (appelé "Dolby Extractor") pour les contenus Dolby Video.

• Un extracteur MP4 standard ne peut extraire que la couche de base d'un fichier, mais pas les couches d'amélioration ni les métadonnées. Un extracteur Dolby spécial est donc nécessaire pour extraire les données du fichier.
• L'extracteur Dolby doit exposer une à deux pistes pour chaque piste vidéo Dolby (groupe) :
  • Piste Dolby Vision HDR avec le type "video/dolby-vision" pour le flux Dolby combiné à deux ou trois couches. Le format d'unité d'accès de la piste HDR, qui définit comment empaqueter les unités d'accès des couches de base/amélioration/métadonnées dans un seul tampon à décoder dans un seul frame HDR, doit être défini par Dolby.
  • Si une piste vidéo Dolby Vision contient une couche de base (BL) distincte (compatible rétroactivement), l'extracteur doit également l'exposer en tant que piste "video/avc" ou "video/hevc" distincte. L'extracteur doit fournir des unités d'accès AVC/HEVC régulières pour ce canal.
  • La piste BL doit avoir le même track-unique-ID ("track-ID") que la piste HDR pour que l'application comprenne qu'il s'agit de deux encodages de la même vidéo.
  • L'application peut choisir le canal en fonction des fonctionnalités de la plate-forme.
• Le profil/niveau Dolby Vision doit être exposé dans le format de la piste HDR.
• Si une plate-forme fournit un décodeur compatible avec Dolby Vision, elle doit également fournir un extracteur compatible avec Dolby Vision, même si elle n'est pas compatible avec la lecture HDR.

Compatibilité avec l'extracteur HDR10 et HDR VP9

Aucune configuration supplémentaire n'est requise concernant les extracteurs pour la compatibilité avec les formats HDR10 ou VP9. Les plates-formes doivent étendre l'extracteur MP4 pour prendre en charge le format VP9 PQ au format MP4. Les métadonnées statiques HDR doivent être propagées dans le flux de bits VP9 PQ, de sorte que ces métadonnées soient transmises au décodeur VP9 PQ et à l'écran via le pipeline MediaExtractor => MediaCodec normal.

Extensions Stagefright pour la compatibilité avec Dolby Vision

Les plates-formes doivent ajouter la prise en charge du format Dolby Vision à Stagefright :

• Prise en charge de la requête de définition de port pour un port compressé.
• Prise en charge de l'énumération de profils/niveaux pour le décodeur DV.
• Prise en charge de l'affichage du profil/niveau DV pour les canaux DV HDR.

Détails de l'implémentation spécifique à chaque technologie

Pipeline du décodeur HDR10

Figure 1 : Pipeline HDR10

Les flux de bits HDR10 sont empaquetés dans des conteneurs MP4. Les applications utilisent un extracteur MP4 standard pour extraire les données de la trame et les envoyer au décodeur.

• MPEG4 Extractor
  Les flux de bits HDR10 sont reconnus comme un flux HEVC normal par un MPEG4Extractor, et la piste HDR avec le type "video/HEVC" est extraite. Le framework sélectionne un décodeur vidéo HEVC compatible avec le profil Main10HDR10 pour décoder cette piste.
• Décodeur HEVC
  Les informations HDR se trouvent dans les SEI ou les SPS. Le décodeur HEVC reçoit d'abord des images contenant les informations HDR. Le décodeur extrait ensuite les informations HDR et informe l'application qu'elle décoder une vidéo HDR. Les informations HDR sont regroupées dans le format de sortie du décodeur, qui est ensuite propagé à la surface.

Actions des fournisseurs

1. Annoncer le profil de décodeur HDR compatible et le type OMX de niveau. Exemple :
   OMX_VIDEO_HEVCProfileMain10HDR10 (et Main10)
2. Implémentation de la prise en charge de l'index : OMX.google.android.index.describeHDRColorInfo
3. Implémentation de la prise en charge de l'index : OMX.google.android.index.describeColorAspects
4. Implémentation de la prise en charge de l'analyse SEI des métadonnées de mastering.

Pipeline du décodeur Dolby Vision

Figure 2. Pipeline Dolby Vision

Les flux de bits Dolby sont empaquetés dans des conteneurs MP4, comme défini par Dolby. En théorie, les applications peuvent utiliser un extracteur MP4 standard pour extraire la couche de base, la couche d'amélioration et la couche de métadonnées indépendamment. Toutefois, cela ne correspond pas au modèle MediaExtractor/MediaCodec actuel d'Android.

• DolbyExtractor:
  • Les Dolby-bitstream sont reconnus par un DolbyExtractor, qui expose les différentes couches sous la forme d'une à deux pistes pour chaque piste vidéo (groupe) :
    • Piste HDR avec le type "video/dolby-vision" pour le flux Dolby combiné à deux ou trois couches. Le format d'unité d'accès de la piste HDR, qui définit comment empaqueter les unités d'accès des couches de base/amélioration/métadonnées dans un seul tampon à décoder dans un seul frame HDR, doit être défini par Dolby.
    • (Facultatif, uniquement si la piste BL est rétrocompatible) Une piste BL ne contient que la couche de base, qui doit pouvoir être décodée par un décodeur MediaCodec standard, par exemple un décodeur AVC/HEVC. L'extracteur doit fournir des unités d'accès AVC/HEVC régulières pour ce canal. Cette piste BL doit avoir le même track-unique-ID ("track-ID") que la piste Dolby pour que l'application comprenne qu'il s'agit de deux encodages de la même vidéo.
  • L'application peut choisir le canal en fonction des fonctionnalités de la plate-forme.
  • Étant donné qu'un canal HDR possède un type HDR spécifique, le framework sélectionne un décodeur vidéo Dolby pour le décoder. La piste BL sera décodée par un décodeur vidéo AVC/HEVC standard.
• DolbyDecoder:
  • Le DolbyDecoder reçoit des unités d'accès contenant les unités d'accès requises pour toutes les couches (EL+BL+MD ou BL+MD).
  • Les informations CSD (données spécifiques au codec, telles que SPS+PPS+VPS) pour les couches individuelles peuvent être empaquetées dans un seul frame CSD à définir par Dolby. Vous devez disposer d'un seul frame CSD.

Actions Dolby

1. Définissez le conditionnement des unités d'accès pour les différents schémas de conteneur Dolby (par exemple, BL+EL+MD) pour le décodeur Dolby abstrait (c'est-à-dire le format de tampon attendu par le décodeur HDR).
2. Définissez le conditionnement du CSD pour le décodeur Dolby abstrait.

Actions des fournisseurs

1. Implémentez l'extracteur Dolby. Dolby peut également le faire.
2. Intégrez DolbyExtractor au framework. Le point d'entrée est frameworks/av/media/libstagefright/MediaExtractor.cpp.
3. Déclarez le profil du décodeur HDR et le type OMX de niveau. Exemple : OMX_VIDEO_DOLBYPROFILETYPE et OMX_VIDEO_DOLBYLEVELTYP.
4. Implémenter la prise en charge de l'index : 'OMX.google.android.index.describeColorAspects'
5. Propager les métadonnées HDR dynamiques à l'application et à la surface dans chaque image. En règle générale, ces informations doivent être empaquetées dans le frame décodé tel que défini par Dolby, car la norme HDMI ne permet pas de les transmettre à l'écran.

Pipeline du décodeur VP9

Figure 3. Pipeline VP9-PQ

Les flux de bits VP9 sont empaquetés dans des conteneurs WebM de la manière définie par l'équipe WebM. Les applications doivent utiliser un extracteur WebM pour extraire les métadonnées HDR du flux de bits avant d'envoyer des images au décodeur.

• Extracteur WebM :
  • L'extracteur WebM extrait les métadonnées et les images HDR du conteneur.
• Décodeur VP9 :
  • Le décodeur reçoit des flux de bits Profile2 et les décode comme des flux VP9 normaux.
  • Le décodeur reçoit toutes les métadonnées statiques HDR du framework.
  • Le décodeur reçoit des métadonnées statiques via les unités d'accès au flux de bits pour les flux VP9 PQ.
  • Le décodeur VP9 doit pouvoir propager les métadonnées statiques/dynamiques HDR à l'écran.

Actions des fournisseurs

1. Implémentez la prise en charge de l'index : OMX.google.android.index.describeHDRColorInfo
2. Implémentez la prise en charge de l'index : OMX.google.android.index.describeColorAspects
3. Propager les métadonnées statiques HDR