Transcodage multimédia compatible

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 efficaces en matière de stockage pour la capture vidéo, tels que HEVC, tout en maintenant 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 le 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 le 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 fonction 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 des conversions à faible latence et de haute qualité. Cela inclut l'API de transcodage, le service de transcodage, un plug-in OEM pour les filtres personnalisés et le matériel. Pour plus de détails, voir Vue d'ensemble de l'architecture .
  • Fonction de transcodage multimédia compatible dans les fournisseurs de médias : ce composant trouvé dans les fournisseurs de médias intercepte les applications accédant aux fichiers multimédias et sert soit le fichier d'origine, 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 spéciale 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 une vue d'ensemble du processus de transcodage multimédia.

Processus de transcodage multimédia compatible

Figure 1. Vue d'ensemble du transcodage de médias compatibles.

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 codec sont effectuées en connectant un décodeur mediacodec et un encodeur mediacode.
  • HDR10+ (10 bits) vers AVC (SDR) : les conversions HDR vers SDR sont effectuées à l'aide d'instances de mediacodec et d'un crochet de plug-in de fournisseur dans les instances de décodeur. Pour plus d'informations, voir Encodage HDR vers SDR .

Sources de contenu prises en charge

La fonction 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/ dans le volume externe principal. La fonctionnalité ne prend pas en charge les médias sur le stockage secondaire. Le contenu transmis aux appareils par e-mail ou cartes SD n'est pas pris en charge.

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

  • Transcodage activé :

    • Accès à l'application via les API MediaStore
    • Accès aux applications via des API de chemin de fichier direct, y compris Java et du code natif
    • Accès aux applications via le Storage Access Framework (SAF)
    • Accès à l'application via la feuille de partage du système d'exploitation Intentions. (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 sous 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 de l'opérateur ou aux réglementations locales.

Pour ajouter un chemin de fichier, utilisez la superposition de ressources d'exécution du chemin de transcodage (RRO) , config_supported_transcoding_relative_paths . Voici un exemple d'ajout d'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 fonction de transcodage multimédia.

architecture de transcodage multimé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 fonction de transcodage multimédia compatible consigne les métriques de transcodage dans le service et 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 de médias compatibles est construit au-dessus du système de fichiers Filesystem in Userspace (FUSE) , qui est utilisé pour le stockage délimité. FUSE permet au module MediaProvider d'examiner les opérations sur les fichiers dans l'espace utilisateur et de limiter l'accès aux fichiers en fonction de la politique pour autoriser, refuser ou masquer 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 d'origine est renvoyé. Si l'application ne prend pas en charge le format, le fichier est transcodé dans un format plus ancien (comme 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 d'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 fonctionnalités dans une ressource et Déclarer des fonctionnalité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 désigner leurs applications pour qu'elles soient ajoutées ou supprimées de la liste de transcodage forcé en soumettant un correctif ou en signalant un bogue . 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 le désactiver pour chaque application dans les 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 de la bascule Convertir les vidéos en AVC dans l'écran de réglage des préférences USB , comme illustré à 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 de longues périodes, 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.

Configuration requise pour l'appareil

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

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

Pour garantir les performances de l'appareil pour le transcodage multimédia, les performances d'accès en lecture/écriture du matériel vidéo et du 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 du transcodeur multimédia 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 globalement la fonctionnalité de transcodage multimédia compatible. Dans la page Paramètres > Système > Développeur > Options de développeur de transcodage multimédia , activez la bascule Remplacer les valeurs par défaut de transcodage , puis activez ou désactivez la bascule Activer le transcodage . Si ce paramètre est activé, le transcodage multimédia peut se produire en arrière-plan pour des 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 actuelles 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 limite de longueur 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 de médias compatibles.

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 filtrage, 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 plug-in 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 filtrage, AOSP inclut un mécanisme d'encapsulation qui encapsule les décodeurs avec les plugins de filtrage. MediaCodec reconnaît ces composants enveloppés comme des décodeurs avec des 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 lancés au démarrage.

Architecture du plug-in de filtrage

Figure 1. Architecture du plug-in de filtrage.

Interface du plug-in de filtrage

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 que l'implémentation du codec 2.0 du fournisseur expose. En règle générale, ce magasin ne contient que les filtres utilisés par la classe FilterWrapper .

  • bool describe(C2String name, Descriptor *desc)

    Décrit les filtres en plus de ce qui est disponible 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 tonalité HDR vers SDR, les paramètres affecté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 tonalité 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 de FilterWrapper

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

Création

Le composant enveloppé 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 en fonction de la description du filtre. Par exemple, la configuration du paramètre de commande 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 enveloppé 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 d'intercommunication et envoie des commandes au décodeur lui-même.

Gestion des tampons

Gestion des tampons

Figure 3. Manipulation du tampon.

Les tampons mis en file d'attente vers le décodeur encapsulé vont au décodeur sous-jacent. Le composant enveloppé 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 des tampons fonctionne, le composant encapsulé doit configurer C2PortBlockPoolsTuning sur le dernier filtre afin que les tampons de sortie de l'infrastructure proviennent du pool de blocs attendu.

Arrêtez, réinitialisez et relâchez

À 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 plug-in, procédez comme suit :

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

    m sample-codec2-filter-plugin
    
  3. Remontez l'appareil et renommez le plug-in 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