Capacidades WebCodecs y privacidad del navegador

WebCodecs ofrece a las aplicaciones web acceso de bajo nivel a la codificación y decodificación de audio y vídeo (definición del W3C). VideoFrame también acepta fuentes de imagen compatibles, por lo que fotogramas derivados de imágenes pueden entrar en un flujo de procesamiento de vídeo (VideoFrame del W3C); no es una API general de códecs para imágenes fijas. El soporte ayuda a elegir una ruta multimedia, pero no describe por completo un dispositivo ni debe tratarse como una identidad. Puede variar según el navegador, el sistema operativo, los códecs disponibles y el contexto de ejecución.

Qué expone WebCodecs

La API representa el trabajo multimedia mediante fragmentos codificados y configuraciones de códec. Una aplicación puede preguntar si una configuración es compatible antes de iniciar el procesamiento. La respuesta permite evitar una ruta que el navegador actual no puede realizar, pero no garantiza una velocidad o calidad concretas. Esta comprobación no garantiza que el procesamiento asíncrono posterior termine bien; sus errores se comunican mediante la función de error (comprobación de compatibilidad, modelo de procesamiento, función de error).

Este ámbito es distinto de una declaración de tipo de archivo o de la negociación de una llamada en tiempo real. La especificación del W3C indica que aquí los medios codificados no se empaquetan en un contenedor (cadena de códec); WebCodecs tampoco define el transporte de red, por lo que empaquetado y transmisión corresponden a capas separadas de la aplicación. Para esos temas, consulta MIME y soporte de códecs y comportamiento de códecs WebRTC.

Una consulta de soporte no equivale a que el procesamiento esté listo. La creación del objeto de códec todavía puede fallar por presión de recursos o por un cambio del contexto. El resultado corresponde a la configuración completa enviada, que puede incluir perfil, dimensiones, frecuencia de fotogramas, frecuencia de muestreo y otros parámetros; consulta solo la configuración de la tarea del usuario, no un inventario de combinaciones ajenas (soporte de configuración).

Como el procesamiento es asíncrono, gestiona colas, resultados, errores y recursos. La especificación expone el tamaño de las colas de codificación y decodificación y eventos dequeue; el trabajo puede acumularse mientras el códec está saturado (modelo de procesamiento). Limita el trabajo pendiente y aplica contrapresión: pausa la entrada cuando el siguiente paso no puede seguir el ritmo, en vez de descartar en silencio fotogramas que el usuario espera conservar. Cierra VideoFrame y AudioData cuando ya no se necesiten (recursos del sistema, VideoFrame.close()). Muestra si la tarea está esperando, procesándose, pausada o lista; una respuesta de soporte no describe una tarea en curso. Una vista previa puede usar una representación menor que una exportación con la calidad solicitada, pero la interfaz debe explicarlo. Al cancelar desde la aplicación, deja de aceptar entradas, libera recursos y conserva el original para elegir otra ruta.

El umbral de saturación depende de cada implementación y puede no tener límite. Cuando se satura, las solicitudes nuevas de codificación o decodificación se almacenan en búfer y aumentan el tamaño de la cola; no existe un recuento portable que prediga la velocidad ni garantice que otra implementación termine igual.

Un evento dequeue puede guiar nuevas entradas limitadas, pero no confirma que los callbacks de salida o el escritor del contenedor hayan terminado; sigue esas colas posteriores por separado. El códec puede retener salidas hasta recibir más entradas, mientras flush() requiere emitir las salidas pendientes; comprueba también los últimos fotogramas y fragmentos antes de finalizar.

El estado de la cola, los callbacks y el archivo son medidas distintas del flujo de trabajo, no propiedades del dispositivo. Una cola más corta no significa que la exportación terminó, y la hora de llegada del callback no sustituye a las marcas de tiempo del medio.

Las marcas timestamp y duration de VideoFrame se expresan en microsegundos; conserva la línea temporal en lugar de sustituirla por la hora de llegada del callback. Revisa también el color, el recorte, la rotación y el volteo al convertir o exportar.

VideoFrame y AudioData pueden mantener memoria de CPU o GPU y recursos exclusivos del códec. Cierra cada objeto cuando termine su consumidor y define quién lo conserva si pasa por un renderizador, una cola o un empaquetador. Al cancelar, cierra los fotogramas que aún no hayan llegado a un consumidor, pero no los que otra parte del flujo siga usando.

Por qué varía el soporte

WebCodecs es una interfaz, no una garantía de que todos los códecs estén disponibles en todas partes. El soporte depende de las funciones implementadas por cada versión del navegador y de los códecs que ofrecen el sistema operativo o la pila multimedia. La aceleración por hardware también puede influir, aunque una configuración compatible no implica que vaya a acelerarse.

Los estándares y las implementaciones cambian con el tiempo. No conviene generalizar el resultado de una versión o plataforma a todas las demás.

Las funciones cambian al evolucionar los estándares y los navegadores: una versión puede añadir una función, corregir una implementación o ajustar su integración con el sistema. El sistema operativo puede actualizar sus servicios multimedia por separado, y un administrador puede restringir funciones en un equipo gestionado. Registra versión del navegador, familia del sistema, versión de la aplicación y requisito multimedia para que el informe sirva sin inferir detalles de hardware. Versiones con el mismo número no necesariamente ofrecen el mismo entorno multimedia: algunas distribuciones dependen de bibliotecas o códecs del sistema y siguen su calendario. Dos equipos pueden responder igual a una consulta y tener rendimientos distintos; el soporte indica compatibilidad, no es un benchmark.

Cuando importe la aceleración, mide la tarea real en sistemas representativos y mantén ese resultado separado de afirmaciones de privacidad o identidad. Una actualización del navegador puede cambiar la disponibilidad sin modificar el estándar; vuelve a comprobarla cuando la aplicación tenga que elegir una ruta y no trates una respuesta antigua como metadato permanente del dispositivo. Una estación de trabajo gestionada puede restringir una función por política y una instalación personal puede exponerla; ambos resultados pueden ser válidos dentro de sus respectivos rangos de soporte. No generalices una observación como regla de toda una plataforma. Si interviene un servicio multimedia del sistema, una actualización del sistema puede cambiar la ruta disponible sin cambios visibles en la aplicación.

Una nota de versión debe indicar qué tarea se volvió a probar y qué alternativa sigue disponible, no prometer un nivel de calidad en todas las máquinas. La tabla de compatibilidad resulta más útil si dice qué se probó, qué se observó y qué puede hacer después el usuario. Registra también si la prueba usó un archivo importado, una fuente en directo o una muestra generada: cada entrada tiene permisos y tratamiento de datos distintos. Una muestra breve no cubre necesariamente una exportación larga, frecuencia de fotogramas variable, varias pistas de audio o una descarga interrumpida. Documenta estos límites sin exponer detalles internos de implementación.

Si una tarea no está admitida, ofrece antes de que el usuario invierta tiempo o datos otro formato, una alternativa local o una carga explícita al servicio. Prueba el primer uso: seleccionar el archivo, conceder un permiso necesario, elegir la salida y esperar a que termine. Un fallo en cualquier paso debe conservar la fuente y explicar cómo continuar sin volver a pedir un permiso no relacionado. En flujos recurrentes, se puede recordar la preferencia de formato sin guardar todo el registro de capacidades. La preferencia debe ser fácil de cambiar si una actualización altera la ruta disponible; una elección del usuario no equivale a una observación del navegador.

Límites de privacidad y compatibilidad

El W3C indica que un perfil de capacidades de códecs tiene muy pocas probabilidades de identificar de forma única por sí solo, pero puede combinarse con otros indicadores para crear una huella (consideraciones de privacidad). No conviertas esa afirmación matizada en una garantía de que una respuesta no pueda contribuir a identificar a alguien o su dispositivo. El riesgo aumenta si la aplicación conserva observaciones innecesarias o las combina con otros datos. Consulta solo las configuraciones necesarias y evita guardar resultados detallados cuando basta con decidir cómo reproducir el contenido.

WebCodecs tampoco concede acceso irrestricto a contenido multimedia. El diseño debe separar la selección de una ruta compatible del acceso a medios del usuario y de los permisos que exijan otras API del navegador. El procesamiento local no demuestra que la aplicación no suba medios o telemetría; es una cuestión del flujo de datos de la aplicación, no una garantía de WebCodecs. Si el procesamiento falla o se cancela, conserve el medio original y ofrezca una recuperación; antes de cambiar a una carga remota, explique el recorrido de los datos y solicite una elección explícita.

WebCodecs no proporciona por sí solo cámara, micrófono ni archivos: esos medios de entrada tienen permisos y expectativas propios. Solicita una entrada solo cuando haga falta, explícalo en contexto y distingue archivos importados de captura en directo. Ajusta las comprobaciones de compatibilidad a la tarea: un editor de audio puede necesitar decodificar una importación y codificar una exportación, pero no consultar ajustes de vídeo ajenos. Las consultas acotadas reducen complejidad y mantienen la recopilación alineada con la función. Separa también la selección de capacidades de la identidad de cuenta, para que una decisión multimedia no se convierta en un campo oculto del perfil.

Si la telemetría ayuda al soporte, prefiere un resultado agregado, completado, no disponible o alternativa utilizada, y explica el motivo y plazo de conservación. No retengas objetos de configuración completos cuando un estado pequeño baste. El medio fuente puede contener voces, rostros, ubicaciones o documentos privados y necesita reglas independientes de acceso y eliminación. Una vista previa local no debe llamarse privada si después se carga el original para exportarlo; una conversión remota debe revelar el límite del servicio antes de empezar la carga. Explica esas diferencias para que el usuario pueda decidir y soporte pueda aclarar qué hizo el navegador.

Revisar una versión

Compara la misma aplicación y tarea multimedia en las versiones de navegador admitidas. Registra si el flujo del usuario termina, usa una alternativa o cambia tras una actualización. Empieza por requisitos visibles, entrada, salida esperada, alternativa compatible y medios representativos, prueba hasta gestionar la salida y separa la aceptación funcional de fidelidad visual, sincronización, latencia, memoria y tamaño del archivo. Para reproducir una diferencia, conserva una reproducción mínima con revisión de la aplicación, compilación del navegador, versión del sistema, tipo de entrada, configuración solicitada y resultado observado, sin recoger detalles ambientales ajenos. La revisión de versiones del navegador trata navegador y configuración probada como una unidad de versión.

Organiza las pruebas por tarea, no por cada combinación de códecs: abrir una grabación, recortar un clip, exportarlo y reproducirlo. Anota contenedor y pistas de entrada, salida esperada y punto de cancelación. Prefiere muestras sintéticas; una muestra larga puede mostrar crecimiento de cola, huecos de tiempo y presión de memoria sin medios personales. Prueba la selección de archivos por separado de los permisos de cámara o micrófono y verifica que denegar la captura en directo deje disponible la importación. Una navegación, suspensión o dispositivo inactivo no debe mostrar un éxito falso. Registra si una exportación interrumpida elimina el archivo parcial, permite recuperarlo o nunca lo expone. Un reintento debe usar una entrada conocida y no cambiar en silencio una operación local elegida por el usuario por un servicio remoto.

Inspecciona metadatos del contenedor, orden y duración de las pistas, orden de fotogramas, rotación, subtítulos e interpretación del color; en audio, escucha inicios cortados, canales ausentes y desfase al buscar. Prueba por separado configuraciones no admitidas, entrada malformada, fallos de recursos, cancelación y salida incompleta. Comprueba continuidad temporal al buscar y verifica que los fotogramas descartados intencionadamente en una vista previa no falten en la exportación de archivo. Estos controles determinan si funciona la tarea sin crear un inventario amplio de capacidades.

Los métodos del códec no son sinónimos de cancelar una tarea de la aplicación. flush() completa los mensajes de control en cola y emite las salidas pendientes, pero no empaqueta un contenedor ni demuestra que la escritura del archivo haya terminado (AudioEncoder.flush()). Espera la promesa, procesa las devoluciones de salida y termina el empaquetado y almacenamiento antes de indicar que la exportación está lista. reset() restablece el estado, la configuración, los mensajes en cola y las devoluciones pendientes; hay que configurar el objeto otra vez (AudioEncoder.reset()). close() aborta el trabajo pendiente, libera recursos del sistema y es definitivo (AudioEncoder.close()). La cancelación es una decisión de la aplicación: deja de aceptar entradas, usa reset o close según el ciclo de vida, conserva el original y comunica cancelación o salida incompleta, nunca éxito. Una vista previa en directo puede omitir fotogramas atrasados, mientras una exportación de archivo puede tener que conservarlos todos; declara esa política. Antes de iniciar una tarea multimedia, comprueba si esta versión del navegador está admitida y qué alternativa hay si la configuración del códec no funciona. Una conversión local y una remota tienen recorridos de datos distintos; explica cualquier carga antes de enviar contenido. Retira una ruta antigua solo cuando la sustituta haya superado las mismas pruebas de tarea y la política lo permita. Para soporte, registra navegador, sistema, versión de la aplicación, tarea y resultado visible; usa muestras sintéticas y no conserves los medios ni resultados detallados más allá del propósito documentado. Una tarea solo está lista cuando la salida y el estado de la aplicación coinciden: el códec puede haber terminado sin que el resultado esté completo, sincronizado o empaquetado. Tras VideoDecoder.flush(), la siguiente entrada debe ser un fragmento clave; tenlo en cuenta al reanudar tras una búsqueda o reinicio (VideoDecoder.flush()).

reset() o close() no pueden deshacer los bytes del archivo que la aplicación ya haya escrito.

Mapa de afirmaciones y fuentes

• El soporte se define para la configuración de códec enviada en soporte de configuración, no para un inventario general del dispositivo.
• Los fragmentos codificados no están encapsulados y las colas y salidas siguen la cadena de códec y el modelo de procesamiento.
• Los metadatos de VideoFrame y la propiedad de recursos siguen VideoFrame y recursos del sistema.
• El límite cualificado de huella está en las consideraciones de privacidad; las cargas y la telemetría de la aplicación son decisiones de flujo de datos separadas.
• Las afirmaciones sobre flush(), reset() y close() se basan en los métodos del codificador y el flush del decodificador.

Fuentes públicas

• WebCodecs del W3C: soporte de configuración
• WebCodecs del W3C: cadena de códec y medios sin contenedor
• WebCodecs del W3C: modelo de procesamiento y colas
• WebCodecs del W3C: salida pendiente del códec
• WebCodecs del W3C: privacidad
• WebCodecs del W3C: VideoFrame y recursos del sistema
• WebCodecs del W3C: flush, reset y close
• WebCodecs del W3C: flush del decodificador y fragmentos clave
• MDN: API WebCodecs