Lecture de vidéos HDR

Les vidéos HDR (High Dynamic Range) représentent la nouvelle frontière de la haute qualité le décodage vidéo, offrant des qualités de reproduction de scène inégalées. Oui Ainsi, en augmentant considérablement la plage dynamique de la composante de luminance, (de 100 cd/m2 à des milliers de cd/m2) et en utilisant une (BT 2020). C'est désormais un élément central de l'évolution de la 4K UHD 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. HDR10 et VP9Profile2 qui utilisent des métadonnées statiques, elles sont signalées dans le format de sortie avec la clé KEY_HDR_STATIC_INFO Pour les HDR10+ qui utilisent des métadonnées dynamiques, le signalement est signalé avec la méthode clé KEY_HDR10_PLUS_INFO sur le format de sortie et peut changer pour chaque trame de sortie. Pour en savoir plus, consultez la page Tunnelisation multimédia.

Depuis Android 7.0, la compatibilité HDR initiale inclut Création de constantes appropriées pour la découverte et la configuration des vidéos HDR les pipelines de ML. 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 le flux HDR. et aider les OEM et les SOC à activer les fonctionnalités HDR.

Technologies HDR compatibles

À partir d'Android 7.0 ou version ultérieure, les technologies HDR suivantes sont compatibles.

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

Sous 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 les SurfaceViews en utilisant le mode opaque. des tampons vidéo. Autrement dit :

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

Détection

La lecture HDR nécessite un décodeur compatible HDR et une connexion à un Écran compatible HDR Certaines technologies nécessitent une configuration d'extraction.

Écran

Les applications devront utiliser le nouveau Display.getHdrCapabilities API pour interroger les technologies HDR compatibles avec l'écran spécifié. C'est c'est-à-dire les 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 fonctionnalités HDR de l'écran.

  • Display.HdrCapabilities Encapsule les fonctionnalités HDR d'un écran donné. Par exemple, quel format HDR types pris en charge et fournit des informations sur les données de luminance souhaitées.

Constantes:


  • int HDR_TYPE_DOLBY_VISION Compatibilité Dolby Vision.

  • int HDR_TYPE_HDR10 Compatibilité HDR10 / PQ.

  • int HDR_TYPE_HDR10_PLUS Compatibilité HDR10+.

  • int HDR_TYPE_HLG Prise en charge de Log-Gamma hybride.

  • float INVALID_LUMINANCE Valeur de luminance non valide.

Méthodes publiques:


  • float getDesiredMaxAverageLuminance() Renvoie les données de luminance maximale de la trame du contenu souhaitées en cd/cd/m2 pour cet écran.

  • float getDesiredMaxLuminance() Renvoie les données de luminance maximale du contenu souhaitées en cd/cd/m2 pour cet affichage.

  • float getDesiredMinLuminance() Renvoie les données de luminance minimale du contenu souhaitées en cd/cd/m2 pour cet affichage.

  • int[] getSupportedHdrTypes() Récupère les types HDR compatibles avec cet écran (voir les constantes). Renvoie vide si la technologie HDR n'est pas compatible avec l'écran.

Décodeur

Les applications doivent utiliser la <ph type="x-smartling-placeholder"></ph> l'API CodecCapabilities.profileLevels pour vérifier la compatibilité avec 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 en un seul par image pour les applications vidéo. Cette opération est effectuée automatiquement MediaExtractor compatible avec Dolby Vision.

HEVC HDR 10

Constantes de profil MediaCodecInfo.CodecProfileLevel:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG et PQ

Profil MediaCodecInfo.CodecProfileLevel constantes:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Si une plate-forme est compatible avec un décodeur compatible HDR, elle doit également prendre en charge Extracteur compatible HDR

Seuls les décodeurs tunnellisent à lire du contenu HDR. Lecture par des décodeurs non tunnelisés peut entraîner la perte des informations HDR le contenu aplati dans un volume de couleur 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

Il n'est pas possible de savoir si une piste (d'un fichier) nécessite une prise en charge HDR. prises en charge par la plate-forme. Les applications peuvent analyser les données spécifiques au codec pour déterminer si un titre nécessite un profil HDR spécifique.

Résumé

Les composants requis pour chaque technologie HDR sont indiqués dans le tableau suivant:

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) L'un des profils Dolby HEVCProfileMain10HDR10 VP9Profile2HDR ou VP9Profile3HDR VP9Profile2HDR ou VP9Profile3HDR

Remarques :

  • Les flux de bits Dolby-Vision sont empaquetés dans un conteneur MP4 par Dolby. Les applications peuvent implémenter leurs propres extracteurs compatibles Dolby à condition qu'ils empaquettent les unités d'accès des couches correspondantes dans un une unité d'accès unique pour le décodeur, tel que défini par Dolby.
  • Une plate-forme peut être compatible avec un extracteur compatible HDR, mais pas Décodeur compatible HDR.

Lecture

Une fois qu'une application a vérifié la compatibilité de la lecture HDR, elle peut lire des contenus en HDR. le contenu HDR est semblable à celui qui ne l'est pas, avec les mises en garde suivantes:

  • Pour Dolby-Vision, le fait qu'un fichier multimédia ou une piste spécifique nécessite ou non aucun décodeur compatible HDR n'est disponible immédiatement. L'application doit de disposer de cette information à l'avance ou de pouvoir les obtenir analyser la section des données spécifiques au codec de MediaFormat.
  • CodecCapabilities.isFormatSupported ne tient pas compte si la fonctionnalité de décodeur 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 déployer des efforts supplémentaires pour activer la plate-forme HDR la prise en charge d’un appareil.

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

Voici quelques modifications importantes 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. contenus. Les caractéristiques et les opérations de combinaison exactes ne sont pas définies par Android à partir de la version 7.0. Toutefois, le processus se déroule généralement comme suit:

  1. Déterminer un espace colorimétrique/volume linéaire contenant toutes les couches à composées, en fonction des couches la couleur, le mastering et les effets de métadonnées.
    En cas de composition directe 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 vous utilisez un câble HDMI: <ph type="x-smartling-placeholder">
      </ph>
    1. Déterminez la couleur, le mastering et les métadonnées dynamiques potentielles pour le d'une scène mélangée.
    2. Convertir la scène fusionnée obtenue en couleur dérivée d'espace/volume.
  5. Si vous l'affichez directement sur l'écran, convertissez le résultat combiné avec les 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 responsables de la mise en œuvre des appareils activez de manière sélective l'adaptateur HWC2 disponible avec Android 7.0 pour cette fonctionnalité. Par conséquent, les plates-formes doivent être compatibles avec le protocole HWC2 ou étendre la cadre AOSP pour permettre un moyen de fournir ces informations. HWC2 expose une nouvelle pour propager des données statiques HDR dans le framework et l'application.

HDMI

  • Un écran HDMI connecté diffuse des annonces sa capacité HDR via un EDID HDMI, tel que défini dans l'article <ph type="x-smartling-placeholder"></ph> CTA-861.3 section 4.2.
  • Le mappage EOTF suivant doit être utilisé: <ph type="x-smartling-placeholder">
      </ph>
    • ET_0 Gamma traditionnel – Plage de luminance SDR: non mappée sur HDR Type
    • ET_1 Gamma traditionnel – Plage de luminance HDR: non mappée à une plage HDR Type
    • ET_2 SMPTE ST 2084 : mappé au type HDR HDR10
  • La signalisation de la compatibilité Dolby Vision ou HLG via HDMI est effectuée conformément à la définition par les organismes compétents.
  • Notez que l'API HWC2 utilise des valeurs de luminance à virgule flottante. La valeur 8 bits Les valeurs EDID doivent être traduites de manière appropriée.

Décodeurs

Les plates-formes doivent ajouter des décodeurs tunnelisés compatibles HDR et annoncer leurs de l'assistance. En règle générale, les décodeurs compatibles HDR doivent:

  • Prise en charge du décodage par tunnel (FEATURE_TunneledPlayback).
  • Prendre en charge les métadonnées statiques HDR (OMX.google.android.index.describeHDRColorInfo) et ses propagation à la composition écran/matérielle. Pour le format HLG, les métadonnées appropriées doit être envoyé à l'écran.
  • Description de la couleur d'assistance (OMX.google.android.index.describeColorAspects) et ses propagation à la composition écran/matérielle.
  • Prendre en charge les métadonnées intégrées HDR telles que définies par la norme pertinente.

Compatibilité avec les décodeurs Dolby Vision

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

  • Prise en charge du type MIME "video/dolby-vision".
  • Annoncez les profils/niveaux Dolby Vision compatibles.
  • Accepter les unités d'accès qui contiennent les sous-unités d'accès de tous les calques défini par Dolby.
  • Accepter les données spécifiques au codec définies par Dolby. Par exemple, les données contenant le profil et le niveau Dolby Vision et éventuellement les données spécifiques au codec pour le et des décodeurs internes.
  • Prise en charge du basculement adaptatif entre les profils/niveaux Dolby Vision requises 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 que le décodeur a commencé. Une plate-forme peut choisir de prendre en charge plusieurs Dolby Vision des décodeurs: un pour les profils AVC et un autre pour les profils HEVC afin de pouvoir pour initialiser les codecs sous-jacents au moment de la configuration. Si une seule image de Dolby Vision compatible avec les deux types de profils, mais aussi le basculement entre ceux-ci de manière dynamique de manière adaptative.

Si une plate-forme fournit un décodeur compatible Dolby Vision en plus du compatible avec les décodeurs HDR, elle doit:

  • Fournissez un extracteur compatible avec Dolby Vision, même s'il n'est pas Lecture HDR.
  • Fournir un décodeur prenant en charge le profil de vision tel que défini par Dolby.

Compatibilité avec les décodeurs HDR10

Pour être compatibles avec la technologie HDR10, les plates-formes doivent ajouter un décodeur OMX compatible HDR10. Ce est généralement un décodeur HEVC par tunnel qui prend également en charge l'analyse et la gestion Métadonnées associées au HDMI. Un décodeur de ce type (en plus du décodeur HDR général ) doit:

  • Prise en charge du type MIME "video/hevc".
  • Annoncez une clé HEVCMain10HDR10 compatible. Prise en charge du profil HEVCMain10HRD10 nécessite également que le profil HEVCMain10 soit pris en charge, le profil HEVCMain au même niveau.
  • Prise en charge de l'analyse des blocs SEI des métadonnées de mastering, ainsi que d'autres types de données HDR informations connexes contenues dans SPS.

Compatibilité avec les décodeurs VP9

Pour prendre en charge le VP9 HDR, les plates-formes doivent ajouter un OMX HDR VP9 compatible Profile2 décodeur. Il s'agit normalement d'un décodeur VP9 par tunnel qui prend également en charge la gestion Métadonnées associées au HDMI. Ces décodeurs (en plus du décodeur HDR standard) ) doit:

  • Prise en charge du type MIME "video/x-vnd.on2.vp9".
  • Annoncez le format VP9Profile2HDR compatible. Prise en charge du profil VP9Profile2HDR également nécessite la prise en charge du profil VP9Profile2 au même niveau.

Extracteurs

Compatibilité avec les extracteurs Dolby Vision

Les plates-formes compatibles avec les décodeurs Dolby Vision doivent ajouter un extracteur Dolby (appelé "Extracteur Dolby") compatible avec le contenu vidéo Dolby.

  • Un extracteur MP4 standard 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 nécessaires pour extraire les données du fichier.
  • L'extracteur Dolby doit exposer une à deux pistes pour chaque piste vidéo Dolby. (groupe): <ph type="x-smartling-placeholder">
      </ph>
    • Une piste HDR Dolby Vision de type "video/dolby-vision" pour le flux Dolby combiné à 2/3 couches. Le format d'unité d'accès de la piste HDR, Définit comment empaqueter les unités d'accès à partir des paramètres de base/d'enrichissement/de métadonnées de couches dans un tampon unique à décoder en une seule image HDR, soit défini par Dolby.
    • Si une piste vidéo Dolby Vision contient un fichier distinct (rétrocompatible) couche de base (BL), l'extracteur doit également l'exposer dans un fichier "video/avc" distinct ou "video/hevc" le titre en question. L'extracteur doit fournir un accès AVC/HEVC standard unités pour ce canal.
    • La piste BL doit avoir le même identifiant unique de piste ("track-ID") que le Piste HDR pour que l'application comprenne qu'il s'agit de deux encodages identiques vidéo.
    • L'application peut décider du canal à choisir en fonction de l'expérience de Google Cloud.
  • Le profil et le niveau Dolby Vision doivent être affichés au format de piste : la piste HDR.
  • Si une plate-forme fournit un décodeur compatible avec Dolby Vision, elle doit également fournir un extracteur compatible avec le format Dolby-Vision, même s'il n'est pas compatible avec la lecture HDR.

Compatibilité avec les extracteurs HDR HDR10 et VP9

Aucune configuration supplémentaire n'est requise concernant les extracteurs pour la compatibilité HDR10 ou VP9 HLG. Les plates-formes doivent étendre l'extracteur MP4 pour accepter le format VP9 PQ en MP4. HDR les métadonnées statiques doivent être propagées dans le bitstream VP9 PQ, de sorte que ce sont transmises au décodeur PQ VP9 et à l'écran via la MediaExtractor => Pipeline MediaCodec.

Extensions Stagefright pour la compatibilité avec Dolby Vision

Les plates-formes doivent ajouter la compatibilité avec le format Dolby Vision à Stagefright:

  • Prise en charge de la requête de définition de port pour un port compressé.
  • Énumération du profil/niveau d'assistance 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 pour extraire les données de la trame et les envoyer au décodeur.

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

Actions des fournisseurs

  1. Promouvoir un profil de décodeur HDR et un niveau de type OMX compatibles. Exemple:
    OMX_VIDEO_HEVCProfileMain10HDR10 (et Main10)
  2. Implémentez la prise en charge de l'index: "OMX.google.android.index.describeHDRColorInfo"
  3. Implémentez la prise en charge de l'index: "OMX.google.android.index.describeColorAspects"
  4. Mettre en œuvre 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 pourraient 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 Android MediaExtractor/MediaCodec actuel.

  • DolbyExtractor: <ph type="x-smartling-placeholder">
      </ph>
    • Les Dolby-bitstream sont reconnus par un DolbyExtractor, qui expose le différentes couches, sous la forme d'une ou deux pistes pour chaque piste vidéo "dolby" (groupe): <ph type="x-smartling-placeholder">
        </ph>
      • Une piste HDR de type "video/dolby-vision" pour l'ensemble Flux dolby à 2/3 couches. Format d'unité d'accès de la piste HDR, qui définit Comment empaqueter les unités d'accès à partir des couches de base/d'amélioration/de métadonnées en un seul tampon à décoder en une seule image HDR, doit être définie par Dolby.
      • (Facultatif, uniquement si la LB 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 un flux AVC/HEVC standard accéder aux unités pour ce canal. Cette piste BL doit avoir le même identifiant unique de piste. ("track-ID") comme la piste Dolby afin que l'application comprenne que ces sont deux encodages d'une même vidéo.
    • L'application peut décider du canal à choisir en fonction de l'expérience de Google Cloud.
    • Étant donné qu'une piste HDR possède un type HDR spécifique, le cadre 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: <ph type="x-smartling-placeholder">
      </ph>
    • Le DolbyDecoder reçoit des unités d'accès contenant les informations unités pour toutes les couches (EL+BL+MD ou BL+MD)
    • Informations CSD (données spécifiques au codec, telles que SPS+PPS+VPS) pour le les couches individuelles peuvent être empaquetées dans une seule trame CSD devant être définie par Dolby. Vous devez disposer d'une seule trame CSD.

Actions Dolby

  1. Définir le packaging des unités d'accès pour les différents conteneurs Dolby (BL+EL+MD, par exemple) pour le décodeur Dolby abstrait (c'est-à-dire le 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. Cela peut également être fait par Dolby.
  2. Intégrer DolbyExtractor au framework. Le point d'entrée est frameworks/av/media/libstagefright/MediaExtractor.cpp
  3. Déclarer le profil du décodeur HDR et le niveau OMX de mots clés. Exemple: OMX_VIDEO_DOLBYPROFILETYPE et OMX_VIDEO_DOLBYLEVELTYP
  4. Implémentez la prise en charge de l'index: 'OMX.google.android.index.describeColorAspects min
  5. Propager les métadonnées HDR dynamiques à l'application et à la surface dans chaque cadre. Généralement, ces informations doivent être empaquetées dans la trame décodée comme défini par Dolby, car la norme HDMI ne permet pas transmettons-le à l'écran.

Pipeline du décodeur VP9

Figure 3. Pipeline VP9-PQ

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

  • Extracteur WebM: <ph type="x-smartling-placeholder">
  • Décodeur VP9: <ph type="x-smartling-placeholder">
      </ph>
    • Le décodeur reçoit les flux de bits Profile2 et les décode en tant que code VP9 normal flux.
    • 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 en flux de bits pour VP9. Flux PQ.
    • Le décodeur VP9 doit être capable de 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 des métadonnées statiques HDR