Reproducción de video HDR

El video de alto rango dinámico (HDR) es la próxima frontera en la decodificación de video de alta calidad, ya que ofrece una calidad de reproducción de escenas inigualable. Esto se logra aumentando significativamente el rango dinámico del componente de luminancia (de los 100 cd/m² actuales a miles de cd/m²) y usando un espacio de color mucho más amplio (BT 2020). Ahora es un elemento central de la evolución del 4K UHD en el espacio de la TV.

Android 10 admite los siguientes videos HDR.

• HDR10
• VP9
• HDR10+

A partir de Android 9 y versiones posteriores, MediaCodec informa los metadatos HDR independientemente del modo de túnel. Puedes obtener datos decodificados junto con metadatos estáticos o dinámicos en el modo sin túnel. En el caso de HDR10 y VP9Profile2, que usan metadatos estáticos, estos se registran en el formato de salida con la clave KEY_HDR_STATIC_INFO. En el caso de HDR10+ que usa metadatos dinámicos, esto se informa con la clave KEY_HDR10_PLUS_INFO en el formato de salida y puede cambiar para cada fotograma de salida. Para obtener más información, consulta Túneles multimedia.

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

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

Tecnologías HDR compatibles

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

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

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

Descubrimiento

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

Pantalla

Las aplicaciones deben usar la nueva API de Display.getHdrCapabilities para consultar las tecnologías HDR compatibles con la pantalla especificada. Básicamente, esta es la información del bloque de datos de metadatos estáticos del EDID, según se define en CTA-861.3:

• public Display.HdrCapabilities getHdrCapabilities()
  Devuelve las capacidades de HDR de la pantalla.
• Display.HdrCapabilities
  Encapsula las capacidades de 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
  Compatibilidad con Dolby Vision.
• int HDR_TYPE_HDR10
  Compatibilidad con HDR10 y PQ.
• int HDR_TYPE_HDR10_PLUS
  Compatibilidad con HDR10+.
• int HDR_TYPE_HLG
  Es compatible con Hybrid Log-Gamma.
• float INVALID_LUMINANCE
  El valor de luminancia no es válido.

Métodos públicos:

• float getDesiredMaxAverageLuminance()
  Devuelve los datos de luminancia promedio máxima de fotogramas del contenido deseado en cd/m² para esta pantalla.
• float getDesiredMaxLuminance()
  Devuelve los datos de luminancia máxima del contenido deseado en cd/m² para esta pantalla.
• float getDesiredMinLuminance()
  Devuelve los datos de luminancia mínima del contenido deseado en cd/m² para esta pantalla.
• int[] getSupportedHdrTypes()
  Obtiene los tipos de HDR compatibles con esta pantalla (consulta las constantes). Devuelve un array vacío si la pantalla no admite HDR.

Decodificador

Las aplicaciones deben usar la API de CodecCapabilities.profileLevels existente para verificar la compatibilidad con los nuevos perfiles compatibles con HDR:

Dolby Vision

Constante de MIME MediaFormat:

String MIMETYPE_VIDEO_DOLBY_VISION

Constantes de perfil MediaCodecInfo.CodecProfileLevel:

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

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

HEVC HDR 10

Constantes de 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 debe admitir un extractor compatible con HDR.

Solo se garantiza que los decodificadores con túnel reproducen contenido HDR. La reproducción con decodificadores no tunelizados puede provocar la pérdida de la información de HDR y que el contenido se aplane en un volumen de color SDR.

Extractor

Se admiten los siguientes contenedores para las distintas tecnologías HDR en Android 7.0:

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 un segmento requiere un perfil HDR específico.

Resumen

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

Notas:

• Los flujos de bits de 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 y cuando empaqueten las unidades de acceso de las capas correspondientes en una sola unidad de acceso para el decodificador, según lo define Dolby.
• Una plataforma puede admitir un extractor compatible con HDR, pero no un decodificador compatible con HDR correspondiente.

Reproducción

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

• En el caso de Dolby Vision, no se sabe de inmediato si un archivo o pista de medios específico requiere un decodificador compatible con HDR. La aplicación debe tener esta información con anticipación o poder obtenerla analizando la sección de datos específicos del códec de MediaFormat.
• CodecCapabilities.isFormatSupported no considera si se requiere la función de decodificador en túnel para admitir ese perfil.

Habilita la compatibilidad con la plataforma HDR

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

Cambios en la plataforma de Android 7.0 para HDR

Estos son algunos cambios clave en la plataforma (capa nativa o de la app) que los OEM y los SoC deben tener en cuenta.

Pantalla

Composición del hardware

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

1. Determina un espacio o volumen de color lineal que contenga todas las capas que se compondrán, según el color, la masterización y los posibles metadatos dinámicos de las capas.
   Si se realiza la composición directamente en una pantalla, este podría ser el espacio lineal que coincide con el volumen de color de la pantalla.
2. Convierte todas las capas al espacio de color común.
3. Realiza la combinación.
4. Si la pantalla se muestra a través de HDMI, haz lo siguiente:
   1. Determina el color, la masterización y los posibles metadatos dinámicos de la escena combinada.
   2. Convierte la escena combinada resultante en el espacio o volumen de color derivado.
5. Si se muestra directamente en la pantalla, convierte la escena combinada resultante en los indicadores de pantalla necesarios para producir esa escena.

Descubrimiento de la pantalla

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

HDMI

• Una pantalla HDMI conectada anuncia su capacidad de HDR a través de HDMI EDID, como se define en la sección 4.2 de CTA-861.3.
• Se debe usar la siguiente asignación de EOTF:
  • ET_0 Gamma tradicional: rango de luminancia SDR: No se asigna a ningún tipo de HDR
  • ET_1 Gamma tradicional: El rango de luminancia HDR no se asigna a ningún tipo de HDR.
  • ET_2 SMPTE ST 2084: Se asigna al tipo de HDR HDR10.
• La señalización de la compatibilidad con Dolby Vision o HLG a través de HDMI se realiza según lo definen sus organismos pertinentes.
• Ten en cuenta que la API de HWC2 usa valores de luminancia deseada de coma flotante, por lo que los valores de EDID de 8 bits se deben traducir de manera adecuada.

Decodificadores

Las plataformas deben agregar decodificadores con túneles compatibles con HDR y anunciar su compatibilidad con HDR. En general, los decodificadores compatibles con HDR deben cumplir con los siguientes requisitos:

• Admite la decodificación en túnel (FEATURE_TunneledPlayback).
• Admite metadatos estáticos de HDR (OMX.google.android.index.describeHDRColorInfo) y su propagación a la composición de hardware o pantalla. En el caso de HLG, se deben enviar los metadatos adecuados a la pantalla.
• Admite la descripción del color (OMX.google.android.index.describeColorAspects) y su propagación a la composición de la pantalla o el hardware.
• Admitir metadatos HDR integrados según lo define el estándar pertinente

Compatibilidad con el decodificador Dolby Vision

Para admitir Dolby Vision, las plataformas deben agregar un decodificador OMX HDR compatible con Dolby Vision. Dadas las especificaciones de Dolby Vision, este suele ser un decodificador wrapper alrededor de uno o más decodificadores AVC o HEVC, así como un compositor. Estos decodificadores deben cumplir con los siguientes requisitos:

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

Cuando se configura el decodificador, el perfil de Dolby real no se comunica al códec. Esto solo se hace a través de datos específicos del códec después de que se inicia el decodificador. Una plataforma podría optar por admitir varios decodificadores de Dolby Vision: uno para los perfiles de AVC y otro para los perfiles de HEVC, de modo que se puedan inicializar los códecs subyacentes durante el tiempo de configuración. Si un solo 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 de la compatibilidad general con el decodificador HDR, debe cumplir con los siguientes requisitos:

• Proporcionar un extractor compatible con Dolby Vision, incluso si no admite la reproducción de HDR.
• Proporciona un decodificador que admita el perfil de visión según lo define Dolby.

Compatibilidad con el decodificador HDR10

Para admitir HDR10, las plataformas deben agregar un decodificador OMX compatible con HDR10. Por lo general, se trata de un decodificador HEVC con túnel que también admite el análisis y el control de metadatos relacionados con HDMI. Este decodificador (además de la compatibilidad general con el decodificador HDR) debe cumplir con los siguientes requisitos:

• Se admite el tipo de MIME "video/hevc".
• Anuncia la compatibilidad con HEVCMain10HDR10. La compatibilidad con el perfil HEVCMain10HRD10 también requiere la compatibilidad con el perfil HEVCMain10, que a su vez requiere la compatibilidad con el perfil HEVCMain en los mismos niveles.
• Se admite el análisis de los bloques de SEI de metadatos de masterización, así como otra información relacionada con HDR que se incluye en el SPS.

Compatibilidad con el decodificador VP9

Para admitir HDR VP9, las plataformas deben agregar un decodificador OMX HDR compatible con VP9 Profile2. Por lo general, se trata de un decodificador VP9 con túnel que también admite el procesamiento de metadatos relacionados con HDMI. Estos decodificadores (además de la compatibilidad general con el decodificador HDR) deben cumplir con los siguientes requisitos:

• Se admite el tipo MIME "video/x-vnd.on2.vp9".
• Anuncia la compatibilidad con VP9Profile2HDR. La compatibilidad con el perfil VP9Profile2HDR también requiere la compatibilidad con el perfil VP9Profile2 en el mismo nivel.

Extractores

Compatibilidad con el extractor de Dolby Vision

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

• Un extractor de MP4 normal solo puede extraer la capa base de un archivo, pero no las capas de mejora ni de metadatos. Por lo tanto, se necesita un extractor Dolby especial para extraer los datos del archivo.
• El extractor de Dolby debe exponer de 1 a 2 pistas para cada pista de video de Dolby (grupo):
  • Una pista HDR de Dolby Vision con el tipo "video/dolby-vision" para la transmisión combinada de Dolby de 2 o 3 capas. Dolby definirá el formato de unidad de acceso de la pista HDR, que define cómo empaquetar las unidades de acceso de las capas base, de mejora y de metadatos en un solo búfer para decodificarlo en un solo fotograma HDR.
  • Si una pista de video de Dolby Vision contiene una capa base (BL) independiente (retrocompatible), el extractor también debe exponerla como una pista independiente de "video/avc" o "video/hevc". El extractor debe proporcionar unidades de acceso AVC/HEVC regulares para este segmento.
  • El segmento BL debe tener el mismo ID único de segmento ("track-ID") que el segmento HDR para que la app comprenda que se trata de dos codificaciones del mismo video.
  • La aplicación puede decidir qué pista elegir según la capacidad de la plataforma.
• El perfil o nivel de Dolby Vision debe exponerse en el formato 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 el extractor HDR de HDR10 y VP9

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

Extensiones de Stagefright para la compatibilidad con Dolby Vision

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

• Se agregó compatibilidad con la consulta de definición de puerto para el puerto comprimido.
• Se admite la enumeración de perfiles o niveles para el decodificador de DV.
• Se admite la exposición del perfil o nivel de DV para las pistas HDR de DV.

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 se empaquetan en contenedores MP4. Las aplicaciones usan un extractor de MP4 normal para extraer los datos de los fotogramas y enviarlos al decodificador.

• MPEG4 Extractor
  Un MPEG4Extractor reconoce los flujos de bits HDR10 como un flujo HEVC normal, y se extraerá la pista HDR con el tipo "video/HEVC". El framework elige un decodificador de video HEVC que admita el perfil Main10HDR10 para decodificar esa pista.
• Decodificador HEVC
  La información de HDR se encuentra en SEI o SPS. Primero, el decodificador HEVC recibe los fotogramas que contienen la información de HDR. Luego, el decodificador extrae la información de HDR y notifica a la aplicación que está decodificando un video HDR. La información de HDR se incluye en el formato de salida del decodificador, que se propaga a la superficie más adelante.

Acciones del proveedor

1. Anuncia el perfil y el nivel del decodificador HDR admitidos del tipo OMX. Ejemplo:
   OMX_VIDEO_HEVCProfileMain10HDR10 (y Main10)
2. Implementa la compatibilidad con el índice: "OMX.google.android.index.describeHDRColorInfo"
3. Implementa la compatibilidad con el índice: "OMX.google.android.index.describeColorAspects"
4. Implementa la compatibilidad con el análisis de SEI de los metadatos de masterización.

Canalización del decodificador Dolby Vision

Figura 2: Canalización de Dolby Vision

Los flujos de bits de Dolby se empaquetan en contenedores MP4 según lo define Dolby. En teoría, las aplicaciones podrían usar un extractor 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 MediaExtractor/MediaCodec de Android.

• DolbyExtractor:
  • Los DolbyExtractor reconocen los flujos de bits de Dolby, que exponen las distintas capas como 1 o 2 pistas para cada pista de video de Dolby (grupo):
    • Es un segmento HDR con el tipo "video/dolby-vision" para la transmisión de Dolby combinada de 2/3 capas. Dolby definirá el formato de unidad de acceso de la pista HDR, que define cómo empaquetar las unidades de acceso de las capas base, de mejora y de metadatos en un solo búfer para decodificarlo en un solo fotograma HDR.
    • (Opcional, solo si la BL es retrocompatible) Una pista de BL contiene solo la capa base, que debe poder decodificarse con el decodificador MediaCodec normal, por ejemplo, el decodificador AVC/HEVC. El extractor debe proporcionar unidades de acceso AVC/HEVC normales para este segmento. Este segmento de BL debe tener el mismo ID único de segmento ("track-ID") que el segmento de Dolby para que la aplicación comprenda que se trata de dos codificaciones del mismo video.
  • La aplicación puede decidir qué pista elegir según la capacidad de la plataforma.
  • Dado que una pista HDR tiene un tipo de HDR específico, el framework elegirá un decodificador de video Dolby para decodificar esa pista. La pista de BL se decodificará con un decodificador de video AVC/HEVC normal.
• DolbyDecoder:
  • 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 de CSD (datos específicos del códec, como SPS + PPS + VPS) para las capas individuales se puede empaquetar en 1 fotograma de CSD que Dolby definirá. Se requiere tener un solo fotograma de CSD.

Acciones de Dolby

1. Define el empaquetado de las unidades de acceso para los distintos esquemas de contenedores Dolby (p. ej., BL+EL+MD) para el decodificador Dolby abstracto (es decir, el formato de búfer que espera el decodificador HDR).
2. Define el empaquetado de CSD para el decodificador abstracto de Dolby.

Acciones del proveedor

1. Implementa el extractor de Dolby. Dolby también puede hacerlo.
2. Integra DolbyExtractor en el framework. El punto de entrada es frameworks/av/media/libstagefright/MediaExtractor.cpp.
3. Declara el perfil y el nivel del decodificador HDR del tipo OMX. Ejemplo: OMX_VIDEO_DOLBYPROFILETYPE y OMX_VIDEO_DOLBYLEVELTYP.
4. Implementa la compatibilidad con el índice: 'OMX.google.android.index.describeColorAspects'
5. Propaga los metadatos de HDR dinámico a la app y a la superficie en cada fotograma. Por lo general, esta información debe empaquetarse en el fotograma decodificado según lo define Dolby, ya que el estándar HDMI no proporciona una forma de pasar esta información a la pantalla.

Canalización del decodificador VP9

Figura 3: Canalización de VP9-PQ

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

• Extractor de WebM:
  • WebM Extractor extrae los metadatos y los fotogramas HDR del contenedor.
• Decodificador VP9:
  • El decodificador recibe flujos de bits de Profile2 y los decodifica como flujos normales de VP9.
  • El decodificador recibe cualquier metadato estático de HDR del framework.
  • El decodificador recibe metadatos estáticos a través de las unidades de acceso de la secuencia de bits para las transmisiones de PQ de VP9.
  • El decodificador VP9 debe poder propagar los metadatos estáticos o dinámicos de HDR a la pantalla.

Acciones del proveedor

1. Implementa la compatibilidad con el índice: OMX.google.android.index.describeHDRColorInfo
2. Implementa la compatibilidad con el índice: OMX.google.android.index.describeColorAspects
3. Propaga metadatos estáticos de HDR