Fingerprinting MIME et codec : signaux de prise en charge

canPlayType(), isTypeSupported() et decodingInfo() répondent différemment pour les mêmes chaînes MIME et de codecs. BotBrowser peut aligner ces réponses sur le profil grâce à un mode de types média ; il ne peut pas ajouter un décodeur que la machine hôte n'a pas.

Regarder la vidéo

Cette vidéo en anglais enquête sur un symptôme : la même chaîne MIME peut recevoir des réponses différentes sur deux machines. Elle examine quatre suspects dans l'ordre : les trois API qui répondent (canPlayType(), MediaSource.isTypeSupported() et MediaCapabilities.decodingInfo()), la chaîne MIME elle-même, l'hôte sous-jacent et le contexte qui interroge. Une page de laboratoire locale déclare une liste fixe de types de médias et interroge chaque API dans la page principale, un Worker dédié et un iframe de même origine ; les réponses sont lues dans la console DevTools d'un navigateur sur un runner Ubuntu et sur un runner Windows. Elle cite ensuite l'article et la documentation BotBrowser sur l'option --bot-media-types et ses trois modes (expand, profile, real). Aucun profil BotBrowser n'est chargé dans les enregistrements : les modes sont cités, pas exécutés. L'audio est en anglais.

Résumé rapide

Les trois API répondent à la même question avec un détail différent, et decodingInfo() ajoute les indicateurs supported, smooth et powerEfficient. Figez une liste de types avec des paramètres codecs explicites et comparez-la entre une page, un Worker et un élément média.

Sommaire de la guide

• Regarder la vidéo
• Ce que signalent les trois API média
• Pourquoi les réponses diffèrent d'une machine à l'autre
• Lire les réponses côte à côte
• Vérifier un profil dans plusieurs contextes
• Limites de confidentialité des requêtes média
• Choisir un mode pour les types média

Ce que signalent les trois API média

HTMLMediaElement.canPlayType(type) prend une chaîne de type MIME, éventuellement avec un paramètre codecs, et renvoie une chaîne vide, maybe ou probably (MDN canPlayType). Une chaîne vide signifie que le navigateur ne peut pas lire ce type. probably indique qu'il en est confiant, et maybe qu'il ne peut pas le savoir sans essayer. La réponse à trois valeurs est volontairement grossière, elle en dit donc peu sur la qualité ou les performances.

MediaSource.isTypeSupported(type) est une méthode statique qui renvoie un booléen pour un type MIME accompagné d'une liste facultative de codecs (MDN isTypeSupported). Elle indique à un lecteur si le navigateur acceptera probablement ce type pour la diffusion via Media Source Extensions. Un résultat true est une prédiction de prise en charge, pas la preuve qu'un flux donné sera lu.

MediaCapabilities.decodingInfo(configuration) est la plus détaillée des trois (MDN decodingInfo). La configuration décrit un flux, avec un type de contenu et, pour la vidéo, les dimensions, le débit et la fréquence d'images. La promesse renvoyée se résout avec les indicateurs supported, smooth et powerEfficient. Les deux derniers décrivent le bon déroulement attendu du décodage, ils dépendent donc davantage du matériel et de l'historique propre au navigateur que les simples réponses de prise en charge.

Toutes partent d'une chaîne de type MIME. Un type de conteneur seul, comme video/mp4, en dit peu, car un même conteneur peut transporter de nombreux codecs. Le paramètre facultatif codecs nomme les codecs réels, par exemple avc1.42E01E pour la vidéo H.264, mp4a.40.2 pour l'audio AAC, vp09.00.10.08 pour la vidéo VP9 ou opus pour l'audio Opus. Les chaînes de codec sont compactes à dessein et encodent un profil et un niveau, si bien que deux chaînes de la même famille de codecs peuvent recevoir des réponses différentes.

Le champ type d'une configuration de decodingInfo() compte aussi. file décrit la lecture simple d'une ressource, tandis que media-source décrit la diffusion via Media Source Extensions, et les deux chemins ne sont pas obligés de concorder. Interroger avec le type qui correspond au fonctionnement réel de votre lecteur garde la réponse pertinente pour la tâche et rend la question identique à chaque fois.

Les appels ci-dessous montrent les trois formes côte à côte.

const type = 'video/mp4; codecs="avc1.42E01E, mp4a.40.2"';
document.createElement('video').canPlayType(type);
MediaSource.isTypeSupported(type);
await navigator.mediaCapabilities.decodingInfo({
  type: 'media-source',
  video: { contentType: 'video/mp4; codecs="avc1.42E01E"', width: 1280, height: 720, bitrate: 2500000, framerate: 30 },
});

Le même code peut afficher des réponses différentes sur deux ordinateurs, ou sur un seul après une mise à jour du navigateur. La chaîne MIME n'est qu'une question. La réponse vient des décodeurs et des politiques dont dispose le navigateur qui la reçoit.

Les médias chiffrés ajoutent une autre couche. decodingInfo() peut aussi être interrogée sur un système de clés, ce qui relève du DRM et non de la simple prise en charge des codecs. Le fingerprinting du DRM traite cette frontière, et les capacités de WebCodecs traitent l'interface de codecs de plus bas niveau, qui a ses propres requêtes de prise en charge.

Pourquoi les réponses diffèrent d'une machine à l'autre

Comparez canPlayType() et MediaSource.isTypeSupported() avec la même chaîne MIME ; le navigateur, le système, le GPU et la politique gérée peuvent modifier chaque réponse.

Une réponse média résulte de plusieurs couches, et chacune peut changer indépendamment. La compilation du navigateur décide quels codecs sont inclus ou sous licence, et certaines compilations ouvertes sont livrées sans codecs propriétaires. Le système d'exploitation décide quels décodeurs sont accessibles par ses services multimédias. Le matériel graphique décide quels codecs peuvent être décodés par le matériel. Les politiques et les réglages peuvent désactiver des fonctions sur une machine gérée.

• Version du navigateur : de nouveaux codecs et de nouvelles fonctions de conteneur arrivent avec le temps, et un chemin de code peut perdre la prise en charge d'un ancien.
• Système d'exploitation : un décodeur installé sur un système peut manquer sur un autre, même avec la même version du navigateur.
• Matériel : un matériel graphique récent peut décoder des codecs qu'un appareil plus ancien traite par logiciel ou pas du tout.
• Configuration : les politiques d'entreprise, les réglages de l'utilisateur et les options de ligne de commande peuvent modifier ce que le navigateur signale.

Des exemples rendent le schéma concret. La vidéo H.264 et l'audio AAC sont largement disponibles dans les navigateurs de bureau courants, et VP9 et Opus sont eux aussi répandus. HEVC dépend souvent d'un décodeur fourni par le système d'exploitation ou le matériel graphique, et AV1 dépend soit d'un décodeur logiciel du navigateur, soit d'un matériel plus récent. Ce sont des tendances, pas des règles.

L'environnement de test change aussi le tableau. Une machine virtuelle ou une session de bureau à distance n'a souvent pas de décodage matériel, de sorte que les résultats de powerEfficient et les réponses en haute résolution peuvent y différer beaucoup de ceux d'un poste physique du même système d'exploitation. Quand vous comparez deux machines, notez si chacune est physique ou virtuelle, car ce seul fait explique de nombreuses différences qui semblent mystérieuses au premier abord.

Cette variation explique pourquoi les réponses sont utiles pour la compatibilité, et aussi pourquoi elles portent des informations sur la machine. Un site qui interroge une douzaine de chaînes de codec reçoit un schéma, et ce schéma tend à se regrouper par famille de système d'exploitation et par génération de matériel. C'est toute la raison pour laquelle les requêtes média apparaissent dans les discussions sur la vie privée.

Il faut être précis sur le poids de ce schéma. Un vecteur de prise en charge des médias est un signal parmi beaucoup d'autres. Il n'identifie pas une personne, aucun résultat isolé ne tranche quoi que ce soit, et de nombreuses personnes différentes partagent le même schéma. Son effet pratique est de réduire l'ensemble des appareils que pourrait décrire un ensemble combiné de signaux, et c'est pourquoi il doit concorder avec les autres signaux que le navigateur déclare.

La réponse peut aussi changer sur la même machine. Une mise à jour du navigateur peut ajouter un chemin de décodage, une mise à jour de pilote peut activer le décodage matériel et un changement de politique peut désactiver une fonction. Une réponse enregistrée est donc une observation datée d'une configuration précise, à revérifier après les mises à jour plutôt qu'à traiter comme une propriété permanente.

Lire les réponses côte à côte

Les trois interfaces sont liées mais pas interchangeables, et un examen utile les compare avec les mêmes chaînes de codec. Chacune a un rôle différent.

• canPlayType() répond pour la lecture simple dans un élément média et renvoie une chaîne à trois états.
• isTypeSupported() répond pour la diffusion via Media Source Extensions et renvoie un booléen.
• decodingInfo() répond pour un flux décrit et ajoute smooth et powerEfficient.

Deux attentes de cohérence en découlent. D'abord, les réponses doivent aller dans le même sens : si decodingInfo() signale supported à false pour un codec à une résolution modeste, un isTypeSupported() qui renvoie true pour le même type demande une explication. Ensuite, une famille de codecs doit paraître cohérente pour la plateforme. Un rapport qui liste des codecs très récents réservés au matériel à côté de l'absence d'un codec de base comme H.264 est inhabituel pour un navigateur de bureau courant, et l'inhabituel est déjà informatif.

L'orthographe et l'ordre comptent aussi. Le paramètre codecs peut s'écrire de plusieurs façons, par exemple avec des codes de profil et de niveau différents pour la même famille de codecs, et un navigateur peut répondre différemment à chacune. Comparez les chaînes telles qu'une page les enverrait, et gardez fixe la liste testée d'une exécution à l'autre, afin qu'un changement de réponse reflète un changement du navigateur et non un changement de la question.

smooth et powerEfficient demandent une prudence supplémentaire. Ils décrivent la qualité de décodage et la consommation d'énergie attendues, et peuvent donc varier avec le matériel et avec l'historique de lecture du navigateur. Traitez-les comme une preuve plus faible que supported, et n'attendez pas que deux exécutions sur deux machines différentes concordent sur ces valeurs.

L'enchaînement compte en pratique. canPlayType() et isTypeSupported() répondent immédiatement, alors que decodingInfo() renvoie une promesse : un script doit donc attendre chaque résultat avant d'enregistrer quoi que ce soit. Exécutez tous les appels depuis un seul chemin de code, rassemblez les réponses dans un ordre fixe et comparez-les à une référence que vous avez produite vous-même sur la même machine. Une liste copiée depuis une page web ou depuis une autre machine décrit un autre environnement, et elle égarera un examen plus souvent qu'elle ne l'aidera.

Voici une lecture typique. Supposons que canPlayType() renvoie probably pour H.264 et AAC dans MP4, que isTypeSupported() renvoie true pour le même type et que decodingInfo() signale supported et smooth pour un flux 720p. Les trois concordent, et la machine gère clairement la vidéo web de base. Si decodingInfo() pour un flux AV1 en haute résolution signale supported mais pas powerEfficient, cela peut indiquer un décodage logiciel plutôt qu'une contradiction.

Vérifier un profil dans plusieurs contextes

Consignez navigator.mediaCapabilities dans la page, un Worker et une iframe de même origine ; gardez la liste codecs identique pour comparer les contextes.

Les API média ne sont pas disponibles seulement sur la page principale. On peut atteindre navigator.mediaCapabilities depuis des Workers, et les éléments média comme MediaSource peuvent servir dans des iframes. Une page peut donc poser la même question depuis plusieurs contextes, et une configuration du navigateur qui donne une réponse sur la page principale et une autre dans un Worker ou un cadre paraît incohérente, même si chaque réponse est plausible isolément.

Pour un examen de cohérence, cela signifie que la vérification doit s'exécuter à plus d'un endroit. Posez la même liste fixe de types depuis la page principale, depuis un Worker dédié lorsque l'API y est disponible et depuis une iframe de même origine, puis comparez les résultats ligne par ligne. Les différences signalent un problème de configuration. La concordance ne prouve pas que la configuration est bonne, mais la divergence est un signe clair que quelque chose cloche.

Si votre flux de travail intègre des lecteurs tiers, ajoutez aussi une iframe d'origine différente à la comparaison. Les lecteurs intégrés posent souvent ces questions de leur propre initiative, fréquemment au chargement, et la réponse qu'ils reçoivent décide donc du flux qu'ils demandent. Un cadre de test de même origine est plus facile à exécuter, mais il ne remplace pas une vérification dans le cadre que votre flux de travail utilise réellement.

1. Fixez une liste de chaînes de type qui correspond aux médias que votre flux de travail utilise réellement, avec des paramètres codecs explicites.
2. Exécutez les trois API sur la liste depuis la page principale et enregistrez chaque réponse.
3. Recommencez depuis un Worker dédié et depuis une iframe de même origine, là où l'API est disponible.
4. Comparez ligne par ligne, puis comparez le résultat avec ce que le profil chargé est censé décrire.
5. Lisez un court échantillon de chaque type important pour voir ce que la machine décode réellement.

Une divergence est un constat à expliquer, pas du bruit à ignorer. Les causes courantes sont une configuration modifiée dans un seul contexte, une liste qui mélange des chaînes avec des codes de profil et de niveau différents, et une réponse qui reflète les décodeurs réels de la machine au lieu du profil. Corrigez la cause, puis relancez toute la liste, car une reprise partielle peut masquer une nouvelle différence. Pour une méthode plus large de comparaison d'un navigateur entre plateformes, consultez l'évaluation de la cohérence du navigateur entre plateformes.

Un court relevé écrit rend le résultat reproductible. Notez le profil ou la configuration chargés, la version du navigateur, le système d'exploitation et le matériel graphique de la machine, la liste des types testés et les réponses par contexte. Ajoutez une ligne sur la lecture réelle : un échantillon de chaque type important a-t-il vraiment été lu sur la machine ? Les réponses de prise en charge décrivent ce que le navigateur signale, tandis que la lecture montre ce que la machine peut décoder, et ce sont deux faits distincts.

Quand les réponses se contredisent vraiment

Paire de réponses	Verdict	Pourquoi
canPlayType probably + isTypeSupported true	Compatibles	Deux chemins différents renvoient tous deux une réponse positive
canPlayType "" + isTypeSupported true	À expliquer	Un support MSE seul est possible mais inhabituel
decodingInfo supported: false + isTypeSupported true	Contradiction	Même codec, un chemin affirme que le décodage est indisponible
supported: true + smooth: false	Indice faible	Attente de qualité, pas une affirmation de support
powerEfficient: true sur un hôte et false sur un autre	Non comparable	Le champ suit le matériel et l'historique de lecture

Seule la troisième ligne est un défaut, et seulement lorsque decodingInfo est interrogé avec un type media-source ; avec un type file, les deux mêmes réponses relèvent de la deuxième ligne, car les API décrivent alors des chemins de livraison différents plutôt qu'une contradiction. La première est le cas normal et les deux dernières sont les signaux plus faibles décrits plus haut.

Notez le verdict à côté de la paire plutôt que les chaînes brutes, car un true et un false enregistrés ne disent pas à laquelle des cinq lignes ils appartiennent. Un tableau de verdicts est aussi ce qui rend deux hôtes comparables : les mêmes cinq lignes, le même verdict, et un diff qui montre quelle ligne a changé de catégorie.

Deux règles gardent la comparaison honnête. Comparez une chaîne de codec à elle-même, jamais à une voisine d'un autre profil ou niveau, car le navigateur peut répondre différemment à chacune. Et traitez smooth et powerEfficient comme des observations sur un hôte nommé, non comme des affirmations de portabilité, car les deux suivent le matériel et l'historique de lecture du navigateur lui-même.

Limites de confidentialité des requêtes média

Limitez les requêtes aux formats nécessaires et conservez le type MIME en échec avec la version du navigateur ; MediaCapabilities ne demande pas de stocker un inventaire complet.

Gardez aussi les signaux voisins en vue. Les réponses sur les codecs doivent concorder avec le système d'exploitation, les informations graphiques et les capacités DRM que le même navigateur déclare. Un rapport média qui correspond à la plateforme mais contredit une autre surface reste incohérent ; examinez-les donc ensemble plutôt qu'un par un.

Les équipes qui tiennent une liste de contrôle de publication peuvent y ajouter une seule ligne pour la prise en charge des médias. Notez la liste fixe de types, les réponses de chaque contexte et la date, puis relancez la liste après une mise à jour du navigateur ou un changement de profil. Un petit contrôle récurrent repère tôt une réponse qui dérive, et il produit un relevé qu'un collègue peut lire sans refaire l'enquête.

Choisir un mode pour les types média

Lorsqu'un profil est chargé, l'option --bot-media-types décide comment les types média du profil se combinent avec les décodeurs propres à la machine. Elle accepte trois valeurs documentées (documentation MIME et codec).

• expand est la valeur par défaut. Il privilégie les décodeurs locaux et complète la liste avec les types que définit le profil, si bien que le résultat mêle la capacité réelle de la machine à celle du profil.
• profile n'utilise que les types média que définit le profil. Il n'ajoute pas les décodeurs de la machine, ce qui convient à une vérification de cohérence qui compare les réponses avec le profil chargé.
• real utilise les types média réels du système. Il convient pour vérifier ce que la machine peut vraiment décoder, mais il peut ne pas correspondre à un profil qui décrit un autre matériel.

Choisissez le mode d'après la question que vous posez. Pour un examen de cohérence, commencez par profile et comparez les trois API entre les contextes. Passez à expand quand la lecture sur la machine compte plus qu'une correspondance stricte, et utilisez real pour savoir ce que la machine elle-même signale. Modifiez un réglage à la fois et gardez fixe la liste de types d'une exécution à l'autre.

Prenons un profil qui décrit un système de bureau et une machine à laquelle manque le décodeur d'un codec que le profil liste. En mode profile, les API signalent la liste du profil, ce qu'une vérification de cohérence veut voir, alors que la lecture réelle de ce codec sur cette machine échouerait encore. En mode real, les réponses suivent la machine et révéleraient le décodeur manquant. Aucun mode n'est faux. Ils répondent à des questions différentes, et le relevé de l'examen doit indiquer laquelle a été posée.

Le comportement des modes peut changer entre les versions : relisez donc la documentation avant de vous appuyer sur un détail de cette page, et relancez votre liste fixe après avoir mis à jour le navigateur ou le profil. Comparez le nouveau relevé au précédent. Une différence qui apparaît juste après une mise à jour est bien plus facile à expliquer que celle découverte des mois plus tard.

BotBrowser signale la prise en charge des types MIME et des codecs à travers le profil chargé et fournit --bot-media-types avec les modes expand (par défaut), profile et real, ce qui permet de vérifier la cohérence des résultats de canPlayType(), isTypeSupported() et MediaCapabilities sur la page principale, dans les Workers, les Service Workers et les iframes. Vous disposez ainsi d'une méthode documentée pour confirmer que les réponses média concordent avec un seul profil. BotBrowser ne peut pas ajouter les décodeurs qui manquent à la machine, ne garantit pas qu'un site donné juge acceptables les capacités média signalées et ne remplace pas la vérification de la lecture réelle dans le flux de travail visé.

Pour approfondir, consultez Widevine dans les navigateurs automatisés : pourquoi EME échoue.

Ce que cette page ajoute à la référence

La page de référence liste les modes média. La matrice ajoutée appelle canPlayType, isTypeSupported et decodingInfo avec les mêmes chaînes MIME, puis compare une page, un Worker et un élément média. Un écart invite à examiner le contexte ou le décodeur de l'hôte.

Sources publiques

• MDN: MediaCapabilities.decodingInfo()
• MDN: HTMLMediaElement.canPlayType()
• MDN: MediaSource.isTypeSupported()
• Documentation BotBrowser : fingerprinting des types MIME et codecs

Conclusion pratique

Partez de profile pour un contrôle de cohérence, passez à expand quand la lecture sur la machine compte davantage, et utilisez real pour voir ce que rapporte la machine elle-même. Changez un mode à la fois et gardez la liste de types fixe ; un désaccord entre contextes pointe vers le contexte ou le décodeur de l'hôte.