Reproducción de vídeo HDR

El vídeo de alto rango dinámico (HDR) es la próxima frontera en la decodificación de vídeo de alta calidad y ofrece cualidades de reproducción de escenas inigualables. Lo hace aumentando significativamente el rango dinámico del componente de luminancia (de los actuales 100 cd/m 2 a 1000 cd/m 2 ) y utilizando un espacio de color mucho más amplio (BT 2020). Este es ahora un elemento central de la evolución del 4K UHD en el espacio de la televisión.

Android 10 admite los siguientes vídeos HDR.

  • HDR10
  • VP9
  • HDR10+

A partir de Android 9 y versiones posteriores, MediaCodec informa metadatos HDR independientemente del modo tunelizado. Puede obtener datos decodificados junto con metadatos estáticos/dinámicos en modo sin túnel. Para HDR10 y VP9Profile2 que utilizan metadatos estáticos, estos se informan en el formato de salida con la clave KEY_HDR_STATIC_INFO . Para HDR10+ que utiliza metadatos dinámicos, esto se informa con la clave KEY_HDR10_PLUS_INFO en el formato de salida y puede cambiar para cada cuadro de salida. Consulte Túnel multimedia para obtener más información.

Desde Android 7.0, la compatibilidad inicial con HDR incluye la creación de constantes adecuadas para el descubrimiento y la configuración de canalizaciones de vídeo HDR. Eso significa definir tipos de códec y modos de visualización y especificar cómo se deben pasar los datos HDR a MediaCodec y suministrarse a los decodificadores HDR.

El propósito de este documento es ayudar a los desarrolladores de aplicaciones a admitir la reproducción de secuencias HDR y ayudar a los OEM y SOC a habilitar las funciones HDR.

Tecnologías HDR compatibles

A partir de Android 7.0 y superiores, se admiten las siguientes tecnologías HDR.

Tecnología Dolby Vision HDR10 VP9-HLG VP9-PQ
Códec AVC/HEVC HEVC VP9 VP9
Función de transferencia ST-2084 ST-2084 HLG ST-2084
Tipo de metadatos HDR Dinámica Estático Ninguno Estático

En Android 7.0, solo se define la reproducción HDR a través del modo túnel , pero los dispositivos pueden agregar soporte para la reproducción de HDR en SurfaceViews usando buffers de video opacos. En otras palabras:

  • No existe una API de Android estándar para verificar si la reproducción HDR es compatible con decodificadores sin túnel.
  • Los decodificadores de video en túnel que anuncian la capacidad de reproducción HDR deben admitir la reproducción HDR cuando se conectan a pantallas compatibles con HDR.
  • La composición GL del contenido HDR no es compatible con la versión AOSP Android 7.0.

Descubrimiento

La reproducción HDR requiere un decodificador compatible con HDR y una conexión a una pantalla compatible con HDR. Opcionalmente, algunas tecnologías requieren de un extractor específico.

Mostrar

Las aplicaciones utilizarán la nueva API Display.getHdrCapabilities para consultar las tecnologías HDR admitidas por la pantalla especificada. Esta es básicamente la información en el bloque de datos de metadatos estáticos EDID como se define en CTA-861.3:

  • public Display.HdrCapabilities getHdrCapabilities()
    Devuelve las capacidades HDR de la pantalla.
  • Display.HdrCapabilities
    Encapsula las capacidades HDR de una pantalla determinada. Por ejemplo, qué tipos de HDR admite y detalles sobre los datos de luminancia deseados.

Constantes:

  • int HDR_TYPE_DOLBY_VISION
    Soporte Dolby Visión.
  • int HDR_TYPE_HDR10
    Soporte HDR10/PQ.
  • int HDR_TYPE_HDR10_PLUS
    Soporte HDR10+.
  • int HDR_TYPE_HLG
    Soporte híbrido Log-Gamma.
  • float INVALID_LUMINANCE
    Valor de luminancia no válido.

Métodos públicos:

  • float getDesiredMaxAverageLuminance()
    Devuelve los datos de luminancia promedio de cuadros máximos del contenido deseado en cd/cd/m 2 para esta pantalla.
  • float getDesiredMaxLuminance()
    Devuelve los datos de luminancia máxima del contenido deseado en cd/cd/m 2 para esta pantalla.
  • float getDesiredMinLuminance()
    Devuelve los datos de luminancia mínima del contenido deseado en cd/cd/m 2 para esta pantalla.
  • int[] getSupportedHdrTypes()
    Obtiene los tipos HDR admitidos de esta pantalla (ver constantes). Devuelve una matriz vacía si la pantalla no admite HDR.

Descifrador

Las aplicaciones utilizarán la API CodecCapabilities.profileLevels existente para verificar la compatibilidad con los nuevos perfiles compatibles con HDR:

Dolby Vision

Constante mime MediaFormat :

String MIMETYPE_VIDEO_DOLBY_VISION

Constantes del perfil MediaCodecInfo.CodecProfileLevel :

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

Las aplicaciones de vídeo deben concatenar las capas de vídeo y los metadatos de Dolby Vision en un único búfer por fotograma. Esto lo hace automáticamente el MediaExtractor compatible con Dolby-Vision.

HEVCHDR 10

Constantes del perfil MediaCodecInfo.CodecProfileLevel :

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG y PQ

Constantes del perfil MediaCodecInfo.CodecProfileLevel :

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Si una plataforma admite un decodificador compatible con HDR, también admitirá un extractor compatible con HDR.

Sólo los decodificadores tunelizados tienen la garantía de reproducir contenido HDR. La reproducción mediante decodificadores sin túnel puede provocar que se pierda la información HDR y que el contenido se aplane en un volumen de color SDR.

Extractor

Los siguientes contenedores son compatibles con las distintas tecnologías HDR en Android 7.0:

Tecnología Dolby Vision HDR10 VP9-HLG VP9-PQ
Envase MP4 MP4 WebM WebM

La plataforma no admite el descubrimiento de si una pista (de un archivo) requiere compatibilidad con HDR. Las aplicaciones pueden analizar los datos específicos del códec para determinar si una pista requiere un perfil HDR específico.

Resumen

Los requisitos de los componentes para cada tecnología HDR se muestran en la siguiente tabla:

Tecnología Dolby Vision HDR10 VP9-HLG VP9-PQ
Tipo HDR soportado (Pantalla) HDR_TYPE_DOLBY_VISION HDR_TYPE_HDR10 HDR_TYPE_HLG HDR_TYPE_HDR10
Contenedor (Extractor) MP4 MP4 WebM WebM
Descifrador MIMETYPE_VIDEO_DOLBY_VISION MIMETYPE_VIDEO_HEVC MIMETYPE_VIDEO_VP9 MIMETYPE_VIDEO_VP9
Perfil (decodificador) Uno de los perfiles Dolby. PerfilHEVCPrincipal10HDR10 VP9Profile2HDR o VP9Profile3HDR VP9Profile2HDR o VP9Profile3HDR

Notas:

  • Los flujos de bits Dolby-Vision se empaquetan en un contenedor MP4 de una manera definida por Dolby. Las aplicaciones pueden implementar sus propios extractores compatibles con Dolby siempre que empaqueten las unidades de acceso de las capas correspondientes en una única unidad de acceso para el decodificador según lo definido por Dolby.
  • Una plataforma puede admitir un extractor compatible con HDR, pero ningún decodificador compatible con HDR correspondiente.

Reproducción

Después de que una aplicación haya verificado la compatibilidad con la reproducción HDR, puede reproducir contenido HDR casi de la misma manera que reproduce contenido que no es HDR, con las siguientes advertencias:

  • Para Dolby-Vision, no está disponible de inmediato si un archivo/pista multimedia específico requiere o no un decodificador compatible con HDR. La aplicación debe tener esta información por adelantado o poder obtenerla analizando la sección de datos específicos del códec de MediaFormat.
  • CodecCapabilities.isFormatSupported no considera si la función de descodificador tunelizado es necesaria para admitir dicho perfil.

Habilitar la compatibilidad con la plataforma HDR

Los proveedores de SoC y los OEM deben realizar un trabajo adicional para habilitar la compatibilidad con la plataforma HDR para un dispositivo.

Cambios de plataforma en Android 7.0 para HDR

A continuación se muestran algunos cambios clave en la plataforma (aplicación/capa nativa) que los OEM y SOC deben tener en cuenta.

Mostrar

Composición del hardware

Las plataformas compatibles con HDR deben admitir la combinación de contenido HDR con contenido que no sea HDR. Las características y operaciones de combinación exactas no están definidas por Android a partir de la versión 7.0, pero el proceso generalmente sigue estos pasos:

  1. Determine un espacio/volumen de color lineal que contenga todas las capas que se van a componer, en función del color, la masterización y los posibles metadatos dinámicos de las capas.
    Si se compone directamente en una pantalla, este podría ser el espacio lineal que coincide con el volumen de color de la pantalla.
  2. Convierta todas las capas al espacio de color común.
  3. Realizar la mezcla.
  4. Si se muestra a través de HDMI:
    1. Determine el color, la masterización y los posibles metadatos dinámicos para la escena combinada.
    2. Convierta la escena combinada resultante al espacio/volumen de color derivado.
  5. Si se muestra directamente en la pantalla, convierta la escena combinada resultante a las señales de pantalla requeridas para producir esa escena.

Mostrar descubrimiento

La detección de pantalla HDR solo se admite a través de HWC2. Los implementadores de dispositivos deben habilitar selectivamente el adaptador HWC2 que se lanza con Android 7.0 para que esta característica funcione. Por lo tanto, las plataformas deben agregar soporte para HWC2 o ampliar el marco AOSP para permitir una forma de proporcionar esta información. HWC2 expone una nueva API para propagar datos estáticos HDR al marco y la aplicación.

hdmi

  • Una pantalla HDMI conectada anuncia su capacidad HDR a través de HDMI EDID como se define en CTA-861.3 sección 4.2.
  • Se utilizará el siguiente mapeo EOTF:
    • ET_0 Gamma tradicional - Rango de luminancia SDR: no asignado a ningún tipo HDR
    • ET_1 Gamma tradicional - Rango de luminancia HDR: no asignado a ningún tipo de HDR
    • ET_2 SMPTE ST 2084 - asignado al tipo HDR HDR10
  • La señalización del soporte Dolby Vision o HLG a través de HDMI se realiza según lo definido por sus respectivos organismos.
  • Tenga en cuenta que la API HWC2 utiliza valores flotantes de luminancia deseados, por lo que los valores EDID de 8 bits deben traducirse de manera adecuada.

Decodificadores

Las plataformas deben agregar decodificadores tunelizados con capacidad HDR y anunciar su compatibilidad con HDR. Generalmente, los decodificadores compatibles con HDR deben:

  • Admite decodificación tunelizada ( FEATURE_TunneledPlayback ).
  • Admite metadatos estáticos HDR ( OMX.google.android.index.describeHDRColorInfo ) y su propagación a la composición de pantalla/hardware. Para HLG, se deben enviar metadatos apropiados a la pantalla.
  • Admite descripción de color ( OMX.google.android.index.describeColorAspects ) y su propagación a la composición de pantalla/hardware.
  • Admite metadatos integrados HDR según lo definido por el estándar correspondiente.

Compatibilidad con el decodificador Dolby Vision

Para admitir Dolby Vision, las plataformas deben agregar un decodificador HDR OMX compatible con Dolby-Vision. Dadas las características específicas de Dolby Vision, normalmente se trata de un decodificador contenedor de uno o más decodificadores AVC y/o HEVC, así como un compositor. Dichos decodificadores deben:

  • Admite el tipo mime "video/dolby-vision".
  • Anuncie perfiles/niveles de Dolby Vision compatibles.
  • Acepte unidades de acceso que contengan las subunidades de acceso de todas las capas según lo definido por Dolby.
  • Acepte datos específicos del códec definidos por Dolby. Por ejemplo, datos que contienen el perfil/nivel de Dolby Vision y posiblemente los datos específicos del códec para los decodificadores internos.
  • Admite el cambio adaptativo entre perfiles/niveles de Dolby Vision según lo requiera Dolby.

Al configurar el decodificador, el perfil Dolby real no se comunica al códec. Esto sólo se hace a través de datos específicos del códec después de que se haya iniciado el decodificador. Una plataforma podría optar por admitir múltiples decodificadores Dolby Vision: uno para perfiles AVC y otro para perfiles HEVC para poder inicializar los códecs subyacentes durante el tiempo de configuración. Si un único decodificador Dolby Vision admite ambos tipos de perfiles, también debe admitir el cambio entre ellos de forma dinámica y adaptativa.

Si una plataforma proporciona un decodificador compatible con Dolby-Vision además del soporte general para el decodificador HDR, debe:

  • Proporcione un extractor compatible con Dolby-Vision, incluso si no admite reproducción HDR.
  • Proporcione un decodificador que admita el perfil de visión definido por Dolby.

Compatibilidad con el decodificador HDR10

Para admitir HDR10, las plataformas deben agregar un decodificador OMX compatible con HDR10. Normalmente se trata de un decodificador HEVC tunelizado que también admite el análisis y el manejo de metadatos relacionados con HDMI. Dicho decodificador (además del soporte general para el decodificador HDR) debe:

  • Admite el tipo mime "video/hevc".
  • Publicidad compatible con HEVCMain10HDR10. La compatibilidad con el perfil HEVCMain10HRD10 también requiere admitir el perfil HEVCMain10, lo que requiere admitir el perfil HEVCMain en los mismos niveles.
  • Admite el análisis de los bloques SEI de metadatos de masterización, así como otra información relacionada con HDR contenida en SPS.

Compatibilidad con el decodificador VP9

Para admitir VP9 HDR, las plataformas deben agregar un decodificador HDR OMX compatible con VP9 Profile2. Normalmente se trata de un decodificador VP9 tunelizado que también admite el manejo de metadatos relacionados con HDMI. Dichos decodificadores (además del soporte general para decodificadores HDR) deben:

  • Admite el tipo mime "video/x-vnd.on2.vp9".
  • Publicidad compatible con VP9Profile2HDR. La compatibilidad con el perfil VP9Profile2HDR también requiere compatibilidad con el perfil VP9Profile2 en el mismo nivel.

Extractores

Soporte de extractor Dolby Vision

Las plataformas que admiten decodificadores Dolby Vision deben agregar compatibilidad con Dolby Extractor (llamado Dolby Extractor) para contenido Dolby Video.

  • Un extractor de MP4 normal sólo puede extraer la capa base de un archivo, pero no las capas de mejora o metadatos. Por lo tanto, se necesita un extractor Dolby especial para extraer los datos del archivo.
  • El extractor Dolby debe exponer de 1 a 2 pistas por cada pista (grupo) de vídeo Dolby:
    • Una pista Dolby Vision HDR con el tipo "video/dolby-vision" para la transmisión Dolby combinada de 2/3 capas. Dolby debe definir el formato de unidad de acceso de la pista HDR, que define cómo empaquetar las unidades de acceso de las capas base/mejora/metadatos en un único búfer para ser decodificado en un solo cuadro HDR.
    • Si una pista de video Dolby Vision contiene una capa base (BL) separada (compatible con versiones anteriores), el extractor también debe exponerla como una pista "video/avc" o "video/hevc" separada. El extractor debe proporcionar unidades de acceso AVC/HEVC regulares para esta vía.
    • La pista BL debe tener el mismo ID único de pista ("ID de pista") que la pista HDR para que la aplicación entienda que se trata de dos codificaciones del mismo vídeo.
    • La aplicación puede decidir qué pista elegir según la capacidad de la plataforma.
  • El perfil/nivel de Dolby Vision debe exponerse en el formato de pista de la pista HDR.
  • Si una plataforma proporciona un decodificador compatible con Dolby-Vision, también debe proporcionar un extractor compatible con Dolby-Vision, incluso si no admite la reproducción HDR.

Compatibilidad con extractores HDR10 y VP9 HDR

No hay requisitos de extractor adicionales para admitir HDR10 o VP9 HLG. Las plataformas deben ampliar el extractor de MP4 para que admita VP9 PQ en MP4. Los metadatos estáticos HDR se deben propagar en el flujo de bits de VP9 PQ, de modo que estos metadatos se pasen al decodificador de VP9 PQ y a la pantalla a través de la canalización normal MediaExtractor => MediaCodec.

Extensiones Stagefright para compatibilidad con Dolby Vision

Las plataformas deben agregar compatibilidad con el formato Dolby Vision a Stagefright:

  • Soporte para consulta de definición de puerto para puerto comprimido.
  • Admite enumeración de perfiles/niveles para decodificador DV.
  • Admite la exposición de perfil/nivel DV para pistas DV HDR.

Detalles de implementación específicos de la tecnología

Canalización del decodificador HDR10

Figura 1. Canalización HDR10

Los flujos de bits HDR10 están empaquetados en contenedores MP4. Las aplicaciones utilizan un extractor de MP4 normal para extraer los datos del cuadro y enviarlos al decodificador.

  • Extractor MPEG4
    Los flujos de bits HDR10 son reconocidos como un flujo HEVC normal mediante un MPEG4Extractor y se extraerá la pista HDR con el tipo "video/HEVC". El marco elige un decodificador de video HEVC que admite el perfil Main10HDR10 para decodificar esa pista.
  • Decodificador HEVC
    La información HDR está en SEI o SPS. El decodificador HEVC recibe primero fotogramas que contienen la información HDR. Luego, el decodificador extrae la información HDR y notifica a la aplicación que está decodificando un video HDR. La información HDR se incluye en el formato de salida del decodificador, que luego se propaga a la superficie.

Acciones del vendedor

  1. Anuncie el perfil de decodificador HDR compatible y el tipo de nivel OMX. Ejemplo:
    OMX_VIDEO_HEVCProfileMain10HDR10 (y Main10 )
  2. Implementar soporte para el índice: ' OMX.google.android.index.describeHDRColorInfo '
  3. Implementar soporte para el índice: ' OMX.google.android.index.describeColorAspects '
  4. Implementar soporte para el análisis SEI de metadatos de masterización.

Tubería de decodificador Dolby Vision

Figura 2. Canalización de Dolby Vision

Los Dolby-bitstreams están empaquetados en contenedores MP4 según lo define Dolby. En teoría, las aplicaciones podrían utilizar un extractor de MP4 normal para extraer la capa base, la capa de mejora y la capa de metadatos de forma independiente; sin embargo, esto no se ajusta al modelo actual de Android MediaExtractor/MediaCodec.

  • Extractor Dolby:
    • Los flujos de bits Dolby son reconocidos por un DolbyExtractor, que expone las distintas capas como 1 o 2 pistas para cada pista de vídeo Dolby (grupo):
      • Una pista HDR con el tipo "video/dolby-vision" para la transmisión Dolby combinada de 2/3 capas. Dolby debe definir el formato de unidad de acceso de la pista HDR, que define cómo empaquetar las unidades de acceso de las capas base/mejora/metadatos en un único búfer para ser decodificado en un solo cuadro HDR.
      • (Opcional, solo si el BL es compatible con versiones anteriores) Una pista BL contiene solo la capa base, que debe ser decodificable mediante un decodificador MediaCodec normal, por ejemplo, un decodificador AVC/HEVC. El extractor debe proporcionar unidades de acceso AVC/HEVC regulares para esta vía. Esta pista BL debe tener el mismo ID único de pista ("ID de pista") que la pista Dolby para que la aplicación entienda que se trata de dos codificaciones del mismo vídeo.
    • La aplicación puede decidir qué pista elegir según la capacidad de la plataforma.
    • Debido a que una pista HDR tiene un tipo HDR específico, el marco elegirá un decodificador de video Dolby para decodificar esa pista. La pista BL será decodificada por un decodificador de vídeo AVC/HEVC normal.
  • DolbyDecodificador:
    • El DolbyDecoder recibe unidades de acceso que contienen las unidades de acceso requeridas para todas las capas (EL+BL+MD o BL+MD)
    • La información CSD (datos específicos del códec, como SPS+PPS+VPS) para las capas individuales se puede empaquetar en 1 cuadro CSD que Dolby definirá. Se requiere tener una única trama CSD.

acciones dolby

  1. Definir el empaquetado de unidades de acceso para los diversos esquemas de contenedor Dolby (por ejemplo, BL+EL+MD) para el decodificador Dolby abstracto (es decir, el formato de búfer esperado por el decodificador HDR).
  2. Defina el empaquetado de CSD para el decodificador Dolby abstracto.

Acciones del vendedor

  1. Implementar extractor Dolby. Esto también lo puede hacer Dolby.
  2. Integre DolbyExtractor en el marco. El punto de entrada es frameworks/av/media/libstagefright/MediaExtractor.cpp .
  3. Declarar perfil de decodificador HDR y tipo de nivel OMX. Ejemplo: OMX_VIDEO_DOLBYPROFILETYPE y OMX_VIDEO_DOLBYLEVELTYP .
  4. Implementar soporte para el índice: 'OMX.google.android.index.describeColorAspects '
  5. Propague los metadatos HDR dinámicos a la aplicación y aparezca en cada cuadro. Normalmente, esta información debe empaquetarse en el marco decodificado según lo define Dolby, porque el estándar HDMI no proporciona una manera de pasarla a la pantalla.

Canalización del decodificador VP9

Figura 3. Canalización VP9-PQ

Los flujos de bits de VP9 se empaquetan en contenedores WebM de una manera definida por el equipo de WebM. Las aplicaciones necesitan utilizar un extractor WebM para extraer metadatos HDR del flujo de bits antes de enviar fotogramas al decodificador.

  • Extractor WebM:
  • Decodificador VP9:
    • El decodificador recibe flujos de bits de Profile2 y los decodifica como flujos VP9 normales.
    • El decodificador recibe los metadatos estáticos HDR del marco.
    • El decodificador recibe metadatos estáticos a través de las unidades de acceso de flujo de bits para flujos VP9 PQ.
    • El decodificador VP9 debe poder propagar los metadatos estáticos/dinámicos HDR a la pantalla.

Acciones del vendedor

  1. Implementar soporte para índice: OMX.google.android.index.describeHDRColorInfo
  2. Implementar soporte para índice: OMX.google.android.index.describeColorAspects
  3. Propagar metadatos estáticos HDR