Cada comparativa de códecs que has leído este año probablemente te haya dicho que AV1 es el futuro y H.264 es el pasado. No se equivocan, pero escriben sobre streaming, no sobre videoconferencia. Si estás construyendo una plataforma de vídeo en tiempo real donde la codificación ocurre en directo, cada fotograma cuenta y tus usuarios usan desde un Chromebook de 2019 hasta el último iPhone, la pregunta del códec tiene una respuesta muy distinta.
Seguramente has leído que AV1 ofrece entre un 30 y un 50 por ciento más de compresión que H.264. Eso es cierto para streaming precodificado. Ahora prueba a codificarlo en tiempo real durante una videollamada en directo, con software, en un portátil de gama media. El panorama cambia bastante.
En esta guía comparamos AV1, H.264, VP9 y VP8 desde el prisma que realmente importa para tu plataforma: velocidad de codificación en tiempo real, compatibilidad entre navegadores, complejidad de enrutamiento en la SFU (Selective Forwarding Unit) y cuánto cuesta hacerlo funcionar en producción. Empezamos por VP8 porque es la base obligatoria de WebRTC, y luego repasamos H.264, VP9 y AV1 en orden de madurez de despliegue. También explicamos por qué VP8, el códec que la mayoría de artículos descarta como "legado", sigue ejecutándose en más despliegues WebRTC en producción de lo que muchos ingenieros suponen. Al final encontrarás un marco práctico de decisión que puedes aplicar directamente.
Índice de contenidos
La conversación sobre códecs de vídeo en 2026 está dominada por ingenieros de streaming, y esa es parte de la razón por la que los consejos que encuentras en internet a menudo no aplican a las plataformas de videoconferencia.
En vídeo bajo demanda (VOD) y en emisión en directo, codificas una vez y sirves el resultado a miles o millones de espectadores. El coste de CPU de la codificación es una inversión única o por lotes. La famosa lentitud de la codificación AV1 por software es irrelevante cuando tu granja de codificación trabaja sin conexión o tu codificador tiene hardware AV1 dedicado. La decisión sobre el códec en streaming gira principalmente en torno a la eficiencia de compresión y los costes de almacenamiento.
En videoconferencia codificas en tiempo real, por participante, de forma continua, en el propio dispositivo del participante. Cada milisegundo de latencia de codificación se suma al retardo de cristal a cristal. Un códec que codifica 10 veces más lento que otra alternativa no solo consume más CPU: degrada directamente la calidad de cada llamada en cada dispositivo que no pueda seguir el ritmo.
Luego está la negociación del códec. Cuando dos navegadores establecen una conexión WebRTC, intercambian una oferta SDP (Session Description Protocol) que enumera los códecs que cada lado admite. La SFU o el par debe seleccionar un códec que ambos extremos soporten, no el que tú prefieras o el que rinda mejor en tu hardware de pruebas. Si la usuaria A está en Chrome y la usuaria B en Safari, esa negociación impone una restricción real sobre lo que puedes usar.
Esta es la realidad multinavegador para la que estás diseñando en 2026:
Para una plataforma de videoconferencia que sirve a usuarios en todos estos entornos, no hay una sola respuesta correcta. La correcta es una mezcla negociada, y entender la posición real de cada códec es la forma de configurarla con criterio.
Lanzado en 2010 por Google y publicado como código abierto a través del proyecto WebM, VP8 se diseñó originalmente como alternativa a H.264 libre de regalías. Se convirtió en el primer códec de vídeo obligatorio en la especificación WebRTC, lo que significa que sigue siendo el códec base que toda implementación WebRTC conforme debe soportar.
Esa historia explica por qué VP8 sigue activo y vivo en despliegues de producción en 2026, no porque nadie sepa hacerlo mejor, sino porque funciona de forma fiable en todas partes. Como dice Tsahi Levent-Levi, una de las principales referencias en arquitectura WebRTC: "VP8 simplemente sigue funcionando". En sus predicciones WebRTC para enero de 2026 recomienda explícitamente a los proveedores que tienen dificultades para estabilizar AV1 que vuelvan a VP8, estabilicen y experimenten hacia arriba desde ahí.
Frente a H.264, el equilibrio de VP8 tiene menos que ver con la calidad y más con dónde encaja cada códec en tu infraestructura. Las ventajas prácticas de VP8 en un contexto de videoconferencia son:
Velocidad de codificación: VP8 es rápido. La codificación por software de vídeo 720p en tiempo real es perfectamente alcanzable en hardware modesto sin aceleración dedicada. Esto importa enormemente para clientes móviles y dispositivos económicos.
Predictibilidad de CPU: la complejidad de codificación de VP8 es baja y predecible. No verás picos de CPU que provoquen pérdida de fotogramas en medio de la llamada.
Soporte universal: VP8 está soportado en Chrome, Firefox, Edge y Safari (desde Safari 12.1 para WebRTC). Es el único códec que puedes usar de forma fiable en prácticamente todas las combinaciones de navegador sin transcodificar en servidor.
Eficiencia de compresión: aquí está la debilidad de VP8. Conseguir buena calidad a 1080p requiere aproximadamente de 4500 a 6000 kbps. Eso es bastante más ancho de banda del que necesitan VP9 o AV1 para una calidad equivalente. En conexiones limitadas o planes de datos móviles, los requisitos de bitrate de VP8 se convierten en un problema real.
Cuándo quedarte con VP8:
Cambiar de códec cuesta tiempo de ingeniería real, así que asegúrate de que la ganancia justifica el movimiento antes de empezar.
H.264 (también conocido como AVC, Advanced Video Coding) es el códec de vídeo más desplegado de la historia. Estandarizado por la ITU-T y la ISO/IEC, fue el códec que hizo viable el vídeo HD por internet, y no va a desaparecer pronto.
Para videoconferencia en concreto, H.264 tiene un atributo que lo hace innegociable para la mayoría de equipos: es el códec WebRTC preferido de Safari, y el soporte de codificación por hardware para H.264 existe en prácticamente todos los dispositivos fabricados en la última década. Si tu base de usuarios incluye dispositivos Apple, y casi seguro que sí, necesitas soporte de H.264.
Velocidad de codificación: rápida, muy optimizada y con excelente aceleración por hardware en casi cualquier dispositivo. Intel, AMD, NVIDIA, Qualcomm, Apple Silicon y Exynos cuentan con codificadores hardware de H.264 maduros. Esto significa que la codificación en tiempo real a 1080p es alcanzable en móviles sin un consumo de batería significativo.
Eficiencia de compresión: H.264 ofrece buena calidad a aproximadamente 4000 a 5000 kbps para 1080p. Eso supera con claridad a VP8 en el mismo escenario, pero queda bastante por detrás de VP9 y AV1. Para videoconferencia en resoluciones habituales de 720p, H.264 suele ser adecuado.
Licencia: H.264 no es código abierto. Está cubierto por patentes, administradas ahora por la Via Licensing Alliance (anteriormente MPEG LA), y usarlo en productos comerciales técnicamente requiere una licencia. Para plataformas WebRTC basadas en navegador, esto lo gestionan en gran medida los fabricantes de navegadores, que tienen sus propias licencias de H.264. Si haces tu propia codificación H.264 en servidor (por ejemplo, en un pipeline de grabación o transcodificación) estás fuera de la licencia del navegador y conviene revisar tus obligaciones con asesoría legal.
El argumento de interoperabilidad: cuando no tienes claro qué códec comparten dos extremos, H.264 es el común denominador. Chrome, Firefox, Edge y Safari lo soportan. Android e iOS lo soportan con aceleración por hardware. Para equipos que necesitan un único códec que funcione en todas las circunstancias, H.264 es la respuesta pragmática, y no una respuesta de la que avergonzarse.
VP9 es el sucesor de Google a VP8, lanzado en 2013, libre de regalías y usado por YouTube para la mayoría de la reproducción de escritorio en Chrome y Firefox. Sobre el papel, VP9 es una opción atractiva para videoconferencia: ofrece mejor compresión que VP8 con la misma calidad visual, llevando 1080p a aproximadamente 2400 a 3200 kbps frente a los 4500 a 6000 kbps de VP8.
Ese ahorro de ancho de banda es real y significativo, sobre todo para plataformas que sirven a usuarios con conexiones móviles variables o en mercados donde los datos son caros.
El reto con VP9 es la velocidad de codificación, aunque en una forma algo menos extrema que la de AV1. La codificación VP9 por software es bastante más lenta que H.264 con ajustes de calidad comparables. Con preajustes de calidad media en libvpx, esa diferencia es lo bastante grande como para que la codificación VP9 por software en tiempo real resulte impracticable en la mayoría de hardware sin aceleración por GPU.
Esto golpea con más fuerza cuando entran en juego los móviles. La descodificación VP9 por hardware está muy extendida (Android tiene descodificación VP9 por software desde Android 4.4 KitKat, con descodificación por hardware llegando en SoC fabricados aproximadamente a partir de 2016), pero la codificación VP9 por hardware está mucho menos disponible en hardware móvil. Esto significa que la codificación VP9 en el cliente WebRTC suele caer en codificación por software lenta, disparando la CPU y agotando la batería.
Soporte de navegadores: Chrome, Firefox y Edge de forma nativa. Safari añadió soporte de descodificación VP9 en macOS Big Sur e iOS 14 (Safari 14 y posteriores), pero VP9 no es el códec WebRTC preferido de Safari y el soporte de codificación en Safari/iOS sigue siendo limitado e inconsistente. Esto genera la misma presión de transcodificación en servidor que VP8 evita.
El rompecabezas de adopción es real: VP9 lleva años disponible, ofrece beneficios claros de compresión y es libre de regalías. Y aun así, muchas plataformas WebRTC no lo han adoptado del todo. Como señala Tsahi Levent-Levi, esa reticencia es una señal útil sobre AV1. Si la industria no se ha movido por completo a VP9 después de más de una década, esperar que AV1 domine en 2026 no es realista.
Cuándo tiene sentido VP9: en entornos controlados donde sabes que ambos extremos están en Chrome o Firefox con aceleración por hardware; en pipelines de grabación (codificas una vez y aprovechas el ahorro de compresión en cada reproducción); o en plataformas dirigidas específicamente a usuarios de escritorio donde tienes más confianza en el margen de CPU.
AV1 es el códec desarrollado por la Alliance for Open Media (AOMedia), una coalición que incluye a Google, Netflix, Amazon, Microsoft, Intel, Mozilla y Cisco, con Apple incorporándose en enero de 2018 poco antes de que la especificación se finalizara. La especificación del bitstream se publicó en marzo de 2018. Su eficiencia de compresión es realmente notable: entre un 30 y un 50 por ciento mejor que VP9 y entre un 50 y un 60 por ciento mejor que H.264 con calidad visual equivalente, llevando 1080p a aproximadamente 1800 a 2200 kbps.
AV1 se diseñó para ser libre de regalías bajo la licencia de patentes de AOMedia. En la práctica, sin embargo, ese compromiso de gratuidad solo vincula a los miembros de AOMedia. Los titulares de patentes que decidieron no unirse a AOMedia pueden hacer valer cualquier patente que consideren relevante para AV1. A marzo de 2026 esto se ha convertido en un asunto activo: Dolby ha presentado demandas por infracción de patentes contra Snap Inc. en Estados Unidos y Brasil dirigidas a su uso de AV1, e InterDigital, Nokia y Sisvel (que reclama un grupo de más de 1500 patentes relevantes) han hecho valer derechos de propiedad intelectual relacionados con implementaciones de AV1. WebRTC.ventures señaló esto específicamente como un riesgo de adquisición relevante en abril de 2026. La posición práctica para un equipo de plataforma hoy: la condición libre de regalías de AV1 refleja el compromiso interno de AOMedia, pero los no miembros están litigando activamente. Consulta con asesoría legal antes de desplegar AV1 comercialmente.
Para streaming y VOD, AV1 ya ha ganado independientemente de esas complicaciones. YouTube, Netflix y la mayoría de plataformas de streaming importantes usan AV1 para una parte significativa de su tráfico. La pregunta de este artículo es si esas ventajas se trasladan a la videoconferencia en tiempo real, y la respuesta honesta en 2026 es: todavía no para la mayoría de plataformas.
El problema de la velocidad de codificación: la codificación AV1 por software es de 5 a 10 veces más lenta que VP9 y puede saturar varios núcleos de CPU durante la codificación activa en hardware de escritorio. Para videollamadas en directo, donde se codifica por participante y por fotograma en tiempo real, esto hace impracticable la codificación AV1 por software en la mayoría del hardware actual sin silicio AV1 dedicado.
Disponibilidad de codificadores AV1 por hardware en 2026: la situación mejora, pero es desigual. El hardware de escritorio y portátiles con codificadores AV1 incluye las GPU discretas Intel Arc (nota: los gráficos integrados de 12.ª generación Alder Lake soportan únicamente descodificación AV1; la codificación por hardware es exclusiva de las GPU discretas Arc y de los gráficos integrados de los Core Ultra de 14.ª generación), AMD RDNA 3 y posteriores (serie RX 7000), NVIDIA RTX serie 40 (Ada Lovelace) y Apple M5 Pro y M5 Max (lanzados en marzo de 2026; las generaciones anteriores de Apple Silicon, M1, M2, M3 y M4, solo tienen descodificación AV1 por hardware). Esto cubre una porción significativa del hardware reciente de gama entusiasta, pero no el parque general de dispositivos de consumo y prácticamente nada del móvil.
La codificación AV1 por hardware en móvil es el hueco crítico. El Samsung Exynos 2200 añadió descodificación AV1 por hardware, pero el soporte de codificación por hardware en Snapdragon y otros SoC móviles sigue siendo limitado. En particular, Qualcomm ha declarado públicamente que no tiene previsto añadir codificación AV1 por hardware a Snapdragon, con la intención de saltarse la codificación AV1 y pasar directamente a VVC (Versatile Video Coding) cuando esté lista. Dada la cuota de Snapdragon en buques insignia Android y gama media, esto convierte el calendario habitualmente citado de 2027 a 2028 para una codificación AV1 móvil ubicua en una predicción razonable para hardware Apple y PC, pero mucho menos segura para Android. La realidad para la mayoría de usuarios de smartphone en 2026 es que la codificación AV1 en tiempo real implica codificación por software, lo cual no es viable para videollamadas sostenidas.
Soporte de navegadores para AV1:
La valoración de Tsahi Levent-Levi, recogida en su sesión de diciembre de 2025 con WebRTC.ventures, es la declaración pública más clara sobre dónde está AV1 para conferencia: "AV1 no será el códec dominante en 2026, y puede que necesite hasta cerca de 2028 para alcanzar ese estatus, mientras VP8 y H.264 se mantienen fuertes". Su entrada de blog de enero de 2026 añade que muchos proveedores pueden encontrar que las implementaciones de códec resultan exigentes para los recursos del dispositivo.
Cuándo tiene sentido AV1 hoy: en pipelines de grabación y transcodificación VOD donde el coste de codificación se paga una sola vez; en entornos empresariales controlados donde puedes verificar que todos los extremos tienen codificadores AV1 por hardware; en compartición de pantalla en dispositivos compatibles, donde las herramientas adaptativas al contenido de AV1 destacan; y en escenarios con limitación de ancho de banda donde el dispositivo tiene soporte AV1 por hardware confirmado y el ahorro de ancho de banda justifica la complejidad de implementación.
La comparativa AV1 vs H.264 cambia mucho cuando el foco son las restricciones de tiempo real y no los benchmarks de streaming.
| VP8 | H.264 | VP9 | AV1 | |
|---|---|---|---|---|
| Año de lanzamiento | 2010 | 2003 | 2013 | 2018 |
| Licencia | Libre de regalías | Patentada (Via Licensing Alliance) | Libre de regalías | Libre de regalías (solo miembros de AOMedia; bajo litigio de no miembros) |
| Velocidad de codificación en tiempo real | Muy rápida | Rápida | Lenta (SW) | Muy lenta (SW) |
| Disponibilidad de codificador HW | Escasa | Universal | Limitada en móvil | Solo escritorio/M5+ |
| Eficiencia de compresión | La más baja | Moderada | Buena | La mejor |
| Bitrate aproximado para 1080p (buena calidad) | 4500-6000 kbps | 4000-5000 kbps | 2400-3200 kbps | 1800-2200 kbps |
| Soporte en Chrome | Completo | Completo | Completo | Depende del HW |
| Soporte en Firefox | Completo | Completo | Completo | Codificación RT limitada |
| Soporte en Safari/iOS | Completo (WebRTC) | Completo (preferido) | Solo descodificación | Experimental (HW nuevo) |
| Complejidad en la SFU | Baja | Baja | Media | Alta |
| Mejor para videoconferencia | Máxima compatibilidad | Usuarios Apple / fallback | Ahorro de ancho de banda | Grabación / futuro |
| Estado en WebRTC de producción | Ampliamente desplegado | Ampliamente desplegado | Adopción parcial | Experimental / emergente |
Antes de ver cómo interactúan estos códecs en una SFU real, conviene cubrir los que aparecen con frecuencia en artículos comparativos pero que en la práctica no pueden ser hoy tu códec principal de conferencia.
H.265 (HEVC, High Efficiency Video Coding): excelente compresión, comparable a VP9 y mejor que H.264, con soporte maduro de codificadores por hardware. La situación de licencias de patentes está fragmentada: tres grupos de patentes separados (MPEG LA vía Via Licensing Alliance, HEVC Advance y Velos Media) reclaman regalías, lo que supone un riesgo comercial significativo y ha mantenido históricamente a H.265 fuera de Chrome y Firefox. Chrome 136 (mediados de 2025) sí añadió soporte WebRTC para H.265 por defecto en Windows, macOS y Android, sujeto a la disponibilidad de hardware, así que H.265 ya no es solo cosa de Safari para WebRTC. Firefox, sin embargo, sigue sin soportar H.265 en WebRTC. La conclusión para la mayoría de equipos es la misma: el grupo de patentes fragmentado sigue siendo una barrera real, y la ausencia de soporte en Firefox hace que H.265 sea impracticable para conferencia multiplataforma general. El Vision Pro de Apple usa H.265 para vídeo espacial, lo que puede extender su relevancia en contextos empresariales específicos del ecosistema Apple.
H.266 (VVC, Versatile Video Coding): ofrece incluso mejor compresión que AV1 en algunos benchmarks, y tiene una situación de patentes aún más complicada que HEVC. Cero soporte de navegador para WebRTC. No es relevante para plataformas de videoconferencia en 2026 ni en el futuro previsible. (Este es además el códec al que Qualcomm ha declarado que dirigirá su futura codificación por hardware móvil, en lugar de AV1.)
AV2: el sucesor planificado de la Alliance for Open Media para AV1, diseñado para mejorar la compresión de AV1 manteniendo la licencia libre de regalías. Todavía en fase inicial de especificación a fecha de 2026. Sin plazo de producción. Conviene observarlo a partir de 2028 o 2029 como muy pronto.
LCEVC (Low Complexity Enhancement Video Coding): un estándar MPEG que funciona como capa de mejora sobre un códec base existente, ya sea VP8, H.264, VP9 o AV1. Reclama una mejora de compresión de aproximadamente un 40 por ciento sobre cualquier códec base, con poco coste adicional de codificación. Es un planteamiento arquitectónico interesante porque esquiva el problema de "a qué códec cambiar" y puede mejorar la eficiencia sobre los códecs existentes sin reemplazarlos. Aún está en una fase temprana para su adopción en WebRTC, pero merece la pena seguirlo como vía hacia una mejor compresión que no obliga a abandonar la infraestructura de H.264 o VP8.
Las características de cada códec por separado cuentan parte de la historia. Cómo interactúan en una arquitectura de conferencia multipartícipe basada en SFU es donde vive la complejidad de ingeniería real.
Negociación del códec en WebRTC: cuando un navegador establece una conexión WebRTC envía una oferta SDP que enumera los códecs soportados en orden de preferencia. La SFU o el par selecciona el códec de mayor prioridad que ambos lados soporten. No eliges el códec que quieres usar: te toca el códec que la negociación produce. Esto significa que el problema multinavegador no es una preocupación teórica: es lo que tu SFU gestiona en cada llamada.
El problema Chrome-y-Safari: un usuario en Chrome (que prefiere VP8 o VP9 para WebRTC) y un usuario en Safari (que prefiere H.264) que se unen a la misma sesión generan un desajuste en la negociación. Sin transcodificación en servidor, que añade latencia, coste y complejidad, la SFU debe enrutar al mínimo común denominador (H.264, que ambos soportan) o transcodificar selectivamente para participantes concretos. La mayoría de SFU en producción gestiona esto soportando H.264 como fallback universal.
Simulcast e interacción de códecs: el simulcast, en el que un cliente envía varias capas de resolución del mismo flujo, depende del códec. VP8 y VP9 soportan capas de escalabilidad temporal. H.264 tiene extensiones SVC que no están ampliamente implementadas en los navegadores. AV1 tiene soporte nativo SVC (Scalable Video Coding) en las tres dimensiones (espacial, temporal y de calidad), lo que queda bien sobre el papel, pero solo en dispositivos que realmente pueden asumir el coste de codificación AV1.
La arquitectura de enrutamiento: la SFU de Digital Samba, basada en Janus, enruta flujos de medios cifrados directamente entre participantes sin descodificar ni mezclar en la ruta de medios. Eso mantiene la latencia baja y la arquitectura limpia. El contrapunto es que cada códec adicional que soporta tu SFU añade coste operativo: rutas de fallback de códec, renegociación cuando un participante se une a mitad de llamada en un navegador distinto y tiempo de ingeniería para probar y mantener cada combinación en la matriz de dispositivos.
Algunas plataformas absorben esa complejidad para perseguir ganancias de eficiencia por códec. Otras, entre ellas Digital Samba, adoptan la postura opuesta: elegir el único códec que funciona de forma fiable en todos los navegadores sin transcodificación en servidor ni renegociación a mitad de sesión, e invertir el esfuerzo de ingeniería en calidad de llamada, funciones de IA y fiabilidad. Ambas son opciones legítimas en producción. La respuesta correcta depende de si tu cuello de botella es el ancho de banda o la capacidad de ingeniería.
El mejor códec para videoconferencia es el que ofrece calidad aceptable en todos los navegadores y dispositivos que tus usuarios tienen realmente, no el que gana benchmarks en hardware de referencia.
Digital Samba ejecuta una pila en tiempo real deliberadamente solo con VP8. Safari ha soportado VP8 para WebRTC desde Safari 12.1 (2019), Chrome, Firefox y Edge lo soportan de forma nativa, y ese único códec cubre todas las combinaciones de navegador que las sesiones de Digital Samba encuentran en la práctica. Este es el razonamiento:
Paso 1: Revisa tu base de usuarios, pero no des por hecho que los usuarios de Apple te obligan a usar H.264. Safari soporta VP8 para WebRTC desde 2019, así que una pila solo con VP8 funciona en Chrome, Firefox, Edge y Safari sin transcodificación en servidor. H.264 merece añadirse si quieres alinearte con el códec preferido de Safari para ganancias marginales de calidad, o si quieres específicamente que los codificadores H.264 por hardware de Apple Silicon hagan el trabajo. Es una decisión contra complejidad de ingeniería, no un requisito duro.
Paso 2: Evalúa tu códec actual. ¿Estás corriendo VP8 y la calidad es aceptable para tus usuarios? No cambies solo porque un blog te diga que AV1 es mejor. Cambiar de códec cuesta esfuerzo de ingeniería real: trabajo de migración, pruebas en combinaciones de dispositivo y navegador y posible gestión de regresiones. Invierte ese esfuerzo donde genere valor visible para el usuario.
Paso 3: Evalúa las restricciones de ancho de banda. ¿Estás pagando costes significativos de CDN o ancho de banda? Considera VP9 para pipelines de grabación/VOD donde el coste de codificar una sola vez se justifica por el ahorro de compresión a escala. Considera AV1 para transcodificación de archivo donde estás optimizando costes de almacenamiento a largo plazo.
Paso 4: Revisa el hardware objetivo. ¿Puedes verificar que una parte significativa de tus extremos tiene codificadores AV1 por hardware? Si es así y dispones de recursos de ingeniería, hacer un piloto de AV1 en un despliegue controlado merece la pena ahora. Si tus usuarios están en hardware de consumo general o en móviles, espera. La codificación AV1 por software hará más daño que beneficio.
Paso 5: Vigila el calendario del hardware. La codificación AV1 por hardware probablemente sea estándar en hardware PC y Apple aproximadamente entre 2027 y 2028. Ese es el momento en que las cuentas cambian para videoconferencia en tiempo real en esas plataformas. Para bases de usuarios con peso en Android, el panorama es menos seguro dada la intención declarada de Qualcomm de saltarse del todo la codificación AV1. Pon un punto de revisión para retomar la decisión sobre AV1 en ese momento y considera la mezcla de dispositivos de tu plataforma cuando lo hagas.
Una nota sobre LCEVC: si quieres una compresión significativamente mejor sin cambiar de códec base, mantén un ojo en LCEVC como vía alternativa. No está listo para producción en WebRTC en 2026, pero podría ser una opción de mejora práctica para plataformas que no están preparadas para migrar a VP9 o AV1.
El códec que deberías usar en 2026 depende casi por completo de los dispositivos y navegadores que tienen tus usuarios, no de qué códec gana el último benchmark de compresión.
Si estás corriendo VP8 y tus usuarios están contentos con la calidad, es una opción de producción legítima que millones de sesiones validan cada día. ¿Costes de ancho de banda significativos o una base de usuarios centrada en Chrome? VP9 para grabación y conexiones de alta calidad es el siguiente paso práctico. Si tienes usuarios Apple, hay dos vías legítimas: añadir H.264 para alinearte con el códec preferido de Safari y ganar calidad marginal, o quedarte en VP8 (que Safari soporta desde 2019) y ahorrarte el esfuerzo de ingeniería que consumiría la funcionalidad de fallback de códec. Y si estás planificando para 2027 a 2028, que es cuando Tsahi Levent-Levi y la comunidad WebRTC en general esperan que la codificación AV1 por hardware sea mayoritaria en plataformas PC y Apple, el momento de empezar a evaluar AV1 en entornos controlados es ahora. Eso sí, no pierdas de vista los litigios de patentes mientras planificas. El estatus libre de regalías de AV1 está siendo puesto a prueba en los tribunales, y conviene mantener una conversación con asesoría legal antes de comprometerse.
El mejor códec para videoconferencia no es un códec. Es una pila negociada, y entender los compromisos de cada opción es la forma de construir una plataforma que funcione para todos los usuarios que realmente tienes.
Descubre cómo Digital Samba gestiona la calidad de vídeo multiplataforma: digitalsamba.com/es/features
Explora la arquitectura de DS en detalle: docs.digitalsamba.com/reference