Reproducción de video HDR

Los videos de alto rango dinámico (HDR) son la próxima frontera en alta calidad y permite grabar videos con calidades inigualables de reproducción de escenas. Sí aumentando significativamente el rango dinámico del componente de luminancia (desde los 100 cd/m² actuales hasta miles de cd/m²) y el uso de espacio de color (BT 2020). Ahora esto es un elemento central de la evolución en 4K UHD en 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 modo no tunelizado. Para HDR10 y VP9Profile2, que usa metadatos estáticos, se informan en el formato de salida con claves KEY_HDR_STATIC_INFO Para HDR10+ que usa metadatos dinámicos, esto se informa con la tecla KEY_HDR10_PLUS_INFO en el formato de salida y puede cambiar para 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 Creación de constantes adecuadas para el descubrimiento y la configuración de video HDR canalizaciones. Esto significa definir tipos de códecs y modos de visualización, y especificar la manera en que se deben pasar los datos HDR a MediaCodec y suministrarse a los decodificadores de HDR

El objetivo de este documento es ayudar a los desarrolladores de aplicaciones a admitir transmisiones HDR reproducción y ayudar 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.

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

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

• No hay una API de Android estándar que verifique si se admite la reproducción HDR. con decodificadores no tunelizados.
• Los decodificadores de video tunelizados que promocionan la capacidad de reproducción HDR deben admitir la reproducción HDR cuando se conecta a pantallas compatibles con HDR.
• La composición GL del contenido HDR no es compatible con el AOSP de Android versión 7.0.

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 una protección extractor.

Pantalla

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

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

Constantes:

• int HDR_TYPE_DOLBY_VISION de
  Compatibilidad con Dolby Vision.
• int HDR_TYPE_HDR10 de
  Compatibilidad con HDR10 y PQ
• int HDR_TYPE_HDR10_PLUS de
  Compatibilidad con HDR10+
• int HDR_TYPE_HLG de
  Compatibilidad con Log-Gamma híbrido
• float INVALID_LUMINANCE de
  El valor de luminancia no es válido.

Métodos públicos:

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

Decodificador

Las aplicaciones deberán usar el API de CodecCapabilities.profileLevels para verificar la compatibilidad con el Perfiles nuevos 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 se deben concatenar en un solo por fotogramas en aplicaciones de video. Esto se hace automáticamente MediaExtractor compatible con Dolby-Vision.

HEVC HDR 10

Constantes de perfil MediaCodecInfo.CodecProfileLevel:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG y Calidad de imagen

Perfil de MediaCodecInfo.CodecProfileLevel constantes:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Si la plataforma admite un decodificador compatible con HDR, también deberá admitir un Extractor compatible con HDR.

Solo los decodificadores tunelizados tienen la garantía de reproducir contenido HDR. Reproducción por decodificadores no tunelizados, esto puede provocar que la información HDR se pierda y aplanar el contenido en un volumen de color SDR.

Extractor

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

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

No se debe determinar si la pista (de un archivo) requiere compatibilidad con HDR. compatibles con la plataforma. 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 forma definida por Dolby. Las aplicaciones pueden implementar sus propios extractores compatibles con Dolby, como siempre que empaqueten las unidades de acceso de las capas correspondientes en un unidad de acceso única para el decodificador, según lo define Dolby.
• Una plataforma puede admitir un extractor compatible con HDR, pero no corresponde decodificador compatible con HDR.

Reproducción

Una vez que la aplicación haya verificado la compatibilidad con la reproducción HDR, podrá reproducir contenido el contenido HDR casi de la misma forma que reproduce el contenido que no es HDR, con las siguientes advertencias:

• Para Dolby-Vision, si una pista o un archivo multimedia específico requiere o no un decodificador compatible con HDR no estará disponible de inmediato. La aplicación debe contar con esta información por adelantado o para obtenerla que analiza 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.

Habilitar la compatibilidad con la plataforma HDR

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

Cambios de plataforma en 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 conocer.

Pantalla

Composición del hardware

Las plataformas compatibles con HDR deben combinar contenido HDR con otros que no sean HDR. contenido. Las características y operaciones exactas de la combinación no están definidas por Android 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 van a compuesto, a partir de las capas color, masterización y posible dinámica metadatos.
   Si se compone 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 el modo HDMI, haz lo siguiente:
   1. Determinar el color, la masterización y los posibles metadatos dinámicos para el escena combinada.
   2. Convertir la escena combinada resultante al color derivado espacio/volumen.
5. Si se muestra directamente en la pantalla, convierte la combinación resultante. a las señales de pantalla requeridas para producir esa escena.

Campañas discovery de Display

La detección de pantallas HDR solo es compatible a través de HWC2. Los implementadores de dispositivos habilitar de forma selectiva el adaptador HWC2 que se lanzó con Android 7.0 para este para que funcione. Por lo tanto, las plataformas deben admitir HWC2 o extender la AOSP para permitir una forma de proporcionar esta información. HWC2 expone un nuevo archivo 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, tal como se define en CTA‐861.3 sección 4.2.
• Se debe usar la siguiente asignación EOTF:
  • ET_0 Gamma tradicional, rango de luminancia SDR: no asignado a ningún HDR tipo
  • ET_1 Gamma tradicional, rango de luminancia HDR: no asignado a ningún HDR tipo
  • ET_2 SMPTE ST 2084: asignado al tipo HDR HDR10
• La señalización de compatibilidad con Dolby Vision o HLG a través de HDMI se realiza según se define. por las entidades relevantes.
• Ten en cuenta que la API de HWC2 usa valores de luminancia flotantes deseados, por lo que la arquitectura Los valores de EDID deben traducirse de manera adecuada.

Decodificadores

Las plataformas deben agregar decodificadores de túneles compatibles con HDR y anunciar su formato y asistencia. En general, los decodificadores compatibles con HDR deben hacer lo siguiente:

• Se admite la decodificación en túnel (FEATURE_TunneledPlayback).
• Compatibilidad con metadatos estáticos de HDR (OMX.google.android.index.describeHDRColorInfo) y su a la composición de pantalla/hardware. Para HLG, los metadatos adecuados deben enviarse a la pantalla.
• Admitir descripción del color (OMX.google.android.index.describeColorAspects) y su a la composición de pantalla/hardware.
• Admiten metadatos incorporados de HDR según la definición del estándar correspondiente.

Compatibilidad con el decodificador Dolby Vision

Para admitir Dolby Vision, las plataformas deben agregar una herramienta compatible con Dolby-Vision. Decodificador HDR OMX. Según los detalles de Dolby Vision, este suele ser un de contenedor alrededor de uno o más decodificadores AVC o HEVC, así como un compositor. Estos decodificadores deben cumplir con lo siguiente:

• Se agregó compatibilidad con el tipo de MIME "video/dolby-vision".
• Anunciar perfiles o niveles de Dolby Vision compatibles
• Aceptar las unidades de acceso que contengan las subunidades de acceso de todas las capas, como definido por Dolby.
• Acepta datos específicos de códecs definidos por Dolby. Por ejemplo, datos que contienen el nivel/perfil de Dolby Vision y, posiblemente, datos específicos del códec para la decodificadores internos.
• Admite el cambio adaptable entre perfiles/niveles de Dolby Vision, como que requiere Dolby.

Cuando se configura el decodificador, no se comunica el perfil de Dolby real. al códec. Esto solo se hace a través de datos específicos del códec después de que el se inició. Una plataforma podría optar por admitir varias Dolby Vision decodificadores: uno para perfiles AVC y otro para perfiles HEVC para inicializar los códecs subyacentes durante la configuración. Si un solo Dolby Vision y el decodificador admite ambos tipos de perfiles, entre ellas de forma dinámica y adaptable.

Si una plataforma proporciona un decodificador compatible con Dolby-Vision, además del el decodificador HDR, debe cumplir con los siguientes requisitos:

• Proporcionar un extractor con reconocimiento de Dolby-Vision, incluso si no es compatible Reproducción en HDR.
• Proporcionar un decodificador que admita el perfil de visión según lo definido por Dolby.

Compatibilidad con el decodificador HDR10

Para admitir HDR10, las plataformas deben agregar un decodificador OMX compatible con HDR10. Esta es normalmente un decodificador HEVC tunelizado que también admite el análisis y el manejo Metadatos relacionados con HDMI. Este decodificador (además del decodificador HDR general asistencia) deben cumplir con los siguientes requisitos:

• Se admite el tipo de MIME “video/hevc”.
• Anunciar el dispositivo HEVCMain10HDR10 admitido Compatibilidad con perfiles HEVCMain10HRD10 también requiere compatibilidad con el perfil HEVCMain10, que requiere compatibilidad el perfil HEVCMain en los mismos niveles.
• Admite el análisis de los bloques SEI de metadatos de masterización y otros HDR. información relacionada incluida en el SPS.

Compatibilidad con el decodificador VP9

Para admitir el HDR de VP9, las plataformas deben agregar un HDR OMX compatible con Profile2 en VP9. decodificador. Este suele ser un decodificador VP9 tunelizado que también admite Metadatos relacionados con HDMI. Estos decodificadores (además del decodificador HDR general asistencia) deben cumplir con los siguientes requisitos:

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

Extractores

Compatibilidad con el extractor Dolby Vision

Las plataformas compatibles con decodificadores Dolby Vision deben agregar el extractor Dolby. (denominado extractor Dolby) es compatible con 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. Un extractor de Dolby especial necesario para extraer los datos del archivo.
• El extractor de Dolby debe exponer 1 o 2 pistas por cada pista de video Dolby. (grupo):
  • Una pista HDR de Dolby Vision con el tipo “video/dolby-vision” para el transmisión de Dolby de 2 o 3 capas combinadas. el formato de unidad de acceso de la pista HDR, define cómo empaquetar las unidades de acceso desde la base, la mejora o los metadatos capas en un solo búfer para decodificarlas en un único fotograma HDR, definido por Dolby.
  • Si una pista de video de Dolby Vision contiene un video independiente (compatible con versiones anteriores) capa base (BL), el extractor también debe exponer esto como una capa base "video/avc" o "video/hevc" de seguimiento. El extractor debe proporcionar acceso normal a AVC/HEVC unidades para esta pista.
  • La pista con BL debe tener el mismo ID único de pista ("track-ID") que Realizar una pista HDR para que la app comprenda que se trata de dos codificaciones iguales video.
  • La aplicación puede decidir qué segmento elegir según la configuración de recuperación ante desastres.
• El nivel o perfil de Dolby Vision debe exponerse en el formato de pista de el recorrido HDR.
• Si una plataforma proporciona un decodificador compatible con Dolby-Vision, también debe un extractor compatible con Dolby-Vision, incluso si no es compatible con la reproducción HDR

Compatibilidad con extractores HDR10 y VP9

No hay requisitos adicionales de extractores para admitir HDR10 o VP9. HLG Las plataformas deben extender el extractor MP4 para admitir VP9 PQ en MP4. HDR los metadatos estáticos deben propagarse en el flujo de bits VP9 PQ, de modo que este los metadatos se pasan al decodificador VP9 PQ y a la pantalla a través del MediaExtractor => Canalización de 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 de HDR10

Los flujos de bits de HDR10 se empaquetan en contenedores MP4. Las aplicaciones usan un Extractor de MP4 para extraer los datos de la trama y enviarlos al decodificador.

• Extractor de MPEG4
  Las transmisiones de bits de HDR10 se reconocen como una transmisión HEVC normal mediante un MPEG4Extractor y la pista HDR con el tipo "video/HEVC" serán extraída. El framework elige un decodificador de video HEVC que admite la Main10HDR10 para decodificar ese recorrido.
• Decodificador HEVC
  La información de HDR está en formato SEI o SPS. El decodificador HEVC primero recibe fotogramas que contienen la información HDR. Luego, el decodificador extrae el HDR información y notifica a la aplicación que está decodificando un video HDR. HDR la información 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. Implementa la compatibilidad con el análisis de SEI de los 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 MP4 según lo definido por Dolby. Las aplicaciones podrían, en teoría, usar un extractor MP4 normal para extraer la capa base, la capa de mejora y la capa de metadatos de manera independiente; Sin embargo, no se ajusta al modelo actual de MediaExtractor/MediaCodec de Android.

• DolbyExtractor:
  • Los flujos de bits de Dolby son reconocidos por un DolbyExtractor, que expone la Varias capas, como 1 o 2 pistas para cada pista de video Dolby (grupo):
    • Una pista HDR con el tipo "video/dolby-vision" para las campañas Transmisión dolby de 2 o 3 capas. El formato de unidad de acceso de la pista HDR, que define cómo empaquetar las unidades de acceso desde las capas de base, mejora y metadatos en un solo búfer para decodificarlo en un único fotograma HDR, se debe definir por Dolby.
    • (Opcional, solo si el BL es retrocompatible) Una pista de BL contiene solo la capa base, que se debe poder decodificar con el decodificador MediaCodec normal como el decodificador AVC/HEVC. El extractor debe proporcionar el AVC/HEVC normal unidades de acceso para esta rama. Esta pista con BL debe tener el mismo ID único de pista ("ID de pista") como la pista de Dolby para que la aplicación comprenda que estas son dos codificaciones del mismo video.
  • La aplicación puede decidir qué segmento elegir según la configuración de recuperación ante desastres.
  • Debido a que una pista HDR tiene un tipo de HDR específico, el framework elegirá un decodificador Dolby Video para decodificar esa pista. El segmento BL se decodificará por un decodificador de video AVC/HEVC normal.
• DolbyDecoder:
  • DolbyDecoder recibe unidades de acceso que contienen el acceso Unidades 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 el capas individuales se pueden empaquetar en 1 trama CSD para que las defina Dolby. Se requiere tener un solo marco CSD.

Acciones de Dolby

1. Definir el empaquetado de las unidades de acceso para los distintos contenedores de Dolby esquemas (p. ej., BL+EL+MD) para el decodificador Dolby abstracto (es decir, el 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 de decodificador HDR y el nivel OMX el tipo de letra. Ejemplo: OMX_VIDEO_DOLBYPROFILETYPE y OMX_VIDEO_DOLBYLEVELTYP
4. Implementa la compatibilidad con el índice: 'OMX.google.android.index.describeColorAspects min
5. Propaga los metadatos de HDR dinámicos a la app y la superficie en cada uno de ellos. marco. Por lo general, esta información debe empaquetarse en un marco decodificado. según lo definido por Dolby, porque el estándar HDMI no proporciona una forma de pasar esto a la pantalla.

Canalización de decodificador de VP9

Figura 3: Canalización de VP9-PQ

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

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