Gli sport dal vivo sono entusiasmanti da guardare. Specialmente durante i momenti cruciali, come quando un colpo esce dal nulla per vincere la partita. Questi momenti possono essere entusiasmanti anche per il team tecnico responsabile dell’azione fluida e in tempo reale. I flussi sportivi in diretta devono bilanciare diverse considerazioni tecniche e compromessi, con una media di circa 30 secondi rispetto alla partita in diretta sul campo. Perché il ritardo?
Sebbene le reti per la 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 formato compresso e trasmesso al centro di elaborazione video, solitamente fuori sede e spesso nel cloud, che può essere influenzato dalla larghezza di banda e dall’infrastruttura disponibili. Successivamente viene eseguita la transcodifica e l’imballaggio 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. Questo è un sacco di passi tra l’obiettivo vincente del team e la rete di distribuzione dei contenuti. E possono aggiungere, soprattutto quando deve succedere per milioni di spettatori tutti insieme. Latenza nei live streaming del Super Bowl, ad esempio, in 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 differiti mettono i partecipanti remoti in una posizione di svantaggio rispetto a quelli presenti sul luogo. I tweet dal vivo di spettatori e giornalisti del luogo possono rovinare momenti emozionanti per i fan che lo guardano in TV e in diretta streaming. E con un numero sempre maggiore di spettatori che utilizzano un secondo schermo mentre guardano gli sport dal vivo, 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.
La riduzione della latenza è un’area di interesse per Edgecast, ora Edgio. Questo impegno implica la ricerca e l’implementazione di miglioramenti incrementali in ogni fase di elaborazione e degli altri fattori coinvolti nella distribuzione dei live streaming. In questo post, esaminiamo cosa comporta un aspetto specifico della riduzione della latenza: Come la nostra rete di distribuzione dei contenuti gestisce l’aumento del volume di richieste derivante da una strategia sempre più diffusa a bassa latenza: La riduzione delle dimensioni del segmento.
Nel tentativo di ridurre il tempo di attesa rispetto al live, i provider di servizi di streaming stanno iniziando ad abbracciare l’uso di periodi di tempo più brevi di segmento HLS o DASH. Ciò può ridurre significativamente la latenza, ma presenta compromessi quali costi aggiuntivi e un maggiore rischio di rebuffering. La validità di questi compromessi dipende interamente dalla priorità attribuita alla latenza rispetto ad altre considerazioni sulla 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 fornire pubblicità personalizzata, programmazione 4K o per consentire l’editing di contenuti live.
Il ruolo della dimensione del segmento nella latenza
Il settore dello streaming video ha utilizzato a lungo tecnologie ABR (Adaptive bitrate) che suddividono uno streaming in molti segmenti o frammenti di video singoli. Ogni segmento ha la stessa durata o dimensione, ma è codificato a diversi livelli di qualità video o bit rate, in modo che il flusso possa adattarsi alla larghezza di banda disponibile dello spettatore quando vengono richiesti nuovi segmenti. Entrambi i principali protocolli ABR, HLS e MPEG-DASH di Apple, forniscono controlli per la regolazione delle dimensioni dei segmenti.
Le dimensioni del segmento giocano un ruolo importante nella latenza perché il giocatore deve scaricare un numero preimpostato di segmenti prima di poter iniziare a riprodurre il live streaming. In questo modo, il lettore video client può eseguire il buffer di un numero sufficiente di video per garantire una riproduzione video fluida senza il rebuffering in caso di congestione della rete. Tuttavia, questo porta lo streaming indietro dal vivo fin dall’inizio. In genere, i lettori video integrati 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 lettore deve eseguire 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 memorizzare nel buffer. Tuttavia, molti lettori e dispositivi DASH devono ancora implementare questa funzionalità.
Riduzione del tempo di attesa
Poiché il buffering di tre segmenti è lo standard de facto, la tecnica più diffusa 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 secondi a due secondi, il tempo dietro il live si riduce a soli sei secondi, metà di quello che sarebbe con segmenti di quattro secondi.
I segmenti più piccoli possono causare il ribuffering
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 dei segmenti più brevi implicano un maggior numero di file, il flusso di lavoro video e, soprattutto, la rete per la distribuzione dei contenuti deve elaborare e consegnare il doppio delle richieste di file da parte dei 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 nuovo buffer. Il lettore è ora più sensibile alla congestione, anche durante eventi di congestione più piccoli.
In secondo luogo, come abbiamo spiegato in un recente articolo tecnico, ottimizzare la CDN per lo streaming live, è comune negli sport live vedere picchi di spettatori quando iniziano eventi popolari o quando una partita vicina ai minuti finali. Con l’aumento del numero di richieste di file, la CDN deve soddisfare più richieste di file nello stesso periodo 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.
Migliora 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 dal vivo si uniscono a uno streaming contemporaneamente. “Questa funzione si riferisce alla replica rapida di un segmento diffuso o “file hot” su server aggiuntivi all’interno di un POP (Point of Presence), in modo che possa essere distribuito agli spettatori con la stessa rapidità con cui la domanda aumenta rapidamente.”
Distribuendo il carico su molti server, Hot Filing impedisce a un server di essere sopraffatto dal picco improvviso delle richieste di file. Quando un server viene sovraccaricato, analogamente a un attacco di tipo Denial of Service, il server sarà lento a rispondere alle richieste di file, portando potenzialmente al rebuffering nel player client. Identificando e replicando rapidamente i file hot, il rischio di sovraccarico di un singolo server è molto inferiore. 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 l’aumento della domanda del pubblico, il traffico aggiuntivo passa a S1, spingendolo oltre la sua capacità di 100 utenti. La situazione continua a peggiorare in quanto S1 serve 200 spettatori al massimo. 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 dei file hot più rapida
Di recente abbiamo migliorato l’Hot Filing riducendo di un secondo il tempo necessario per spostare i file hot su più server. Abbiamo migliorato il tempo di reazione modificando il modo in cui i file hot vengono identificati in un pop. Utilizziamo un processo centrale per aggregare le richieste di file e i conteggi di 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 dei file hot. 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 a soddisfare il carico per la maggior parte degli eventi live.
L’importanza fondamentale di un tempo di reazione rapido per gli eventi live è mostrata nella Figura 3.c, che offre informazioni 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 rapidamente trasferiti in S2 man mano che raggiunge la capacità. Ciò consente al sistema di accogliere tutti e 200 gli utenti in modo rapido ed efficiente e di utilizzare la piena capacità dei server disponibili.
Hot Filing su più porte
Per eventi molto popolari, come le partite di football professionistico dei 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 su una porta per server. Ma ora possiamo replicare i file su più porte in ogni server. Ciò aumenta notevolmente il throughput di ogni 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 CARP (cache Array Routing Protocol). Per quanto riguarda i contenuti regolari, il nostro approccio è stato quello di replicare i file su più server, e usiamo CARP hashing 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 le comunicazioni tra processi.
Quando un file diventa abbastanza caldo, CARP inizia a selezionare più porte per server per supportare ancora più 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 erogati 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 offrire un flusso live a latenza inferiore, le funzionalità di archiviazione a caldo della piattaforma di Edgio aiutano la rete di distribuzione dei contenuti a gestire le richieste di file video più richieste, soprattutto quando le dimensioni del pubblico aumentano per gli eventi sportivi più diffusi.
