Cualquier ingeniero que haya construido un sistema de streaming en directo acaba teniendo la misma conversación incómoda con su equipo de producto: "Podemos tener latencia inferior a un segundo, o podemos tener millones de espectadores simultáneos. Elige una".

Este es el trilema del streaming, el equilibrio a tres bandas entre latencia, escala y simplicidad arquitectónica que ha condicionado la distribución de medios en directo durante buena parte de las dos últimas décadas. WebRTC nos dio la velocidad de una videollamada pero se desmorona ante el fan-out a escala de broadcast. HLS y DASH nos dieron distribución global pero castigan al espectador con retardos de 5–30 segundos. Cada nuevo protocolo que llegó después, como SRT, RTMP o LL-HLS, parcheó un lado del triángulo a la vez que empeoraba discretamente los otros.

Media over QUIC (MoQ) es el intento del IETF de colapsar ese triángulo por completo. Es un protocolo de transporte pub/sub construido sobre QUIC (la misma base que HTTP/3) y diseñado desde cero para entregar latencia inferior a un segundo a escala de CDN, sin la complejidad arquitectónica que ha hecho doloroso desplegar WebRTC a volúmenes de broadcast. Si lo conseguirá sigue siendo una pregunta abierta, pero las organizaciones que están apostando por él, por ejemplo Cloudflare, Google, Meta, Cisco o Akamai, sugieren que esto no es otro experimento de protocolo de nicho.

Este es un análisis a fondo de qué es MoQ, cómo se compara con los protocolos que podría llegar a sustituir, quién lo está construyendo y cuál es el panorama de madurez para producción en abril de 2026.

Índice de contenidos

1. El trilema del streaming
2. ¿Qué es Media over QUIC?
3. MoQ vs WebRTC: coexistencia, no sustitución
4. ¿Quién está construyendo MoQ?
5. Estado de madurez para producción
6. Qué significa MoQ para las plataformas de vídeo
7. FAQ

El trilema del streaming

Para entender por qué MoQ importa, ayuda entender el problema que está resolviendo y por qué cada solución anterior ha exigido un compromiso incómodo.

WebRTC: tiempo real, pero no realmente escalable

WebRTC se diseñó para videoconferencia. Entrega latencia inferior a 100 ms a través de conexiones directas peer-to-peer usando flujos RTP sobre UDP. Para una llamada de dos personas o una reunión de grupo pequeño, esta es exactamente la arquitectura correcta.

El problema es que el modelo peer-to-peer de WebRTC no escala a broadcast. Cuando 100 000 personas se conectan a un evento en directo, no puedes establecer 100 000 conexiones peer individuales desde el emisor. Las Selective Forwarding Units (SFU) ayudan al retransmitir flujos en servidor, pero incluso las arquitecturas basadas en SFU requieren una gestión de estado por conexión significativa, lo que hace el fan-out a gran escala caro, operativamente complejo y propenso a fallos en cascada ante picos de carga inesperados.

WebRTC también arrastra una sobrecarga de conexión considerable: negociación ICE, traversal STUN/TURN, handshake DTLS y una capa de señalización que debe ejecutarse antes de que un solo fotograma de medio llegue al espectador. Esta maquinaria es apropiada para conferencia, donde la comunicación bidireccional justifica la complejidad. Para streaming en directo uno-a-muchos es una sobrecarga importante para un caso de uso que no la necesita.

HLS y DASH: escalables, pero lentos

HTTP Live Streaming de Apple y MPEG-DASH resolvieron el problema de la escalabilidad con elegancia. Al codificar el vídeo en segmentos cortos y entregarlos sobre HTTP, estos protocolos aprovecharon la infraestructura CDN global que ya existía para contenido web. Un directo sobre HLS puede servir a millones de espectadores simultáneos sin más infraestructura especial que una CDN estándar.

El coste es la latencia. HLS clásico opera con una latencia de 20–45 segundos. Low-Latency HLS (LL-HLS) y Low-Latency DASH mejoraron esto bastante (hasta aproximadamente 2–4 segundos en condiciones ideales), pero conseguirlo en la práctica requiere ajustar con cuidado la duración del segmento, la configuración de la CDN y el comportamiento de buffering del reproductor. El modelo de polling inherente a HTTP obliga a los reproductores a pedir segmentos nuevos una y otra vez, lo que introduce sobrecarga de round-trip que hace prácticamente imposible la entrega sub-segundo.

MoQ vs HLS: por qué esta comparación importa

El planteamiento MoQ vs HLS es donde lo que está en juego queda más claro. La escala de HLS es real y está probada. La pregunta que MoQ responde es: ¿puedes tener esa escala sin la penalización de latencia? La evidencia temprana sugiere que sí, pero con la salvedad importante de que la madurez de ecosistema de HLS (un estándar con una década de existencia y soporte universal en herramientas) no es algo que MoQ pueda replicar de la noche a la mañana.

¿Qué es Media over QUIC?

Media over QUIC es un protocolo de transporte publish-subscribe que está desarrollando el grupo de trabajo MoQ del IETF. La última versión publicada de la especificación principal de transporte, draft-ietf-moq-transport-17, se publicó el 2 de marzo de 2026, con coeditores de Cisco, Google y Meta.

La base QUIC

QUIC es un protocolo de transporte multiplexado y cifrado desarrollado originalmente por Google y estandarizado ahora como RFC 9000. Opera sobre UDP evitando el bloqueo de cabeza de línea de TCP y, al mismo tiempo, proporciona la fiabilidad, el orden y el control de congestión que las aplicaciones necesitan. HTTP/3 funciona sobre QUIC, lo que significa que el protocolo ya sustenta una parte significativa del tráfico web global.

Las propiedades del protocolo de streaming QUIC que lo hacen atractivo para medios son:

• Flujos multiplexados con entrega independiente: un paquete perdido en un flujo no bloquea la entrega en otros, a diferencia de TCP
• Fiabilidad parcial: QUIC se puede configurar para descartar datos en lugar de retransmitirlos, lo cual es el equilibrio correcto para medios en directo, donde un fotograma desactualizado es peor que uno perdido
• Cifrado integrado: TLS 1.3 está incorporado en QUIC a nivel de transporte, no añadido encima
• Migración de conexiones: las conexiones QUIC sobreviven a cambios de dirección IP, algo que importa para clientes móviles

El modelo pub/sub y la arquitectura de relays

La capa de transporte MOQT se sitúa por encima de QUIC (o de WebTransport, en entornos de navegador) y define un modelo publish-subscribe para la entrega de medios. En lugar del modelo petición-respuesta de HTTP o del modelo peer-to-peer de WebRTC, MOQT usa una arquitectura construida en torno a publishers, subscribers y relays.

Un publisher (el codificador en directo o el emisor) se conecta a un relay y publica tracks. Los subscribers (espectadores) se conectan a relays y se suscriben a tracks. La red de relays se encarga del fan-out: un único flujo publicado puede distribuirse a cualquier número de subscribers sin que el publisher tenga que mantener conexiones individuales con cada uno.

Este modelo de red de relays MoQ es arquitectónicamente análogo a cómo las CDN distribuyen contenido HTTP (los nodos edge se suscriben a contenido de nodos de origen bajo demanda), pero opera a nivel de transporte y no de HTTP, con los beneficios de latencia que eso implica.

Tracks, grupos y objetos

MOQT define un modelo de datos de tres niveles:

Objetos: son la unidad base, secuencias arbitrarias de bytes con cabeceras que contienen metadatos. Un fotograma de vídeo, un segmento de audio, una pista de subtítulos o cualquier otra pieza de datos alineada en el tiempo es un objeto.

Grupos: son secuencias ordenadas de objetos, normalmente delimitadas por fotogramas clave de vídeo (I-frames). Un grupo puede decodificarse de forma independiente, así que suscribirse a un flujo a mitad de emisión significa empezar desde el siguiente límite de grupo, no esperar al inicio de la transmisión.

Tracks: son colecciones de grupos de un único publisher. Una pista de vídeo, una pista de audio y una pista de subtítulos pueden suscribirse por separado, priorizarse de forma distinta y descartarse de forma independiente cuando la red lo exige.

Agnosticismo respecto al medio

Una aclaración importante en el último borrador: a pesar de su nombre, MOQT es explícitamente agnóstico respecto al medio. Como dice la especificación, "se puede usar para una amplia variedad de casos de uso" más allá del vídeo. Hay investigadores explorando ya MOQT como transporte para Model Context Protocol (MCP) en comunicaciones entre agentes de IA, lo que demuestra que la arquitectura pub/sub generaliza bien más allá del streaming en directo.

MoQ vs WebRTC: coexistencia, no sustitución

La conversación MoQ vs WebRTC es uno de los debates más habituales y peor planteados en ingeniería de streaming ahora mismo. Respuesta corta: resuelven problemas distintos, y la arquitectura correcta para la mayoría de plataformas en 2026 usa ambos.

WebRTC sigue siendo la opción inequívoca para comunicación bidireccional en tiempo real: conferencia, plataformas de entrevistas, herramientas colaborativas y voz con IA. Su soporte en navegadores es universal y su stack de medios (negociación de códecs, cancelación de eco, estimación de ancho de banda) gestiona automáticamente la complejidad de la comunicación interactiva.

La ventaja de MoQ aparece cuando el caso de uso es distribución y no conversación. Un emisor deportivo retransmitiendo a 500 000 espectadores simultáneos no necesita la sobrecarga bidireccional de WebRTC. Lo que necesita es latencia sub-segundo a escala de CDN, que es exactamente el problema que aborda la arquitectura de relays de MoQ.

La arquitectura híbrida a la que llegarán la mayoría de plataformas de streaming: WebRTC para la capa interactiva (panelistas, comentaristas, herramientas de emisión), MoQ para la capa de distribución (la audiencia que ve pero no participa). Esto no es una sustitución de suma cero, sino un stack complementario donde cada protocolo opera en su dominio de ventaja.

¿Quién está construyendo MoQ?

IETF MoQ 2026 no es un proyecto de investigación. Las organizaciones que están construyendo infraestructura MoQ en producción representan una parte significativa del tráfico global de internet.

Cloudflare: la primera CDN MoQ

En agosto de 2025, Cloudflare lanzó lo que describió como la primera red de relays MoQ en producción, funcionando sobre su infraestructura global en más de 330 ciudades. Cada servidor de Cloudflare es ahora un relay MoQ, así que no es un despliegue de prueba, sino infraestructura de producción a la misma escala que los servicios existentes de Cloudflare.

La implementación, moq-rs, es de código abierto y compatible con múltiples publishers, players y herramientas del ecosistema MoQ. Cloudflare también ha sido un contribuyente activo en el IETF, con ingenieros que han coescrito borradores de internet (Internet-Drafts) sobre mitigación de denegación de servicio en relays y provisión de CDN para MoQ.

OpenMOQ Software Consortium

Fundado por Red5, Akamai, CDN77, Cisco, Synamedia y YouTube, el OpenMOQ Software Consortium es el organismo de la industria que coordina el trabajo de implementación MoQ en código abierto. A abril de 2026, el Consortium ha completado su gobernanza, ha establecido una hoja de ruta técnica y ha entrado en la fase de desarrollo de infraestructura básica.

Once proveedores (Ant Media, AWS, Bitmovin, Broadpeak, CacheFly, Cloudflare, Nomad Media, Oracle, Norsk, Synamedia y Red5) demostraron sus primeras implementaciones MoQ en NAB Show 2026 en Las Vegas, en la mayor demostración coordinada de interoperabilidad MoQ hasta la fecha.

Oracle OCI: MoQ empresarial en el edge

La plataforma Oracle Video @ Edge (OVE) de Oracle funciona como una red de relays MOQT para flujos de trabajo de medios empresariales. En NAB Show 2026, Oracle demostró flujos MoQ multi-partner que integraban Ateme (codificación), Broadpeak (empaquetado) y Cloudflare (distribución CDN), conectados a través de una infraestructura compartida de relays MOQT. OVE actúa como capa de coordinación, gestionando el ciclo de vida de la sesión, el enrutamiento y la telemetría en un pipeline de streaming multi-proveedor.

Google y Meta: coautores en el IETF

Los ingenieros Ian Swett (Google) y Alan Frindell (Meta) figuran como editores de la especificación principal de MOQT. Esto no es respaldo pasivo: los editores son responsables de la dirección técnica del borrador y de resolver los problemas de implementación que plantea el grupo de trabajo. Ambas empresas tienen implementaciones MoQ que participan en pruebas de interoperabilidad.

moq.dev: Rust y TypeScript de código abierto

El proyecto moq.dev mantiene librerías MoQ de código abierto en Rust y TypeScript con APIs equivalentes. El proyecto incluye moq-lite (el subconjunto simplificado de transporte), hang (abstracciones de codificación y streaming específicas de medios) e infraestructura de relays. La demo hang.live ejecuta un flujo MoQ público en directo que muestra latencia sub-segundo en un navegador sin necesidad de plugins.

Estado de madurez para producción

Dónde está realmente MoQ en abril de 2026

Valoración honesta: MoQ está listo para producción en despliegues controlados, cargas experimentales de primeros adoptantes y pipelines de ingest. Aún no está listo para despliegues de cara al consumidor que requieran compatibilidad universal con navegadores y una gestión pulida de fallbacks, pero esa brecha se está cerrando más rápido de lo que la mayoría esperaba.

WebTransport llega a Baseline

La dependencia de infraestructura crítica para MoQ en navegadores es WebTransport, la API del W3C que expone las capacidades de QUIC a las aplicaciones del navegador. A marzo de 2026, Safari 26.4 envió WebTransport de serie, sumándose a Chrome, Firefox y Edge. Eso cruzó el umbral de "Baseline", la designación que la web platform usa para funciones seguras para producción en todos los navegadores principales.

Es un punto de inflexión importante. Hasta marzo de 2026, la ausencia de Safari en WebTransport significaba que cada dispositivo iOS y cada usuario de Safari quedaba excluido de las aplicaciones web basadas en MoQ. Esa restricción ya no existe.

El reto de la incompatibilidad entre drafts

La especificación de transporte ha pasado por varias revisiones, y las implementaciones escritas contra draft-14 o draft-15 pueden no interoperar bien con draft-17. Esto es el típico "lío del medio" en la estandarización del IETF. Las organizaciones que construyen sobre MoQ hoy aceptan cierto riesgo de bloqueo por versión a cambio de ventaja de primer movimiento. Se espera que la especificación llegue a RFC en 2027 o 2028, momento en el que el problema de incompatibilidad pasará a ser histórico.

La pregunta de la adopción

También hay una contranarrativa que conviene tomar en serio. En un análisis de mayo de 2026, Tsahi Levent-Levi (BlogGeek.me) argumentó que MoQ está mostrando las señales clásicas de un protocolo empujado por proveedores y no tirado por clientes: pese a la red de relays de Cloudflare en más de 330 ciudades, ningún broadcaster de referencia ni plataforma de consumo se ha nombrado públicamente todavía como cliente final, y la pregunta empresarial típica sigue siendo si es demasiado pronto para empezar a mirar MoQ, no cuándo migrar.

El caso pesimista descansa sobre tres puntos concretos. Primero, MoQ no es una actualización transparente como sí lo fue HTTP/3. HTTP/3 se desplegó de forma invisible porque la capa de aplicación no cambió; MoQ requiere reescribir reproductores, retocar codificadores y hacer ajustes operativos que necesitan un detonante comercial claro. Segundo, la superficie del protocolo sigue siendo fragmentaria, con propuestas competidoras de formato de medios (WARP, LOC, CMSF, MSF), lo que significa que, incluso entre proveedores de acuerdo sobre el transporte, todavía no hay acuerdo sobre qué corre por encima, y la publicación del RFC del transporte principal se proyecta de forma realista para finales de 2027 o mediados de 2028. Tercero, MoQ compite contra incumbentes cuya infraestructura está amortizada, cuyas cadenas de herramientas son maduras y cuyos ingenieros son fáciles de contratar. A diferencia de WebRTC, que habilitó un caso de uso (videollamada nativa en el navegador) que antes no existía, MoQ propone mejoras arquitectónicas sobre casos de uso que ya tienen soluciones funcionales, y ese es un caso comercial más difícil de defender.

Nada de esto es un argumento de que MoQ vaya a fracasar. El protocolo es sólido, el grupo de trabajo es serio y la infraestructura de relays es real. Pero el plazo entre "existe una red de relays de calidad producción" y "una parte significativa del tráfico de streaming en directo corre realmente sobre ella" es probable que se mida en años, no en trimestres. Para las plataformas que están evaluando MoQ hoy, esto refuerza el consejo práctico en lugar de invalidarlo: construye familiaridad ahora, haz prototipos contra las redes de relays disponibles, pero no apuestes una hoja de ruta de producto de 2027 a un despliegue masivo de MoQ que el mercado todavía no ha validado.

moq-lite: el camino pragmático al despliegue

moq-lite es un subconjunto simplificado y compatible hacia delante de la especificación completa de MOQT, desarrollado por Luke Curley (anteriormente en Twitch y Discord) y usado por el proyecto moq.dev. Quita las funciones que han sido polémicas o lentas de estabilizar en el grupo de trabajo, dejando una API pub/sub limpia que funciona con cualquier CDN MoQ.

Como dice la documentación de moq.dev: "Los principios detrás de MoQ son fantásticos, pero los estándares son lentos e implican demasiada discusión/relleno". moq-lite es la respuesta pragmática: un subconjunto compatible hacia delante con MOQT completo (draft-14 y superiores) y desplegable hoy, sin esperar a que cada caso límite de la especificación se resuelva.

La implementación de moq-lite en Rust está disponible en crates.io. La implementación en TypeScript apunta a navegadores vía WebTransport. Ambas comparten APIs equivalentes, lo que significa que la infraestructura de relays puede compartirse entre componentes del lado servidor y del lado navegador.

Qué significa MoQ para las plataformas de vídeo

Para plataformas que unen conferencia y broadcast (herramientas de reuniones de vídeo que ofrecen streaming en directo, plataformas de eventos o soluciones híbridas conferencia-a-audiencia), MoQ representa una oportunidad arquitectónica relevante.

La arquitectura híbrida

El patrón de despliegue más probable para plataformas con componentes tanto interactivos como de broadcast es un stack híbrido:

• WebRTC gestiona la capa interactiva de la sesión: vídeo, audio, compartición de pantalla de los participantes y comunicación bidireccional entre ponentes y moderadores
• MoQ gestiona la capa de distribución: toma la salida mixta de la sesión de conferencia y la distribuye a escala de broadcast a audiencias que ven pero no participan

Esto es arquitectónicamente limpio porque WebRTC y MoQ abordan puntos diferentes del pipeline. La SFU que gestiona la conferencia WebRTC puede publicar un flujo compuesto en una red de relays MoQ, que luego lo reparte a las audiencias sin que la SFU tenga que gestionar conexiones por espectador.

Restreaming e ingest MoQ

Para plataformas que ofrecen restreaming (la capacidad de empujar simultáneamente un directo a múltiples destinos como YouTube, Twitch o un endpoint RTMP personalizado), el modelo de ingest de MoQ es relevante. El ingest MoQ tiene menos sobrecarga que RTMP para el publisher y es más sencillo de implementar que el ingest WebRTC, sin la negociación de peer connection. A medida que el soporte para MoQ llega a herramientas de emisión como OBS (los plugins de GStreamer ya están en desarrollo), la ruta ingest-a-relay se convierte en una alternativa natural a los flujos de restreaming basados en RTMP.

La cuestión del momento

Para los equipos de ingeniería y arquitectura de streaming que evalúan dónde invertir en 2026: merece la pena construir familiaridad con MoQ y dedicar inversión a prototipos ahora. La especificación es lo suficientemente estable para evaluarla, la infraestructura de relays (Cloudflare, OCI) es de calidad producción y el ecosistema de implementaciones es lo bastante amplio para desarrollar contra él.

El despliegue universal de cara al consumidor (el escenario en el que envías MoQ a los usuarios finales sin fallback a WebRTC o HLS) es una historia de 2027–2028 como muy pronto, sujeta a la publicación del RFC y a un soporte más amplio en la cadena de herramientas. La ventana para una adopción temprana sin riesgo se está estrechando.

Diagrama de arquitectura

FAQ

¿Sustituirá MoQ a WebRTC para videoconferencia?

No, y esta es una distinción importante. WebRTC y MoQ están diseñados para casos de uso distintos que solo se solapan parcialmente. WebRTC está optimizado para comunicación bidireccional en tiempo real: conferencia, llamadas de voz, herramientas colaborativas. Su stack ICE/DTLS/STUN, aunque complejo, gestiona el traversal NAT y el establecimiento de conexiones peer que la comunicación interactiva requiere. MoQ es un protocolo de distribución publish-subscribe, fundamentalmente unidireccional en su modelo pub/sub y optimizado para fan-out a audiencias grandes. Las arquitecturas en las que MoQ desplazará a WebRTC son aquellas en las que se estaba forzando a WebRTC a hacer distribución broadcast, como entrega uno-a-muchos sirviendo audiencias a escala mediante cascadas de SFU. Para conferencia real, WebRTC seguirá siendo la elección correcta en el futuro previsible.

¿Qué empresas tienen despliegues de MoQ en producción?

A abril de 2026, Cloudflare tiene el mayor despliegue conocido de MoQ en producción: una red de relays en más de 330 ciudades funcionando sobre la misma infraestructura que sus servicios CDN existentes. WINK Streaming tiene una implementación MoQ en producción para MediaMTX que alcanza 200-300 ms de latencia, desplegada actualmente en redes de cámaras de tráfico gubernamentales y sistemas de seguridad pública. nanocosmos lanzó soporte MoQ en su plataforma nanoStream en IBC 2025. Oracle tiene un servicio de relays MoQ en producción en Oracle Video @ Edge (OVE). Red5 tiene una oferta beta de MoQ construida sobre infraestructura OCI en colaboración con CacheFly. Once proveedores demostraron implementaciones interoperables de MoQ en NAB Show 2026.

¿Qué es el OpenMOQ Software Consortium?

El OpenMOQ Software Consortium es un organismo industrial fundado para desarrollar infraestructura MoQ de código abierto y alto rendimiento, apta para despliegue real en producción. Sus miembros fundadores incluyen Red5, Akamai, CDN77, Cisco, Synamedia, Oracle y YouTube (Google). Entre los miembros académicos están la Universität Klagenfurt y la Özyeğin University. Con su gobernanza y hoja de ruta técnica ya en marcha, el Consortium se centra ahora en construir implementaciones de relays y reproductores de código abierto que permitan a la industria desplegar MoQ sin dependencia de soluciones propietarias.

¿Está MoQ listo para uso en producción en 2026?

Depende del caso de uso. Para despliegues empresariales controlados, flujos de ingest servidor-a-servidor y aplicaciones donde controlas el entorno del navegador, MoQ es desplegable hoy: la red de relays de Cloudflare es infraestructura de calidad producción. Para aplicaciones de cara al consumidor en broadcast que requieren compatibilidad universal con navegadores, el panorama mejoró bastante en marzo de 2026 cuando Safari envió WebTransport y cruzó el umbral Baseline. Sin embargo, la especificación de transporte sigue en draft-17 y no se ha publicado todavía como RFC, lo que significa que las implementaciones pueden requerir actualizaciones a medida que se finalice. Valoración honesta: el despliegue experimental en producción es viable ahora; el despliegue universal de cara al consumidor es una historia de 2027-2028.

¿Cuál es la diferencia entre MoQ y WebRTC?

MoQ (concretamente el transporte MOQT) y WebRTC difieren a nivel arquitectónico. WebRTC es un framework completo para comunicación peer-to-peer en tiempo real, que incluye stack de medios (códecs, cancelación de eco, estimación de ancho de banda), modelo de señalización y arquitectura de seguridad (DTLS-SRTP). MoQ es un protocolo de transporte, una primitiva de más bajo nivel para publicar y suscribirse a tracks de medios mediante redes de relays. WebRTC requiere infraestructura ICE/STUN/TURN y una capa de señalización antes de que fluya cualquier medio; MoQ establece conexiones con menos sobrecarga gracias a la capacidad 0-RTT de QUIC. WebRTC escala vía SFU con gestión de estado por conexión; MoQ escala vía árboles de relays con caché compartida y suscripción pull-through. Para conferencia interactiva: WebRTC. Para broadcast escalable de baja latencia: MoQ.

Conclusión

Dos décadas de ingeniería de streaming han producido un panorama fragmentado: un protocolo para comunicación en tiempo real, otro para distribución a broadcast, un tercero para ingest y un stack creciente de configuraciones de CDN, clústeres de SFU y servidores TURN para sostenerlo todo.

MoQ es un intento de reconstruir sobre una base más limpia: un único protocolo de transporte, asentado en QUIC, capaz de cubrir todo el espectro latencia-escala sin requerir arquitecturas separadas para cada punto. El protocolo MoQ explicado en su forma más simple: entrega de medios pub/sub sobre QUIC, con un modelo de relays que escala como una CDN y una latencia que se acerca a WebRTC.

El ecosistema es real, la infraestructura de relays es de calidad producción y el soporte en navegadores ha cruzado a territorio Baseline. Lo que queda es la publicación del RFC, la maduración de la cadena de herramientas y la clase de experiencia de despliegue amplia que convierte un protocolo prometedor en un estándar de industria.

Para los equipos de ingeniería de streaming: ahora es el momento adecuado para construir familiaridad con MoQ, hacer experimentos contra la red de relays de Cloudflare y diseñar arquitecturas híbridas. La ventana de producción se está abriendo.

→ Descubre las funciones de streaming de Digital Samba, incluida nuestra API de restreaming, que conecta con endpoints RTMP y de la que estamos siguiendo de cerca el soporte de ingest MoQ a medida que madure el ecosistema.