SVC frente a Simulcast en WebRTC: comparativa 2026

Usamos IA para escribir más rápido, no para decidir qué es verdad. Alguien de Digital Samba ha leído cada línea de este artículo antes que tú.

Doce participantes. Doce conexiones a internet distintas. Doce tamaños de pantalla diferentes. ¿Cómo entrega tu plataforma de vídeo la mejor calidad posible a cada uno de ellos a la vez? En WebRTC hay dos enfoques radicalmente distintos para resolver este problema: Scalable Video Coding (SVC) y Simulcast. Los dos consiguen calidad de vídeo adaptativa, pero funcionan de formas completamente diferentes, y las decisiones de ingeniería afectan a todo: la carga del SFU, el uso de CPU y hasta lo bien que aguanta tu plataforma cuando a un participante se le cae el ancho de banda en mitad de la llamada.

Ya hemos escrito sobre SVC en profundidad. Este artículo es una comparativa completa de SVC frente a Simulcast en WebRTC: cómo funciona cada enfoque a nivel de arquitectura, dónde gana cada uno, qué códecs se usan en 2026 (incluidos VP9 SVC y AV1 SVC) y por qué Digital Samba eligió VP8 con Simulcast para la arquitectura de su SFU. Si estás construyendo una plataforma WebRTC nueva o auditando una que ya tienes, aquí tienes los detalles de ingeniería que necesitas.

Índice de contenidos

1. El problema que resuelven los dos enfoques
   
2. Simulcast: cómo funciona
   
3. SVC: cómo funciona
   
4. Comparación directa
   
5. Cuándo gana SVC de verdad
   
6. Cuándo gana Simulcast (y por qué lo eligió Digital Samba)
   
7. La tercera vía emergente: mejora de calidad con IA
   
8. Recomendaciones prácticas para quien construye plataformas
9. Preguntas frecuentes

El problema que resuelven los dos enfoques

Las videollamadas en grupo plantean un problema de distribución que no existe en las sesiones uno a uno. En una llamada uno a uno, los dos participantes envían y reciben con la mejor calidad que soporten sus conexiones. En una llamada en grupo servida por una Unidad de Reenvío Selectivo (SFU, por sus siglas en inglés), el emisor publica un flujo que tiene que llegar a varios receptores a la vez. Cada receptor tiene un ancho de banda disponible distinto, un dispositivo con capacidades distintas y un tamaño de pantalla distinto asignado a cada mosaico de participante.

Enviar el mismo flujo de alta calidad a todo el mundo desperdicia ancho de banda para quien tiene una conexión justa y provoca pérdida de paquetes y congestión. Enviar solo un flujo de baja calidad penaliza a quien sí tiene ancho de banda y pantalla para recibir algo mejor. El requisito de ingeniería es la entrega de calidad adaptativa: poder entregar niveles de calidad distintos desde un único emisor a varios receptores, sin recodificar ni transcodificar en el servidor.

Dos enfoques de arquitectura cumplen este requisito. Simulcast codifica el vídeo en varios niveles de calidad a la vez y los envía todos. Scalable Video Coding codifica el vídeo una sola vez, pero incrusta varias capas de calidad dentro de un mismo flujo binario. Los dos dejan que el SFU tome decisiones de reenvío por receptor según el ancho de banda disponible, el tamaño del mosaico y quién está hablando, pero la mecánica, la eficiencia y los compromisos de cada enfoque son muy diferentes.

Simulcast: cómo funciona

Con Simulcast, el navegador o el SDK del emisor codifica la misma fuente de vídeo en dos o tres niveles de calidad a la vez. Una configuración típica genera flujos independientes a 720p/1,5 Mbps, 360p/500 kbps y 180p/150 kbps. Cada codificación es un flujo totalmente independiente, completo y decodificable a esa resolución, sin depender de los demás. Si un flujo se pierde o se corrompe, los otros siguen intactos.

Los tres flujos suben al SFU, que los recibe y elige uno para reenviarlo a cada receptor (suscriptor) según una combinación de señales:

• Ancho de banda del receptor: se mide con los paquetes de feedback REMB (Receiver Estimated Maximum Bitrate) o TWCC (Transport-Wide Congestion Control) que devuelve el navegador del receptor.
• Tamaño del mosaico de vídeo: un mosaico del tamaño de una miniatura no gana nada con un flujo a 720p. Muchos SFU reciben datos de la distribución de pantalla desde la aplicación cliente para tomar esta decisión y evitar reenviar una resolución que se va a reducir de inmediato al mostrarla.
• Detección del participante activo: quien habla en cada momento suele recibir su flujo reenviado en alta resolución; a los demás se les baja de calidad para dejar ancho de banda a la entrega en calidad completa del que habla.
• Fijado manual: algunas plataformas dejan que el usuario fije a un participante concreto, lo que indica al SFU que dé prioridad al flujo de alta resolución de ese participante para ese receptor, sin importar el tamaño del mosaico.

Un detalle fácil de pasar por alto: en una llamada grande, el emisor sigue publicando un número fijo de flujos (dos o tres) sin importar cuántos participantes haya en la sesión. El trabajo de distribución del SFU crece con el número de receptores, pero la carga de subida del emisor no.

Cambiar de un nivel de calidad a otro es rápido. El SFU deja de reenviar un flujo y empieza a reenviar otro, pero hace falta una petición de keyframe (fotograma de inicio) al emisor para que el decodificador del receptor arranque limpio en el flujo nuevo sin corrupción visual. Ese ida y vuelta añade un retardo breve, normalmente una fracción de segundo, y produce una pequeña discontinuidad visual durante los cambios de calidad. Este es el principal inconveniente de Simulcast frente a SVC.

El coste de ancho de banda de subida es el compromiso más citado de Simulcast. En la práctica, como los flujos de menor resolución son mucho más baratos de codificar, la sobrecarga combinada suele situarse entre el 30 y el 50 por ciento por encima del coste de un único flujo de alta calidad, aunque la cifra real depende mucho de la configuración de bitrate; algunas mediciones con compresión de subcapas más agresiva registran sobrecargas de apenas el 17 por ciento. Como ejemplo concreto, enviar 720p a 1,5 Mbps, 360p a 500 kbps y 180p a 150 kbps cuesta unos 2,15 Mbps en total, no 4,5 Mbps.

Arquitectura de flujos (simplificada): Emisor > [flujo 720p | flujo 360p | flujo 180p] > SFU > selecciona por receptor > el receptor A recibe 720p | el receptor B recibe 360p | el receptor C recibe 180p

SVC: cómo funciona

Scalable Video Coding hace justo lo contrario. En lugar de codificar varios flujos independientes, SVC codifica el vídeo una sola vez e incrusta varias capas de calidad dentro de un único flujo binario. El SFU reenvía ese flujo por capas de forma selectiva: envía todas las capas a los receptores bien conectados y descarta las capas superiores para los que tienen poco ancho de banda. En ningún punto de la cadena de señal se recodifica.

SVC admite tres tipos de escalabilidad, y un despliegue concreto puede usar uno o cualquier combinación:

• Escalabilidad temporal: varía la tasa de fotogramas manteniendo fija la resolución. Una capa base puede llevar fotogramas a 7,5 fps. La primera capa temporal de mejora añade fotogramas hasta llegar a 15 fps; una segunda lo lleva a 30 fps. Descartar capas temporales reduce el ancho de banda de forma suave a costa de la tasa de fotogramas, sin cambiar la resolución.
• Escalabilidad espacial: varía la resolución. La capa base lleva una imagen a 180p. Las capas espaciales de mejora añaden detalle de píxel para reconstruir una imagen a 360p y luego a 720p. Descartar capas espaciales es el equivalente en SVC al cambio de calidad de Simulcast, pero sin la discontinuidad del keyframe.
• Escalabilidad de calidad (SNR): varía la fidelidad de imagen a una resolución fija. La capa base produce una imagen de menor fidelidad; las capas de mejora la refinan de forma progresiva. Útil para gestionar la congestión con suavidad sin cambiar la resolución ni la tasa de fotogramas.

El SFU lee los metadatos de capa por paquete (los identificadores temporales y espaciales incrustados en las cabeceras de extensión RTP) para decidir qué paquetes reenvía a cada receptor. Los receptores con conexiones justas reciben la capa base o un subconjunto limitado de capas de mejora. Los bien conectados reciben la pila de capas completa.

Como cada capa de mejora depende de la capa base para decodificarse, perder paquetes de la capa base hace que las capas superiores no se puedan decodificar. Esta cadena de dependencias es la principal preocupación de fiabilidad de SVC en redes con pérdidas. Desde el punto de vista del SFU, en cambio, descartar capas es barato en cómputo: el SFU lee la etiqueta de identificador de capa, descarta los paquetes por encima del umbral objetivo y reenvía el resto sin transcodificar.

Arquitectura de capas (simplificada): el emisor codifica un solo flujo > [capa base | temporal L1 | temporal L2 | espacial L1 | espacial L2] > el SFU lee los identificadores de capa > reenvía un subconjunto por receptor > receptor A (todas las capas) | receptor B (base + temporal L1) | receptor C (solo base)

Comparación directa

Esta comparativa de SVC frente a Simulcast recoge la ingeniería real en siete dimensiones. Los resultados de abajo reflejan las condiciones de producción de 2026, incluidas las limitaciones de compatibilidad con navegadores más relevantes para los despliegues reales.

La fila de compatibilidad con navegadores es la columna más decisiva de 2026. El VP9 SVC completo (capas espaciales y temporales combinadas) es una capacidad exclusiva de Chrome. Firefox admite VP9, pero solo envía escalabilidad temporal, no capas espaciales. Safari no codifica VP9 en WebRTC en absoluto. Esta limitación de codificación de VP9 afecta por igual a cualquier estrategia con VP9, sea SVC o Simulcast: un participante con Safari no puede enviar VP9 use el SFU el enfoque que use. Si tu plataforma da servicio a algún participante con Safari o iOS, una estrategia basada solo en VP9 (SVC o Simulcast) necesita un plan de respaldo de códec por participante. VP8 Simulcast (o H.264 Simulcast) es el estándar de producción multinavegador porque lo universalmente compatible es VP8, no Simulcast en sí.

Cuándo gana SVC de verdad

SVC no es un enfoque peor. Es un enfoque más especializado que funciona claramente mejor en los escenarios donde sus compromisos encajan con el contexto del despliegue.

• Emisores con poco ancho de banda: el menor consumo de subida de SVC importa sobre todo cuando los emisores están en conexiones móviles o en mercados con costes de subida altos. Enviar un único flujo por capas en lugar de dos o tres flujos independientes reduce la presión de subida de forma notable, sobre todo en resoluciones base más altas. Las cifras que citan los fabricantes suelen indicar reducciones de en torno al 40 a 60 por ciento frente a VP8 Simulcast en condiciones de calidad equivalentes, y esa diferencia es real para despliegues centrados en el móvil.
• Transiciones de calidad suaves: el descarte de capas de SVC produce cambios de calidad imperceptibles. No hay petición de keyframe, ni reinicio del decodificador, ni congelación de imagen. Para casos de uso donde la continuidad visual es crítica, como la revisión de imagen médica, la inspección industrial remota o la monitorización de producción audiovisual, esta transición suave es una ventaja real frente al cambio con keyframe de Simulcast.
• Reenvío selectivo a gran escala: cuando un SFU sirve a la vez a cientos de receptores en niveles de calidad distintos desde un único emisor, descartar capas con SVC sale más barato en cómputo que almacenar y gestionar varios flujos codificados independientes por emisor. Cada flujo adicional de Simulcast añade memoria y carga de reenvío al SFU; SVC no. En sesiones muy grandes, esa diferencia de sobrecarga por emisor suma.
• Grabación en el servidor: un único flujo SVC se puede archivar y posprocesar en varias calidades de salida sin recodificar la captura original. Guardar dos o tres flujos de Simulcast por sesión multiplica los costes de almacenamiento. Para plataformas con mucho volumen de sesiones y requisitos de retención largos, conviene tenerlo en cuenta.

Cuando se dan estos escenarios y todos los participantes usan Chrome, VP9 SVC es una opción de producción viable hoy. Google Meet usa VP9 SVC de forma interna por exactamente estas razones: menor ancho de banda de subida y adaptación de calidad más suave a gran escala, en un entorno mayoritariamente Chrome.

Cuándo gana Simulcast (y por qué lo eligió Digital Samba)

Para la mayoría de las plataformas WebRTC de producción que dan servicio a bases de usuarios reales, Simulcast es la decisión de arquitectura correcta. Hay cuatro motivos que lo explican de forma consistente.

• La compatibilidad multinavegador no es negociable: cualquier plataforma que atienda a un público general tiene que dar soporte a Safari e iOS. Y Safari no puede codificar VP9 en WebRTC, lo que descarta por igual VP9 SVC y VP9 Simulcast. El códec que te da alcance multinavegador de verdad es VP8, y Simulcast es la única opción para adaptar la resolución cuando usas VP8. VP8 Simulcast funciona en Chrome, Firefox, Safari y Edge sin tener que negociar códecs ni comprobar capacidades por dispositivo.
• Madurez de implementación: la implementación de Simulcast en los servidores de medios asentados (Janus, mediasoup y Jitsi Videobridge) lleva años de pruebas en producción, en una gran variedad de condiciones de red, tipos de dispositivo y tamaños de sesión. Las implementaciones de SVC en el SFU están menos maduras, con menos modos de fallo documentados y una comunidad de despliegues de referencia más pequeña de la que aprender.
• Previsibilidad: la lógica de selección de flujo de Simulcast es transparente y fácil de razonar. Cuando algo se rompe, la depuración es abordable: identificas cuál de los N flujos ha fallado y por qué. Las cadenas de dependencia entre capas de SVC añaden una dificultad de diagnóstico que alarga el tiempo de resolución de las incidencias en producción. Para equipos sin experiencia profunda en SVC dentro del SFU, esto es un riesgo operativo real.
• Dependencia del códec: VP8 no admite SVC espacial. Si tu plataforma usa VP8, Simulcast es la única opción para adaptar la resolución. VP8 en WebRTC sí admite escalabilidad temporal (modos L1T2 y L1T3), que permite al SFU descartar capas temporales para reducir la tasa de fotogramas sin una petición de keyframe. No es SVC espacial completo, pero cierra en parte la diferencia de suavidad en las transiciones de tasa de fotogramas.

Digital Samba usa VP8 con Simulcast en su SFU basado en Janus. Fue una decisión de arquitectura deliberada, no un valor por defecto. VP8 nos da compatibilidad universal con navegadores y un coste de codificación de CPU bajo. Simulcast gestiona la calidad adaptativa multinavegador sin dependencia de códec. El SFU de Janus encamina los paquetes de medios cifrados sin mezclarlos ni decodificarlos, lo que mantiene la selección de flujo ligera y la latencia de procesamiento baja de forma consistente. Cada participante, en cualquier navegador y cualquier dispositivo, recibe calidad adaptativa fiable.

Esa decisión sí conlleva un coste de ancho de banda que conviene nombrar sin rodeos. VP9 comprime en torno a un 30 a 50 por ciento mejor que VP8 a igual calidad (las cifras varían según el contenido y los ajustes), así que una plataforma con VP8 Simulcast acepta un ancho de banda mayor de subida y de bajada para todos los participantes con Chrome y Firefox frente a una ruta con VP9. Aceptamos ese compromiso a propósito: una estrategia de un solo códec que funciona igual en todos los navegadores, Safari incluido, simplifica la lógica del SFU, elimina las comprobaciones de capacidad de códec por participante y quita de en medio toda una clase de casos límite en la negociación de códecs.

VP9 Simulcast merece la pena como opción complementaria en sesiones de Chrome a Chrome donde la eficiencia de ancho de banda sea prioritaria. Pero conviene dejarlo claro: VP9 Simulcast se enfrenta al mismo requisito de respaldo para Safari que VP9 SVC. La ventaja multinavegador viene de VP8, no de Simulcast como enfoque.

La tercera vía emergente: mejora de calidad con IA

Está surgiendo un tercer enfoque que esquiva la decisión entre SVC y Simulcast a nivel de arquitectura: en lugar de enviar más calidad desde el emisor, usar IA para mejorar la calidad en el receptor.

La superresolución con IA aplica redes neuronales para escalar un flujo de baja resolución en el lado del receptor. Un flujo de entrada a 360p se puede mostrar con una calidad percibida bastante cercana a 720p sin coste de bitrate adicional para el emisor. Combinada con reducción de ruido por IA e interpolación de fotogramas, la mejora en el receptor puede producir una imagen mejor a partir de una entrada limitada por ancho de banda, sin cambiar la cadena de codificación.

NVIDIA Maxine (comercializada también como NVIDIA AI for Media) ofrece un SDK de producción para esto en cadenas WebRTC. Puede ejecutarse en el lado del cliente, donde la mejora ocurre en la propia GPU del receptor y requiere hardware con capacidad suficiente para asumir la carga, o en el lado del servidor, donde servidores de medios equipados con NVIDIA hacen el procesamiento para todos los receptores. La ruta del servidor elimina la dependencia del hardware del usuario final, pero exige invertir en infraestructura de GPU. Google Meet ha estado explorando la mejora en el receptor en una dirección parecida, aunque no consta un despliegue amplio de forma pública. El coste de cómputo es alto, lo que hoy limita su aplicación práctica a dispositivos o despliegues con hardware capaz. En móviles y portátiles modestos, justo los participantes que más se beneficiarían de una mejora de calidad, la IA en el receptor todavía no es práctica en 2026.

Un calendario realista para este enfoque en casos de uso concretos es 2027 a 2028. Quien esté construyendo una plataforma ahora debería tener en cuenta esta dirección al fijar los objetivos de calidad de codificación y al diseñar sus cadenas de calidad adaptativa.

Recomendaciones prácticas para quien construye plataformas

• ¿Empiezas una plataforma nueva en 2026? Usa VP8 o H.264 Simulcast. Los dos funcionan en todos los navegadores principales, están probados en cada implementación importante de SFU y cubren Safari e iOS sin necesidad de un plan de respaldo. Añade VP9 Simulcast como opción complementaria para sesiones de Chrome a Chrome donde quieras mejor eficiencia de ancho de banda en conexiones justas.
• ¿Ya usas VP9 SVC? Si tu despliegue es solo para Chrome (un entorno de empresa controlado, con gestión de dispositivos bloqueada, por ejemplo), VP9 SVC es una opción de producción razonable. Define y prueba tu plan de respaldo para Safari antes de abrirte a un público general.
• ¿Planificas para AV1? AV1 SVC para WebRTC todavía no está listo de forma amplia para videollamadas bidireccionales generales entre navegadores. Chrome admite la codificación AV1 en WebRTC desde Chrome 90, en 2021, pero la codificación AV1 en tiempo real sigue exigiendo mucha CPU y la aceleración por hardware se limita a chips recientes concretos, lo que la frena para el uso general. La pila WebRTC de Safari no expone la codificación AV1 en absoluto, ni siquiera en los chips Apple Silicon que ya incluyen codificación AV1 por hardware. El calendario realista para un soporte amplio de AV1 SVC entre navegadores es 2028 o más adelante. Diseña tu SFU ahora con una capa de abstracción de códecs limpia para poder añadir AV1 SVC como opción de reenvío cuando llegue el soporte de los navegadores, sin reconstruirlo desde cero. Para compartir pantalla en concreto, AV1 ya merece una valoración en los navegadores compatibles, porque su eficiencia de compresión a tasas de fotogramas bajas resulta interesante para el contenido de pantalla incluso hoy.
• Para flujos de trabajo de grabación: transcodificar las grabaciones de sesión a AV1 para almacenamiento y entrega por CDN merece una valoración sea cual sea tu enfoque de codificación en directo. Las restricciones de codificación en tiempo real no se aplican al procesamiento posterior a la sesión, y la ventaja de compresión de AV1 frente a VP8 y H.264 es sustancial a igual calidad.
• Para videollamadas en grupo con Simulcast y más de diez flujos de vídeo activos a la vez: vigila de cerca la CPU del SFU y valora VP9 SVC para los subconjuntos de participantes que estén solo en Chrome, o arquitecturas de SFU en cascada para sesiones muy grandes donde el cuello de botella pase a ser la gestión de flujos por emisor.

Preguntas frecuentes

¿Cuál es la diferencia principal entre SVC y Simulcast en WebRTC?

Con Simulcast, el emisor codifica el mismo vídeo en varios niveles de calidad a la vez y los envía todos como flujos independientes. El SFU elige qué flujo reenvía a cada receptor según el ancho de banda disponible, el tamaño del mosaico y quién habla. Con SVC, el emisor codifica una sola vez y produce un único flujo por capas. El SFU descarta de forma selectiva las capas superiores para los receptores con poco ancho de banda. SVC es más eficiente en ancho de banda en el emisor; Simulcast ofrece mayor compatibilidad con navegadores y un análisis de fallos más sencillo.

¿Safari admite la codificación SVC en 2026?

No. Safari no puede codificar VP9 en WebRTC, lo que descarta VP9 SVC como estrategia de envío para cualquier participante con Safari. La misma limitación descarta también VP9 Simulcast desde Safari. Safari sí puede decodificar VP9 desde Safari 14 / iOS 14 en adelante, pero al no poder codificar, los participantes con Safari tienen que recurrir a VP8 o H.264, independientemente de que el SFU use SVC o Simulcast.

¿Qué es SVC en la codificación de vídeo?

SVC (Scalable Video Coding, codificación de vídeo escalable) es una técnica que codifica el vídeo una sola vez en un único flujo dividido en capas: una capa base de baja calidad y varias capas de mejora temporal, espacial o de fidelidad. Al descartar capas superiores, un servidor puede adaptar la calidad a cada receptor sin recodificar. En WebRTC, el SVC espacial completo está disponible sobre todo en VP9 y AV1.

¿Qué enfoque usa menos ancho de banda de subida: SVC o Simulcast?

SVC usa bastante menos ancho de banda de subida. Un único flujo SVC por capas añade una sobrecarga mínima frente a codificar a un solo nivel de calidad. Simulcast codifica dos o tres flujos independientes; en una configuración típica de tres capas, el coste de subida combinado se sitúa entre el 30 y el 50 por ciento por encima de un solo flujo de alta calidad, aunque la sobrecarga real depende de lo agresiva que sea la compresión de las subcapas. Para emisores en conexiones móviles justas, esta diferencia importa. La codificación SVC espacial completa está disponible solo en Chrome en 2026; Firefox ofrece escalabilidad temporal; Safari no codifica VP9.

¿Cuándo estará AV1 SVC listo para videoconferencia en producción?

No se espera un soporte amplio de AV1 SVC entre navegadores antes de 2028. Chrome admite la codificación AV1 en WebRTC desde 2021, pero la codificación en tiempo real exige mucha CPU y la aceleración por hardware se limita a chips recientes, que es lo que hoy la frena para las llamadas bidireccionales generales. La pila WebRTC de Safari todavía no expone la codificación AV1, así que no está disponible para ningún participante con Safari. Los casos de compartir pantalla son los más avanzados, donde la eficiencia de AV1 a tasas de fotogramas bajas ya resulta interesante en los navegadores compatibles. Diseña tu arquitectura ahora para poder añadir AV1 SVC más adelante sin rehacer tu SFU.

¿Quieres ver la calidad de vídeo adaptativa en producción?

Para ver cómo gestiona Digital Samba la calidad de vídeo adaptativa en un despliegue de producción, solicita una demo y te enseñamos la arquitectura de primera mano.

Y si quieres la imagen completa de la arquitectura de medios de Digital Samba, incluidos el diseño de nuestro SFU y nuestro enfoque de cifrado, descarga el Informe de Seguridad.

Referencias

1. Ant Media. (2025). VP9 codec: Google's open-source video codec for streaming. Ant Media.

2. Ant Media. (2026). WebRTC browser support 2026: Complete compatibility guide. Ant Media.

3. Daily.co. (s. f.). Smooth sailing with simulcast. Daily.co Blog.

4. Digital Samba. (2024). AV1 vs H.264 vs VP9 vs VP8: Video codec guide 2026. Digital Samba Blog.

5. Digital Samba. (2024). SVC in video conferencing: How it works and why it matters. Digital Samba Blog.

6. Digital Samba. (2024). Why Janus is Digital Samba's preferred SFU for WebRTC applications. Digital Samba Blog.

7. Divorra, O. (s. f.). Optimising video quality using simulcast. webrtcHacks.

8. Forasoft. (2026). AV1 in production: When royalty-free codec saves money. Forasoft Blog.

9. Garcia Murillo, S. y Garcia, G. (s. f.). Chrome's WebRTC VP9 SVC layer cake. webrtcHacks.

10. GetStream.io. (s. f.). WebRTC codecs: What's supported?. GetStream.io Resources.

11. Levent-Levi, T. (s. f.). Simulcast. BlogGeek.me WebRTC Glossary.

12. Levent-Levi, T. (s. f.). SVC in WebRTC: VP9 & AV1 scalable video coding explained. BlogGeek.me WebRTC Glossary.

13. Levent-Levi, T. (2025, diciembre). Five WebRTC predictions for 2026: AV1, MOQ, and what might break next. WebRTC.ventures.

14. WebRTC.ventures. (2026, abril). Should you still consider the AV1 codec in your WebRTC architecture?. WebRTC.ventures Blog.