Lecture de vidéos HDR

La vidéo HDR (High Dynamic Range) est la prochaine étape en matière de décodage vidéo de haute qualité. Elle offre 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/m2 actuellement à des milliers de cd/m2) 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 4K UHD dans le domaine de la télévision.

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

  • HDR10
  • VP9
  • HDR10+

À partir d'Android 9, MediaCodec signale les métadonnées HDR quel que soit le mode tunnelisé. En mode non tunnelé, vous pouvez obtenir des données décodées ainsi que des métadonnées statiques/dynamiques. Pour HDR10 et VP9Profile2 qui utilisent des métadonnées statiques, celles-ci sont indiquées dans le format de sortie avec la clé KEY_HDR_STATIC_INFO. Pour le HDR10+ qui utilise des métadonnées dynamiques, cela est indiqué avec la clé KEY_HDR10_PLUS_INFO dans le format de sortie et peut changer pour chaque frame de sortie. Pour en savoir plus, consultez 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 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 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 Aucun Statique

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

  • Il n'existe pas d'API Android standard permettant de vérifier si la lecture HDR est prise en charge à l'aide de décodeurs non tunnelés.
  • Les décodeurs vidéo tunnelés qui annoncent une 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 compatible avec la version 7.0 d'AOSP Android.

Découverte

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

É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 contenues dans le bloc de données de métadonnées statiques EDID, tel que défini dans CTA-861.3 :

  • public Display.HdrCapabilities getHdrCapabilities()
    Renvoie les capacités HDR de l'écran.
  • Display.HdrCapabilities
    Encapsule les fonctionnalités HDR d'un écran donné. Par exemple, les types de HDR qu'il prend en charge et des informations sur les données de luminance souhaitées.

Constantes :

  • int HDR_TYPE_DOLBY_VISION
    Prise en charge de Dolby Vision.
  • int HDR_TYPE_HDR10
    Compatibilité HDR10 / PQ.
  • int HDR_TYPE_HDR10_PLUS
    Prise en charge de HDR10+.
  • int HDR_TYPE_HLG
    Compatibilité avec Hybrid Log-Gamma.
  • float INVALID_LUMINANCE
    Valeur de luminance non valide.

Méthodes publiques :

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

Décodeur

Les applications doivent utiliser l'API CodecCapabilities.profileLevels existante pour vérifier la compatibilité avec les nouveaux profils 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 applications vidéo doivent concaténer les calques vidéo et les métadonnées Dolby Vision dans un seul tampon par frame. 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 du profil MediaCodecInfo.CodecProfileLevel : 

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

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

Seuls les décodeurs tunnelisés sont garantis pour la lecture de contenus HDR. La lecture par des décodeurs non tunnelés 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 :

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

La plate-forme ne permet pas de déterminer si une piste (d'un fichier) nécessite la prise en charge du 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é

Le tableau suivant indique les exigences des composants pour chaque technologie HDR :

Technologie Dolby Vision HDR10 VP9-HLG VP9-PQ
Type HDR compatible (écran) HDR_TYPE_DOLBY_VISION HDR_TYPE_HDR10 HDR_TYPE_HLG HDR_TYPE_HDR10
Conteneur (extracteur) MP4 MP4 WebM WebM
Décodeur MIMETYPE_VIDEO_DOLBY_VISION MIMETYPE_VIDEO_HEVC MIMETYPE_VIDEO_VP9 MIMETYPE_VIDEO_VP9
Profil (décodeur) Un des profils Dolby HEVCProfileMain10HDR10 VP9Profile2HDR ou VP9Profile3HDR VP9Profile2HDR ou VP9Profile3HDR

Remarques :

  • Les flux binaires Dolby Vision sont empaquetés dans un conteneur MP4 de 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 en une seule unité d'accès pour le décodeur, comme défini par Dolby.
  • Une plate-forme peut être compatible avec un extracteur HDR, mais pas avec un décodeur HDR correspondant.

Lecture

Une fois qu'une application a vérifié la compatibilité avec la lecture HDR, elle peut lire du contenu HDR presque 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/une piste multimédia spécifique nécessite un décodeur compatible 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écifiques au codec du MediaFormat.
  • CodecCapabilities.isFormatSupported ne tient pas compte de la nécessité de la fonctionnalité de décodeur tunnelisé pour la prise en charge d'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 activer la compatibilité de la plate-forme HDR pour un appareil.

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

Voici quelques modifications clés apportées à 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 combiner des contenus HDR et non HDR. Les caractéristiques et les opérations de fusion 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 couleur linéaire qui contient 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 tous les calques dans l'espace colorimétrique commun.
  3. Effectuez le mélange.
  4. Si vous utilisez un câble 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 composite obtenue dans l'espace/volume de couleurs dérivé.
  5. Si vous affichez directement la scène combinée sur l'écran, convertissez-la en signaux d'affichage requis pour la produire.

Découverte de l'écran

La détection des écrans HDR n'est compatible qu'avec HWC2. Les intégrateurs d'appareils doivent activer sélectivement 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 de 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é indique sa compatibilité HDR via HDMI EDID, comme défini dans la section 4.2 de CTA-861.3.
  • Le mappage EOTF suivant doit être utilisé :
    • ET_0 Gamma traditionnel : plage de luminance SDR non mappée sur un type HDR
    • ET_1 Gamma traditionnel : plage de luminance HDR non mappée sur un type HDR
    • ET_2 SMPTE ST 2084 : mappé au type HDR10
  • La signalisation de la compatibilité Dolby Vision ou HLG via HDMI est effectuée conformément aux définitions de leurs organismes respectifs.
  • Notez que l'API HWC2 utilise des valeurs de luminance souhaitées flottantes. Les valeurs EDID 8 bits doivent donc être traduites de manière appropriée.

Décodeurs

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

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

Compatibilité avec le décodeur Dolby Vision

Pour prendre en charge Dolby Vision, les plates-formes doivent ajouter un décodeur HDR OMX compatible avec Dolby Vision. Compte tenu des spécificités de 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. Ces décodeurs doivent :

  • Ajout du type MIME "video/dolby-vision".
  • Annoncez les profils/niveaux Dolby Vision compatibles.
  • 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.
  • 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 de la commutation adaptative 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 n'est fait que via des données spécifiques au codec une fois le décodeur démarré. 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 lors de la configuration. Si un seul décodeur Dolby Vision prend en charge les deux types de profils, il doit également permettre de passer de l'un à l'autre 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 :

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

Compatibilité 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 tunnelisé qui prend également en charge l'analyse et la gestion des métadonnées liées à HDMI. En plus de la prise en charge générale du décodage HDR, un tel décodeur doit :

  • Prise en charge du type MIME "video/hevc".
  • Publicité compatible avec HEVCMain10HDR10. La compatibilité avec le profil HEVCMain10HRD10 nécessite également la compatibilité avec le profil HEVCMain10, qui nécessite la compatibilité avec le 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 compatible avec le profil 2 du VP9. Il s'agit normalement d'un décodeur VP9 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 des décodeurs HDR) doivent :

  • Prise en charge du type MIME "video/x-vnd.on2.vp9."
  • Annonce compatible avec VP9Profile2HDR. La prise en charge du profil VP9Profile2HDR nécessite également la prise en charge du 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 la prise en charge de l'extracteur Dolby (appelé Dolby Extractor) pour 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 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 une ou 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 des unités 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 "video/avc" ou "video/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 ID unique ("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 choisir la piste en fonction des capacités de la plate-forme.
  • Le profil/niveau Dolby Vision doit être exposé dans le 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.

Compatibilité avec l'extracteur HDR10 et VP9 HDR

Aucune exigence supplémentaire concernant l'extracteur n'est requise pour prendre en charge HDR10 ou VP9 HLG. Les plates-formes doivent étendre l'extracteur MP4 pour prendre en charge la qualité de perception VP9 dans MP4. Les métadonnées statiques HDR doivent être propagées dans le flux binaire 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 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 des profils/niveaux pour le décodeur DV.
  • Prise en charge de l'exposition du profil/niveau DV pour les pistes HDR DV.

Détails d'implémentation spécifiques à la technologie

Pipeline de décodage 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 frame et les envoyer au décodeur.

  • Extracteur MPEG4
    Les flux de bits HDR10 sont reconnus comme un flux HEVC normal par un MPEG4Extractor, et la piste HDR de type "video/HEVC" sera extraite. Le framework choisit 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 SEI ou SPS. Le décodeur HEVC reçoit d'abord les frames contenant les informations HDR. Le décodeur extrait ensuite les informations HDR et avertit l'application qu'il décode 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. Annoncez le profil et le niveau du décodeur HDR compatibles avec le type 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 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 pourraient utiliser un extracteur MP4 standard pour extraire indépendamment la couche de base, la couche d'amélioration et la couche de métadonnées. Toutefois, cela ne correspond pas au modèle actuel Android MediaExtractor/MediaCodec.

  • DolbyExtractor :
    • Les flux de bits Dolby sont reconnus par un DolbyExtractor, qui expose les différentes couches sous forme de une à deux pistes pour chaque piste vidéo Dolby (groupe) :
      • Piste HDR de type "video/dolby-vision" pour le flux Dolby combiné à deux ou trois couches. Le format des unités d'accès de la piste HDR, qui définit la manière d'empaqueter 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 la couche de base est rétrocompatible) Une piste BL ne contient que 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 ID 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 choisir la piste en fonction des capacités de la plate-forme.
    • É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 standard.
  • DolbyDecoder :
    • DolbyDecoder reçoit des 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 calques individuels peuvent être regroupées dans un seul frame CSD à définir par Dolby. Vous devez disposer d'un seul frame CSD.

Actions Dolby

  1. Définissez le packaging 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 packaging 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 et le niveau du décodeur HDR de type 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 frame. En règle générale, ces informations doivent être regroupé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 conditionné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 frames au décodeur.

  • Extracteur WebM :
  • Décodeur VP9 :
    • Le décodeur reçoit les flux de bits du profil 2 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 HDR statiques/dynamiques à 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