Transcodificación de medios compatibles

La transcodificación de medios compatibles, introducida en Android 12, es una función que permite a los dispositivos utilizar formatos de medios más modernos y eficientes en almacenamiento para la captura de video, como HEVC, mientras mantiene la compatibilidad con las aplicaciones. Con esta función, los fabricantes de dispositivos pueden utilizar HEVC en lugar de AVC de forma predeterminada para mejorar la calidad del vídeo y al mismo tiempo 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 se abren con 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 multimedia. Para obtener más información sobre cómo declarar capacidades multimedia, 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 compatible en proveedores de medios: este componente que se encuentra en los proveedores de medios intercepta las aplicaciones que acceden a archivos multimedia 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 ningún manejo especial. Si una aplicación no admite el formato, el marco convierte el archivo a un formato más antiguo, 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 soportados

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 mediacodec y un codificador de mediacode.
  • HDR10+ (10 bits) a AVC (SDR): las conversiones de HDR a SDR se realizan utilizando instancias de mediacodec y un 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 compatibles 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 función no admite medios en almacenamiento secundario. No se admite el contenido pasado a dispositivos a través de correo electrónico o tarjetas SD.

Las aplicaciones acceden a los archivos según varias rutas de archivo. A continuación se describen las rutas de archivos donde 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 aplicaciones a través de API de ruta de archivo directa que incluyen Java y código nativo
    • Acceso a la aplicación a través del Storage Access Framework (SAF)
    • Acceso a la aplicación a través de la hoja para compartir del sistema operativo Intents. (Solo URI de MediaStore)
    • Transferencia de archivos MTP/PTP desde el teléfono a la PC

  • Transcodificación omitida:

    • Transferir archivos desde un dispositivo expulsando la tarjeta SD
    • Transferir archivos de un dispositivo a otro usando opciones como Near Share o transferencia por Bluetooth.

Agregue rutas de archivos personalizadas para transcodificar

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

Para agregar una ruta de archivo, utilice la superposición de recursos en 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 archivos configuradas, utilice:

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

Esta sección 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 gestiona las conexiones de los clientes, programa las solicitudes de transcodificación y gestiona la contabilidad de TranscodingSessions .
  • MediaTranscoder: biblioteca nativa que realiza transcodificación. Esta biblioteca está construida sobre el marco de medios NDK para que sea compatible con los módulos .

La función de transcodificación de medios compatibles registra métricas de transcodificación tanto en el servicio como en el transcodificador de medios. El código del lado del cliente y del lado 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 compatibles se basa en el sistema de archivos Filesystem in Userspace (FUSE) , que se utiliza para el almacenamiento con alcance. 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 admite HEVC, Android no transcodifica archivos a menos que una aplicación lo especifique en un archivo de manifiesto o en la lista de transcodificación forzada .

Las aplicaciones pueden solicitar activos transcodificados mediante las siguientes opciones:

  • Declare formatos no compatibles en el archivo de manifiesto. Para obtener más información, consulte Declarar capacidades en un recurso y Declarar capacidades en 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 compatibles, 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 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 aplicaciones 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 la opció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. Cambie para habilitar la transcodificación de medios en la pantalla de Preferencias de USB.

Restricciones al solicitar 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 excede 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 que admiten transcodificación de HDR a SDR) El dispositivo admite captura de vídeo HDR

Para garantizar el rendimiento del dispositivo para la transcodificación de medios, se debe optimizar el rendimiento del acceso de lectura/escritura al hardware de vídeo y al 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 la prueba comparativa 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 a nivel mundial

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 compatible a nivel mundial. En la página de opciones de desarrollador Configuración > Sistema > Desarrollador > Transcodificación de medios , active o desactive la opción Anular valores predeterminados de transcodificación y luego active o desactive la opción 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ás desarrollando.

Verificar el estado de transcodificación

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

adb shell dumpsys media.transcoding

Ampliar la limitación de duración del vídeo

Para fines de prueba, puede ampliar la limitación de duración del vídeo de un minuto para la transcodificación mediante 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 de AOSP

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

Codificación HDR a SDR

Para admitir la codificación HDR a SDR, los fabricantes de dispositivos pueden utilizar el complemento de filtro Codec 2.0 de muestra de AOSP ubicado en /platform/frameworks/av/media/codec2/hidl/plugin/ . Esta sección 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 HDR a SDR, una aplicación que accede a un video HDR obtiene el descriptor del 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 empaquetados como decodificadores con funciones de filtrado.

Descripción general

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

Arquitectura del complemento de filtro

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 del 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 del filtro altera el búfer. Por ejemplo, el filtro de mapeo 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 detalles de la clase FilterWrapper .

Creación

El componente empaquetado crea una instancia del descodificador subyacente y de todos los filtros definidos en el momento de la creación.

Consulta y configuración

El componente empaquetado 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 del filtro se enruta al filtro correspondiente y los parámetros afectados de los filtros están presentes en las consultas (en lugar de leerse desde el decodificador que tiene parámetros no afectados).

Consulta y configuración

Figura 2. Consulta y configuración.

Comenzar

Al inicio, el componente empaquetado inicia el decodificador y todos los filtros que alteran los buffers. Si no hay ningún filtro habilitado, el componente empaquetado inicia el decodificador y los buffers de paso y envía comandos al propio decodificador.

Manejo del búfer

Manejo del búfer

Figura 3. Manejo del búfer.

Los buffers en cola para el decodificador empaquetado van al decodificador subyacente. El componente empaquetado 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 en los filtros. El búfer de salida final del último filtro se informa al cliente.

Para que este manejo del 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 empaquetado detiene el decodificador y todos los filtros habilitados que se iniciaron. Durante el reinicio y el lanzamiento, 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 .

Pruebe el complemento

Para probar el complemento de muestra, haga lo siguiente:

  1. Reconstruya y actualice el dispositivo.

  2. Cree el complemento de muestra usando 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