- Cloudflare presentó oficialmente el primer CDN basado en Media over QUIC (MoQ)
- MoQ es un nuevo estándar para la transmisión de medios en tiempo real, y se espera que reemplace a WebRTC, HLS/DASH y RTMP/SRT
- Por ahora está en fase de developer preview, y puede probarse con varios clientes y bibliotecas a través del endpoint público de Cloudflare
- Ya se ofrecen funciones de demostración como emisión y reproducción en vivo, además de subtítulos impulsados por IA, en la web y en clientes Rust
- Aún faltan funciones clave como autenticación, soporte para Safari y ANNOUNCE, y los desarrolladores interesados también pueden operar su propio relay de MoQ
Cloudflare lanza oficialmente el primer CDN de MoQ
Introducción
- Con el lanzamiento oficial de un CDN basado en el estándar Media over QUIC (MoQ) por parte de Cloudflare, se anticipa un cambio importante en el ámbito de la transmisión de medios en tiempo real
- MoQ está llamando la atención como un estándar de nueva generación capaz de reemplazar por completo a los protocolos existentes WebRTC, HLS/DASH y RTMP/SRT en la transmisión de medios en vivo como video y audio en tiempo real
- Este lanzamiento llega como un producto oficial que usuarios reales ya pueden probar directamente sobre la red Anycast global
- Cloudflare se convirtió en el primer proveedor de CDN de MoQ, y se espera que esta tecnología impulse innovación dentro del ecosistema de transmisión de medios en tiempo real
Funciones disponibles actualmente
- Esta tecnología está disponible como versión preview, por lo que la estabilidad del servicio y el alcance funcional siguen siendo limitados
- Cloudflare abrió el endpoint público
relay.cloudflare.mediaoverquic.com - Puede probarse mediante varias bibliotecas y clientes de código abierto, como los siguientes
- Con la demo web y las bibliotecas es posible emitir y ver transmisiones en vivo en tiempo real dentro del navegador
- Se está demostrando una función de procesamiento de subtítulos basada en IA
- Dentro del navegador se generan y transmiten subtítulos con tecnologías como [silero-vad], [whisper], [transformers.js], [onnxruntime-web] y [WebGPU]
- Además de una API con enfoque de Web Components, también se admite un uso más avanzado mediante JavaScript API
- También se ofrece un entorno para quienes prefieren no usar JavaScript, con una biblioteca en Rust para importar MP4, integración con ffmpeg y emisión/reproducción basada en gstreamer
Funciones aún no implementadas
- La versión actual solo admite un subconjunto limitado de Draft-07
- Principales funciones que todavía no están disponibles
- Sin autenticación para emisiones: es necesario asignar manualmente a cada emisión un nombre difícil de adivinar
- Sin soporte para ANNOUNCE: no existe detección de inicio o finalización de emisiones
- Sin soporte para el navegador Safari: no es compatible con Safari por problemas de soporte de WebTransport
- Optimización incompleta: la experiencia de usuario y otros aspectos se irán mejorando gradualmente
- Si es necesario, se puede desplegar una instancia propia de moq-relay para usar funciones avanzadas
- Se están desarrollando funciones adicionales como autenticación basada en JWT y fallback a WebSocket para Safari/TCP
- También es posible construir una red CDN global con el módulo de terraform
Qué significan MoQ y Cloudflare
- El trabajo de estandarización de MoQ lleva más de 3 años en marcha, y es probable que su adopción real a escala mundial todavía tome bastante tiempo
- Al lanzar rápidamente un producto real antes de la adopción del RFC, Cloudflare tomó una decisión audaz para obtener retroalimentación práctica de desarrolladores y usuarios
- La tecnología MoQ tiene el potencial de reemplazar a protocolos de medios existentes como WebRTC, HLS y RTMP
- Las discusiones sobre el borrador del estándar y los issues del código continuarán, pero se espera que la experiencia operativa real contribuya en gran medida a la evolución del estándar
- En el futuro, en el mercado de transmisión de medios basado en MoQ, empresas como Google, Akamai y Fastly también necesitarán desplegar código en sus propias redes y servidores para identificar necesidades reales
Planes futuros y comunidad
- Aún queda mucho trabajo para reimplementar WebRTC y los protocolos existentes con APIs web modernas
- No se debe evaluar a MoQ en su conjunto solo por el rendimiento o las funciones de esta etapa, y es importante participar activamente con pruebas y retroalimentación
- Más de 900 personas ya participan en la comunidad (Discord), donde se pueden hacer preguntas y proponer colaboraciones
1 comentarios
Opiniones de Hacker News
Probé la demo en https://moq.dev/publish/ y se siente realmente fluida. Muy impresionante. Y se agradece una tecnología tan buena. Pero al ver la demo de Big Buck Bunny en https://moq.dev/watch/?name=bbb desde mi celular, aparecen muchas líneas negras horizontales (curiosamente, en una PC conectada al mismo Wi‑Fi se ve normal). Me pregunto si será por el tamaño del búfer. Quisiera saber si se puede aumentar el búfer del lado del cliente o si eso tiene que configurarse en el servidor. Y también agradezco que no se hayan olvidado de South Korea en el mapa de CDN "global"
Me pregunto si esto solo funciona en Chrome. En Firefox para Android solo me aparece el mensaje de que el navegador no es compatible
No estoy muy seguro sobre el tema de las líneas negras horizontales. Renderizamos con un elemento <canvas>, redimensionamos para que coincida con el tamaño del video fuente, y luego CSS lo vuelve a redimensionar para ajustarlo al tamaño de la ventana
Al reproducirlo en Chrome en un OnePlus Ten, las líneas negras parpadean con frecuencia. Sobre todo bajando desde la parte superior de la pantalla hacia la esquina inferior derecha; quizá sea un artefacto de refresco de pantalla (rolling shutter effect)
Como en la página se menciona mucho código Rust y WASM, quizá el problema sea que el CPU del teléfono no puede ejecutar WASM lo suficientemente rápido. En mi Samsung S20 no veo ninguna línea negra
Lo probé en una mac book air m4 con conexión de 600mbps y la respuesta fue inmediata; me sorprendió mucho
Este post tiene una sección de "¿por qué debería importarte?", pero no explica qué beneficio aporta Media over QUIC para los publicadores de medios o los usuarios finales —es decir, las dos partes más importantes (y probablemente las únicas) en este intercambio—. Así que me pregunto por qué debería importarme esta tecnología
Fue error mío. Traté de evitar repetir cosas de posts anteriores del blog y por eso faltó explicación: https://moq.dev/blog/replacing-webrtc/ y, de hecho, MoQ es una tecnología que beneficia sobre todo a los desarrolladores. Los beneficios para otros son más bien indirectos, porque escalar o implementar funciones se vuelve mucho más fácil
La latencia de extremo a extremo (glass-to-glass) mejora bastante. Principalmente porque el protocolo ya no funciona en modo request/response
¡Hola! Soy desarrollador de Cloudflare MoQ, bienvenidas las preguntas. Y gracias por el premio, kixelated xD
Había una explicación que decía: "Sin bloqueo por head-of-line: a diferencia de TCP, los streams de QUIC son independientes. Aunque se pierda un paquete en un stream (por ejemplo, una pista de audio), las otras pistas (por ejemplo, la de video) no se bloquean. Esto elimina los cortes que siempre ocurrían en RTMP". Pero si la estructura es así, me pregunto: si hay pérdida de paquetes en la pista de audio y la de video sigue reproduciéndose sin detenerse, ¿no podría desincronizarse el audio y el video? Puede que no lo entienda bien porque no estoy familiarizado con la tecnología
Tengo una pregunta. Me gustaría saber si hay planes concretos para reducir la brecha de goodput entre TCP y QUIC[1]. El paper enlazado dice que al pasar de HTTP/2 (TCP) a HTTP/3 (QUIC) observaron una caída de hasta 9.8% en el bitrate de video. Claro, MoQ tiene una estructura de stack algo distinta, así que no se puede generalizar directamente, pero parece posible que haya un problema similar. (En lo personal, en los últimos meses estuve investigando el datapath AF_XDP de MsQuic como parte de mi tesis de maestría. Al final me quedó la impresión de que GSO/GRO es una mejor alternativa y que QUIC definitivamente necesita más offload por hardware :p)
[1]: https://arxiv.org/pdf/2310.09423
Tengo algunas dudas :)
Me pregunto qué tan cerca está QUIC de llegar al punto en que realmente pueda usarse en navegadores (con soporte tanto del navegador como de la infraestructura, a nivel de "simplemente funciona")
Y también me pregunto cómo resuelve QUIC el problema del NAT. En WebRTC, STUN/TURN es indispensable para atravesar full cone NAT, y en especial TURN es problemático porque hay que operar mucha infraestructura
Trabajo en streaming con WebRTC en getstream.io. WebRTC puede ser algo molesto de configurar, pero una vez que conecta, su punto fuerte es la baja latencia. Me interesa saber qué ventajas o problemas tiene MoQ después de que la conexión ya está establecida; es decir, cómo se siente en comparación con WebRTC
Me pregunto si el balanceo de carga de los relays queda fuera del alcance de MoQ. No parece que el post lo aborde
Me encanta este proyecto, y de vez en cuando también leo el blog de kixelated y lo sigo en Github.
Antes que nada, quiero felicitar tanto a kixelated como a Cloudflare por un trabajo tan genial.
Tengo curiosidad por el live streaming en tiempo real. Normalmente un live streaming tiene cientos o miles de espectadores simultáneos, así que quiero saber si en MoQ existe la posibilidad o la intención de usar o implementar multicast. Con HTTP/1.1 y HTTP/2 eso era difícil por estar basados en TCP, pero ahora que HTTP/3 usa UDP, me parece una idea más realista. Me interesa saber qué piensan. Tengo entendido que Akamai y la BBC también están investigando esto
¡No hace falta multicast! En la práctica, un CDN ya es básicamente una implementación de multicast en L7 (capa de aplicación). No hace falta que routers o ISP lo implementen directamente en L3. Eso fue precisamente a lo que me dediqué durante 5 años en Twitch
En teoría, multicast solo reduciría el tráfico entre el edge del CDN y el ISP, pero eso solo aplica a transmisiones gigantescas que ocurren una vez al año (por ejemplo, el Super Bowl), y no ayuda en la mayoría de los eventos. Muchos CDN ya resuelven eso instalando sus edges dentro de los ISP, y en eventos pequeños es poco probable que dos espectadores compartan exactamente la misma ruta, así que el beneficio es mínimo
Multicast también trae otros problemas, como control de congestión y cifrado, y aquí además hablamos de multicast en una estructura federada, lo que lo complica aún más
Donde más beneficio podría aportar multicast sería en P2P, pero parece difícil que se adopte dentro del enorme ecosistema de CDN
WebRTC también encaja muy bien con multicast y usa RTP (que originalmente se diseñó para multicast), pero en la práctica no hay mucho interés en darle soporte a multicast
Aunque se rumorea que Google usa multicast dentro de su propia red para Meet, así que quién sabe
El enlace de "just announced" es muy bueno incluso para alguien que no tiene idea de qué es esto: https://blog.cloudflare.com/moq/ (yo también me lo salté al principio)
"Latencia sub-segundo a escala de broadcast", pero sin multicast real
La frase "No es simplemente otro protocolo, sino una nueva filosofía de diseño" activó mi radar detector de IA
Me pregunto cómo maneja MOQ la recuperación ante fallos (failback) de resolución y la degradación gradual de calidad. Y en zed también hay un problema donde incluso en pantalla completa no llena toda la pantalla
Soy usuario de Firefox, y si visitaste un sitio alojado en Cloudflare que usa HTTP/3, quería compartir esto como referencia:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
¿Parece que podría ser un problema de happy eyeballs? Pienso comentárselo a gente que sepa más
Me pregunto si estás usando un resolvedor de DNS over HTTPS (DoH) dentro del navegador. Yo personalmente no he podido reproducir este problema. Estoy usando DoH con 1.1.1.1
Tanto en Chrome como en Firefox, he notado que el uso de HTTP/3 es más consistente cuando usan un resolvedor DoH en lugar del DNS del sistema. Cuando usan el resolvedor del sistema, a menudo no obtienen registros DNS HTTPS de forma consistente (o no los obtienen en absoluto),
y el soporte del servidor para HTTP/3 solo funciona si el navegador lo descubre mediante registros DNS HTTPS o mediante un encabezado Alt-Svc cacheado previamente de HTTP/2/1.1. Además, el navegador tiende a reutilizar conexiones ya abiertas, así que no crea conexiones nuevas con facilidad
El encabezado Alt-Svc tampoco se cachea de manera consistente, especialmente en Firefox
Para complicar más las cosas, si el navegador (especialmente Chrome) acumula cierto nivel de fallos de conexión, desactiva por completo el soporte de HTTP/3. Me pasó usando el Wi‑Fi de la universidad, donde bloqueaban mucho tráfico UDP de manera irregular, y después en mi casa tampoco funcionaba HTTP/3. La única solución fue ir a chrome://flags y volver a activar manualmente el soporte de QUIC. Aunque se vea como "enabled by default", el estado real del navegador puede ser distinto. Firefox también abandona HTTP/3 de forma parecida, pero no es tan terco como Chrome y no suele ser un gran problema
Si quieres depurar más, revisa en https://tls-ech.dev si EncryptedClientHello (ECH) está funcionando; eso aísla el problema porque usa exclusivamente registros HTTPS para las claves ECH.
Luego puedes usar la prueba de HTTP/3 de Fastly (https://http3.is) para ver si solo está negociando por Alt-Svc.
La página de prueba de Cloudflare (https://cloudflare-quic.com) usa tanto registros DNS HTTPS como Alt-Svc, así que si toma HTTP/3 de inmediato, significa que la resolución de registros HTTPS está funcionando bien
Estaría bueno que compartieras tus resultados de prueba. El problema de Firefox no es consistente para todo el mundo precisamente por todas estas variables
(Lo que quisiera comentar a la gente de Cloudflare es que https://cloudflare-quic.com/favicon.ico parece estar mal configurado. Y la imagen https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg se carga desde Wayback Machine y eso retrasa la carga de la página; para imágenes, conviene usar enlaces "id_" para que no haya rewrite y sea más rápido. Antes incluso era posible usar esto junto con Cloudflare Workers para restaurar temporalmente un sitio cuando fallaba una migración de servidor. O simplemente usar el original https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg, que todavía sigue disponible en el sitio actual)
En los últimos años he experimentado muchísimo con varias implementaciones y despliegues raros de HTTP/3. Es un protocolo excelente. Pero tiene muchos problemas extraños y peculiares de implementación y despliegue
Me pregunto si está limitado a macOS. No logro reproducirlo en FF 141 y 142 en Windows
¡Está realmente genial! Impresiona el trabajo. Al principio lo leí como QUIC CDN y pensé "ni de broma", pero al mirar con más detalle y ver que Media over QUIC es algo aparte, me pareció bastante interesante
La primera app me pareció interesante. Creo que valdría la pena enviarla a Show HN. He trabajado en plataformas de video en vivo, y MoQ me parece lo bastante interesante como para hacerme querer volver a desarrollar en esto
Si "la tecnología funciona por dentro", creo que da igual siempre que tenga soporte en los navegadores principales (ni siquiera aparece en caniuse).
Y si también es compatible con motores webview como Microsoft Edge WebView2, siento que ya podría adoptarse en desarrollo de inmediato.
Pero por otro lado, parece que para que realmente tenga sentido, tendría que haber soporte del lado de cosas como OBS o YouTube
Así que... MoQ va un poco por una ruta distinta a la de una gran API web de "caja negra" como WebRTC. Desde la perspectiva del navegador, la clave es el soporte para la API de WebTransport.
Si usas MoQT junto con WebTransport, por ejemplo también se abren varias formas nuevas de usar un reproductor de video, como WebCodecs. Si toleras algo más de latencia, incluso puedes reproducir con MSE y aplicar DRM
Y el trabajo para publicar directamente desde OBS ya lo estaba haciendo antes de entrar a Cloudflare, pero eso depende bastante de cómo se implementen los detalles relacionados con medios en la capa de "streaming format". En la industria, la especificación de esa capa todavía sigue evolucionando, y actualmente WARP es la especificación dominante. A medida que el estándar WARP se vaya consolidando, esta capacidad podría incorporarse también en OBS y otros. Incluso ahora, ya es posible publicar video mediante un formato provisional basado en fMP4 a través de Norsk (https://norsk.video/)
En el caso de YouTube, hay gente de Google contribuyendo activamente a MoQT, pero no me atrevería a asegurar cuándo ni de qué forma eso podría reflejarse en el producto de YouTube
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
En realidad WebCodecs no es estrictamente obligatorio; también se puede renderizar con MSE, pero es más complicado y la latencia es mayor.
Estamos trabajando en un fallback con WebSocket y un encoder OPUS basado en WASM para dar soporte a Safari