Reproducción de video HDR

Los videos de alto rango dinámico (HDR) son la siguiente frontera en cuanto a la decodificación de video de alta calidad, ya que ofrecen calidades de reproducción de escenas inigualables. Para ello, aumenta considerablemente el rango dinámico del componente de luminancia (de los 100 cd/m² actuales a miles de cd/m²) y utiliza un espacio de color mucho más amplio (BT 2020). Este es ahora un elemento central de la evolución en 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 de 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. Para HDR10 y VP9Profile2 que usan metadatos estáticos, estos se informan 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 en cada fotograma de salida. Consulta Túneles multimedia para obtener más información.

A partir de Android 7.0, la compatibilidad inicial con HDR incluye la creación de constantes adecuadas para el descubrimiento y la configuración de las canalización de video HDR. Es decir, se definen los tipos de códecs y los modos de visualización, y se especifica cómo se deben pasar los datos HDR a MediaCodec y proporcionarlos a los decodificadores de 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 HDR a través del modo de túnel, pero los dispositivos pueden agregar compatibilidad con la reproducción de HDR en SurfaceViews con búferes de video opacos. En otras palabras:

• No existe una API de Android estándar que verifique si la reproducción HDR es compatible con decodificadores no tunelizados.
• Los decodificadores de video túneles que anuncian la función de reproducción HDR deben ser compatibles con la reproducción HDR cuando se conectan a pantallas compatibles con ese formato.
• La versión 7.0 de Android de AOSP no admite la composición de GL de contenido HDR.

Descubrimiento

La reproducción HDR requiere un decodificador compatible con HDR y una conexión a una pantalla compatible con HDR. De forma 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, es la información del 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 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/PQ.
• int HDR_TYPE_HDR10_PLUS
  Compatibilidad con HDR10+
• int HDR_TYPE_HLG
  Compatibilidad con Log-Gamma híbrido
• float INVALID_LUMINANCE
  El valor de luminancia no es válido.

Métodos públicos:

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

Decodificador

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

Dolby Vision

Constante de MIME de 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 capas de video y los metadatos de Dolby Vision deben concatenarse en un solo búfer por fotogramas por las aplicaciones de video. Esto se hace automáticamente con MediaExtractor compatible con Dolby Vision.

HEVC HDR 10

Constantes del perfil MediaCodecInfo.CodecProfileLevel:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG y PQ

Constantes de 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 los decodificadores tunelizados tienen la garantía de reproducir contenido HDR. La reproducción con decodificadores no tunelizados puede provocar que se pierda la información de HDR y que el contenido se aplane en un volumen de color SDR.

Extractor

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

La plataforma no admite la detección 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

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 la manera que define 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 definido por 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 HDR, puede reproducir contenido HDR casi de la misma manera en que lo hace con contenido que no es HDR, con las siguientes advertencias:

• En el caso de Dolby Vision, no se puede saber de inmediato si un archivo o una pista de contenido multimedia específicos requieren 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 decodificador en túnel es necesaria para admitir ese perfil.

Habilita la compatibilidad con plataformas HDR

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

Cambios en la plataforma de Android 7.0 para HDR

A continuación, se muestran algunos cambios clave en la plataforma (capa nativa o de la app) que los OEM y los SOC deben conocer.

Pantalla

Composición del hardware

Las plataformas compatibles con HDR deben combinar contenido HDR con contenido que no sea HDR. Android no define las operaciones ni las características de combinación exactas a partir de la versión 7.0, pero el proceso suele seguir 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 compones directamente en una pantalla, este podría ser el espacio lineal que coincida 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 usas HDMI, haz lo siguiente:
   1. Determina el color, la masterización y los posibles metadatos dinámicos para la escena combinada.
   2. Convierte la escena combinada resultante en el espacio de color o el volumen derivados.
5. Si se muestra directamente en la pantalla, convierte la escena combinada resultante en los indicadores de pantalla necesarios para producir esa escena.

Campañas discovery de Display

El descubrimiento de pantallas HDR solo se admite a través de HWC2. Para que esta función se ejecute correctamente, los implementadores de dispositivos deben habilitar de manera selectiva el adaptador HWC2 que se lanzó con Android 7.0. 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 API nueva para propagar datos estáticos HDR al framework y a la aplicación.

HDMI

• Una pantalla HDMI conectada anuncia su capacidad de HDR mediante EDID HDMI, como se define en la sección 4.2 de CTA-861.3.
• Se debe usar la siguiente asignación EOTF:
  • ET_0 Gamma tradicional, rango de luminancia SDR: no asignado a ningún tipo de HDR
  • ET_1 Gamma tradicional: Rango de luminancia HDR: No se asigna a ningún tipo de HDR
  • ET_2 SMPTE ST 2084: asignado al tipo 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 los organismos relevantes.
• Ten en cuenta que la API de HWC2 usa valores de luminancia deseados de punto flotante, por lo que los valores de EDID de 8 bits deben traducirse de forma adecuada.

Decodificadores

Las plataformas deben agregar decodificadores con túneles compatibles con HDR y anunciar su compatibilidad con HDR. Por lo 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 HDR (OMX.google.android.index.describeHDRColorInfo) y su propagación a la composición de hardware o pantalla. Para HLG, se deben enviar los metadatos adecuados a la pantalla.
• Se agregó compatibilidad con la descripción del color (OMX.google.android.index.describeColorAspects) y su propagación a la composición de pantalla/hardware.
• Se admiten metadatos incorporados de HDR según la definición del estándar correspondiente.

Compatibilidad con decodificador Dolby Vision

Para admitir Dolby Vision, las plataformas deben agregar un decodificador OMX HDR compatible con Dolby Vision. Según los detalles de Dolby Vision, suele ser un decodificador de wrapper en torno a uno o más decodificadores AVC o HEVC, además de un compositor. Estos decodificadores deben cumplir con los siguientes requisitos:

• Compatibilidad con el tipo MIME "video/dolby-vision"
• Anunciar perfiles o niveles de Dolby Vision compatibles
• Acepta unidades de acceso que contengan las subunidades de acceso de todas las capas según lo definido por Dolby.
• Acepta datos específicos del códec definidos por Dolby. Por ejemplo, datos que contienen el nivel o perfil de Dolby Vision y, en algunos casos, datos específicos del códec para los decodificadores internos.
• Admitir el cambio adaptable entre perfiles o niveles de Dolby Vision, según lo requiera Dolby.

Cuando se configura el decodificador, el perfil 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 Dolby Vision: uno para perfiles AVC y otro para perfiles HEVC con el fin de poder inicializar códecs subyacentes durante la configuración. Si un solo decodificador de Dolby Vision admite ambos tipos de perfiles, también debe admitir el cambio entre ellos de forma dinámica y adaptativa.

Si, además de la compatibilidad general con el decodificador HDR, una plataforma proporciona un decodificador compatible con Dolby-Vision, debe cumplir con lo siguiente:

• Proporcionar un extractor con reconocimiento de Dolby-Vision, incluso si no es compatible con la reproducción HDR
• Proporcionar un decodificador que admita el perfil de visión como lo define Dolby

Compatibilidad con el decodificador HDR10

Para admitir HDR10, las plataformas deben agregar un decodificador OMX compatible con HDR10. Por lo general, es un decodificador HEVC con tunelización que también admite el análisis y el manejo de metadatos relacionados con HDMI. Este decodificador (además de la compatibilidad general con el decodificador HDR) debe hacer lo siguiente:

• Se admite el tipo de MIME “video/hevc”.
• Anuncia HEVCMain10HDR10 compatible. La compatibilidad con el perfil HEVCMain10HRD10 también requiere compatibilidad con el perfil HEVCMain10, 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 HDR VP9, las plataformas deben agregar un decodificador OMX HDR compatible con el perfil 2 de VP9. Por lo general, es un decodificador VP9 con túnel que también admite el manejo de metadatos relacionados con HDMI. Además de la compatibilidad general con el decodificador HDR, estos decodificadores deben hacer lo siguiente:

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

Extractores

Compatibilidad con el extractor Dolby Vision

Las plataformas que admiten decodificadores Dolby Vision deben agregar compatibilidad con el extractor de 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 de Dolby especial para extraer los datos del archivo.
• El extractor de Dolby debe exponer 1 o 2 pistas para cada pista de video Dolby (grupo):
  • Una pista HDR de Dolby Vision con el tipo “video/dolby-vision” para la transmisión de Dolby en capas combinadas. 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 de base, mejora o 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 (compatible con versiones anteriores), el extractor también debe exponerla como una pista “video/avc” o “video/hevc” independiente. El extractor debe proporcionar unidades de acceso AVC/HEVC normales para esta pista.
  • El segmento BL debe tener el mismo ID único de pista ("ID de pista") que el segmento HDR para que la app comprenda que estas son dos codificaciones del mismo video.
  • La aplicación puede decidir qué segmento elegir según la capacidad de la plataforma.
• El perfil o nivel de Dolby Vision se debe exponer 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 extractores HDR10 y VP9

No hay requisitos adicionales de extractor para admitir HDR10 ni VP9 HLG. Las plataformas deben extender el extractor MP4 para admitir VP9 PQ en MP4. Los metadatos estáticos de HDR deben propagarse en el flujo de bits PQ de VP9, de modo que estos metadatos se pasen al decodificador 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:

• Compatibilidad con la consulta de definición de puerto para un puerto comprimido.
• Se admite la enumeración de perfil/nivel para el decodificador de DV.
• Se admite la exposición del perfil/nivel de DV para 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 MP4 común para extraer los datos de la trama y enviarlos al decodificador.

• Extractor de MPEG4
  Un MPEG4Extractor reconoce los flujos de bits HDR10 como una transmisión 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. El decodificador HEVC recibe primero los fotogramas que contienen la información de HDR. Luego, el decodificador extrae la información HDR y notifica a la aplicación que está decodificando un video HDR. La información de HDR se agrupa en el formato de salida del decodificador, que se propaga a la superficie más adelante.

Acciones del proveedor

1. Anuncia el perfil de decodificador HDR y el tipo de OMX de nivel compatible. 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. Se implementó la compatibilidad con el análisis SEI de metadatos de masterización.

Canalización del decodificador de Dolby Vision

Figura 2: Canalización de Dolby Vision

Los Dolby-bitstream se empaquetan en contenedores de MP4 según la definición de 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:
  • DolbyExtractor reconoce los flujos de bits de Dolby, que exponen las diferentes capas como 1 o 2 pistas para cada pista de video de Dolby (grupo):
    • Una pista HDR con el tipo “video/dolby-vision” para la transmisión combinada de Dolby de 2 o 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, de mejora y de metadatos en un solo búfer para decodificarlas en un solo fotograma HDR.
    • (Opcional, solo si la BL es retrocompatible) Un segmento de BL solo contiene la capa base, que debe ser decodable por un decodificador MediaCodec normal, por ejemplo, un decodificador AVC/HEVC. El extractor debe proporcionar unidades de acceso AVC/HEVC normales para esta pista. Esta pista de BL debe tener el mismo ID de pista único ("ID de pista") que la pista Dolby para que la aplicación comprenda que se trata de dos codificaciones del mismo video.
  • La aplicación puede decidir qué segmento elegir en función de la capacidad de la plataforma.
  • Debido a que una pista HDR tiene un tipo de HDR específico, el framework elegirá un decodificador de video Dolby para decodificar esa pista. Un decodificador de video AVC/HEVC normal decodificará la pista BL.
• DolbyDecoder:
  • DolbyDecoder recibe unidades de acceso que contienen las unidades de acceso necesarias para todas las capas (EL+BL+MD o BL+MD).
  • La información de CSD (datos específicos de códecs, como SPS+PPS+VPS) para las capas individuales se puede empaquetar en 1 trama de CSD para que Dolby la defina. Se requiere tener un solo marco CSD.

Acciones de Dolby

1. Define el empaquetado de unidades de acceso para los diversos esquemas de contenedor de 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 Dolby abstracto.

Acciones del proveedor

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

Canalización de decodificador de VP9

Figura 3: Canalización de VP9-PQ

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

• Extractor de WebM:
  • El extractor de WebM extrae los metadatos y marcos HDR del contenedor.
• Decodificador VP9:
  • El decodificador recibe flujos de bits de Profile2 y los decodifica como transmisiones VP9 normales.
  • El decodificador recibe metadatos estáticos HDR del framework.
  • El decodificador recibe metadatos estáticos a través de las unidades de acceso de flujo de bits para las transmisiones de VP9 PQ.
  • El decodificador de VP9 debe 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