Fingerprinting MIME y códecs: señales de soporte multimedia

canPlayType(), isTypeSupported() y decodingInfo() responden de forma distinta ante las mismas cadenas MIME y de códecs. BotBrowser puede alinear esas respuestas con el perfil mediante un modo de tipos multimedia; no puede añadir un decodificador que el equipo anfitrión no tenga.

Ver el vídeo

Este vídeo en inglés investiga un síntoma: la misma cadena MIME puede recibir respuestas distintas en dos máquinas. Revisa cuatro sospechosos por orden: las tres API que responden (canPlayType(), MediaSource.isTypeSupported() y MediaCapabilities.decodingInfo()), la propia cadena MIME, el host subyacente y el contexto que pregunta. Una página de laboratorio local declara una lista fija de tipos de medio y consulta cada API en la página principal, en un Worker dedicado y en un iframe del mismo origen; las respuestas se leen en la consola de DevTools de un navegador en un runner Ubuntu y en uno Windows. Después cita el artículo y la documentación de BotBrowser sobre el indicador --bot-media-types y sus tres modos (expand, profile, real). En las grabaciones no se carga ningún perfil de BotBrowser, así que los modos se citan, no se ejecutan. El audio está en inglés.

Resumen rápido

Las tres API responden a la misma pregunta con distinto detalle, y decodingInfo() añade los indicadores supported, smooth y powerEfficient. Fija una lista de tipos con parámetros codecs explícitos y compárala entre una página, un Worker y un elemento multimedia.

Contenido de esta guía

• Ver el vídeo
• Qué informan las tres API multimedia
• Por qué las respuestas cambian entre equipos
• Cómo leer las respuestas lado a lado
• Comprobar un perfil en distintos contextos
• Límites de privacidad de las consultas multimedia
• Cómo elegir un modo de tipos multimedia

Qué informan las tres API multimedia

HTMLMediaElement.canPlayType(type) recibe una cadena de tipo MIME, opcionalmente con un parámetro codecs, y devuelve una cadena vacía, maybe o probably (MDN canPlayType). Una cadena vacía significa que el navegador no puede reproducir ese tipo. probably indica que está seguro, y maybe que no puede saberlo sin intentarlo. La respuesta de tres valores es deliberadamente tosca, así que dice poco sobre calidad o rendimiento.

MediaSource.isTypeSupported(type) es un método estático que devuelve un booleano para un tipo MIME con una lista opcional de códecs (MDN isTypeSupported). Indica a un reproductor si el navegador probablemente aceptará ese tipo para la transmisión mediante Media Source Extensions. Un resultado true es una predicción de soporte, no una prueba de que un flujo concreto vaya a reproducirse.

MediaCapabilities.decodingInfo(configuration) es la más detallada de las tres (MDN decodingInfo). La configuración describe un flujo e incluye un tipo de contenido y, en vídeo, las dimensiones, la tasa de bits y la tasa de fotogramas. La promesa devuelta se resuelve con los indicadores supported, smooth y powerEfficient. Los dos últimos describen qué tan bien se espera que vaya la decodificación, por lo que dependen más del hardware y del historial propio del navegador que las respuestas simples de soporte.

Las tres parten de una cadena de tipo MIME. Un tipo de contenedor sin más, como video/mp4, dice poco, porque un mismo contenedor puede llevar muchos códecs. El parámetro opcional codecs nombra los códecs reales, por ejemplo avc1.42E01E para vídeo H.264, mp4a.40.2 para audio AAC, vp09.00.10.08 para vídeo VP9 u opus para audio Opus. Las cadenas de códec son compactas a propósito y codifican un perfil y un nivel, así que dos cadenas de la misma familia de códecs pueden recibir respuestas distintas.

El campo type de una configuración de decodingInfo() también importa. file describe la reproducción simple de un recurso, mientras que media-source describe la transmisión mediante Media Source Extensions, y ambos caminos no tienen por qué coincidir. Preguntar con el tipo que corresponde al funcionamiento real de tu reproductor mantiene la respuesta relevante para la tarea y hace que la pregunta sea la misma cada vez.

Las llamadas siguientes muestran las tres formas una junto a otra.

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 },
});

El mismo código puede mostrar respuestas distintas en dos ordenadores, o en uno solo tras una actualización del navegador. La cadena MIME es solo una pregunta. La respuesta sale de los decodificadores y las políticas que tiene disponibles el navegador que la recibe.

El contenido cifrado añade otra capa. decodingInfo() también puede consultar un sistema de claves, algo que pertenece al DRM y no al soporte simple de códecs. Fingerprinting de DRM trata ese límite, y las capacidades de WebCodecs tratan la interfaz de códecs de más bajo nivel, que tiene sus propias consultas de soporte.

Por qué las respuestas cambian entre equipos

Compara canPlayType() y MediaSource.isTypeSupported() con la misma cadena MIME; el navegador, el sistema operativo, la GPU y la política administrada pueden cambiar cada respuesta.

Una respuesta multimedia es el resultado de varias capas, y cada capa puede cambiar de forma independiente. La compilación del navegador decide qué códecs están incluidos o licenciados, y algunas compilaciones abiertas se distribuyen sin códecs propietarios. El sistema operativo decide qué decodificadores son accesibles mediante sus servicios multimedia. El hardware gráfico decide qué códecs pueden decodificarse por hardware. Las políticas y los ajustes pueden desactivar funciones en un equipo administrado.

• Versión del navegador: con el tiempo llegan códecs y funciones de contenedor nuevos, y una ruta de código puede perder el soporte de uno antiguo.
• Sistema operativo: un decodificador instalado en un sistema puede faltar en otro, incluso con la misma versión del navegador.
• Hardware: el hardware gráfico más reciente puede decodificar códecs que un dispositivo más antiguo resuelve por software o no resuelve en absoluto.
• Configuración: las políticas de empresa, los ajustes del usuario y las opciones de línea de comandos pueden cambiar lo que informa el navegador.

Los ejemplos concretan el patrón. El vídeo H.264 y el audio AAC están ampliamente disponibles en los navegadores de escritorio habituales, y VP9 y Opus también son comunes. HEVC suele depender de un decodificador que ofrece el sistema operativo o el hardware gráfico, y AV1 depende de un decodificador por software en el navegador o de hardware más reciente. Son tendencias, no reglas.

El entorno donde pruebas también cambia el panorama. Una máquina virtual o una sesión de escritorio remoto suele carecer de decodificación por hardware, así que los resultados de powerEfficient y las respuestas en alta resolución pueden diferir mucho de los de un escritorio físico con el mismo sistema operativo. Al comparar dos equipos, anota si cada uno es físico o virtual, porque ese único dato explica muchas diferencias que al principio parecen misteriosas.

Esta variación es la razón por la que las respuestas son útiles para la compatibilidad y, a la vez, la razón por la que transmiten información sobre el equipo. Un sitio que consulta una docena de cadenas de códec recibe un patrón, y ese patrón tiende a agruparse por familia de sistema operativo y generación de hardware. Esa es toda la razón por la que las consultas multimedia aparecen en los debates sobre privacidad.

Conviene ser preciso sobre el peso de ese patrón. Un vector de soporte multimedia es una señal entre muchas. No identifica a una persona, ningún resultado aislado decide nada y muchas personas distintas comparten el mismo patrón. Su efecto práctico es reducir el conjunto de dispositivos que podría describir un conjunto combinado de señales, y por eso debe coincidir con las demás señales que informa el navegador.

La respuesta también puede cambiar en el mismo equipo. Una actualización del navegador puede añadir una ruta de decodificación, una actualización del controlador puede activar la decodificación por hardware y un cambio de política puede desactivar una función. Por eso una respuesta registrada es una observación fechada de una configuración concreta, y conviene volver a comprobarla tras las actualizaciones en lugar de tratarla como una propiedad permanente.

Cómo leer las respuestas lado a lado

Las tres interfaces están relacionadas pero no son intercambiables, y una revisión útil las compara con las mismas cadenas de códec. Cada una tiene una función distinta.

• canPlayType() responde para la reproducción simple en un elemento multimedia y devuelve una cadena de tres estados.
• isTypeSupported() responde para la transmisión mediante Media Source Extensions y devuelve un booleano.
• decodingInfo() responde para un flujo descrito y añade smooth y powerEfficient.

De ahí salen dos expectativas de coherencia. Primera, las respuestas deben coincidir en el sentido: si decodingInfo() informa supported como false para un códec a una resolución modesta, que isTypeSupported() devuelva true para el mismo tipo necesita una explicación. Segunda, una familia de códecs debe verse coherente para la plataforma. Un informe que lista códecs recientes que solo existen por hardware junto a la ausencia de un códec básico como H.264 resulta extraño en un navegador de escritorio habitual, y lo extraño ya es informativo.

La escritura y el orden también importan. El parámetro codecs puede escribirse de varias formas, por ejemplo con códigos de perfil y nivel distintos para la misma familia de códecs, y un navegador puede responder de forma diferente a cada una. Compara las cadenas tal como las enviaría una página y mantén fija la lista que pruebas entre ejecuciones, de modo que un cambio en la respuesta refleje un cambio en el navegador y no un cambio en la pregunta.

smooth y powerEfficient merecen un cuidado extra. Describen la calidad de decodificación y el consumo de energía esperados, por lo que pueden variar con el hardware y con el historial de reproducción del navegador. Trátalos como una evidencia más débil que supported y no esperes que dos ejecuciones en dos equipos distintos coincidan en ellos.

El orden de ejecución importa en la práctica. canPlayType() y isTypeSupported() responden al instante, mientras que decodingInfo() devuelve una promesa, así que un script debe esperar cada resultado antes de registrar nada. Ejecuta todas las llamadas desde un único flujo de código, reúne las respuestas en un orden fijo y compara con una referencia que hayas producido tú mismo en el mismo equipo. Una lista copiada de una página web o de otra máquina describe un entorno distinto, y confundirá una revisión más a menudo de lo que la ayudará.

Esta es una lectura típica. Supón que canPlayType() devuelve probably para H.264 y AAC en MP4, que isTypeSupported() devuelve true para el mismo tipo y que decodingInfo() informa supported y smooth para un flujo de 720p. Los tres coinciden, y el equipo maneja con claridad el vídeo web básico. Si decodingInfo() para un flujo AV1 de alta resolución informa supported pero no powerEfficient, eso puede indicar decodificación por software y no una contradicción.

Comprobar un perfil en distintos contextos

Registra navigator.mediaCapabilities en la página, un Worker y un iframe del mismo origen; conserva la lista codecs idéntica para poder comparar contextos.

Las API multimedia no están disponibles solo en la página principal. A navigator.mediaCapabilities se puede acceder desde Workers, y los elementos multimedia y MediaSource se pueden usar dentro de iframes. Por eso una página puede hacer la misma pregunta desde varios contextos, y una configuración del navegador que da una respuesta en la página principal y otra en un Worker o en un marco parece incoherente aunque cada respuesta sea plausible por separado.

Para una revisión de coherencia, esto significa que la comprobación debe ejecutarse en más de un lugar. Haz la misma lista fija de tipos desde la página principal, desde un Worker dedicado cuando la API esté disponible y desde un iframe del mismo origen, y luego compara los resultados línea por línea. Las diferencias señalan un problema de configuración. La coincidencia no demuestra que la configuración sea buena, pero la discrepancia es una señal clara de que algo falla.

Si tu flujo de trabajo incrusta reproductores de terceros, incluye también un iframe de origen cruzado en la comparación. Los reproductores incrustados suelen hacer estas preguntas por su cuenta, a menudo al cargar, así que la respuesta que reciben es la que decide qué flujo piden. Un marco de prueba del mismo origen es más fácil de ejecutar, pero no sustituye la comprobación en el marco que tu flujo de trabajo usa de verdad.

1. Fija una lista de cadenas de tipo que corresponda al contenido multimedia que usa tu flujo de trabajo, con parámetros codecs explícitos.
2. Ejecuta las tres API sobre la lista en la página principal y registra cada respuesta.
3. Repite desde un Worker dedicado y desde un iframe del mismo origen, donde la API esté disponible.
4. Compara línea por línea y después compara el resultado con lo que el perfil cargado debe describir.
5. Reproduce una muestra corta de cada tipo importante para ver qué decodifica realmente el equipo.

Una discrepancia es un hallazgo que hay que explicar, no ruido que se pueda ignorar. Las causas habituales son una configuración cambiada solo en un contexto, una lista que mezcla cadenas con distintos códigos de perfil y nivel, y una respuesta que refleja los decodificadores reales del equipo en lugar del perfil. Corrige la causa y vuelve a ejecutar la lista completa, porque una repetición parcial puede ocultar una diferencia nueva. Para un método más amplio de comparar un navegador entre plataformas, consulta cómo evaluar la coherencia del navegador entre plataformas.

Un registro escrito breve hace que el resultado sea repetible. Anota el perfil o la configuración cargados, la versión del navegador, el sistema operativo y el hardware gráfico del equipo, la lista de tipos probados y las respuestas por contexto. Añade una línea sobre la reproducción real: si una muestra de cada tipo importante se reprodujo de verdad en el equipo. Las respuestas de soporte describen lo que informa el navegador, mientras que la reproducción muestra lo que el equipo puede decodificar, y ambos son hechos distintos.

Cuándo las respuestas se contradicen de verdad

Par de respuestas	Veredicto	Por qué
canPlayType probably + isTypeSupported true	Compatibles	Dos rutas distintas devuelven ambas una respuesta positiva
canPlayType "" + isTypeSupported true	Explicar	El soporte solo por MSE es posible pero poco habitual
decodingInfo supported: false + isTypeSupported true	Contradicción	Mismo códec, una ruta afirma que la decodificación no está disponible
supported: true + smooth: false	Evidencia blanda	Expectativa de calidad, no una afirmación de soporte
powerEfficient: true en un host y false en otro	No comparable	El campo sigue al hardware y al historial de reproducción

Solo la tercera fila es un defecto, y solo cuando decodingInfo se consulta con un tipo media-source; con un tipo file las mismas dos respuestas pertenecen a la segunda fila, porque entonces las API describen rutas de entrega distintas en lugar de contradecirse. La primera es el caso normal y las dos últimas son las señales más blandas que describen los párrafos anteriores.

Anota el veredicto junto al par y no las cadenas en bruto, porque un true y un false registrados no dicen a cuál de las cinco filas pertenecen. Una tabla de veredictos también es lo que hace comparables dos hosts: las mismas cinco filas, el mismo veredicto y un diff que muestra qué fila cambió de categoría.

Dos reglas mantienen honesta la comparación. Compara una cadena de códec consigo misma, nunca con una hermana de otro perfil o nivel, porque el navegador puede responder distinto a cada una. Y trata smooth y powerEfficient como observaciones de un host nombrado y no como afirmaciones de portabilidad, porque ambos siguen al hardware y al historial de reproducción del propio navegador.

Límites de privacidad de las consultas multimedia

Limita las consultas a los tipos que la página necesita y guarda el MIME que falla junto con la versión del navegador; MediaCapabilities no requiere conservar un inventario completo.

Mantén también a la vista las señales relacionadas. Las respuestas de códecs deben coincidir con el sistema operativo, con la información gráfica y con las capacidades de DRM que informa el mismo navegador. Un informe multimedia que encaja con la plataforma pero contradice otra superficie sigue siendo incoherente, así que revísalos juntos y no uno por uno.

Los equipos que mantienen una lista de comprobación de versiones pueden añadir una sola línea para el soporte multimedia. Anota la lista fija de tipos, las respuestas de cada contexto y la fecha, y vuelve a ejecutar la lista tras una actualización del navegador o un cambio de perfil. Una pequeña comprobación periódica detecta pronto una respuesta que se desvía y genera un registro que un compañero puede leer sin repetir la investigación.

Cómo elegir un modo de tipos multimedia

Cuando hay un perfil cargado, la opción --bot-media-types decide cómo se relacionan los tipos multimedia del perfil con los decodificadores propios del equipo. Acepta tres valores documentados (documentación de MIME y códecs).

• expand es el valor predeterminado. Da prioridad a los decodificadores locales y amplía la lista con los tipos que define el perfil, así que el resultado mezcla la capacidad real del equipo con la del perfil.
• profile usa solo los tipos multimedia que define el perfil. No mezcla decodificadores del equipo, por lo que encaja con una comprobación de coherencia que compara las respuestas con el perfil cargado.
• real usa los tipos multimedia reales del sistema. Encaja para comprobar qué puede decodificar de verdad el equipo, pero puede no coincidir con un perfil que describe otro hardware.

Elige el modo según la pregunta que te haces. Para una revisión de coherencia, empieza con profile y compara las tres API entre contextos. Pasa a expand cuando la reproducción en el equipo importe más que una coincidencia estricta, y usa real para saber qué informa el propio equipo. Cambia un ajuste cada vez y mantén fija la lista de tipos entre ejecuciones.

Imagina un perfil que describe un sistema de escritorio y un equipo al que le falta el decodificador de un códec que el perfil lista. En modo profile, las API informan de la lista del perfil, que es lo que una comprobación de coherencia quiere ver, mientras que la reproducción real de ese códec en este equipo seguiría fallando. En modo real, las respuestas siguen al equipo y dejarían ver el decodificador ausente. Ningún modo es incorrecto. Responden a preguntas distintas, y el registro de la revisión debe indicar cuál se planteó.

El comportamiento de los modos puede cambiar entre versiones, así que relee la documentación antes de apoyarte en un detalle de esta página y vuelve a ejecutar tu lista fija después de actualizar el navegador o el perfil. Compara el registro nuevo con el anterior. Una diferencia que aparece justo después de una actualización es mucho más fácil de explicar que una descubierta meses después.

BotBrowser informa del soporte de tipos MIME y códecs a través del perfil cargado y proporciona --bot-media-types con los modos expand (el predeterminado), profile y real, de modo que los resultados de canPlayType(), isTypeSupported() y MediaCapabilities se pueden comprobar para verificar su coherencia en la página principal, los Workers, los Service Workers y los iframes. Eso te da una forma documentada de confirmar que las respuestas multimedia coinciden con un solo perfil. BotBrowser no puede añadir decodificadores que el equipo no tiene, no garantiza que un sitio concreto considere aceptables las capacidades multimedia informadas y no sustituye la comprobación de la reproducción real en el flujo de trabajo de destino.

Para más contexto, consulta Widevine en navegadores automatizados: por qué falla EME.

Qué añade frente a la página de referencia

La página de referencia enumera los modos multimedia. La matriz añadida llama a canPlayType, isTypeSupported y decodingInfo con las mismas cadenas MIME y compara una página, un Worker y un elemento multimedia. Un desacuerdo orienta la investigación del contexto o del decodificador del host.

Fuentes públicas

• MDN: MediaCapabilities.decodingInfo()
• MDN: HTMLMediaElement.canPlayType()
• MDN: MediaSource.isTypeSupported()
• Documentación de BotBrowser: fingerprinting de tipos MIME y códecs

Conclusión práctica

Empieza con profile para una revisión de coherencia, pasa a expand cuando importe más la reproducción en el equipo y usa real para ver qué informa el propio equipo. Cambia un modo cada vez y mantén fija la lista de tipos; un desacuerdo entre contextos apunta al contexto o al decodificador del host.