Lecture vidéo HDR

La vidéo HDR (High Dynamic Range) constitue la prochaine frontière en matière de décodage vidéo de haute qualité, offrant des qualités de reproduction de scène inégalées. Pour ce faire, il augmente considérablement la plage dynamique de la composante de luminance (de 100 cd/m ² actuels à 1 000 s de cd/m ² ) et en utilisant un espace colorimétrique beaucoup plus large (BT 2020). Il s’agit désormais d’un élément central de l’évolution de la 4K UHD dans le domaine de la télévision.

Android 10 prend en charge 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 tunnelé. 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, celles-ci sont signalées dans le format de sortie avec la clé KEY_HDR_STATIC_INFO . Pour 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 image de sortie. Voir Tunneling multimédia pour plus d’informations.

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 codecs 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 prises en charge

À partir d'Android 7.0 et versions ultérieures, les technologies HDR suivantes sont prises en charge.

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

• Il n'existe pas d'API Android standard pour vérifier si la lecture HDR est prise en charge à l'aide de décodeurs non tunnelisés.
• Les décodeurs vidéo tunnelés qui annoncent la capacité de lecture HDR doivent prendre en charge 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. Eventuellement, certaines technologies nécessitent un extracteur spécifique.

Afficher

Les applications doivent utiliser la nouvelle API Display.getHdrCapabilities pour interroger les technologies HDR prises en charge par l'affichage spécifié. Il s'agit essentiellement des informations contenues dans le bloc de données de métadonnées statiques EDID telles que définies dans CTA-861.3 :

• public Display.HdrCapabilities getHdrCapabilities()
  Renvoie les capacités HDR de l’écran.
• Display.HdrCapabilities
  Encapsule les capacités HDR d’un écran donné. Par exemple, les types HDR pris en charge et des détails sur les données de luminance souhaitées.

Constantes :

• int HDR_TYPE_DOLBY_VISION
  Prise en charge de Dolby Vision.
• int HDR_TYPE_HDR10
  Prise en charge HDR10/PQ.
• int HDR_TYPE_HDR10_PLUS
  Prise en charge HDR10+.
• int HDR_TYPE_HLG
  Prise en charge hybride Log-Gamma.
• float INVALID_LUMINANCE
  Valeur de luminance invalide.

Méthodes publiques :

• float getDesiredMaxAverageLuminance()
  Renvoie les données de luminance moyenne d'image maximale du contenu souhaité en cd/cd/m ² pour cet affichage.
• float getDesiredMaxLuminance()
  Renvoie les données de luminance maximale du contenu souhaité en cd/cd/m ² pour cet affichage.
• float getDesiredMinLuminance()
  Renvoie les données de luminance minimale du contenu souhaité en cd/cd/m ² pour cet affichage.
• int[] getSupportedHdrTypes()
  Obtient les types HDR pris en charge pour cet affichage (voir constantes). Renvoie un tableau vide si le HDR n'est pas pris en charge par l'écran.

Décodeur

Les applications doivent utiliser l'API CodecCapabilities.profileLevels existante pour vérifier la prise en charge des nouveaux profils compatibles 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. Ceci est effectué automatiquement par le MediaExtractor compatible Dolby-Vision.

HEVCHDR10

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 prend en charge un décodeur compatible HDR, elle doit également prendre en charge un extracteur compatible HDR.

Seuls les décodeurs tunnelés sont garantis pour lire le contenu HDR. La lecture par des décodeurs sans tunnel peut entraîner la perte des informations HDR et l'aplatissement du contenu dans un volume de couleur SDR.

Extracteur

Les conteneurs suivants sont pris en charge pour les différentes technologies HDR sur Android 7.0 :

La découverte de savoir si une piste (d'un fichier) nécessite la prise en charge HDR n'est pas prise en charge par la plateforme. 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 en matière de composants pour chaque technologie HDR sont indiquées dans le tableau suivant :

Remarques:

• Les flux binaires Dolby-Vision sont regroupés dans un conteneur MP4 d'une manière définie par Dolby. Les applications peuvent implémenter leurs propres extracteurs compatibles Dolby à condition qu'elles regroupent 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 prendre en charge un extracteur compatible HDR, mais aucun décodeur compatible HDR correspondant.

Relecture

Une fois qu'une application a vérifié la prise en charge de la lecture HDR, elle peut lire le contenu HDR presque de la même manière qu'elle lit le contenu non HDR, avec les mises en garde suivantes :

• Pour Dolby-Vision, il n’est pas immédiatement disponible si un fichier/une piste multimédia spécifique nécessite ou non un décodeur compatible HDR. L'application doit disposer de ces informations à l'avance ou être en mesure d'obtenir ces informations en analysant la section de données spécifiques au codec du MediaFormat.
• CodecCapabilities.isFormatSupported ne considère pas si la fonctionnalité de décodeur tunnelé est requise pour prendre en charge un tel profil.

Activer la prise en charge de la plateforme HDR

Les fournisseurs de SoC et les OEM doivent effectuer un travail supplémentaire pour activer la prise en charge de la plate-forme HDR pour un appareil.

Modifications de la plate-forme dans Android 7.0 pour HDR

Voici quelques changements clés dans la plate-forme (application/couche native) dont les OEM et les SOC doivent être conscients.

Afficher

Composition du matériel

Les plates-formes compatibles HDR doivent prendre en charge le mélange de contenu HDR avec du contenu non HDR. Les caractéristiques et opérations exactes de mélange ne sont pas définies par Android à partir de la version 7.0, mais le processus suit généralement ces étapes :

1. Déterminez un espace/volume colorimétrique linéaire contenant tous les calques à composer, en fonction de la couleur, du mastering et des métadonnées dynamiques potentielles des calques.
   Si vous composez directement sur un écran, il peut s'agir de l'espace linéaire qui correspond au volume de couleur de l'écran.
2. Convertissez tous les calques dans l’espace colorimétrique commun.
3. Effectuez le mélange.
4. Si vous affichez via HDMI :
   1. Déterminez la couleur, le mastering et les métadonnées dynamiques potentielles pour la scène mélangée.
   2. Convertissez la scène mélangée résultante en espace colorimétrique/volume dérivé.
5. En cas d'affichage directement sur l'écran, convertissez la scène mélangée résultante en signaux d'affichage requis pour produire cette scène.

Découverte d'affichage

La découverte d'affichage HDR n'est prise en charge que via HWC2. Les implémenteurs d'appareils doivent activer de manière sélective l'adaptateur HWC2 publié avec Android 7.0 pour que cette fonctionnalité fonctionne. Par conséquent, les plates-formes doivent ajouter la prise en charge de HWC2 ou étendre le cadre 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 HDMI EDID tel que 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é à un type HDR
  • ET_1 Gamma traditionnel - Plage de luminance HDR : non mappé à un type HDR
  • ET_2 SMPTE ST 2084 - mappé au type HDR HDR10
• La signalisation du support Dolby Vision ou HLG via HDMI est effectuée comme défini par leurs organismes compétents.
• Notez que l'API HWC2 utilise des valeurs de luminance flottantes souhaitées, les valeurs EDID 8 bits doivent donc être traduites de manière appropriée.

Décodeurs

Les plates-formes doivent ajouter des décodeurs tunnelés compatibles HDR et annoncer leur prise en charge HDR. Généralement, les décodeurs compatibles HDR doivent :

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

Prise en charge du décodeur Dolby Vision

Pour prendre en charge Dolby Vision, les plates-formes doivent ajouter un décodeur HDR OMX compatible Dolby-Vision. Compte tenu des spécificités du Dolby Vision, il s'agit normalement d'un décodeur wrapper autour d'un ou plusieurs décodeurs AVC et/ou HEVC ainsi que d'un compositeur. De tels décodeurs doivent :

• Prise en charge du type MIME « vidéo/dolby-vision ».
• Annoncez les profils/niveaux Dolby Vision pris en charge.
• Acceptez les unités d'accès qui contiennent les sous-unités d'accès de toutes les couches telles que définies par Dolby.
• Acceptez 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 la commutation adaptative entre les profils/niveaux Dolby Vision comme requis par Dolby.

Lors de la configuration du décodeur, le profil Dolby réel n'est pas communiqué au codec. Cela se fait uniquement 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écodeurs Dolby Vision : un pour les profils AVC et un autre pour les profils HEVC afin de pouvoir initialiser les codecs sous-jacents pendant le temps de configuration. Si un seul décodeur Dolby Vision prend en charge les deux types de profils, il doit également prendre en charge la commutation entre ceux-ci de manière dynamique et adaptative.

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

• Fournissez un extracteur compatible Dolby-Vision, même s'il ne prend pas en charge la lecture HDR.
• Fournissez un décodeur prenant en charge le profil de vision tel que défini par Dolby.

Prise en charge du décodeur HDR10

Pour prendre en charge HDR10, les plates-formes doivent ajouter un décodeur OMX compatible HDR10. Il s'agit normalement d'un décodeur HEVC tunnelé qui prend également en charge l'analyse et la gestion des métadonnées liées au HDMI. Un tel décodeur (en plus du support général du décodeur HDR) doit :

• Prise en charge du type MIME « vidéo/hevc ».
• Annonce prise en charge HEVCMain10HDR10. La prise en charge du profil HEVCMain10HRD10 nécessite également la prise en charge du profil HEVCMain10, ce 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 maîtrise, ainsi que d'autres informations liées au HDR contenues dans SPS.

Prise en charge du décodeur VP9

Pour prendre en charge VP9 HDR, les plates-formes doivent ajouter un décodeur HDR OMX compatible VP9 Profile2. Il s'agit normalement d'un décodeur VP9 tunnelé qui prend également en charge la gestion des métadonnées liées au HDMI. De tels 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 pris en charge VP9Profile2HDR. La prise en charge du profil VP9Profile2HDR nécessite également la prise en charge du profil VP9Profile2 au même niveau.

Extracteurs

Prise en charge de l'extracteur Dolby Vision

Les plates-formes prenant en charge les décodeurs Dolby Vision doivent ajouter la prise en charge de l'extracteur Dolby (appelé Dolby Extractor) pour le contenu Dolby Video.

• Un extracteur MP4 classique ne peut extraire que la couche de base d'un fichier, mais pas les couches d'amélioration ou de métadonnées. Un extracteur Dolby spécial est donc nécessaire pour extraire les données du fichier.
• L'extracteur Dolby doit exposer 1 à 2 pistes pour chaque piste vidéo Dolby (groupe) :
  • Une piste Dolby Vision HDR avec le type "vidéo/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 regrouper les unités d'accès des couches de base/d'amélioration/de métadonnées dans un seul tampon à décoder en 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 « vidéo/avc » ou « vidéo/hevc » distincte. L'extracteur doit fournir des unités d'accès AVC/HEVC régulières pour cette piste.
  • 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 de la même vidéo.
  • L'application peut décider quelle piste choisir en fonction des capacités de la plateforme.
• Le profil/niveau Dolby Vision doit être exposé au format de piste de la piste HDR.
• Si une plate-forme fournit un décodeur compatible Dolby-Vision, elle doit également fournir un extracteur compatible Dolby-Vision, même si elle ne prend pas en charge la lecture HDR.

Prise en charge des extracteurs HDR10 et VP9 HDR

Il n’y a aucune exigence supplémentaire en matière d’extracteur pour prendre en charge HDR10 ou VP9 HLG. Les plates-formes doivent étendre l'extracteur MP4 pour prendre en charge VP9 PQ en MP4. Les métadonnées statiques HDR doivent être propagées dans le flux binaire VP9 PQ, de telle sorte que ces métadonnées soient transmises au décodeur VP9 PQ et à l'affichage via le pipeline MediaExtractor => MediaCodec normal.

Extensions Stagefright pour la prise en charge de 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 le port compressé.
• Prise en charge de l'énumération de profil/niveau pour le décodeur DV.
• Prise en charge de l'exposition du profil/niveau DV pour les pistes DV HDR.

Détails de mise en œuvre spécifiques à la technologie

Pipeline de décodeur HDR10

Figure 1. Pipeline HDR10

Les flux binaires HDR10 sont regroupés dans des conteneurs MP4. Les applications utilisent un extracteur MP4 classique pour extraire les données de trame et les envoyer au décodeur.

• Extracteur MPEG4
  Les flux binaires HDR10 sont reconnus comme un simple flux HEVC normal par un MPEG4Extractor et la piste HDR de type « vidéo/HEVC » sera extraite. Le framework choisit un décodeur vidéo HEVC qui prend en charge le profil Main10HDR10 pour décoder cette piste.
• Décodeur HEVC
  Les informations HDR sont au format SEI ou SPS. Le décodeur HEVC reçoit d'abord les 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 du décodeur, qui est ensuite propagé à la surface.

Actions du fournisseur

1. Annoncez le profil de décodeur HDR pris en charge et le type de niveau OMX. 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émentez la prise en charge de l'analyse SEI des métadonnées de maîtrise.

Pipeline de décodeur Dolby Vision

Figure 2. Pipeline Dolby Vision

Les flux binaires Dolby sont regroupés dans des conteneurs MP4 tels que définis par Dolby. Les applications pourraient, en théorie, utiliser un extracteur MP4 classique pour extraire indépendamment la couche de base, la couche d'amélioration et la couche de métadonnées ; cependant, cela ne correspond pas au modèle Android MediaExtractor/MediaCodec actuel.

• DolbyExtracteur :
  • Les flux binaires Dolby sont reconnus par un DolbyExtractor, qui expose les différentes couches sous forme de 1 à 2 pistes pour chaque piste vidéo Dolby (groupe) :
    • Une piste HDR de type « vidéo/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 regrouper les unités d'accès des couches de base/d'amélioration/de métadonnées dans un seul tampon à décoder en une seule image HDR, doit être défini par Dolby.
    • (Facultatif, uniquement si le BL est rétrocompatible) Une piste BL contient uniquement la couche de base, qui doit être décodable 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 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 de la même vidéo.
  • L'application peut décider quelle piste choisir en fonction des capacités de la plateforme.
  • Étant donné qu'une piste HDR a un type HDR spécifique, le framework choisira un décodeur vidéo Dolby pour décoder cette piste. La piste BL sera décodée par un décodeur vidéo AVC/HEVC classique.
• Décodeur Dolby :
  • Le DolbyDecoder reçoit les unités d'accès qui contiennent 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 regroupées dans 1 trame CSD à définir par Dolby. Avoir une seule trame CSD est requis.

Actions Dolby

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

Actions du fournisseur

1. Implémentez l’extracteur Dolby. Cela peut également être fait par Dolby.
2. Intégrez DolbyExtractor dans le 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 de niveau OMX. 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 à l'application et à la surface dans chaque image. Généralement, 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 transmettre ces informations à l'écran.

Pipeline de décodeur VP9

Figure 3. Pipeline VP9-PQ

Les flux binaires VP9 sont regroupés dans des conteneurs WebM d'une manière définie par l'équipe WebM. Les applications doivent utiliser un extracteur WebM pour extraire les métadonnées HDR du flux binaire avant d'envoyer des trames au décodeur.

• Extracteur WebM :
  • WebM Extractor extrait les métadonnées et les images HDR du conteneur .
• Décodeur VP9 :
  • Le décodeur reçoit les flux binaires 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 binaire pour les flux VP9 PQ.
  • Le décodeur VP9 doit être capable de propager les métadonnées statiques/dynamiques HDR à l'écran.

Actions du fournisseur

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