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 économes en 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 exigences de stockage et de 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 lorsqu'elles sont ouvertes par une application non compatible. 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 fonctionnalité de transcodage de contenus multimédias dans un format compatible est désactivée par défaut. Pour demander le transcodage multimédia, les applications doivent déclarer leurs fonctionnalités multimédias. Pour en savoir plus sur la déclaration de fonctionnalités multimédias, consultez la section Transcodage de contenus multimédias compatibles sur le site des développeurs Android.

Fonctionnement

La fonctionnalité de transcodage de contenus multimédias compatible comprend deux parties principales:

  • Services de transcodage dans le framework multimédia:ces services convertissent des fichiers d'un format à un autre à l'aide de matériel pour offrir une faible latence et des conversions 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 en savoir plus, consultez la section Présentation de l'architecture.
  • Fonctionnalité de transcodage multimédia compatible chez les fournisseurs multimédias:ce composant disponible chez les fournisseurs multimédias intercepte les applications qui accèdent aux fichiers multimédias et diffuse le fichier d'origine ou un fichier transcodé en fonction des fonctionnalités déclarées par l'application. Si une application est compatible avec le format du fichier multimédia, aucune gestion spéciale n'est requise. Si une application n'est pas compatible avec le format, le framework convertit le fichier vers un format plus ancien, tel que AVC, lorsque l'application y accède.

La figure 1 présente le processus de transcodage de contenus multimédias.

Processus de transcodage de contenus multimédias dans un format compatible

Figure 1 : Présentation du transcodage de contenus multimédias dans un format compatible.

Formats compatibles

La fonctionnalité de transcodage multimédia compatible accepte 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 en SDR sont effectuées à l'aide d'instances Mediacodec et d'un hachage de plug-in fournisseur dans les instances du décodeur. Pour en savoir plus, consultez Encodage HDR vers SDR.

Sources de contenu compatibles

La fonctionnalité de transcodage multimédia compatible prend en charge les contenus multimédias sur l'appareil générés par l'application d'appareil photo OEM native stockée dans le dossier DCIM/Camera/ du volume externe principal. Cette fonctionnalité n'est pas compatible avec les contenus multimédias sur un stockage secondaire. Les contenus transmis aux appareils par e-mail ou carte SD ne sont pas acceptés.

Les applications accèdent aux fichiers en fonction de différents chemins d'accès. Vous trouverez ci-dessous la description des chemins d'accès pour lesquels le transcodage est activé ou ignoré :

  • Transcodage activé:

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

  • Transcodage ignoré:

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

Ajouter des chemins d'accès personnalisés pour le transcodage

Les fabricants d'appareils peuvent éventuellement ajouter des chemins d'accès pour le transcodage multimédia dans le répertoire DCIM/. Les chemins situés en dehors du répertoire DCIM/ sont refusés. L'ajout de ces chemins d'accès peut être nécessaire pour répondre aux exigences du transporteur ou aux réglementations locales.

Pour ajouter un chemin d'accès au fichier, utilisez le chemin de transcodage de la superposition de ressources d'exécution (RRO), config_supported_transcoding_relative_paths. Voici un exemple d'ajout d'un chemin d'accès :

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

Pour vérifier les chemins d'accès aux 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-media

Figure 2. Architecture de transcodage multimédia

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

  • API système MediaTranscodingManager : interface permettant 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 requêtes de transcodage et gère la comptabilité pour TranscodingSessions.
  • MediaTranscoder:bibliothèque native qui effectue le transcodage. Cette bibliothèque est basée sur le NDK du framework multimédia pour être compatible avec les modules.

La fonctionnalité de transcodage multimédia compatible enregistre les métriques de transcodage dans le service et dans le transcodage de contenus multimédias. Le code côté client et côté service se trouve dans le module MediaProvider pour permettre de corriger les bugs et de mettre à jour le code de manière opportune.

Accès au fichier

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

Lorsqu'une application tente d'accéder à un fichier, le daemon FUSE intercepte l'accès en lecture du fichier à partir de l'application. Si l'application est compatible avec un format plus récent (tel que HEVC), le fichier d'origine est renvoyé. Si l'application n'est pas compatible avec ce format, le fichier est transcodé dans un format plus ancien (par exemple, AVC) ou est renvoyé à partir 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. Par conséquent, si l'appareil est compatible avec le format HEVC, Android ne transcode pas les fichiers, sauf si une application l'indique dans un fichier manifeste ou dans la liste de transcodage forcée.

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

  • Déclarer des formats non compatibles dans le fichier manifeste Pour en savoir plus, 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 a mis à jour son fichier manifeste avec des formats non compatibles, elle doit être supprimée de la liste de transcodage forcé. Les fabricants d'appareils peuvent demander l'ajout ou la suppression de leurs applications de la liste de transcodage forcé en envoyant un correctif ou en signalant un bug. L'équipe Android examine régulièrement la liste et peut en supprimer des applications.
  • Désactivez les formats compatibles avec le framework de compatibilité des applications au moment de l'exécution (les utilisateurs peuvent également désactiver cette option pour chaque application dans les paramètres).
  • Ouvrez un fichier avec MediaStore en spécifiant explicitement les formats non compatibles avec l'API openTypedAssetFileDescriptor.

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

Activer/Désactiver le transcodage multimédia

Figure 3. Activez le transcodage multimédia sur l'écran "Préférences USB".

Restrictions concernant les requêtes de fichiers transcodés

Pour éviter que les requêtes de transcodage ne bloquent les ressources système pendant de longues périodes, les applications qui demandent des sessions de transcodage sont limitées aux éléments suivants :

  • 10 sessions consécutives
  • une durée d'exécution totale de trois minutes ;

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

Configuration d'appareil requise

Pour accepter 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 d'appareil photo native de l'appareil.
  • (Appareils compatibles avec le transcodage HDR vers SDR) L'appareil est compatible avec 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, ils doivent fonctionner au débit le plus élevé possible. Nous vous recommandons d'atteindre au moins 200 FPS pour les performances de transcodage. Pour tester les performances de votre matériel, exécutez le benchmark du transcodeur multimédia à 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 de façon globale

Pour tester le framework 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 à l'échelle globale. Sur la page Settings > System > Developer > Media transcodage (Paramètres > Système > Développeur > Transcodage multimédia), définissez le bouton Ignorer les valeurs par défaut de transcodage sur activé, puis définissez le bouton Activer le transcodage sur activé ou désactivé. 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

Lors des 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

Prolonger la limite de durée de la vidéo

À des fins de test, vous pouvez étendre la limite de durée de 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

Vous trouverez ci-dessous le code source AOSP associé au transcodage de contenus multimé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 Codec 2.0 AOSP situé dans /platform/frameworks/av/media/codec2/hidl/plugin/. Cette section décrit le fonctionnement du plug-in de filtrage, comment l'implémenter et comment le tester.

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

Fonctionnement

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 à android::hardware::media::c2. Pour les plug-ins de filtre, AOSP inclut un mécanisme de wrapper qui encapsule les décodeurs avec les plug-ins de filtre. MediaCodec reconnaît ces composants encapsulés comme des décodeurs avec des fonctionnalités de filtrage.

Présentation

La classe FilterWrapper renvoie les codecs fournisseurs 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 plug-in. 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 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 contenant des filtres. Cela 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 dans C2ComponentStore. Les descriptions suivantes sont définies :

    • controlParam : paramètres qui contrôlent le comportement des filtres. Par exemple, pour le mappeur de tons 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 des tons renvoie true si la fonction de transfert cible est SDR et que la fonction de transfert d'entrée est HDR (HLG ou PQ).

Détails de FilterWrapper

Cette 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 requêtes de configuration en fonction de la description du filtre. Par exemple, la configuration du paramètre de commande de filtrage est acheminée vers le filtre correspondant, et les paramètres concernés par les filtres sont présents dans les requêtes (au lieu de lire à partir du décodeur dont les paramètres ne sont pas affectés).

Requête et configuration

Figure 2. Requête et configuration

Début

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 passthrough et envoie des commandes au décodeur lui-même.

Gestion des tampons

Gestion des tampons

Figure 3. Gestion du tampon.

Les tampons mis en file d'attente vers le décodeur encapsulé sont dirigés 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 du tampon fonctionne, le composant encapsulé doit configurer C2PortBlockPoolsTuning sur le dernier filtre afin que le framework de sortie soit mis en mémoire tampon à 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. Au moment de la réinitialisation et de la publication, tous les composants sont réinitialisés ou libérés, qu'ils soient activés ou non.

Implémenter l'exemple de plug-in de filtre

Pour activer le plug-in, procédez comme suit:

  1. Implémentez l'interface FilterPlugin dans une bibliothèque et placez-la à /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 recompilez le service media.c2.

Tester le plug-in

Pour tester l'exemple de plug-in, procédez comme suit:

  1. Recompilez et flashez l'appareil.

  2. Compilez l'exemple de plug-in à l'aide de la commande suivante :

    m sample-codec2-filter-plugin

  3. Réinstallez 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