La transcodificación de contenido multimedia compatible, que se introdujo en Android 12, es una función que permite que los dispositivos usen formatos multimedia más modernos y eficientes en cuanto al almacenamiento para la captura de video, como HEVC, sin perder compatibilidad con las apps. Con esta función, los fabricantes de dispositivos pueden usar HEVC en lugar de AVC de forma predeterminada para mejorar la calidad de video y, al mismo tiempo, reducir los requisitos de almacenamiento y ancho de banda. En los dispositivos con la transcodificación de contenido multimedia compatible habilitada, Android puede convertir automáticamente videos (de hasta un minuto de duración) grabados en formatos como HEVC o HDR cuando los videos se abren con una app que no admite el formato. Esto permite que las apps funcionen incluso cuando se capturan videos en formatos más nuevos en el dispositivo.
La función de transcodificación de contenido multimedia compatible está desactivada de forma predeterminada. Para solicitar la transcodificación de contenido multimedia, las apps deben declarar sus capacidades de contenido multimedia. Para obtener más información sobre cómo declarar capacidades de medios, consulta Transcodificación de contenido multimedia compatible en el sitio para desarrolladores de Android.
Cómo funciona
La función de transcodificación de medios compatible consta de dos partes principales:
- Servicios de transcodificación en el framework de medios: Estos servicios convierten archivos de un formato a otro con hardware para lograr conversiones de alta calidad y baja latencia. Esto incluye la API de transcodificación, el servicio de transcodificación, un complemento OEM para filtros personalizados y hardware. Para obtener más detalles, consulta Descripción general de la arquitectura.
- Función de transcodificación de contenido multimedia compatible en proveedores de contenido multimedia: Este componente que se encuentra en los proveedores de contenido multimedia intercepta las apps que acceden a archivos multimedia y entrega el archivo original o uno transcodificado según las capacidades declaradas de la app. Si una app admite el formato del archivo multimedia, no se requiere un procesamiento especial. Si una app no admite el formato, el framework convierte el archivo a un formato anterior, como AVC, cuando la app accede al archivo.
En la Figura 1, se muestra una descripción general del proceso de transcodificación de medios.
Figura 1: Descripción general de la transcodificación de contenido multimedia compatible.
Formatos compatibles
La función de transcodificación de medios compatible admite las siguientes conversiones de formato:
- HEVC (8 bits) a AVC: Las conversiones de códec se realizan conectando un decodificador de MediaCodec y un codificador de MediaCodec.
- HDR10+ (10 bits) a AVC (SDR): Las conversiones de HDR a SDR se realizan con instancias de MediaCodec y un hook de complemento del proveedor en las instancias del decodificador. Para obtener más información, consulta Codificación de HDR a SDR.
Fuentes de contenido admitidas
La función de transcodificación de medios compatible admite los medios en el dispositivo generados por la app de cámara nativa del OEM que se almacenan en la carpeta DCIM/Camera/
del volumen externo principal. La función no admite contenido multimedia en el almacenamiento secundario.
No se admite el contenido que se pasa a los dispositivos a través de correo electrónico o tarjetas SD.
Las apps acceden a los archivos según varias rutas de acceso. A continuación, se describen las rutas de acceso a archivos en las que se habilita o se omite la transcodificación:
Transcodificación habilitada:
- Acceso a la app a través de las APIs de MediaStore
- Acceso a la app a través de APIs de rutas de archivos directas, incluido código nativo y Java
- Acceso a la app a través del framework de acceso al almacenamiento (SAF)
- Acceso a la app a través de intents de la hoja para compartir del SO (Solo URI de MediaStore)
- Transferencia de archivos MTP/PTP del teléfono a la PC
Se omitió la transcodificación:
- Cómo transferir archivos desde un dispositivo expulsando la tarjeta SD
- Transferir archivos de un dispositivo a otro con opciones como Compartir con Nearby o transferencia por Bluetooth
Agrega rutas de archivo personalizadas para la transcodificación
Los fabricantes de dispositivos pueden agregar de forma opcional rutas de archivo para la transcodificación de contenido multimedia en el directorio DCIM/
. Se rechazan las rutas de acceso fuera del directorio DCIM/
.
Es posible que debas agregar esas rutas de acceso a archivos para cumplir con los requisitos de los operadores o las reglamentaciones locales.
Para agregar una ruta de acceso al archivo, usa la ruta de transcodificación superposición de recursos del tiempo de ejecución (RRO), config_supported_transcoding_relative_paths
. A continuación, se muestra un ejemplo de cómo agregar una ruta de acceso al archivo:
<string-array name="config_supported_transcoding_relative_paths" translatable="false">
<item>DCIM/JCF/</item>
</string-array>
Para verificar las rutas de acceso configuradas, usa el siguiente comando:
adb shell dumpsys activity provider com.google.android.providers.media.module/com.android.providers.media.MediaProvider | head -n 20
Descripción general de la arquitectura
En esta sección, se describe la arquitectura de la función de transcodificación de medios.
Figura 2: Arquitectura de transcodificación de medios
La arquitectura de transcodificación de medios consta de los siguientes componentes:
- API del sistema de MediaTranscodingManager: Es una interfaz que permite que el cliente se comunique con el servicio de MediaTranscoding. El módulo MediaProvider usa esta API.
- MediaTranscodingService: Servicio nativo que administra las conexiones de clientes, programa solicitudes de transcodificación y administra la contabilidad de
TranscodingSessions
. - MediaTranscoder: Biblioteca nativa que realiza la transcodificación. Esta biblioteca se compila sobre el NDK del framework de medios para que sea compatible con los módulos.
La función de transcodificación de contenido multimedia compatible registra las métricas de transcodificación tanto en el servicio como en el transcodificador de medios. El código del cliente y del servicio se encuentran en el módulo MediaProvider para permitir correcciones de errores y actualizaciones oportunas.
Acceso a archivos
La transcodificación de medios compatible se basa en el sistema de archivos Filesystem in Userspace (FUSE), que se usa para el almacenamiento específico. FUSE permite que el módulo MediaProvider examine las operaciones de archivos en el espacio del usuario y controle el acceso a los archivos según la política para permitir, rechazar o redactar el acceso.
Cuando una app intenta acceder a un archivo, el daemon de FUSE intercepta el acceso de lectura de archivos de la app. Si la app admite un formato más reciente (como HEVC), se devuelve el archivo original. Si la app no admite el formato, el archivo se transcodifica a un formato anterior (como AVC) o se devuelve desde la caché si hay disponible una versión transcodificada.
Solicita archivos transcodificados
La función de transcodificación de contenido multimedia compatible está inhabilitada de forma predeterminada. Las apps pueden solicitar recursos transcodificados con las siguientes opciones:
- Declara los formatos no compatibles en el archivo de manifiesto. Para obtener más detalles, consulta Declara capacidades en un recurso y Declara capacidades en el código.
- Inhabilita los formatos compatibles con el framework de compatibilidad de apps en el tiempo de ejecución (los usuarios también pueden inhabilitar esta opción para cada app en Configuración).
- Abre un archivo con
MediaStore
y especifica de forma explícita los formatos no admitidos con la API deopenTypedAssetFileDescriptor
.
En el caso de las transferencias por USB (del dispositivo a la PC), la transcodificación está inhabilitada de forma predeterminada, pero los usuarios pueden habilitarla con el botón de activación Convertir videos a AVC en la pantalla de configuración Preferencias de USB, como se muestra en la Figura 3.
Figura 3: Activa o desactiva la opción para habilitar la transcodificación de medios en la pantalla de preferencias de USB.
Restricciones para solicitar archivos transcodificados
Para evitar que las solicitudes de transcodificación bloqueen los recursos del sistema durante períodos prolongados, las apps que solicitan sesiones de transcodificación están limitadas a lo siguiente:
- 10 sesiones consecutivas
- un tiempo de ejecución total de tres minutos
Si una app supera todas estas restricciones, el framework devuelve el descriptor de archivo original.
Requisitos del dispositivo
Para admitir la función de transcodificación de medios compatible, los dispositivos deben cumplir con los siguientes requisitos:
- El dispositivo tiene habilitada la codificación HEVC de forma predeterminada en la app de cámara nativa.
- (Dispositivos compatibles con la transcodificación de HDR a SDR) El dispositivo admite la captura de video en HDR.
Para garantizar el rendimiento del dispositivo en la transcodificación de medios, se debe optimizar el rendimiento de acceso de lectura/escritura del almacenamiento y el hardware de video. Cuando los códecs de medios se configuran con una prioridad igual a 1
, deben funcionar con la mayor capacidad de procesamiento posible. Te recomendamos que el rendimiento de transcodificación alcance un mínimo de 200 FPS. Para probar el rendimiento del hardware, ejecuta la comparativa del transcodificador de medios en frameworks/av/media/libmediatranscoding/transcoder/benchmark
.
Validación
Para validar la función de transcodificación de medios compatible, ejecuta las siguientes pruebas de CTS:
android.media.mediatranscoding.cts
android.mediaprovidertranscode.cts
Habilita la transcodificación de medios de forma global
Para probar el marco de transcodificación de contenido multimedia o el comportamiento de la app con la transcodificación, puedes habilitar o inhabilitar la función de transcodificación de contenido multimedia compatible de forma global. En la página de opciones para desarrolladores Configuración > Sistema > Desarrollador > Transcodificación de medios, establece el botón de activación Anular los valores predeterminados de transcodificación en activado y, luego, establece el botón de activación Habilitar transcodificación en activado o desactivado. Si este parámetro de configuración está habilitado, es posible que la transcodificación de medios se produzca en segundo plano para apps que no sean la que estás desarrollando.
Cómo verificar el estado de la transcodificación
Durante las pruebas, puedes usar el siguiente comando de shell de ADB para verificar el estado de la transcodificación, incluidas las sesiones de transcodificación actuales y anteriores:
adb shell dumpsys media.transcoding
Extiende la limitación de la duración del video
Para realizar pruebas, puedes extender la limitación de un minuto de duración de los videos para la transcodificación con el siguiente comando. Es posible que debas reiniciar el dispositivo después de ejecutar este comando.
adb shell device_config put storage_native_boot transcode_max_duration_ms <LARGE_NUMBER_IN_MS>
Fuentes y referencias del AOSP
A continuación, se muestra el código fuente del AOSP relacionado con la transcodificación de contenido multimedia compatible.
API de Transcoding System (solo la usa MediaProvider)
API de ApplicationMediaCapabilities
frameworks/base/apex/media/framework/java/android/media/ApplicationMediaCapabilities.java
Servicio de MediaTranscoding
frameworks/av/services/mediatranscoding/
frameworks/av/media/libmediatranscoding/
Native MediaTranscoder
frameworks/av/media/libmediatranscoding/transcoder
Complemento de muestra de HDR para MediaTranscoder
Código de transcodificación y de interceptación de archivos de MediaProvider
Comparativa de MediaTranscoder
frameworks/av/media/libmediatranscoding/transcoder/benchmark
Pruebas de CTS
cts/tests/tests/mediatranscoding/
Codificación de HDR a SDR
Para admitir la codificación de HDR a SDR, los fabricantes de dispositivos pueden usar el complemento de filtro Codec 2.0 de muestra del AOSP que se encuentra en /platform/frameworks/av/media/codec2/hidl/plugin/
.
En esta sección, se describe cómo funciona el complemento de filtro, cómo implementarlo y cómo probarlo.
Si un dispositivo no incluye un complemento que admita la codificación de HDR a SDR, una app que acceda a un video en HDR obtendrá el descriptor de archivo original, independientemente de las capacidades multimedia de la app declaradas en el manifiesto.
Cómo funciona
En esta sección, se describe el comportamiento general del complemento de filtro Codec 2.0.
Información general
Android proporciona una implementación de la capa de adaptación entre la interfaz Codec 2.0 y la interfaz HAL de android.hardware.media.c2
en android::hardware::media::c2
. En el caso de los complementos de filtro, el AOSP incluye un mecanismo de wrapper que une los decodificadores con los complementos de filtro.
MediaCodec
reconoce estos componentes encapsulados como decodificadores con funciones de filtrado.
Descripción general
La clase FilterWrapper
toma los códecs del proveedor y devuelve los códecs encapsulados a la capa de adaptación media.c2
. La clase FilterWrapper
carga libc2filterplugin.so
a través de la API de FilterWrapper::Plugin
y registra los filtros disponibles del complemento. Cuando se crea, FilterWrapper
instancia todos los filtros disponibles. Solo los filtros que alteran el búfer se inician al principio.
Figura 4: Arquitectura de complementos de filtro
Interfaz del complemento de filtro
La interfaz de FilterPlugin.h
define las siguientes APIs para exponer los filtros:
std::shared_ptr<C2ComponentStore>getComponentStore()
Devuelve un objeto
C2ComponentStore
que contiene filtros. Esto es independiente de lo que expone la implementación del códec 2.0 del proveedor. Por lo general, este almacén solo contiene los filtros que usa la claseFilterWrapper
.bool describe(C2String name, Descriptor *desc)
Describe los filtros, además de lo que está disponible en
C2ComponentStore
. Se definen las siguientes descripciones:controlParam
: Son los parámetros que controlan el comportamiento de los filtros. Por ejemplo, para el asignador de tonos de HDR a SDR, el parámetro de control es la función de transferencia de destino.affectedParams
: Son los parámetros que se ven afectados por las operaciones de filtrado. Por ejemplo, para el asignador de tonos de HDR a SDR, los parámetros afectados son los aspectos de color.
bool isFilteringEnabled(const std::shared_ptr<C2ComponentInterface> &intf)
Devuelve
true
si el componente del filtro altera el búfer. Por ejemplo, el filtro de asignación de tonos devuelvetrue
si la función de transferencia de destino es SDR y la función de transferencia de entrada es HDR (HLG o PQ).
Detalles de FilterWrapper
En esta sección, se describen los detalles de la clase FilterWrapper
.
Creación
El componente wrapper crea una instancia del decodificador subyacente y de todos los filtros definidos en el momento de la creación.
Consulta y configuración
El componente encapsulado separa los parámetros entrantes de las consultas o las solicitudes de configuración según la descripción del filtro. Por ejemplo, la configuración del parámetro de control del filtro se enruta al filtro correspondiente, y los parámetros afectados de los filtros están presentes en las consultas (en lugar de leer desde el decodificador que tiene parámetros no afectados).
Figura 5: Consulta y configuración
Iniciar
Al inicio, el componente encapsulado inicia el decodificador y todos los filtros que alteran los búferes. Si no se habilita ningún filtro, el componente encapsulado inicia el decodificador y los búferes de transferencia, y envía comandos al decodificador.
Control de búfer
Figura 6: Manejo de búferes
Los búferes en cola para el decodificador encapsulado van al decodificador subyacente. El componente ajustado toma el búfer de salida del decodificador a través de una devolución de llamada onWorkDone_nb()
y, luego, lo pone en cola para los filtros. El búfer de salida final del último filtro se informa al cliente.
Para que este control de búferes funcione, el componente ajustado debe configurar C2PortBlockPoolsTuning
en el último filtro para que los búferes de salida del framework provengan del grupo de bloques esperado.
Detener, restablecer y liberar
Cuando se detiene, el componente encapsulado detiene el decodificador y todos los filtros habilitados que se iniciaron. Cuando se restablecen y sueltan, todos los componentes se restablecen o sueltan, independientemente de si están habilitados o no.
Implementa el complemento de filtro de muestra
Para habilitar el complemento, haz lo siguiente:
- Implementa la interfaz
FilterPlugin
en una biblioteca y descártala en/vendor/lib[64]/libc2filterplugin.so.
. - Agrega permisos adicionales a
mediacodec.te
si es necesario. - Actualiza la capa de adaptación a Android 12 y vuelve a compilar el servicio
media.c2
.
Prueba el complemento
Para probar el complemento de muestra, haz lo siguiente:
- Vuelve a compilar el dispositivo y graba la imagen en su memoria flash.
Compila el complemento de ejemplo con el siguiente comando:
m sample-codec2-filter-plugin
Vuelve a montar el dispositivo y cambia el nombre del complemento del proveedor para que el servicio de códec lo reconozca.
adb root adb remount adb reboot adb wait-for-device adb root adb remount adb push /out/target/<...>/lib64/sample-codec2-filter-plugin.so \ /vendor/lib64/libc2filterplugin.so adb push /out/target/<...>/lib/sample-codec2-filter-plugin.so \ /vendor/lib/libc2filterplugin.so adb reboot