Transcodificación de medios compatibles

La transcodificación de medios compatibles, introducida en Android 12, es una función que permite que los dispositivos usen formatos de medios más modernos y eficientes en el almacenamiento para la captura de video, como HEVC, mientras mantienen la compatibilidad con las aplicaciones. Con esta función, los fabricantes de dispositivos pueden usar HEVC en lugar de AVC de manera predeterminada para mejorar la calidad del video y reducir los requisitos de almacenamiento y ancho de banda. Para dispositivos con transcodificación de medios 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 son abiertos por una aplicación que no admite el formato. Esto permite que las aplicaciones funcionen incluso cuando los videos se capturan en formatos más nuevos en el dispositivo.

La función de transcodificación de medios compatibles está desactivada de forma predeterminada. Para solicitar la transcodificación de medios, las aplicaciones deben declarar sus capacidades de medios. Para obtener más información sobre la declaración de capacidades de medios, consulte Transcodificación de medios compatibles en el sitio de desarrolladores de Android.

Cómo funciona

La función de transcodificación de medios compatibles consta de dos partes principales:

  • Servicios de transcodificación en el marco de medios: estos servicios convierten archivos de un formato a otro utilizando hardware para conversiones de baja latencia y alta calidad. 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, consulte Descripción general de la arquitectura .
  • Función de transcodificación de medios compatibles en los proveedores de medios: este componente que se encuentra en los proveedores de medios intercepta las aplicaciones que acceden a los archivos de medios y sirve el archivo original o un archivo transcodificado según las capacidades declaradas de la aplicación. Si una aplicación admite el formato del archivo multimedia, no se requiere un manejo especial. Si una aplicación no admite el formato, el marco convierte el archivo a un formato anterior, como AVC, cuando la aplicación accede al archivo.

La Figura 1 muestra una descripción general del proceso de transcodificación de medios.

Proceso de transcodificación de medios compatibles

Figura 1. Descripción general de la transcodificación de medios compatibles.

Formatos admitidos

La función de transcodificación de medios compatibles admite las siguientes conversiones de formato:

  • HEVC (8 bits) a AVC: las conversiones de códec se realizan conectando un decodificador de códec de medios y un codificador de códec de medios.
  • HDR10+ (10 bits) a AVC (SDR): las conversiones de HDR a SDR se realizan utilizando instancias de mediacodec y un enlace de complemento del proveedor en las instancias del decodificador. Para obtener más información, consulte Codificación de HDR a SDR .

Fuentes de contenido admitidas

La función de transcodificación de medios compatible admite medios en el dispositivo generados por la aplicación de cámara OEM nativa que se almacena en la carpeta DCIM/Camera/ en el volumen externo principal. La característica no admite medios en almacenamiento secundario. No se admite el contenido transferido a dispositivos a través de correo electrónico o tarjetas SD.

Las aplicaciones acceden a los archivos en función de varias rutas de archivo. A continuación, se describen las rutas de archivo en las que se habilita o se omite la transcodificación:

  • Transcodificación habilitada:

    • Acceso a la aplicación a través de las API de MediaStore
    • Acceso a la aplicación a través de API de ruta de archivo directa, incluidos Java y código nativo
    • Acceso a la aplicación a través de Storage Access Framework (SAF)
    • Acceso a la aplicación a través de las intenciones de la hoja compartida del sistema operativo. (URI de MediaStore solamente)
    • Transferencia de archivos MTP/PTP del teléfono a la PC
  • Transcodificación omitida:

    • Transferencia de archivos desde un dispositivo mediante la expulsión de la tarjeta SD
    • Transferir archivos de un dispositivo a otro usando opciones como Near Share o Bluetooth transfer.

Agregue rutas de archivo personalizadas para la transcodificación

Los fabricantes de dispositivos pueden agregar opcionalmente rutas de archivo para la transcodificación de medios en el directorio DCIM/ . Se rechaza cualquier ruta fuera del directorio DCIM/ . Es posible que sea necesario agregar dichas rutas de archivo para cumplir con los requisitos del operador o las regulaciones locales.

Para agregar una ruta de archivo, use la superposición de recursos de tiempo de ejecución (RRO) de la ruta de transcodificación, config_supported_transcoding_relative_paths . El siguiente es un ejemplo de cómo agregar una ruta de archivo:

<string-array name="config_supported_transcoding_relative_paths" translatable="false">
    <item>DCIM/JCF/</item>
</string-array>

Para verificar las rutas de archivo configuradas, use:

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.

arquitectura 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 MediaTranscodingManager: Interfaz que permite al cliente comunicarse con el servicio MediaTranscoding. El módulo MediaProvider utiliza esta API.
  • MediaTranscodingService: servicio nativo que administra las conexiones de los clientes, programa las solicitudes de transcodificación y administra la contabilidad de TranscodingSessions .
  • MediaTranscoder: biblioteca nativa que realiza la transcodificación. Esta biblioteca se basa en el marco de medios NDK para ser compatible con los módulos .

La función de transcodificación de medios compatibles registra las métricas de transcodificación tanto en el servicio como en el transcodificador de medios. El lado del cliente y el código del lado del servicio están en el módulo MediaProvider para permitir correcciones de errores y actualizaciones oportunas.

Acceso a archivos

La transcodificación de medios compatibles se basa en el sistema de archivos Filesystem in Userspace (FUSE) , que se utiliza para el almacenamiento de ámbito. 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, denegar o redactar el acceso.

Cuando una aplicación intenta acceder a un archivo, el demonio FUSE intercepta el acceso de lectura del archivo desde la aplicación. Si la aplicación admite un formato más nuevo (como HEVC), se devuelve el archivo original. Si la aplicación no admite el formato, el archivo se transcodifica a un formato anterior (como AVC) o se devuelve desde la memoria caché si hay una versión transcodificada disponible.

Solicitar archivos transcodificados

La función de transcodificación de medios compatibles está deshabilitada de forma predeterminada, lo que significa que si el dispositivo es compatible con HEVC, Android no transcodifica archivos a menos que lo especifique una aplicación en un archivo de manifiesto o en la lista de transcodificación forzada .

Las aplicaciones pueden solicitar recursos transcodificados mediante las siguientes opciones:

  • Declare formatos no admitidos en el archivo de manifiesto. Para obtener más información, consulte Declarar capacidades en un recurso y Declarar capacidades en el código .
  • Agregue aplicaciones a la lista de transcodificación forzada que se incluye en el módulo MediaProvider . Esto permite la transcodificación de aplicaciones que no han actualizado su archivo de manifiesto. Una vez que una aplicación actualiza su archivo de manifiesto con formatos no admitidos, debe eliminarse de la lista de transcodificación forzada. Los fabricantes de dispositivos pueden nominar sus aplicaciones para que se agreguen o eliminen de la lista de transcodificación forzada enviando un parche o informando de un error . El equipo de Android revisa periódicamente la lista y puede eliminar aplicaciones de la lista.
  • Deshabilite los formatos admitidos con el marco de compatibilidad de la aplicación en tiempo de ejecución (los usuarios también pueden deshabilitar esto para cada aplicación en Configuración).
  • Abra un archivo con MediaStore mientras especifica explícitamente formatos no admitidos con la API openTypedAssetFileDescriptor .

Para transferencias USB (de dispositivo a PC), la transcodificación está deshabilitada de forma predeterminada, pero los usuarios pueden optar por habilitar la transcodificación usando el botón Convertir videos a AVC en la pantalla de configuración de Preferencias de USB , como se muestra en la Figura 3.

Alternar para habilitar la transcodificación de medios

Figura 3. Alterne para habilitar la transcodificación de medios en la pantalla de Preferencias de USB.

Restricciones en la solicitud de archivos transcodificados

Para evitar que las solicitudes de transcodificación bloqueen los recursos del sistema durante períodos prolongados, las aplicaciones que solicitan sesiones de transcodificación se limitan a:

  • 10 sesiones consecutivas
  • un tiempo total de ejecución de tres minutos

Si una aplicación supera todas estas restricciones, el marco devuelve el descriptor de archivo original.

Requisitos del dispositivo

Para admitir la función de transcodificación de medios compatibles, los dispositivos deben cumplir los siguientes requisitos:

  • El dispositivo tiene la codificación HEVC habilitada de forma predeterminada en la aplicación de cámara nativa
  • (Dispositivos compatibles con la transcodificación de HDR a SDR) El dispositivo admite la captura de vídeo HDR

Para garantizar el rendimiento del dispositivo para la transcodificación de medios, se debe optimizar el hardware de video y el rendimiento de acceso de lectura/escritura de almacenamiento. Cuando los códecs multimedia se configuran con una prioridad igual a 1 , los códecs deben funcionar con el mayor rendimiento posible. Recomendamos que el rendimiento de transcodificación alcance un mínimo de 200 fps. Para probar el rendimiento de su hardware, ejecute el punto de referencia del transcodificador de medios en frameworks/av/media/libmediatranscoding/transcoder/benchmark .

Validación

Para validar la función de transcodificación de medios compatibles, ejecute las siguientes pruebas CTS:

  • android.media.mediatranscoding.cts
  • android.mediaprovidertranscode.cts

Habilite la transcodificación de medios globalmente

Para probar el marco de transcodificación de medios o el comportamiento de la aplicación con la transcodificación, puede habilitar o deshabilitar la función de transcodificación de medios compatibles globalmente. En la página Configuración > Sistema > Desarrollador > Opciones de desarrollador de transcodificación de medios , active o desactive la opción Anular valores predeterminados de transcodificación y , a continuación , active o desactive Habilitar transcodificación . Si esta configuración está habilitada, la transcodificación de medios puede ocurrir en segundo plano para aplicaciones distintas a la que está desarrollando.

Comprobar el estado de transcodificación

Durante la prueba, puede usar el siguiente comando de shell ADB para verificar el estado de la transcodificación, incluidas las sesiones de transcodificación actuales y pasadas:

adb shell dumpsys media.transcoding

Extender la limitación de duración del video

Para fines de prueba, puede extender la limitación de duración de video de un minuto para la transcodificación usando el siguiente comando. Es posible que sea necesario reiniciar después de ejecutar este comando.

adb shell device_config put storage_native_boot transcode_max_duration_ms <LARGE_NUMBER_IN_MS>

Fuente y referencias AOSP

Los siguientes son códigos fuente de AOSP relacionados con la transcodificación de medios compatibles.

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 AOSP sample Codec 2.0 ubicado en /platform/frameworks/av/media/codec2/hidl/plugin/ . Esta sección describe cómo funciona el complemento de filtro, cómo implementar el complemento y cómo probar el complemento.

Si un dispositivo no incluye un complemento que admita la codificación HDR a SDR, una aplicación que accede a un video HDR obtiene el descriptor de archivo original, independientemente de las capacidades multimedia de la aplicación declaradas en el manifiesto.

Cómo funciona

Esta sección describe el comportamiento general del complemento de filtro Codec 2.0.

Fondo

Android proporciona una implementación de capa de adaptación entre la interfaz Codec 2.0 y la interfaz HAL android.hardware.media.c2 en android::hardware::media::c2 . Para los complementos de filtro, AOSP incluye un mecanismo contenedor que envuelve los decodificadores junto con los complementos de filtro. MediaCodec reconoce estos componentes envueltos como decodificadores con funciones de filtrado.

Visión general

La clase FilterWrapper toma los códecs del proveedor y devuelve los códecs envueltos a la capa de adaptación media.c2 . La clase FilterWrapper carga libc2filterplugin.so a través de FilterWrapper::Plugin API y registra los filtros disponibles del complemento. En la creación, FilterWrapper instancia todos los filtros disponibles. Solo los filtros que alteran el búfer se inician al inicio.

Filtrar la arquitectura del complemento

Figura 1. Arquitectura del complemento de filtro.

Interfaz del complemento de filtro

La interfaz FilterPlugin.h define las siguientes API 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 de Codec 2.0 del proveedor. Normalmente, este almacén solo contiene los filtros utilizados por la clase FilterWrapper .

  • bool describe(C2String name, Descriptor *desc)

    Describe los filtros además de lo que está disponible en C2ComponentStore . Se definen las siguientes descripciones:

    • controlParam : Parámetros que controlan el comportamiento de los filtros. Por ejemplo, para el mapeador de tonos HDR a SDR, el parámetro de control es la función de transferencia de destino.
    • affectedParams : Parámetros que se ven afectados por las operaciones de filtrado. Por ejemplo, para el mapeador de tonos 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 de filtro altera el búfer. Por ejemplo, el filtro de asignación de tonos devuelve true 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

La sección describe los detalles de la clase FilterWrapper .

Creación

El componente envuelto instancia el decodificador subyacente y todos los filtros definidos en la creación.

Consulta y configuración

El componente envuelto separa los parámetros entrantes de las consultas o solicitudes de configuración según la descripción del filtro. Por ejemplo, la configuración del parámetro de control de filtro se enruta al filtro correspondiente y los parámetros afectados de los filtros están presentes en las consultas (en lugar de leerse del decodificador que tiene parámetros no afectados).

Consulta y configuración

Figura 2. Consulta y configuración.

comienzo

Al inicio, el componente envuelto inicia el decodificador y todos los filtros que alteran los búferes. Si no se habilita ningún filtro, el componente envuelto inicia el decodificador y los búferes de transferencia y envía comandos al decodificador mismo.

Manejo de búfer

Manejo de búfer

Figura 3. Manejo de tampones.

Los búferes en cola para el decodificador envuelto van al decodificador subyacente. El componente envuelto 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 manejo de búfer funcione, el componente empaquetado debe configurar C2PortBlockPoolsTuning en el último filtro para que el marco genere búferes del grupo de bloques esperado.

Detener, restablecer y liberar

Al detenerse, el componente envuelto detiene el decodificador y todos los filtros habilitados que se iniciaron. Al reiniciar y liberar, todos los componentes se reinician o liberan independientemente de si están habilitados o no.

Implementar el complemento de filtro de muestra

Para habilitar el complemento, haga lo siguiente:

  1. Implemente la interfaz FilterPlugin en una biblioteca y colóquela en /vendor/lib[64]/libc2filterplugin.so.
  2. Agregue permisos adicionales a mediacodec.te si es necesario.
  3. Actualice la capa de adaptación a Android 12 y reconstruya el servicio media.c2 .

Prueba el complemento

Para probar el complemento de muestra, haga lo siguiente:

  1. Reconstruye y flashea el dispositivo.
  2. Cree el complemento de muestra con el siguiente comando:

    m sample-codec2-filter-plugin
    
  3. Vuelva a montar el dispositivo y cambie 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