La API WebCodecs: control de códecs a bajo nivel en el navegador

WebCodecs es una API de JavaScript del navegador que da a los desarrolladores acceso directo a los códecs de vídeo y audio integrados en el propio navegador, mediante objetos VideoEncoder, VideoDecoder, AudioEncoder y AudioDecoder en crudo, sin pasar por toda la pila de WebRTC ni por el elemento <video>. Existe porque cada vez más desarrolladores necesitan un control a nivel de fotograma que WebRTC abstrae a propósito: transporte a medida, procesamiento por fotograma, aprendizaje automático sobre píxeles en crudo, nada de lo cual encaja bien dentro de una API diseñada para simplificar las llamadas entre pares. Este artículo mira qué es de verdad la API WebCodecs, qué te da, cómo se relaciona con WebRTC y cuándo merece la pena de verdad recurrir a ella.

Índice de contenidos

1. El problema que resuelve WebCodecs
   
2. Los bloques de construcción
   
3. WebCodecs frente a WebRTC
   
4. Qué construirías de verdad con ella
   
5. Compatibilidad con navegadores y salvedades del mundo real
   
6. ¿Necesitas WebCodecs o una plataforma que lo resuelva por ti?
7. Conclusión
8. Preguntas frecuentes

El problema que resuelve WebCodecs

WebRTC y el elemento <video> son, por diseño, todo en uno. WebRTC agrupa captura, codificación, transporte, buffer de jitter y renderizado en una sola canalización, y deja a propósito la capa de códec fuera de alcance: configuras preferencias, pero nunca tocas un fotograma codificado en crudo. Eso es justo lo correcto para una videollamada estándar: nadie que construya un producto de reuniones quiere programarse a mano el control de congestión. Pero se convierte en una limitación en cuanto necesitas algo que WebRTC no fue pensado para exponer, como meter fotogramas en un modelo de aprendizaje automático antes de enviarlos, empaquetar la salida codificada en tu propio formato de archivo o enviar los medios por un transporte que WebRTC no usa.

WebCodecs resuelve esto exponiendo los pasos de codificación y decodificación por su cuenta, separados de la captura y el transporte. Obtienes acceso al códec en crudo, y tú te encargas de construir la canalización a su alrededor, que es justo el trato que busca hacer el desarrollador que recurre a esta API.

Los bloques de construcción

La superficie de la API es más pequeña de lo que parece. Dos familias de objetos hacen el trabajo:

• Unidades de medios en crudo. VideoFrame y AudioData contienen medios sin comprimir. Un VideoFrame lleva los datos de píxel más metadatos como la marca de tiempo y la duración, ligados a la memoria de respaldo que el navegador esté usando en ese momento.
• Codificadores y decodificadores. VideoEncoder y VideoDecoder hacen el trabajo real de códec. Un VideoEncoder toma objetos VideoFrame y los convierte en instancias EncodedVideoChunk (los bytes comprimidos más algo de metadatos, en particular si un fragmento es un keyframe o un fotograma delta). Un VideoDecoder hace lo contrario: convierte objetos EncodedVideoChunk de nuevo en objetos VideoFrame. AudioEncoder y AudioDecoder reflejan esto para el audio, trabajando con AudioData y EncodedAudioChunk.

Una canalización mínima tiene este aspecto:

1. Captura o genera un VideoFrame.
2. Pásalo a un VideoEncoder configurado.
3. Recibe de vuelta un EncodedVideoChunk en una función de retorno (callback).
4. Envía ese fragmento adonde lo necesites, por ejemplo por WebTransport, un WebSocket o un canal de datos, o dirígelo a una biblioteca de empaquetado (muxing) para un archivo.
5. En el lado receptor, mete cada fragmento en un VideoDecoder, que te devuelve objetos VideoFrame.

Lo que hagas con esos fotogramas a partir de ahí depende de ti: píntalos en un canvas, súbelos a WebGPU o WebGL como textura para efectos en la GPU, lee sus píxeles en crudo para un modelo de aprendizaje automático o mételos en un MediaStreamTrackGenerator para volver a convertirlos en un flujo de vídeo normal. Todo funciona de forma asíncrona y conviene ejecutarlo fuera del hilo principal, en un web worker, ya que las funciones de retorno de codificación y decodificación pueden dispararse muchas veces por segundo y, si no, dejarían la página lenta.

Nada de esto es libre, eso sí. Tanto los codificadores como los decodificadores tienen que configurarse con una cadena de códec concreta antes de aceptar nada, y esa cadena tiene que nombrar no solo la familia de códec, sino también el perfil y el nivel (para códecs distintos de VP8), ya que el decodificador por hardware de un navegador a menudo solo admite una banda estrecha de configuraciones. Equivocarse aquí no bloquea la página; el codificador o el decodificador simplemente informan de que no pueden admitir la configuración pedida, por lo que la mayoría de las implementaciones reales comprueban el soporte antes de comprometerse con un códec en vez de descubrir el fallo a mitad de flujo.

WebCodecs frente a WebRTC: cómo se relacionan (no compiten)

La confusión más común es tratar esto como un sustituto directo de WebRTC. No lo es. WebRTC sigue siendo el dueño de las conexiones entre pares en tiempo real, de la travesía de NAT vía ICE, del control de congestión y de toda la negociación de oferta/respuesta SDP, y WebCodecs no intenta replicar nada de eso. WebCodecs es solo la capa de códec, ahora accesible de forma directa en vez de encerrada dentro de la canalización de WebRTC. Si necesitas llamadas entre pares con valores por defecto sensatos, WebRTC sigue siendo la herramienta; WebCodecs es lo que usas cuando quieres construir algo que la caja negra de WebRTC no ofrece, y estás dispuesto a aportar tú la lógica de transporte y de recuperación de errores.

Ese es justo el hueco que llena el patrón emergente de WebCodecs más WebTransport. WebTransport da al navegador una primitiva de transporte basada en QUIC y HTTP/3 sin nada de la sobrecarga de negociación de WebRTC, aunque es un transporte cliente-servidor (del navegador al servidor, no entre pares), así que complementa a WebRTC en vez de sustituirlo del todo. Emparejarlo con WebCodecs produce una alternativa más desagregada a WebRTC para ciertos escenarios de streaming de baja latencia: es la pila del lado del navegador sobre la que se construyen protocolos más nuevos como Media over QUIC. Hemos cubierto WebRTC y Media over QUIC en detalle en otros artículos, así que no volveremos sobre ese terreno aquí, más allá de señalar cómo encajan las piezas.

Qué construirías de verdad con ella

En la práctica, WebCodecs suele aparecer en un conjunto bastante concreto de proyectos:

• Streaming en directo de baja latencia con un transporte a medida. Este es el caso estrella: emparejar WebCodecs con WebTransport te permite construir una canalización de entrega ajustada a tus propios compromisos de latencia y calidad en vez de aceptar los valores por defecto de WebRTC.
• Procesamiento a nivel de fotograma, como la eliminación de fondo o el análisis de visión por computador que necesita inspeccionar o modificar los píxeles en crudo antes de codificarlos. Si ese procesamiento ocurre dentro de una llamada WebRTC en directo, la propia API de Insertable Streams de WebRTC a menudo puede hacerlo sin necesitar WebCodecs en absoluto (más sobre esto en la sección de decisión de abajo). WebCodecs se gana su sitio en el trabajo a nivel de fotograma que queda fuera de una llamada en directo, donde la abstracción de WebRTC nunca estuvo en juego desde el principio.
• Videojuegos en la nube y renderizado remoto. Estas cargas se preocupan mucho por la latencia de codificación y no quieren una pila de conferencia de propósito general de por medio, así que la codificación acelerada por hardware resulta atractiva. En la práctica, eso sí, hardwareAcceleration en la configuración de un códec es solo una pista que el navegador es libre de ignorar, y el soporte real por hardware varía según el dispositivo y el sistema operativo. Una canalización de producción todavía tiene que comprobar isConfigSupported() y tener lista una alternativa de codificación por software, en vez de dar por hecho que la aceleración por hardware va a estar ahí sin más.
• Grabación o transcodificación en el navegador. Tomar un flujo y recodificarlo en un códec o un contenedor distinto por completo en el lado del cliente es práctico ahora de una forma que sencillamente no lo era antes de que existiera WebCodecs, cuando la alternativa era enviar los medios a un servidor o empaquetar un codificador en WebAssembly.

Compatibilidad con navegadores y salvedades del mundo real

El soporte es fuerte y maduro en todo Chromium: Chrome, Edge y Opera tienen acceso completo al códec desde Chrome 94, hace ya varios años. Firefox se puso al día en escritorio más recientemente, con soporte completo a partir de Firefox 130, aunque Firefox para Android todavía no lo implementa. La historia de Safari fue la que más tardó: durante varios años Safari solo ofreció soporte parcial, solo de vídeo, y la paridad completa, incluido el audio, llegó únicamente en Safari 26. La consecuencia práctica es que WebCodecs es una apuesta segura para un producto que priorice Chromium o el escritorio hoy, pero comprueba las tablas de compatibilidad actuales para tus navegadores y versiones concretos antes de comprometerte, sobre todo si en tu base de usuarios hay Firefox móvil o versiones antiguas de Safari.

WebTransport, la mitad de transporte del emparejamiento WebCodecs más WebTransport del que hablábamos arriba, tardó aún más en volverse universal. Solo alcanzó el estado Baseline, es decir, soporte en Chrome, Edge, Firefox y Safari, en marzo de 2026, cuando Safari 26.4 lo incorporó por fin. Chromium lo tiene desde 2022 y Firefox desde 2023. Así que esa pila combinada solo lleva desplegable de forma amplia unos meses, no años, lo que conviene tener en cuenta antes de apostar un sistema de producción por ella.

La salvedad mayor no es un hueco de navegador. Es lo que asumes tú mismo en cuanto bajas por debajo de la abstracción de WebRTC. WebRTC te da recuperación de pérdidas, sincronización, buffer de jitter y control de congestión gratis, ajustados a lo largo de más de una década de uso en producción. Recurre a WebCodecs y WebTransport y nada de eso viene de serie: tú te haces cargo de la adaptación de bitrate, del manejo de la pérdida de paquetes y de mantener el audio y el vídeo sincronizados, porque el navegador ya no toma esas decisiones por ti a propósito. El propio WebTransport todavía no tiene equivalentes a los algoritmos de estimación de ancho de banda y de bitrate adaptativo de WebRTC, así que una canalización a medida seria suele implicar implementar o tomar prestada esa lógica en vez de suponer que el transporte se encarga. Ese es el trato honesto: más control a bajo nivel a cambio de hacerte cargo de las partes difíciles que una pila agrupada resolvía en silencio.

¿Necesitas WebCodecs o una plataforma que lo resuelva por ti?

Vale la pena plantear esto como una verdadera decisión de construir o integrar, en vez de dar por hecho que el acceso en crudo es siempre la mejor respuesta. WebCodecs compensa su dificultad para equipos que construyen una canalización de medios genuinamente a medida, un protocolo de streaming propio, un paso de procesamiento que tiene que ocurrir sobre fotogramas en crudo o una forma de producto que WebRTC sencillamente no encaja.

Hay una vía intermedia que conviene conocer antes de recurrir a WebCodecs, eso sí. Si lo único que necesitas es acceso a nivel de fotograma dentro de una llamada de vídeo por lo demás normal, como desenfoque de fondo o un efecto de visión por computador, WebRTC ya tiene una forma de hacerlo sin renunciar a su propio transporte. Insertable Streams (MediaStreamTrackProcessor y MediaStreamTrackGenerator) y WebRTC Encoded Transform te permiten leer y modificar fotogramas a mitad de llamada mientras WebRTC sigue encargándose del control de congestión, la travesía de NAT y la sincronización. WebCodecs es la opción correcta cuando necesitas más que eso: una canalización que vive fuera de una llamada WebRTC en directo, un transporte a medida o un formato de contenedor que WebRTC nunca fue pensado para producir.

La mayoría de los productos que solo necesitan videollamadas estándar no necesitan nada de esto, porque WebRTC (o un SDK integrado construido sobre él) ya se encarga de la codificación, el transporte y la recuperación de pérdidas sin que haya que escribir ese código dos veces.

La pila en tiempo real de Digital Samba entra en esa última categoría: una canalización basada en WebRTC con arquitectura de SFU y VP8 como códec de base, más grabación y retransmisión integradas, cubre los casos estándar de conferencia y difusión sin que un equipo tenga que programarse a mano el manejo de códecs. Esto no es una afirmación de que Digital Samba use o necesite WebCodecs internamente, sino sencillamente la otra cara de la decisión hacia la que ha ido construyendo este artículo: saber en qué categoría cae tu producto antes de elegir tus herramientas.

Conclusión

WebCodecs desbloquea la codificación y la decodificación en crudo, a nivel de fotograma, en el navegador: poder real para equipos que construyen streaming de baja latencia a medida o canalizaciones de procesamiento por fotograma, y peso innecesario para quien solo hace videollamadas estándar. La superficie de la API es pequeña y está bien definida, y el soporte de navegadores ahora es sólido salvo unos pocos huecos en móvil y en versiones antiguas, pero la responsabilidad que llega al bajar por debajo de la abstracción de WebRTC es real. Para más sobre cómo encaja esto frente a la capa de transporte, consulta nuestra guía sobre Media over QUIC y nuestra guía de códecs de vídeo para el contexto de códec que hay debajo de todo.

Preguntas frecuentes

¿Qué es la API WebCodecs?

Es una API de JavaScript del navegador que expone de forma directa los codificadores y decodificadores de vídeo y audio integrados en el navegador, y da a los desarrolladores control a nivel de fotograma sin pasar por WebRTC ni por el elemento <video>.

¿En qué se diferencia WebCodecs de WebRTC?

WebRTC es una pila de comunicación en tiempo real completa y agrupada, con captura, codificación, transporte y renderizado gestionados en conjunto. WebCodecs es solo la capa de códec, la codificación y la decodificación por su cuenta, y deja el transporte y todo lo demás en manos del desarrollador.

¿Para qué sirven VideoEncoder y VideoDecoder?

VideoEncoder convierte objetos VideoFrame en crudo en objetos EncodedVideoChunk comprimidos; VideoDecoder hace lo contrario, y convierte los fragmentos codificados de nuevo en fotogramas mostrables.

¿Qué navegadores admiten la API WebCodecs?

Chrome, Edge y Opera la admiten por completo desde Chrome 94. Firefox añadió soporte completo en escritorio a partir de Firefox 130, aunque todavía no en Android. El soporte de Safari fue solo de vídeo durante varios años y solo alcanzó la paridad completa, incluido el audio, en Safari 26.

¿Funciona ya WebTransport en todos los navegadores?

Sí, desde marzo de 2026, cuando Safari 26.4 lo incorporó y WebTransport alcanzó el estado Baseline en Chrome, Edge, Firefox y Safari. Chromium lo admite desde 2022 y Firefox desde 2023, también en Android, pero como pila completa entre navegadores es una llegada reciente.

¿Cuándo deberías usar WebCodecs en vez de un SDK de vídeo integrado?

Recurre a WebCodecs cuando construyas una canalización de medios genuinamente a medida, un transporte propio, un procesamiento a nivel de fotograma o una forma de producto que las videollamadas estándar no encajan. La mayoría de los productos que necesitan videollamadas normales se sirven mejor de un SDK integrado que ya se encarga de la codificación y el transporte.

¿Se puede usar WebCodecs con WebTransport para streaming en directo?

Sí, emparejar WebCodecs con WebTransport es el patrón emergente detrás de enfoques de streaming de baja latencia más nuevos, como Media over QUIC, y da a los desarrolladores un transporte basado en QUIC junto con acceso directo al códec en vez de la canalización agrupada de WebRTC.

Fuentes

1. Mozilla Developer Network. (s. f.). WebCodecs API.
2. Mozilla Developer Network. (s. f.). Using the WebCodecs API.
3. Mozilla Developer Network. (s. f.). Video processing concepts.
4. Mozilla Developer Network. (s. f.). VideoEncoder.
5. Chrome for Developers. (22 de enero de 2025). Video processing with WebCodecs.
6. Can I use. (s. f.). WebCodecs API.
7. TestMu AI. (30 de abril de 2026). WebCodecs: browser support, features, use cases.
8. WebRTC.ventures. (23 de abril de 2026). WebTransport is now Baseline. Here's what that means for real-time media.
9. Fora Soft. (28 de mayo de 2026). WebTransport and WHIP-over-WebTransport.
10. Fluendo. (1 de junio de 2026). WebTransport support in GStreamer.
11. Digital Samba. (22 de agosto de 2025). WebRTC explained: how WebRTC works and its applications.
12. Digital Samba. (29 de mayo de 2026). Media over QUIC (MoQ) explained.
13. Digital Samba. (agosto de 2026). AV1 vs H.264 vs VP9 vs VP8: video codec guide.