Home Articoli tecnici Live streaming a bassa latenza con CDN più veloce
Applications

Live streaming a bassa latenza con CDN più veloce

About The Author

Outline

Gli sport dal vivo sono emozionanti da guardare. Soprattutto durante i momenti più importanti, come quando un colpo esce dal nulla per vincere la partita. Questi momenti possono anche essere entusiasmanti per il team tecnico responsabile della fornitura di azioni fluide e in tempo reale. I live streaming sportivi devono bilanciare diverse considerazioni tecniche e compromessi, con una media di circa 30 secondi dietro la partita live sul campo. Perché questo ritardo?

Sebbene le reti di distribuzione dei contenuti siano essenziali, non possono ridurre la latenza causata da altre parti del flusso di lavoro video. Ad esempio, la latenza viene aggiunta dal momento dell’acquisizione quando un’immagine viene convertita in un segnale. Il segnale grezzo deve quindi essere convertito in un formato compresso e trasmesso al centro di elaborazione video, in genere fuori sede e spesso nel cloud, che può essere influenzato dalla larghezza di banda e dall’infrastruttura disponibili. Successivamente, la transcodifica e il packaging del contenuto per vari dispositivi e larghezze di banda. Infine, mentre il flusso è in riproduzione, la pubblicità può essere inserita dinamicamente nel flusso appena prima che si sposti attraverso l’ultimo miglio di Internet verso il dispositivo dello spettatore. In questo caso, il lettore esegue il buffering della decodifica, della decompressione e del rendering del segmento video finale. Si tratta di un sacco di passaggi tra l’obiettivo vincente della squadra e la rete di distribuzione dei contenuti. E possono sommarsi, soprattutto quando deve succedere per milioni di spettatori tutti insieme. Latenza nei live streaming del Super Bowl, ad esempio, media da 28 a 47 secondi.

La riduzione della latenza è diventata una priorità per i provider di servizi di streaming. Per gli sport legati a scommesse di gioco di frazioni di secondo, come le corse ippiche, i flussi ritardati mettono i partecipanti remoti in uno svantaggio rispetto a quelli della sede. I tweet in diretta di spettatori e giornalisti della sede possono rovinare momenti emozionanti per i fan che lo guardano in TV e in live streaming. E con un numero sempre maggiore di spettatori che utilizzano un secondo schermo mentre guardano gli sport in diretta, non c’è da meravigliarsi se ridurre il tempo trascorso dal vivo sta diventando un requisito importante per rimanere competitivi e offrire un’esperienza visiva eccellente.

Ridurre la latenza è un’area di interesse per noi di Edgecast, ora Edgio. Questo sforzo comporta la ricerca e l’implementazione di miglioramenti incrementali in ogni fase di elaborazione e gli altri fattori coinvolti nella distribuzione dei live streaming. In questo post, esaminiamo i fattori coinvolti in un aspetto specifico della riduzione della latenza, ovvero il modo in cui la nostra rete di distribuzione dei contenuti gestisce l’aumento del volume di richieste derivante da una strategia a bassa latenza sempre più diffusa, ovvero la riduzione delle dimensioni dei segmenti.

Nel tentativo di ridurre il tempo trascorso dal vivo, i provider di servizi di streaming stanno iniziando ad abbracciare l’uso di HLS o segmenti DASH più brevi. Ciò può ridurre significativamente la latenza, ma presenta compromessi come un sovraccarico aggiuntivo e un aumento del rischio di rebuffering. La validità di questi compromessi dipende interamente dalla priorità attribuita alla latenza rispetto ad altre considerazioni di QoE. In alcune situazioni, come indicato sopra, la bassa latenza è una priorità assoluta, mentre in altre, i livelli di latenza attuali possono essere accettabili per offrire pubblicità personalizzata, programmazione 4K o per consentire la modifica di contenuti live.

Il ruolo della dimensione del segmento nella latenza

Il settore dello streaming video utilizza da tempo tecnologie a bitrate adattivo (ABR, Adaptive bitrate) che suddividono un flusso in molti segmenti o frammenti di video individuali. Ogni segmento ha la stessa durata o dimensione, ma è codificato a diversi livelli di qualità video o bitrate, in modo che il flusso possa adattarsi alla larghezza di banda disponibile dello spettatore man mano che vengono richiesti nuovi segmenti. Entrambi i principali protocolli ABR, HLS e MPEG-DASH di Apple, forniscono controlli per regolare le dimensioni dei segmenti.

La dimensione del segmento gioca un ruolo importante nella latenza perché il giocatore deve scaricare un numero preimpostato di segmenti prima di poter iniziare a riprodurre il live streaming. Questo avviene in modo che il lettore video client possa eseguire il buffer di un video sufficiente per garantire una riproduzione video fluida senza il rebuffering in presenza di congestione nella rete. Tuttavia, anche questo mette lo streaming dietro il live sin dall’inizio. In genere, i lettori video incorporati su dispositivi iOS e browser Web eseguono il buffer di tre segmenti video prima di avviare la riproduzione. Se un segmento è lungo quattro secondi e il giocatore deve effettuare il buffer di tre segmenti prima di poter iniziare a giocare, allora il client è già indietro di 12 secondi dal vivo. Il protocollo DASH offre una certa flessibilità consentendo ai file manifesti di specificare la quantità di file da sottoporre a buffer. Tuttavia, molti lettori DASH e dispositivi devono ancora implementare questa funzionalità.

Riduzione del tempo in ritardo

Poiché il buffering di tre segmenti è lo standard de facto, la tecnica più popolare per ridurre il tempo di attesa è ridurre le dimensioni o la durata di ciascun segmento. Nell’esempio riportato di seguito, riducendo le dimensioni del segmento da quattro a due secondi, il tempo trascorso in tempo reale si riduce a soli sei secondi, metà di quello che sarebbe con segmenti di quattro secondi.

I segmenti più piccoli possono causare il ripristino dei buffer

Quando si utilizzano segmenti di dimensioni più piccole, il flusso di lavoro video deve essere più reattivo per offrire un’esperienza di streaming video live senza buffer. Ciò è dovuto a due fattori:

Innanzitutto, riducendo le dimensioni del segmento, il lettore, che memorizza un numero fisso di segmenti, ora memorizza meno video. Inoltre, poiché le dimensioni più brevi dei segmenti comportano un maggior numero di file, il flusso di lavoro video e, soprattutto, la rete di distribuzione dei contenuti deve elaborare e distribuire il doppio delle richieste di file dai lettori in una determinata durata del flusso. Poiché c’è meno video nel buffer nel lettore durante la congestione della rete, è più probabile che la congestione possa causare un rebuffer. Il giocatore è ora più sensibile alla congestione, anche durante eventi di congestione più piccoli.

In secondo luogo, come abbiamo spiegato in un recente articolo tecnologico, Optimizing the CDN for Live streaming, è comune negli sport live vedere picchi di spettatori quando iniziano eventi popolari o quando una partita vicina si avvicina ai minuti finali. Man mano che il numero di richieste di file aumenta, la CDN deve gestire più richieste di file nello stesso lasso di tempo. Questa attività è composta da vari tipi di dispositivi e velocità di connessione specificate dai parametri di bitrate adattivi.

Per illustrare l’aumento del volume dei file, la Figura 2 mostra un segmento video di 16 secondi distribuito in segmenti di lunghezza diversa. Con segmenti di quattro secondi, sono necessari solo quattro file per fornire il segmento di 16 secondi. Ma quando passiamo a segmenti di due secondi, abbiamo bisogno di otto file separati, il doppio dei file che devono essere elaborati tramite la CDN.

Migliorate le prestazioni di consegna dei segmenti con Hot Filing

Abbiamo creato una funzionalità chiamata Hot Filing per affrontare il cosiddetto fenomeno “flash Crowd” quando molti spettatori live si uniscono a uno streaming contemporaneamente. Questa funzione si riferisce alla replica rapida di un segmento o di un “file hot” diffuso su altri server all’interno di un POP (punto di presenza), in modo che possa essere distribuito agli spettatori con la rapidità con l’aumento della domanda.

Distribuendo il carico a molti server, l’Hot Filing impedisce a qualsiasi server di essere sopraffatto quando le richieste di file aumentano improvvisamente. Quando un server viene sovraccaricato, analogamente a un attacco di tipo Denial of Service, il server sarà lento a rispondere alle richieste di file, causando potenzialmente il rebuffering nel player client. Identificando e replicando rapidamente i file hot, il rischio di sovraccarico di un singolo server è molto più basso. I cambiamenti improvvisi della domanda possono ora essere soddisfatti senza aggiungere latenza.

La Figura 3 mostra in che modo Hot Filing (Fig. 3.b) migliora le prestazioni evitando il sovraccarico del server. Senza Hot Filing (Fig. 3.a), tutto il traffico di un segmento va al server 1 (S1). Con i picchi della domanda del pubblico, il traffico aggiuntivo passa a S1, spingendolo al di sopra della sua capacità di 100 utenti. La situazione continua a peggiorare poiché S1 serve 200 spettatori al culmine. Al contrario, Hot Filing (Fig. 3.b) gestisce questo carico aggiuntivo replicando i file su due server (S1 più S2) e reindirizzando le richieste di file al nuovo server disponibile.

Identificazione rapida dei file più rapida

Recentemente abbiamo migliorato l’Hot Filing diminuendo di un secondo il tempo necessario per spostare i file hot su più server. Abbiamo migliorato i tempi di reazione modificando il modo in cui i file hot vengono identificati all’interno di un pop. Utilizziamo un processo centrale per aggregare le richieste di file e il conteggio dei byte per l’analisi. In precedenza, i dati venivano estratti dal processo del server Web su ciascun server. Anche se questo ha funzionato bene, abbiamo scoperto che un server Web lento potrebbe rallentare l’aggregazione dei dati hot file. Per risolvere questo problema, i server scrivono la richiesta e il conteggio dei byte sul disco ogni secondo. Di conseguenza, quando il processo centrale estrae i dati, non deve attendere i processi del server Web poiché i dati sono già scritti su un disco a stato solido. Questa modifica da sola è sufficiente per gestire il carico per la maggior parte degli eventi live.

L’importanza fondamentale di un tempo di reazione rapido per gli eventi live è illustrata nella Figura 3.c, che offre informazioni dettagliate sul funzionamento del processo di archiviazione a caldo per reclutare risorse aggiuntive. Nell’esempio mostrato nella Figura 3.c, poiché il server S1 supera la capacità di 100 utenti, i file vengono spostati rapidamente in S2 non appena raggiunge la capacità massima. Ciò consente al sistema di gestire tutti i 200 utenti in modo rapido ed efficiente e di utilizzare tutta la capacità dei server disponibili.

Hot Filing su più porte

Per eventi estremamente popolari, come le partite di football professionistico ai playoff o le principali partite di calcio internazionali, picchi e picchi di traffico possono essere molto significativi. Per soddisfare questo livello di domanda è necessario anche modificare il modo in cui i segmenti di file vengono replicati per aumentare la capacità del server. In precedenza, la rete per la distribuzione dei contenuti era limitata alla replica dei segmenti a una porta per server. Ma ora possiamo replicare i file su più porte in ogni server. Ciò aumenta notevolmente il throughput di ciascun server, in modo che ogni POP possa gestire più richieste e, di conseguenza, eventi live molto più grandi rispetto al passato.

Nel nostro sistema, il bilanciamento del carico è gestito dall’hashing CAPA (cache Array Routing Protocol). Per i contenuti normali, il nostro approccio è stato quello di replicare i file su più server e utilizziamo l’hashing CARP per selezionare una singola porta da ciascun server. Questa operazione consente di evitare l’invio di richieste duplicate al server di origine e di limitare la comunicazione tra processi.

Quando un file diventa abbastanza caldo, CARP inizia a selezionare più porte per server per supportare un numero ancora maggiore di richieste. Questo approccio funziona bene per i file hot poiché rappresentano una piccola frazione dei file univoci serviti da un server. Il numero di porte aperte dipende dalla richiesta di un file hot. Questo approccio aumenta il volume di dati servito per server e la quantità di potenza della CPU disponibile per elaborare queste richieste.

Conclusione

Poiché i provider di servizi di streaming riducono le dimensioni dei segmenti video per fornire un live streaming a latenza inferiore, le funzionalità Platform Hot Filing di Edgio aiutano la rete di distribuzione dei contenuti a gestire le richieste crescenti di file video, soprattutto con l’aumento delle dimensioni del pubblico per gli eventi sportivi più popolari.