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 de la composante de luminance (de 100 cd/m² à des milliers de cd/m²) et utilise un espace colorimétrique 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 ou version ultérieure, MediaCodec génère des rapports sur 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 sans tunnel. 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 les HDR10+ qui utilisent des métadonnées dynamiques, ce paramètre est signalé avec la clé KEY_HDR10_PLUS_INFO sur le format de sortie et peut changer pour chaque image de sortie. Pour en savoir plus, consultez la page Tunnelisation 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 signifie définir les types de codec et les modes d'affichage, et 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.

Sous Android 7.0, seule la lecture HDR via le mode tunnel est définie. Toutefois, les appareils peuvent ajouter la prise en charge de la lecture HDR sur les SurfaceViews utilisant des 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 prise en charge par la version AOSP Android 7.0.

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 devront 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ées en cd/cd/m² pour cet affichage.
• int[] getSupportedHdrTypes()
  Obtient les types HDR compatibles de 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 en un seul tampon par trame 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 en tunnel peut entraîner la perte des informations HDR et l'aplatissement du contenu dans un volume de couleurs SDR.

Extracteur

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

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 Dolby à condition de regrouper les unités d'accès des couches correspondantes dans une seule unité d'accès pour le décodeur, tel que défini par Dolby.
• Une plate-forme peut être compatible avec un extracteur compatible HDR, mais pas avec un décodeur compatible 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 des données spécifiques au codec de 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 prise en charge de 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 dans Android 7.0 pour le HDR

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

Écran

Composition matérielle

Les plates-formes compatibles HDR doivent permettre de combiner des contenus HDR et 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/volume de couleurs linéaire contenant toutes les couches à composer, en fonction de la couleur, du mastering et des métadonnées dynamiques potentielles des couches.
   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 calques dans l'espace colorimétrique commun.
3. Effectuez le mélange.
4. Si l'affichage se fait via HDMI :
   1. Déterminez la couleur, le mastering et les métadonnées dynamiques potentielles pour la scène combiné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écouverte de l'inventaire display

La détection d'écrans HDR n'est compatible qu'avec le protocole 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 ajouter la prise en charge du protocole 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 un EDID HDMI, comme défini dans la section 4.2 du CTA-861.3.
• Le mappage EOTF suivant doit être utilisé :
  • ET_0 Gamma traditionnel – Plage de luminance SDR: non mappée à un type HDR
  • ET_1 Gamma traditionnel – Plage de luminance HDR: non mappée à un type HDR.
  • ET_2 SMPTE ST 2084 : mappé au type HDR HDR10
• La signalisation de la compatibilité Dolby Vision ou HLG via HDMI est définie par les organismes concernés.
• Notez que l'API HWC2 utilise des valeurs de luminance souhaitées à virgule flottante. Par conséquent, les valeurs EDID à 8 bits doivent ê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 règle générale, 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 le format HLG, les métadonnées appropriées doivent être envoyées à l'affichage.
• Prise en charge de la description de la couleur (OMX.google.android.index.describeColorAspects) et de sa propagation dans la composition graphique/matérielle.
• Prendre en charge les métadonnées intégrées HDR telles que définies par la norme pertinente.

Compatibilité avec le décodeur Dolby Vision

Pour être compatibles avec Dolby Vision, les plates-formes doivent ajouter un décodeur HDR OMX compatible. 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".
• Annoncer 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.
• Prend en charge le basculement adaptatif entre les profils/niveaux Dolby Vision selon les besoins du format Dolby.

Lors de la configuration du décodeur, le profil Dolby réel n'est pas communiqué au codec. Cela n'est effectué 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 le format 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 la technologie HDR10, les plates-formes doivent ajouter un décodeur OMX compatible HDR10. 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 tel décodeur (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 compatibilité avec le profil HEVCMain10HRD10 nécessite également la compatibilité avec le profil HEVCMain10, qui nécessite la prise en charge du profil HEVCMain au même niveau.
• 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 HDR VP9, les plates-formes doivent ajouter un décodeur OMX HDR compatible avec le profil 2 du VP9. Il s'agit généralement d'un décodeur VP9 acheminé par 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".
• Annoncez le format VP9Profile2HDR compatible. La prise en charge du profil VP9Profile2HDR nécessite également de prendre en charge le profil VP9Profile2 au même niveau.

Extracteurs

Compatibilité avec l'extracteur Dolby Vision

Les plates-formes compatibles avec les décodeurs Dolby Vision doivent ajouter l'extracteur Dolby (appelé "extracteur Dolby") compatible avec le contenu 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 HDR Dolby Vision 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/d'amélioration/de métadonnées dans un seul tampon à décoder dans une seule image HDR, doit être défini par Dolby.
  • Si une piste vidéo Dolby Vision contient une couche de base (BL) distincte (rétrocompatible), 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 identifiant unique de piste ("track-ID") que la piste HDR afin que l'application comprenne qu'il s'agit de deux encodages d'une même vidéo.
  • L'application peut décider du canal à choisir en fonction des capacité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 cette technologie, 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 les ports compressés.
• Énumération du profil/niveau d'assistance pour le décodeur DV.
• Prise en charge de l'exposition du profil/niveau DV pour les pistes DV HDR.

Détails d'implémentation spécifiques à la 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'il décode une vidéo HDR. Les informations HDR sont regroupées dans un format de sortie décodeur, qui est propagé à la surface ultérieurement.

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émenter la prise en charge de l'index : OMX.google.android.index.describeHDRColorInfo
3. Implémenter 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 de décodeur Dolby Vision

Figure 2. Pipeline Dolby Vision

Les Dolby-bitstream sont empaquetés dans des conteneurs MP4 tels que définis 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 flux de bits Dolby sont reconnus par un DolbyExtractor, qui expose les différentes couches sous la forme de 1 à 2 pistes pour chaque piste vidéo Dolby (groupe) :
    • Une piste HDR avec le type "video/dolby-vision" pour le flux dolby combiné à 2/3 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/d'amélioration/de métadonnées dans un seul tampon à décoder dans une seule image 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 standards pour cette piste. Cette piste BL doit avoir le même identifiant unique de piste ("track-ID") que la piste Dolby afin que l'application comprenne qu'il s'agit de deux encodages d'une même vidéo.
  • L'application peut décider du canal à choisir en fonction des capacité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éfinir le packaging de CSD pour le décodeur abstrait Dolby.

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. Propagez les métadonnées HDR dynamiques dans l'application et la surface dans chaque frame. En règle générale, ces informations doivent être regroupées dans la trame décodée telle que définie 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 :
  • WebM Extractor extrait les métadonnées HDR et les images du conteneur.
• Décodeur VP9 :
  • Le décodeur reçoit les flux de bits Profile2 et les décode en 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