Transcodage de contenus multimédias dans un format compatible

Le transcodage multimédia compatible, introduit dans Android 12, est une fonctionnalité qui permet aux appareils d'utiliser des formats multimédias plus modernes et plus efficaces en matière de stockage pour la capture vidéo, tels que HEVC, tout en conservant la compatibilité avec les applications. Grâce à cette fonctionnalité, les fabricants d'appareils peuvent utiliser HEVC au lieu d'AVC par défaut pour améliorer la qualité vidéo tout en réduisant les besoins en stockage et en bande passante. Pour les appareils sur lesquels le transcodage multimédia compatible est activé, Android peut convertir automatiquement les vidéos (d'une durée maximale d'une minute) enregistrées dans des formats tels que HEVC ou HDR lorsque les vidéos sont ouvertes par une application qui ne prend pas en charge ce format. Cela permet aux applications de fonctionner même lorsque les vidéos sont capturées dans des formats plus récents sur l'appareil.

La fonction de transcodage multimédia compatible est désactivée par défaut. Pour demander un transcodage multimédia, les applications doivent déclarer leurs capacités multimédias. Pour plus d’informations sur la déclaration des capacités multimédias, consultez Transcodage multimédia compatible sur le site des développeurs Android.

Comment ça fonctionne

La fonctionnalité de transcodage multimédia compatible se compose de deux parties principales :

  • Services de transcodage dans le cadre multimédia : ces services convertissent les fichiers d'un format à un autre à l'aide de matériel pour une faible latence et des conversions de haute qualité. Cela inclut l'API de transcodage, le service de transcodage, un plugin OEM pour les filtres personnalisés et le matériel. Pour plus de détails, voir Présentation de l'architecture .
  • Fonctionnalité de transcodage multimédia compatible chez les fournisseurs de médias : ce composant trouvé chez les fournisseurs de médias intercepte les applications accédant aux fichiers multimédias et sert soit le fichier original, soit un fichier transcodé en fonction des capacités déclarées de l'application. Si une application prend en charge le format du fichier multimédia, aucune manipulation particulière n'est requise. Si une application ne prend pas en charge le format, le framework convertit le fichier dans un format plus ancien, tel qu'AVC, lorsque l'application accède au fichier.

La figure 1 montre un aperçu du processus de transcodage multimédia.

Processus de transcodage multimédia compatible

Figure 1. Présentation du transcodage multimédia compatible.

Formats pris en charge

La fonctionnalité de transcodage multimédia compatible prend en charge les conversions de format suivantes :

  • HEVC (8 bits) vers AVC : les conversions de codecs sont effectuées en connectant un décodeur mediacodec et un encodeur mediacode.
  • HDR10+ (10 bits) en AVC (SDR) : les conversions HDR en SDR sont effectuées à l'aide d'instances mediacodec et d'un plug-in du fournisseur intégré aux instances du décodeur. Pour plus d’informations, consultez Encodage HDR vers SDR .

Sources de contenu prises en charge

La fonctionnalité de transcodage multimédia compatible prend en charge les médias sur l'appareil générés par l'application de caméra OEM native qui est stockée dans le dossier DCIM/Camera/ du volume externe principal. La fonctionnalité ne prend pas en charge les médias sur le stockage secondaire. Le contenu transmis aux appareils par courrier électronique ou par carte SD n'est pas pris en charge.

Les applications accèdent aux fichiers en fonction de différents chemins de fichiers. Ce qui suit décrit les chemins de fichiers où le transcodage est activé ou ignoré :

  • Transcodage activé :

    • Accès aux applications via les API MediaStore
    • Accès aux applications via des API de chemin de fichier direct, notamment Java et le code natif
    • Accès aux applications via Storage Access Framework (SAF)
    • Accès à l'application via les intentions de la feuille de partage du système d'exploitation. (URI MediaStore uniquement)
    • Transfert de fichiers MTP/PTP du téléphone vers le PC
  • Transcodage contourné :

    • Transférer un fichier depuis un appareil en éjectant la carte SD
    • Transférer des fichiers d'un appareil à l'autre à l'aide d'options telles que le partage à proximité ou le transfert Bluetooth.

Ajouter des chemins de fichiers personnalisés pour le transcodage

Les fabricants d'appareils peuvent éventuellement ajouter des chemins de fichiers pour le transcodage multimédia dans le répertoire DCIM/ . Tous les chemins en dehors du répertoire DCIM/ sont rejetés. L'ajout de tels chemins de fichiers peut être nécessaire pour répondre aux exigences des opérateurs ou aux réglementations locales.

Pour ajouter un chemin de fichier, utilisez la superposition de ressources d'exécution (RRO) du chemin de transcodage , config_supported_transcoding_relative_paths . Voici un exemple de la façon d'ajouter un chemin de fichier :

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

Pour vérifier les chemins de fichiers configurés, utilisez :

adb shell dumpsys activity provider com.google.android.providers.media.module/com.android.providers.media.MediaProvider | head -n 20

Présentation de l'architecture

Cette section décrit l'architecture de la fonctionnalité de transcodage multimédia.

architecture-de-transcodage-média

Figure 2. Architecture de transcodage multimédia.

L'architecture de transcodage multimédia se compose des composants suivants :

  • API système MediaTranscodingManager : Interface qui permet au client de communiquer avec le service MediaTranscoding. Le module MediaProvider utilise cette API.
  • MediaTranscodingService : service natif qui gère les connexions client, planifie les demandes de transcodage et gère la comptabilité des TranscodingSessions .
  • MediaTranscoder : Bibliothèque native qui effectue le transcodage. Cette bibliothèque est construite sur le framework multimédia NDK pour être compatible avec les modules .

La fonctionnalité de transcodage multimédia compatible enregistre les métriques de transcodage à la fois dans le service et dans le transcodeur multimédia. Le code côté client et côté service se trouve dans le module MediaProvider pour permettre des corrections de bogues et des mises à jour en temps opportun.

Accès aux fichiers

Le transcodage multimédia compatible est construit sur le système de fichiers Filesystem in Userspace (FUSE) , qui est utilisé pour le stockage étendu. FUSE permet au module MediaProvider d'examiner les opérations sur les fichiers dans l'espace utilisateur et de contrôler l'accès aux fichiers en fonction de la politique pour autoriser, refuser ou supprimer l'accès.

Lorsqu'une application tente d'accéder à un fichier, le démon FUSE intercepte l'accès en lecture au fichier depuis l'application. Si l'application prend en charge un format plus récent (tel que HEVC), le fichier original est renvoyé. Si l'application ne prend pas en charge le format, le fichier est transcodé dans un format plus ancien (tel qu'AVC) ou est renvoyé du cache si une version transcodée est disponible.

Demander des fichiers transcodés

La fonctionnalité de transcodage multimédia compatible est désactivée par défaut, ce qui signifie que si l'appareil prend en charge HEVC, Android ne transcode pas les fichiers, sauf indication contraire par une application dans un fichier manifeste ou dans la liste de transcodage forcé .

Les applications peuvent demander des éléments transcodés à l'aide des options suivantes :

  • Déclarez les formats non pris en charge dans le fichier manifeste. Pour plus de détails, consultez Déclarer des capacités dans une ressource et Déclarer des capacités dans le code .
  • Ajoutez des applications à la liste de transcodage forcé incluse dans le module MediaProvider . Cela permet le transcodage pour les applications qui n'ont pas mis à jour leur fichier manifeste. Une fois qu'une application met à jour son fichier manifeste avec des formats non pris en charge, elle doit être supprimée de la liste de transcodage forcé. Les fabricants d'appareils peuvent proposer que leurs applications soient ajoutées ou supprimées de la liste de transcodage forcé en soumettant un correctif ou en signalant un bug . L'équipe Android examine périodiquement la liste et peut supprimer des applications de la liste.
  • Désactivez les formats pris en charge avec le cadre de compatibilité des applications au moment de l'exécution (les utilisateurs peuvent également désactiver cette fonctionnalité pour chaque application dans Paramètres).
  • Ouvrez un fichier avec MediaStore tout en spécifiant explicitement les formats non pris en charge avec l'API openTypedAssetFileDescriptor .

Pour les transferts USB (appareil vers PC), le transcodage est désactivé par défaut, mais les utilisateurs peuvent choisir d'activer le transcodage à l'aide du bouton Convertir des vidéos en AVC dans l'écran de configuration des préférences USB , comme illustré dans la figure 3.

Basculer pour activer le transcodage multimédia

Figure 3. Basculez pour activer le transcodage multimédia dans l'écran Préférences USB.

Restrictions sur la demande de fichiers transcodés

Pour éviter que les demandes de transcodage ne bloquent les ressources système pendant des périodes prolongées, les applications demandant des sessions de transcodage sont limitées à :

  • 10 séances consécutives
  • une durée totale de trois minutes

Si une application dépasse toutes ces restrictions, le framework renvoie le descripteur de fichier d'origine.

Exigences relatives à l'appareil

Pour prendre en charge la fonctionnalité de transcodage multimédia compatible, les appareils doivent répondre aux exigences suivantes :

  • L'encodage HEVC est activé par défaut sur l'application appareil photo native de l'appareil.
  • (Appareils prenant en charge le transcodage HDR vers SDR) L'appareil prend en charge la capture vidéo HDR

Pour garantir les performances de l'appareil en matière de transcodage multimédia, les performances du matériel vidéo et de l'accès en lecture/écriture au stockage doivent être optimisées. Lorsque les codecs multimédias sont configurés avec une priorité égale à 1 , les codecs doivent fonctionner au débit le plus élevé possible. Nous recommandons que les performances de transcodage atteignent un minimum de 200 ips. Pour tester les performances de votre matériel, exécutez le benchmark Media Transcoder sur frameworks/av/media/libmediatranscoding/transcoder/benchmark .

Validation

Pour valider la fonctionnalité de transcodage multimédia compatible, exécutez les tests CTS suivants :

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

Activer le transcodage multimédia à l’échelle mondiale

Pour tester la structure de transcodage multimédia ou le comportement de l'application avec le transcodage, vous pouvez activer ou désactiver la fonctionnalité de transcodage multimédia compatible globalement. Dans la page Paramètres > Système > Développeur > Options du développeur de transcodage multimédia , activez l' option Remplacer les paramètres par défaut du transcodage , puis activez ou désactivez l'option Activer le transcodage . Si ce paramètre est activé, le transcodage multimédia peut se produire en arrière-plan pour les applications autres que celle que vous développez.

Vérifier l'état du transcodage

Pendant les tests, vous pouvez utiliser la commande shell ADB suivante pour vérifier l'état du transcodage, y compris les sessions de transcodage en cours et passées :

adb shell dumpsys media.transcoding

Étendre la limitation de la durée de la vidéo

À des fins de test, vous pouvez étendre la limitation de durée vidéo d’une minute pour le transcodage à l’aide de la commande suivante. Un redémarrage peut être nécessaire après l'exécution de cette commande.

adb shell device_config put storage_native_boot transcode_max_duration_ms <LARGE_NUMBER_IN_MS>

Source et références AOSP

Voici le code source AOSP lié au transcodage multimédia compatible.

Encodage HDR vers SDR

Pour prendre en charge l'encodage HDR vers SDR, les fabricants d'appareils peuvent utiliser l'exemple de plug-in de filtre AOSP Codec 2.0 situé dans /platform/frameworks/av/media/codec2/hidl/plugin/ . Cette section décrit le fonctionnement du plugin de filtre, comment implémenter le plugin et comment tester le plugin.

Si un appareil n'inclut pas de plug-in prenant en charge l'encodage HDR vers SDR, une application accédant à une vidéo HDR obtient le descripteur de fichier d'origine, quelles que soient les capacités multimédias de l'application déclarées dans le manifeste.

Comment ça fonctionne

Cette section décrit le comportement général du plugin de filtre Codec 2.0.

Arrière-plan

Android fournit une implémentation de couche d'adaptation entre l'interface Codec 2.0 et l'interface HAL android.hardware.media.c2 sur android::hardware::media::c2 . Pour les plugins de filtre, AOSP inclut un mécanisme de wrapper qui regroupe les décodeurs avec les plugins de filtre. MediaCodec reconnaît ces composants encapsulés comme des décodeurs dotés de fonctionnalités de filtrage.

Aperçu

La classe FilterWrapper prend les codecs du fournisseur et renvoie les codecs encapsulés à la couche d'adaptation media.c2 . La classe FilterWrapper charge libc2filterplugin.so via l'API FilterWrapper::Plugin et enregistre les filtres disponibles à partir du plugin. Lors de la création, FilterWrapper instancie tous les filtres disponibles. Seuls les filtres qui modifient le tampon sont démarrés au démarrage.

Architecture du plugin de filtre

Figure 1. Architecture du plug-in de filtre.

Interface du plugin de filtre

L'interface FilterPlugin.h définit les API suivantes pour exposer les filtres :

  • std::shared_ptr<C2ComponentStore>getComponentStore()

    Renvoie un objet C2ComponentStore qui contient des filtres. Ceci est distinct de ce qu'expose l'implémentation du Codec 2.0 du fournisseur. Généralement, ce magasin contient uniquement les filtres utilisés par la classe FilterWrapper .

  • bool describe(C2String name, Descriptor *desc)

    Décrit les filtres en plus de ceux disponibles sur C2ComponentStore . Les descriptions suivantes sont définies :

    • controlParam : Paramètres qui contrôlent le comportement des filtres. Par exemple, pour le mappeur de tonalité HDR vers SDR, le paramètre de contrôle est la fonction de transfert cible.
    • affectedParams : paramètres affectés par les opérations de filtrage. Par exemple, pour le mappeur de tons HDR vers SDR, les paramètres concernés sont les aspects de couleur.
  • bool isFilteringEnabled(const std::shared_ptr<C2ComponentInterface> &intf)

    Renvoie true si le composant de filtre modifie le tampon. Par exemple, le filtre de mappage de tons renvoie true si la fonction de transfert cible est SDR et la fonction de transfert d'entrée est HDR (HLG ou PQ).

Détails du FilterWrapper

La section décrit les détails de la classe FilterWrapper .

Création

Le composant encapsulé instancie le décodeur sous-jacent et tous les filtres définis lors de la création.

Requête et configuration

Le composant encapsulé sépare les paramètres entrants des requêtes ou des demandes de configuration selon la description du filtre. Par exemple, la configuration du paramètre de contrôle de filtre est acheminée vers le filtre correspondant, et les paramètres affectés des filtres sont présents sur les requêtes (au lieu d'être lus à partir du décodeur qui a des paramètres non affectés).

Requête et configuration

Figure 2. Requête et configuration.

Commencer

Au démarrage, le composant encapsulé démarre le décodeur et tous les filtres qui modifient les tampons. Si aucun filtre n'est activé, le composant encapsulé démarre le décodeur et les tampons pass-through et envoie des commandes au décodeur lui-même.

Gestion des tampons

Gestion des tampons

Figure 3. Gestion des tampons.

Les tampons mis en file d'attente vers le décodeur encapsulé vont vers le décodeur sous-jacent. Le composant encapsulé récupère le tampon de sortie du décodeur via un rappel onWorkDone_nb() , puis le met en file d'attente dans les filtres. Le tampon de sortie final du dernier filtre est signalé au client.

Pour que cette gestion de tampon fonctionne, le composant encapsulé doit configurer C2PortBlockPoolsTuning sur le dernier filtre afin que le framework génère des tampons à partir du pool de blocs attendu.

Arrêter, réinitialiser et relâcher

À l'arrêt, le composant encapsulé arrête le décodeur et tous les filtres activés qui ont été démarrés. Lors de la réinitialisation et de la libération, tous les composants sont réinitialisés ou libérés, qu'ils soient activés ou non.

Implémenter l'exemple de plugin de filtre

Pour activer le plugin, procédez comme suit :

  1. Implémentez l'interface FilterPlugin dans une bibliothèque et déposez-la dans /vendor/lib[64]/libc2filterplugin.so.
  2. Ajoutez des autorisations supplémentaires à mediacodec.te si nécessaire.
  3. Mettez à jour la couche d'adaptation vers Android 12 et reconstruisez le service media.c2 .

Testez le plugin

Pour tester l'exemple de plugin, procédez comme suit :

  1. Reconstruisez et flashez l'appareil.
  2. Créez l'exemple de plug-in à l'aide de la commande suivante :

    m sample-codec2-filter-plugin
    
  3. Remontez l'appareil et renommez le plugin du fournisseur afin qu'il soit reconnu par le service de codec.

    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