Nota dell’editor: quello che segue è un post sponsorizzato di Luke Curley, uno dei creatori di Media over Quic. Le opinioni, le prospettive tecniche e i pareri espressi di seguito sono interamente suoi e sono separati dalle opinioni di Fastly, dall’offerta di prodotto e dalle specifiche tecniche.
Ciao, fan di Fastly.
Sono Luke, alias @kixelated, alias uno dei creatori di Media over QUIC. A Fastly piacciono i miei post sul blog su MoQ e mi ha sponsorizzato per scriverne altri. Per qualche motivo...
Il punto è che esistono due copie di questo post del blog:
Questo normale post su MoQ e Formula 1.
Un post sfrenato su Lightning McQueen.
Sta a te scegliere. Impareremo i numerosi modi in cui puoi usare MoQ nella corsia di sorpasso. In ogni caso, ti becchi un’immagine di un’auto tracciata male. Almeno non è generata dall’IA.
Il punto sulla gara
Mettiamo che tu sia un grande fan della F1. Un fan ENORME, ma questa piccola cosa chiamata reddito disponibile ti impedisce di andare a ogni gara.
Prima o poi, vorrai guardare la gara dal soggiorno di casa. Ci serve un modo per fare live streaming della gara su internet fino ai tuoi occhi.
La risposta nell’ultimo decennio è stata HLS/DASH. Prendi un flusso multimediale, dividilo in segmenti lunghi da 0,5 s a 4 s e distribuiscili tramite HTTP. È noioso, ma funziona, e Fastly lo fa bene (pubblicità sponsorizzata, tra l’altro).
Il problema è che abbiamo raggiunto un muro di latenza:
Inviare i media in batch aggiunge latenza (da 0,5 s a 4 s).
La congestione della rete causa head-of-line blocking e buffering.
Ogni secondo di buffering significa ancora più latenza.
Questo muro di latenza è il motivo per cui ho creato MoQ, quando lavoravo in Twitch. L’obiettivo era rendere il live streaming più interattivo (e meno noioso). Trasmetti i frame dello stream e, occasionalmente, scartali invece di bloccare.
Nessuna quantità di prefissi LL- o di marketing ULTRA LOW LATENCY può risolvere questo problema. Ci serve un nuovo protocollo per evitare il blocco head-of-line, subito.
MoQ per i fan
Per prima cosa, voglio affrontare l’elefante nella stanza. In passato ho affermato che non serve MoQ per contenuti di alta qualità.
Ed è vero. Se vuoi vedere ogni frame di un live streaming, MoQ offre ben pochi vantaggi. È molto meglio usare HLS/DASH con un buffer ampio per attenuare i problemi momentanei della rete. In modo simile a come YouTube scarica in anticipo minuti di video.
Sì, certo, aspettare porterà sempre a una qualità dell’immagine migliore. Ma l’ipotesi è che alcuni utenti preferiscano una latenza inferiore a scapito della qualità.
Spesso il bello di guardare un live streaming è far parte della storia IN DIRETTA, non vedere ogni millisecondo del giro 392. È il motivo per cui Twitch esiste, in primo luogo: l’interattività è più importante della qualità.
Forse l’utente sta scommettendo sulla gara, o pubblicando sui social media, o vuole semplicemente essere il primo a saperlo. Essere all’ultimo posto non è una bella sensazione. Sapere che sei ancora al giro 392 mentre il tuo vicino è al giro 393.
Comunque, questo non sarebbe un vero post tecnico del blog se non spiegassi come funziona. MoQ può dare priorità ai contenuti più recenti rispetto a quelli meno recenti (in ordine di dipendenza). Quindi ogni spettatore/spettatrice può scegliere se avere un vuoto nel mezzo o un vuoto alla fine.
Qui c’è assolutamente un compromesso. Ma questa è anche la bellezza di MoQ: è una manopola di latenza configurabile che puoi alzare o abbassare.
NOTA: MoQ può eguagliare la qualità/latenza che ti aspetti da HLS/DASH. Noi consentiamo solo una soglia minima di latenza più bassa.
MoQ per le auto
Anche se inizialmente ho creato MoQ per i fan, le aziende insistono per eseguirlo sulle auto. O sui droni. O sulle barche.
Una delle sfide del live streaming è far uscire il contenuto dal veicolo. Le reti cellulari e satellitari sono un disastro. In realtà non guardo la F1, ma quando ne vedo degli spezzoni, le riprese dalle auto sono terribili.
Sono una star del video, non della radio, ma immagino che probabilmente dipenda dalla rete. Ci saranno zone morte o interferenze o altro lungo la traccia. Una realtà della trasmissione del segnale è che dovrai gestire periodi di larghezza di banda alta, bassa e nulla.
Il feed proveniente da un’auto di F1 userà qualcosa come RTP su UDP. Esistono moltissimi approcci diversi, ma in genere un editore RTP assegna a un frame una scadenza di ~100 ms prima che venga eliminato per sempre. Quindi una piccola interferenza del segnale provoca artefatti, tearing o video bloccato.
Ma MoQ non si arrende.
Come ho detto prima, MoQ dà invece priorità alla trasmissione dei contenuti più recenti (in ordine di dipendenza). I contenuti meno recenti non vengono eliminati, ma messi in coda nella RAM (fino a un Time-To-Live). Quando la larghezza di banda si ripristina, possiamo recuperare i filmati precedenti invece di perderli per sempre.
Ogni abbonato MoQ decide in modo indipendente quanto aspettare per ogni frame:
Il live streaming potrebbe attendere fino a 1 secondo
Il relay istantaneo potrebbe attendere fino a 10 secondi
La registrazione VOD potrebbe attendere fino a 1 minuto.
Tutto quel tempo extra significa più tempo perché i vecchi frame arrivino. Il feed in tempo reale potrebbe essere dannatamente lossy, ma il VOD è impeccabile.
MoQ per i robot
Gli esseri umani non sono gli unici ad aver bisogno del live streaming. Entrano in scena i robot. Danno un morso.
Si scopre che MoQ funziona per molto più dei soli media:
Il tachimetro? Un live streaming
Il volante? Uno live streaming
Il sensore di forza G? Che ci crediate o no, un live streaming
Sul serio, non c'è niente di speciale nei media. Sono solo dati con codifica delta. Puoi applicare la codifica delta a molte cose, persino a JSON.
Le rete sono finite, quindi suddividiamo i contenuti multimediali in parti. Ogni singola traccia, gruppo, frame, pacchetto, potrebbe essere eliminato senza interrompere il flusso multimediale. La realtà è che alcuni byte hanno semplicemente meno valore di altri.
La parte difficile è rimettere insieme i pezzi. Per questo usiamo i timestamp: ci dicono quando sono successe le cose rispetto ad altre cose. Anche i metadati vengono contrassegnati con un timestamp in modo da poter essere associati ai frame audio/video.
Puoi, e dovresti, prendere la pillola rossa e usare MoQ per TUTTO. Un’unica connessione QUIC cooperativa con: ‘controllo > audio > metadati > video’
CURIOSITÀ: MoQ viene usato da remoto per pilotare droni tramite Starlink. Non solo per il feed della videocamera, ma anche per i controlli!
E sì, sembra semplice, ma è una cosa che WebRTC gestisce malissimo. Devi usare una connessione separata per i metadati e i timestamp non sono esposti nel browser.
MoQ per la traccia
A quanto pare ci sono MOLTISSIME videocamere intorno a una pista. E ci sono MOLTISSIMI occhi che vogliono vederle.
Ovviamente non vogliamo che gli spettatori si colleghino direttamente a ogni videocamera. Non c’è modo che quella povera videocamera possa inviare 100.000 copie dello stesso feed. Vogliamo che gli studi di trasmissione prendano quei feed di input e li combinino in un feed sindacato per la distribuzione.
Ma cosa succede se ci sono più studi di trasmissione che vogliono lo stesso filmato? I camion satellitari sono costosi e hanno un budget di larghezza di banda limitato. Non vogliamo trasmettere più copie dello stesso filmato, né vogliamo trasmettere filmati che nessuno vuole.
È qui che MoQ dà il meglio di sé.
moq-relay è un semplice proxy che collega 1 editore a N abbonati (per broadcast/traccia). Quando le istanze di moq-relay si connettono tra loro, formano automaticamente un cluster. Puoi ospitarle tu stesso (è tutto open source) oppure pagare una Rete di distribuzione dei contenuti perché le ospiti per te.
moq-relay gestisce il rilevamento, l'instradamento e il proxying. Per esempio:
Ogni telecamera si connette a un moq-relay self-hosted all’indirizzo
192.168.420.69.moq-relay viene eseguito con
--cluster-connect https://cdn.moq.dev/f1.I client dello studio (o anche un relay!) si connettono a
https://cdn.moq.dev/f1.
Magicamente, tutti i feed delle videocamere sono automaticamente disponibili in ogni relay e, se necessario, vengono automaticamente inoltrati tramite proxy. E viene trasmessa una sola copia tra ogni istanza di moq-relay, indipendentemente dal numero di abbonati downstream.
È un aspetto fondamentale quando sono coinvolti una connessione internet instabile nella sede e costosi camion satellitari. Esegui alcune istanze di moq-relay su ogni traccia di gara, aggregando automaticamente tutti i feed, e pubblicali su una Rete di distribuzione dei contenuti. facile facile!
E non c’è limite al numero di connessioni che puoi stabilire. moq-lite userà la connessione con il percorso più breve in caso di parità. Magari una connessione è su ethernet mentre l’altra è su satellite; sbizzarrisciti.
Conclusione
Media over QUIC ha un sacco di casi d’uso interessanti, anche oltre i media. È il futuro del live streaming e dovresti salire a bordo. vroom vroom.
Grazie ancora a Fastly per aver sponsorizzato questo post. Mi hanno semplicemente detto di scrivere qualcosa su MoQ, quindi l’ho fatto. DISCLAIMER: non guardo nemmeno la F1 lul.
Scritto da @kixelated. Sentiti libero di inviarmi un’email o di dare un’occhiata a moq.dev per altre bontà su MoQ.
