Nota del editor: lo siguiente es un artículo patrocinado de invitado de Luke Curley, uno de los creadores de Media over Quic. Los puntos de vista, las perspectivas técnicas y las opiniones expresados a continuación son exclusivamente suyos y son independientes de los puntos de vista de Fastly, su oferta de productos y sus especificaciones técnicas.
Hola, fans de Fastly.
Soy Luke, también conocido como @kixelated, también conocido como uno de los creadores de Media over QUIC. A Fastly le gustan mis artículos del blog sobre MoQ y me patrocinó para escribir algunos más. Por algún motivo...
El giro es que hay dos copias de este artículo del blog:
Este artículo normal sobre MoQ y Formula 1.
Un artículo desquiciado sobre Lightning McQueen.
Elige lo que prefieras. Vamos a aprender sobre las numerosas formas en que puedes usar MoQ en el carril rápido. En cualquier caso, te llevas una imagen de un coche mal trazada. Al menos no está generada por IA.
El estado de la carrera
Digamos que eres muy fan de la F1. Un fan ENORME, pero esta pequeña cosa llamada renta disponible te impide ir a todas las carreras.
Tarde o temprano, querrás ver la carrera desde el salón de tu casa. Necesitamos alguna forma de transmitir la carrera por internet en streaming en vivo hasta tus ojos.
La respuesta durante la última década ha sido HLS/DASH. Coge un flujo de medios, divídelo en fragmentos de entre 0,5 s y 4 s de duración, y sírvelos a través de HTTP. Es aburrido, pero funciona, y Fastly lo hace bien (publirreportaje patrocinado, por cierto).
El problema es que nos topamos con un muro de latencia:
Vaciar los medios por lotes añade latencia (0,5 s a 4 s).
La congestión de red provoca bloqueo de cabecera y almacenar en búfer.
Cada segundo de almacenar en búfer significa aún más latencia.
Este muro de latencia es la razón por la que creé MoQ, mientras estaba en Twitch. El objetivo era hacer que el streaming en vivo fuera más interactivo (y menos aburrido). Transmitir fotogramas y, de vez en cuando, descartar en lugar de bloquear.
Ninguna cantidad de prefijos LL- ni de marketing de ULTRA BAJA LATENCIA puede arreglar esto. Necesitamos un protocolo nuevo para evitar el bloqueo de cabecera de línea, ya.
MoQ para los fans
Primero, quiero abordar el elefante en la habitación. En el pasado he afirmado que no necesitas MoQ para contenido de alta calidad.
Y es cierto. Si quieres ver cada fotograma de un streaming en vivo, no hay mucho que ganar con MoQ. Es mucho mejor usar HLS/DASH con un búfer grande para suavizar los altibajos de la red. Parecido a cómo YouTube descarga minutos de vídeo por adelantado.
Sí, claro, esperar siempre va a dar como resultado una mejor calidad de imagen. Pero la hipótesis es que algunos usuario prefieren una latencia menor a costa de la calidad.
A menudo, la emoción de ver un streaming en vivo es formar parte de la historia EN DIRECTO, no ver cada milisegundo de la vuelta 392. Por eso existe Twitch en primer lugar: la interactividad es más importante que la calidad.
Puede que el usuario esté apostando en la carrera, publicando en redes sociales o simplemente quiera ser el primero en enterarse. Se siente mal estar en último lugar. Saber que todavía vas por la vuelta 392 mientras tu vecino va por la 393.
En cualquier caso, esta no sería una entrada de blog muy técnica si no explicara cómo funciona. MoQ puede priorizar el contenido más reciente sobre el más antiguo (en orden de dependencia). Así que cada espectador puede elegir si hay un hueco en medio o un hueco al final.
Aquí hay claramente una compensación. Pero esa es también la belleza de MoQ: es un dial de latencia configurable que puedes subir o bajar.
NOTA: MoQ puede igualar la calidad/latencia que esperas de HLS/DASH. Simplemente permitimos un umbral de latencia más bajo.
MoQ para los coches
Aunque originalmente hice MoQ para los fans, las empresas insisten en ejecutarlo en los coches. O los drones. O los barcos.
Uno de los retos del streaming en vivo es sacar el contenido del vehículo. Las redes celulares y por satélite son un desastre. En realidad no veo la F1, pero cuando veo fragmentos, las tomas de cámara de los coches son horribles.
Soy una estrella de vídeo, no una estrella de radio, pero supongo que probablemente se deba a la red. Va a haber zonas muertas o interferencias o lo que sea alrededor de la pista. Una realidad de la transmisión de señales es que vas a tener que lidiar con periodos de ancho de banda alto, bajo y nulo.
La señal procedente de un coche de F1 va a usar algo como RTP sobre UDP. Hay muchos, muchos enfoques diferentes, pero normalmente un editorial de RTP da a un fotograma un plazo de ~100 ms antes de que se descarte para siempre. Así que una pequeña interferencia en la señal provoca artefactos, desgarros o vídeo congelado.
Pero MoQ no se rinde.
Como he dicho antes, MoQ en su lugar prioriza la transmisión de lo más reciente (en orden de dependencia). Lo antiguo no se descarta, se pone en cola en la RAM (hasta un tiempo de vida (TTL)). Cuando el ancho de banda se recupera, podemos rellenar metraje antiguo en lugar de perderlo para siempre.
Cada suscriptor de MoQ decide de forma independiente cuánto tiempo esperar por cada fotograma:
Es posible que el streaming en vivo espere hasta 1 segundo
El retransmisor instantáneo podría esperar hasta 10 segundos
La grabación VOD podría esperar hasta 1 minuto.
Todo ese tiempo extra significa más tiempo para que lleguen fotogramas antiguos. La transmisión en tiempo real puede tener pérdidas de narices, pero el VOD es impecable.
MoQ para los robots
Los humanos no son los únicos que necesitan streaming en vivo. Entran los robots. Muerden bytes.
Resulta que MoQ funciona para algo más que los medios:
¿El speedometer? Streaming en vivo
¿El volante? Streaming en vivo
¿El sensor de fuerza G? Lo creas o no, un streaming en vivo
En serio, no hay nada especial en los medios. Son solo datos codificados por diferencias. Puedes codificar por diferencias muchas cosas, incluso JSON.
Las redes son finitas, así que dividimos los medios en partes. Cada pista, grupo, fotograma, paquete individuales, podría descartarse sin finalizar el flujo multimedia. La realidad es que algunos bytes son simplemente menos valiosos que otros.
La parte difícil es recomponerlo todo. Por eso usamos marcas de tiempo; nos dicen cuándo ocurrieron las cosas en relación con otras cosas. Hasta los metadatos llevan una marca para poder asociarlos con los fotogramas de audio y vídeo.
Puedes, y deberías, tomar la píldora roja y usar MoQ para TODO. Una única conexión QUIC cooperativa con: ‘control > audio > metadatos > vídeo’
DATO CURIOSO: MoQ se está utilizando de forma remota para pilotar drones a través de Starlink. ¡No solo para la señal de la cámara, sino también para los controles!
Y sí, esto suena simple, pero es algo que WebRTC estropea por completo. Tienes que usar una conexión independiente para los metadatos y las marcas de tiempo no están expuestas en el navegador.
MoQ para la pista
Resulta que hay MUCHÍSIMAS cámaras de vídeo alrededor de una pista de carreras. Y hay MUCHÍSIMOS ojos que quieren verlas.
No queremos que los espectadores se conecten directamente a cada cámara, por supuesto. No hay forma de que esa pobre cámara de vídeo pueda enviar 100 000 copias de la misma señal. Queremos que los estudios de radiodifusión tomen esas señales de entrada y las combinen en una señal sindicada para su distribución.
Pero ¿qué pasa si hay varios estudios de retransmisión que quieren las mismas imágenes? Las unidades móviles por satélite son caras y tienen un presupuesto de ancho de banda limitado. No queremos transmitir varias copias de las mismas imágenes, ni queremos transmitir imágenes que nadie quiere.
Aquí es donde MoQ brilla.
moq-relay es un proxy sencillo que conecta 1 editorial con N suscriptores (por emisión/pista). Cuando las instancias de moq-relay se conectan entre sí, forman automáticamente un clúster. Puedes alojarlos tú mismo (todo es código abierto) o pagar a una red de distribución de contenidos para que los aloje por ti.
moq-relay se encarga del descubrimiento, el enrutamiento y la proxy. Por ejemplo:
Cada cámara se conecta a un moq-relay autohospedado en
192.168.420.69.moq-relay se ejecuta con
--cluster-connect https://cdn.moq.dev/f1.Los clientes del estudio (¡o un relay!) se conectan a
https://cdn.moq.dev/f1.
Mágicamente, todas las fuentes de cámara están disponibles automáticamente en cada relay y, si es necesario, se sirven automáticamente mediante proxy. Y solo se transmite una copia entre cada instancia de moq-relay, independientemente del número de suscriptores aguas abajo.
Esto es muy importante cuando hay una conexión a internet inestable en el recinto y entran en juego costosos camiones satélite. Ejecuta unas cuantas instancias de moq-relay en cada pista, agregando automáticamente todas las señales, y publícalas en una red de distribución de contenidos. ¡Facilísimo!
Y no hay ningún límite en el número de conexiones que puedes establecer. moq-lite usará la conexión con la ruta más corta si hay empate. Puede que una conexión sea por ethernet mientras que la otra sea por satélite; haz lo que quieras.
Conclusiones
Media over QUIC tiene un montón de caso de uso interesantes, incluso más allá de los medios. Es el futuro del streaming en vivo y deberías subirte al viaje. vroom vroom.
Gracias de nuevo a Fastly por patrocinar este artículo. Me acaban de decir que escribiera algo sobre MoQ, así que lo hice. AVISO: ni siquiera veo la F1, lul.
Escrito por @kixelated. No dudes en enviarme un correo electrónico o echar un vistazo a moq.dev para más delicias de MoQ.
