Capacités WebCodecs et confidentialité du navigateur

WebCodecs donne aux applications web un accès de bas niveau à l’encodage et au décodage audio et vidéo (définition du W3C). VideoFrame accepte aussi des sources d’image prises en charge ; des images peuvent ainsi fournir des trames à un traitement vidéo (VideoFrame du W3C), sans faire de WebCodecs une API générale de codec d’images fixes. Le support annoncé aide à choisir un traitement, mais ne décrit pas entièrement un appareil et ne constitue pas une identité. Il peut varier selon le navigateur, le système d’exploitation, les codecs disponibles et le contexte d’exécution.

Ce que WebCodecs expose

L’API représente le traitement média par des fragments encodés et des configurations de codec. Une application peut vérifier le support d’une configuration avant de commencer, afin d’éviter un chemin que le navigateur ne sait pas effectuer. Cette réponse aide à choisir un chemin, sans garantir une vitesse ou une qualité précises. Cette vérification ne garantit pas la réussite du traitement asynchrone ultérieur : ses erreurs sont signalées séparément par le rappel d’erreur (vérification du support, modèle de traitement, rappel d’erreur).

Ce sujet diffère d’une déclaration de type de fichier ou de la négociation d’un appel en temps réel. La spécification du W3C précise que les médias encodés n’y sont pas encapsulés dans un conteneur (chaîne de codec) ; WebCodecs ne définit pas non plus le transport réseau, qui relève donc d’une couche applicative distincte. Voir MIME et support des codecs et comportement des codecs WebRTC pour ces sujets voisins.

Une vérification positive ne garantit pas que le traitement soit prêt. La création du codec peut échouer à cause d’un manque de ressources ou d’un changement de contexte. La réponse porte sur toute la configuration soumise, qui peut inclure profil, dimensions, cadence d’image, fréquence d’échantillonnage et autres paramètres ; vérifiez celle de la tâche demandée, pas un inventaire de combinaisons sans rapport (support de configuration).

Le traitement étant asynchrone, gérez files d’attente, sorties, erreurs et ressources. La spécification expose la taille des files d’encodage et de décodage ainsi que des événements dequeue ; le travail peut s’accumuler lorsque le codec est saturé (modèle de traitement). Limitez le travail en attente et appliquez une contre-pression : suspendez les nouvelles entrées lorsque l’étape suivante ne suit pas, au lieu de supprimer silencieusement des trames que l’utilisateur veut conserver. Fermez VideoFrame et AudioData lorsqu’ils ne sont plus utiles (ressources système, VideoFrame.close()).

Indiquez si la tâche attend, traite, est en pause ou est prête ; une réponse de support ne décrit pas un travail en cours. Un aperçu peut utiliser une représentation réduite par rapport à l’export demandé, à condition que l’interface le précise. En cas d’annulation applicative, cessez les entrées, libérez les ressources et gardez la source pour permettre un autre choix.

Le seuil de saturation dépend de l’implémentation et peut être illimité ; la taille de file compte les demandes en attente, ce n’est ni un seuil universel de performance ni un résultat final.

Un événement dequeue aide à réguler les nouvelles entrées, mais ne confirme pas la fin des rappels de sortie ou du muxage. Suivez ces étapes séparément, car une file de codec ne décrit pas à elle seule l’état des files suivantes.

Le codec peut retenir des sorties jusqu’à de nouvelles entrées, tandis que flush() exige l’émission des sorties en attente ; vérifiez aussi les dernières trames et les derniers fragments avant de conclure.

L’état de la file, des rappels et du fichier correspond à des mesures distinctes du parcours applicatif, pas à des propriétés de l’appareil. Une file qui raccourcit ne signifie pas que l’export est terminé, et l’heure d’arrivée d’un rappel ne remplace pas les horodatages média.

VideoFrame.timestamp et duration sont exprimés en microsecondes : conservez la chronologie au lieu d’utiliser l’heure d’arrivée du rappel. Vérifiez aussi les informations de couleur, le rectangle visible, le recadrage, la rotation et le retournement lors d’une conversion ou d’un export. VideoFrame et AudioData peuvent retenir de la mémoire CPU/GPU et des ressources exclusives du codec. Fermez chaque objet après son utilisation et définissez qui le détient lorsqu’il passe par un moteur d’affichage, une file ou un muxeur. Lors d’une annulation, fermez les trames qui n’ont pas encore atteint un consommateur, mais pas un objet dont une autre partie du pipeline a encore besoin (ressources système, VideoFrame).

Pourquoi le support varie

WebCodecs est une interface, pas une garantie que chaque codec soit disponible partout. Le support dépend des fonctions implémentées dans la version du navigateur et des codecs proposés par le système ou sa pile média. L’accélération matérielle peut aussi intervenir, mais la prise en charge d’une configuration ne prouve pas qu’elle sera accélérée.

Les normes et leurs implémentations évoluent : une version peut ajouter une fonction, corriger une implémentation ou modifier son intégration au système. Celui-ci peut mettre à jour ses services média indépendamment, et un administrateur peut restreindre des fonctions sur un poste géré. Consignez la version du navigateur, la famille du système, la version de l’application et le besoin média pour rendre le rapport utile sans déduire des caractéristiques matérielles non observées. Des versions portant le même numéro n’offrent pas nécessairement le même environnement média : certaines distributions dépendent de bibliothèques ou codecs système et suivent leur propre calendrier. Deux machines peuvent répondre pareil à une requête de support tout en ayant des performances différentes ; le support décrit la compatibilité, pas un benchmark.

Quand l’accélération importe, mesurez la tâche réelle sur des systèmes représentatifs et séparez ce résultat des affirmations de confidentialité ou d’identité. Une mise à jour du navigateur peut changer la disponibilité sans changement de norme ; vérifiez à nouveau lorsque l’application doit choisir un parcours et ne traitez pas une ancienne réponse comme une métadonnée permanente de l’appareil. Un poste de travail administré peut restreindre une fonction par politique tandis qu’une installation personnelle l’expose ; les deux résultats peuvent être valides dans leurs plages de support respectives. Ne transformez pas un résultat unique en règle universelle de plateforme. Si le navigateur utilise un service média système, une mise à jour système peut changer le parcours disponible sans changement visible de l’application.

Une note de version doit nommer la tâche retestée et le repli disponible, sans promettre un niveau de qualité sur chaque machine. Un tableau de compatibilité est utile s’il précise ce qui a été testé, observé et ce que l’utilisateur peut faire ensuite. Notez aussi si le test utilisait un fichier importé, une source en direct ou un échantillon généré : permissions et traitement des données diffèrent. Un extrait court ne couvre pas nécessairement un export long, une cadence variable, plusieurs pistes audio ou un téléchargement interrompu. Documentez ces limites sans exposer les détails internes d’implémentation.

Si une tâche n’est pas prise en charge, proposez avant que l’utilisateur n’engage temps ou données un autre format, un traitement local alternatif ou un téléversement explicite vers un service. Testez le parcours de première utilisation : choisir un fichier, accorder une permission nécessaire, choisir une sortie et attendre la fin. Un échec à n’importe quelle étape doit laisser la source disponible et indiquer la suite sans redemander une permission sans rapport. Pour un usage récurrent, le produit peut mémoriser une préférence de format sans conserver tout l’inventaire de capacités. Cette préférence doit être facile à changer si une mise à jour modifie le parcours ; un choix utilisateur n’est pas une observation du navigateur.

Limites de confidentialité et de compatibilité

Le W3C indique qu’un profil de capacités de codecs a très peu de chances d’identifier quelqu’un de façon unique à lui seul, mais qu’il peut être combiné à d’autres métriques pour créer une empreinte (considérations de confidentialité). N’en faites pas une garantie qu’une réponse ne peut pas contribuer à identifier une personne ou un appareil. Le risque augmente lorsque l’application conserve des observations inutiles ou les rapproche d’autres données. Ne demandez que les configurations utiles au traitement média et n’enregistrez pas les détails bruts si une simple décision de lecture suffit.

WebCodecs ne supprime pas les autorisations exigées par les API voisines pour accéder aux médias. L’interface doit distinguer le choix d’un chemin compatible de l’accès aux médias de l’utilisateur. Le traitement local ne prouve pas que l’application n’envoie pas de média ou de télémétrie ailleurs : c’est un point à vérifier dans le flux de données applicatif, pas une garantie de WebCodecs. En cas d’échec ou d’annulation, conservez le média original et prévoyez une reprise ; avant de passer à un envoi distant, expliquez le parcours des données et demandez un choix explicite.

WebCodecs ne fournit pas une caméra, un microphone ou un fichier : ces entrées ont leurs propres permissions et attentes. Ne demandez une entrée que lorsque nécessaire, expliquez-le dans son contexte et distinguez fichiers importés et capture en direct. Proportionnez les vérifications de compatibilité à la tâche : un éditeur audio peut devoir décoder un import et encoder un export, sans interroger des réglages vidéo sans rapport. Des vérifications ciblées réduisent la complexité et gardent la collecte alignée sur la fonction. Séparez aussi le choix de capacité de l’identité du compte pour éviter de transformer une décision média en champ de profil caché.

Si une télémétrie est utile au support, préférez un résultat agrégé, terminé, indisponible ou repli utilisé, et expliquez pourquoi il est conservé et pendant combien de temps. Ne gardez pas l’objet de configuration complet lorsqu’un état réduit suffit. Le média source peut contenir voix, visages, lieux ou documents privés ; définissez pour lui des règles d’accès et de suppression distinctes. Ne qualifiez pas un aperçu local de privé si l’original est ensuite téléversé pour l’export. Une conversion distante doit révéler la frontière du service avant le début du téléversement. Ces distinctions aident l’utilisateur à choisir et le support à décrire ce que le navigateur a fait.

Examiner une version

Comparez la même application et la même tâche média sur les versions de navigateur prises en charge. Notez si le parcours aboutit, utilise un repli ou change après une mise à jour. Partez des exigences visibles, entrée, sortie attendue, repli pris en charge et média représentatif, testez jusqu’au traitement de sortie et séparez acceptation fonctionnelle de fidélité visuelle, synchronisation, latence, mémoire et taille du fichier. Pour reproduire un écart, gardez une reproduction minimale avec révision de l’application, build du navigateur, version du système, type d’entrée, configuration demandée et résultat observé, sans collecter de détails d’environnement sans rapport. La revue des versions du navigateur traite navigateur et configuration testée comme une unité de version.

Organisez les essais par tâche, pas pour chaque combinaison de codecs : ouvrir un enregistrement, couper un extrait, l’exporter puis le relire. Notez conteneur et pistes d’entrée, sortie attendue et point d’annulation. Préférez les échantillons synthétiques ; un extrait long peut révéler croissance de file, trous d’horodatage et pression mémoire sans média personnel. Testez séparément sélection de fichier et permissions caméra ou microphone, et vérifiez qu’un refus de capture en direct laisse l’import utilisable. Navigation, mise en arrière-plan ou veille ne doivent pas afficher un faux succès. Notez si un export interrompu supprime le fichier partiel, le rend récupérable ou ne l’expose jamais. Une reprise doit utiliser une entrée connue et ne pas basculer silencieusement d’un traitement local choisi vers un service distant.

Inspectez métadonnées du conteneur, ordre et durée des pistes, ordre des trames, rotation, sous-titres et interprétation des couleurs ; en audio, écoutez les débuts coupés, canaux manquants et décalages après recherche. Testez séparément configurations non prises en charge, entrée malformée, manque de ressources, annulation et sortie incomplète. Vérifiez la continuité temporelle après recherche et que les trames volontairement omises de l’aperçu restent présentes dans l’export d’archive. Ces contrôles indiquent si la tâche fonctionne sans créer un inventaire général de capacités.

Les méthodes du codec ne sont pas synonymes d’annulation applicative. flush() termine les messages de contrôle en attente et émet les sorties, mais n’encapsule pas un conteneur et ne confirme pas que l’écriture du fichier est finie (AudioEncoder.flush()). Attendez sa promesse, traitez chaque rappel de sortie et terminez le muxage et l’enregistrement avant d’annoncer l’export prêt. reset() réinitialise l’état, la configuration, les messages en attente et les rappels ; il faut reconfigurer l’objet avant réutilisation (AudioEncoder.reset()). close() interrompt le travail en cours, libère les ressources système et est définitif (AudioEncoder.close()). L’annulation est une décision de l’application : arrêter les entrées, choisir reset ou close selon le cycle de vie, conserver la source et signaler l’annulation ou la sortie incomplète, jamais un succès. Un aperçu direct peut ignorer des trames périmées, tandis qu’un export d’archive doit parfois toutes les garder ; indiquez cette règle. Avant une tâche média, vérifiez si cette version du navigateur est prise en charge et quel repli est disponible si la configuration du codec ne l’est pas. Un traitement local et une conversion distante ont des flux de données différents : expliquez tout envoi avant le transfert. Ne retirez un ancien parcours qu’après validation du remplacement pour les mêmes tâches et accord avec la politique de support. Pour l’assistance, consignez navigateur, système, version de l’application, tâche et résultat visible ; préférez les échantillons synthétiques et ne gardez pas les médias ni des profils détaillés au-delà du besoin documenté. Une tâche n’est prête que lorsque sortie et état applicatif concordent : le codec peut avoir terminé sans que le résultat soit complet, synchronisé ou encapsulé. Après VideoDecoder.flush(), l’entrée suivante doit être un fragment clé ; prévoyez-le pour reprendre après une recherche ou un redémarrage (VideoDecoder.flush()).

reset() ou close() ne peuvent pas annuler les octets déjà écrits dans un fichier par l’application.

Correspondance affirmations-sources

• Le support concerne la configuration complète du codec selon le support de configuration, et non un inventaire général de la machine.
• Les fragments encodés ne sont pas encapsulés ; les files et sorties suivent la chaîne de codec et le modèle de traitement.
• Les métadonnées de VideoFrame et la propriété des ressources sont décrites par VideoFrame et les ressources système.
• La limite nuancée concernant l’empreinte figure dans les considérations de confidentialité ; les téléversements et la télémétrie de l’application sont des choix distincts de flux de données.
• Les affirmations sur flush(), reset() et close() renvoient aux méthodes de l’encodeur et au flush du décodeur.

Sources publiques

• WebCodecs du W3C : support de configuration
• WebCodecs du W3C : chaîne de codec et médias sans conteneur
• WebCodecs du W3C : modèle de traitement et files
• WebCodecs du W3C : sortie du codec en attente
• WebCodecs du W3C : confidentialité
• WebCodecs du W3C : VideoFrame et ressources système
• WebCodecs du W3C : flush, reset et close
• WebCodecs du W3C : flush du décodeur et trames clés
• MDN : API WebCodecs