Vai al contenuto principale
BlogLinodeMigrazione dallo streaming adattativo di bitrate sul lato client a quello sul lato server

Migrazione dallo streaming adattivo di bitrate lato client a quello lato server

Testo: Migrazione dallo streaming adattativo di bitrate dal lato client al lato server

Le piattaforme di streaming scalano per ospitare milioni di spettatori simultanei su diversi dispositivi e condizioni di rete, rendendo essenziale uno streaming efficiente con bitrate adattivo (ABR). In questo post esploreremo gli aspetti tecnici della transizione dall'ABR lato client a quello lato server, concentrandoci sui dettagli dell'implementazione e sulle ottimizzazioni delle prestazioni.

Fondamenti di streaming a bitrate adattivo

Come funziona esattamente lo streaming a bitrate adattivo? Vediamo le singole fasi. Innanzitutto, il contenuto video viene preparato codificandolo a più bitrate (ad esempio 500kbps, 1Mbps, 2Mbps, ecc.) e memorizzando queste diverse versioni. 

Un file manifest, come un M3U8 per HLS o un MPD per DASH, contiene informazioni sui diversi flussi di bitrate disponibili.

Quando un utente avvia la riproduzione, il dispositivo client scarica il file manifest per vedere le opzioni di bitrate disponibili. Il client seleziona una velocità di trasmissione iniziale, di solito iniziando con una velocità di trasmissione inferiore per un avvio più rapido. 

Durante la riproduzione del video, il dispositivo client monitora continuamente le condizioni della rete e i livelli del suo buffer interno. Se la larghezza di banda della rete è limitata, il client richiederà bitrate più bassi per evitare il rebuffering. Al contrario, se la larghezza di banda migliora, il client richiede bitrate più elevati per migliorare la qualità del video. Questo cambio di bitrate avviene richiedendo nuovi segmenti video al livello di bitrate aggiornato. 

Sfide dello streaming tradizionale a bitrate adattativo (ABR lato client)

Tradizionalmente, lo streaming ABR è stato gestito dal lato client, dove il dispositivo che riproduce il video determina la migliore velocità di trasmissione da utilizzare. Tuttavia, questo approccio comporta alcune sfide. Innanzitutto, i dispositivi client hanno una potenza di elaborazione molto diversa. Un telefono vecchio potrebbe non essere in grado di gestire tutti i calcoli necessari per regolare costantemente la qualità video con la stessa fluidità di un nuovo modello di punta. Per questo motivo, a volte, quando si guarda un programma sul telefono, la qualità video può variare. 

Un altro problema è rappresentato dalle variazioni delle connessioni Internet, anche in un breve lasso di tempo. Il dispositivo deve adattarsi costantemente a questi cambiamenti, il che può portare a cali di qualità davvero evidenti o a frequenti passaggi da una risoluzione all'altra che rendono l'esperienza visiva piuttosto stridente. Soprattutto se vivete in un'area con internet a macchia di leopardo, potreste notare molti buffering o cali di qualità.

C'è anche il problema della latenza: se il dispositivo si accorge in ritardo che la connessione è cambiata, potrebbe non regolare la velocità del bitrate con sufficiente rapidità, causando stalli o improvvisi cali di qualità.

Infine, tutti questi continui aggiustamenti e le potenziali inefficienze possono portare a utilizzare più dati del necessario. Questo può essere un vero problema per gli utenti con piani dati mobili limitati.

Come l'ABR lato server può risolvere queste sfide

Per risolvere questi problemi, invece di determinare la selezione del bitrate appropriato sul lato client, SSABR effettua la selezione sul lato server.

Ecco come potrebbe funzionare lo streaming a bitrate adattativo lato server. Innanzitutto, il client invia una richiesta HTTP GET per il file manifest. La richiesta include i metadati del client (ad esempio, tipo di dispositivo, risoluzione dello schermo, codec supportati). Quindi, il server analizza i metadati del client dalle intestazioni della richiesta ed esegue alcune analisi (carico attuale del CDN, distanza geografica dal client, prestazioni storiche per client simili, ecc.) Quindi, il server genera un file manifest personalizzato, adattato alle capacità del cliente e alle condizioni di rete attuali, e include solo le velocità di trasmissione ritenute adatte al cliente. Il server seleziona quindi la velocità di trasmissione ottimale in base alla larghezza di banda disponibile (stimata da RTT e throughput), alla complessità del contenuto (dimensioni dei fotogrammi I, vettori di movimento) e al livello di buffer del client (segnalato tramite feedback in tempo reale). Successivamente, il server consegna i segmenti video codificati al bitrate selezionato al dispositivo client, che li decodifica e li riproduce. Infine, il server monitora continuamente le condizioni della rete e le capacità del dispositivo di visualizzazione. Se le condizioni cambiano durante la riproduzione (ad esempio, se si verifica una congestione della rete), il server può regolare dinamicamente la velocità di trasmissione per garantire una riproduzione fluida senza buffering o degrado della qualità.

I vantaggi di questo approccio lato server sono molteplici. Invece di essere il dispositivo client a dover scegliere da solo la giusta velocità di trasmissione, il server ha una visione olistica migliore delle condizioni di rete, della complessità del contenuto video e delle capacità del dispositivo. Grazie a tutte queste informazioni, è in grado di prendere decisioni più appropriate in merito all'aumento o alla riduzione della velocità di trasmissione. Ciò significa transizioni più fluide tra i diversi livelli di qualità e un'esperienza di streaming più coerente e priva di buffer per gli spettatori.

L'esternalizzazione del processo di selezione della velocità di trasmissione al server riduce anche il carico di elaborazione sui dispositivi client. Ciò è particolarmente vantaggioso per i dispositivi con risorse limitate, in quanto ne migliora le prestazioni e la durata della batteria.

Un altro vantaggio dello streaming con bitrate adattivo lato server è che il server è in grado di monitorare continuamente le condizioni della rete in tempo reale, regolando il bitrate in modo più preciso e rapido rispetto agli algoritmi lato client. Quindi, se rileva che la connessione sta per rallentare, può abbassare proattivamente il bitrate prima ancora che si verifichino intoppi. E non appena la velocità della connessione riprende, la qualità aumenta di nuovo. Può anche analizzare la complessità del contenuto video in un determinato momento. Le scene di maggior movimento con molta azione saranno pompate a un bitrate più alto per una migliore qualità, mentre le scene più tranquille possono essere trasmesse a bitrate più bassi senza peggiorare l'aspetto. 

Infine, lo streaming adattativo del bitrate sul lato server può essere molto conveniente per i fornitori di streaming. Una gestione più efficiente del bitrate si traduce in una riduzione dei costi della larghezza di banda. I fornitori di streaming possono fornire video di alta qualità senza incorrere in costi di trasferimento dati eccessivi, mentre gli utenti possono godersi i loro contenuti preferiti senza preoccuparsi di sovraccarichi di dati.

In poche parole, flussi di qualità superiore, riproduzione più fluida, migliori prestazioni dei dispositivi e risparmi sui costi sono ottime ragioni per iniziare a prendere in considerazione lo streaming con bitrate adattivo lato server.

Ottimizzazioni delle prestazioni

Per massimizzare i vantaggi dell'ABR lato server, è necessario considerare l'implementazione di alcune ottimizzazioni delle prestazioni. La prima è l'edge computing. Distribuendo la logica ABR sui server edge, è possibile ridurre drasticamente la distanza percorsa dai dati, che a sua volta riduce al minimo la latenza durante la riproduzione video. Questa vicinanza agli utenti finali non solo rende lo streaming più fluido, con meno buffering e tempi di ritardo, ma garantisce anche una regolazione più rapida della velocità di trasmissione. Inoltre, la riduzione del carico sui server centrali può portare a una maggiore scalabilità ed efficienza complessiva della rete, consentendo di gestire più facilmente carichi di traffico elevati.

Un'altra importante ottimizzazione delle prestazioni consiste nell'implementazione di strategie di caching efficaci. Mettendo in cache in modo intelligente i segmenti video più popolari a varie velocità di trasmissione, è possibile ridurre in modo significativo il carico sul server e migliorare le prestazioni dello streaming. A tale scopo, è possibile utilizzare strutture di dati probabilistiche, come i filtri Bloom, che tengono traccia e prevedono in modo efficiente la popolarità dei diversi segmenti. Ciò consente al sistema di memorizzare e servire più rapidamente i contenuti di frequente accesso, riducendo la latenza per gli utenti finali e minimizzando la necessità di recuperare ripetutamente i dati dal server di origine. Inoltre, questo approccio può aiutare a ottimizzare l'uso della larghezza di banda, portando a un'architettura di streaming più scalabile ed efficiente.

Benchmarking e Monitoring L'esperienza dello streaming

Dopo la migrazione alla distribuzione adattiva del bitrate sul lato server, è necessario quantificare i miglioramenti attraverso indicatori chiave di prestazione (KPI) che misurano sia l'esperienza dell'utente che l'efficienza del sistema. Ci sono alcuni indicatori di prestazione chiave che sono importanti.

Il primo è il tempo di avvio, che misura il tempo che intercorre tra la richiesta di riproduzione dell'utente e il primo fotogramma renderizzato. Un tempo di avvio più breve è fondamentale per un'esperienza senza interruzioni, poiché lunghi ritardi possono portare alla frustrazione dell'utente e all'aumento del churn. Un altro KPI importante è il rebuffer ratio, calcolato dividendo il tempo totale di rebuffer per il tempo totale di riproduzione, quindi moltiplicando per 100. Questo rapporto riflette la percentuale di tempo in cui una richiesta di riproduzione viene eseguita. Questo rapporto riflette la percentuale di tempo che un video trascorre in buffering durante la riproduzione e la sua riduzione al minimo garantisce una visione ininterrotta. La frequenza di cambio di bitrate, che tiene conto del numero di cambi di qualità al minuto, è un'altra metrica utile. Un numero eccessivo di cambi di bitrate può disturbare l'esperienza dell'utente, per cui è essenziale bilanciare prestazioni e stabilità. Il bitrate medio misura il bitrate medio erogato durante una sessione, fornendo indicazioni sulla qualità video complessiva sperimentata dagli utenti. Un bitrate più elevato è generalmente sinonimo di migliore qualità, ma deve essere in linea con la larghezza di banda disponibile per evitare il buffering. Infine, i punteggi VMAF (Video Multi-Method Assessment Fusion) sono metriche di qualità percettiva che assicurano che la qualità video fornita corrisponda alle decisioni di bitrate prese dall'algoritmo ABR. Punteggi VMAF elevati indicano una buona qualità visiva rispetto alla velocità di trasmissione, garantendo un'esperienza visiva di alta qualità. 

Il tempo di avvio, la frequenza di rebuffer, la frequenza di commutazione del bitrate, il bitrate medio e i punteggi VMAF sono tutti KPI che possono essere utilizzati per mettere a punto gli algoritmi ABR e ottimizzare la soddisfazione degli utenti.

Conclusione

L'adaptive bitrate streaming lato server risolve molti dei limiti del tradizionale ABR lato client, offrendo un'esperienza di streaming più efficiente e coerente. Centralizzando il processo decisionale, l'ABR lato server migliora le prestazioni, aumenta il controllo della qualità e ottimizza l'uso dei dati. 

In questo post del blog, abbiamo esplorato le sfide dell'ABR lato client e gli interessanti vantaggi delle soluzioni lato server. Se siete uno sviluppatore di un'azienda di streaming e volete saperne di più sull'ottimizzazione delle vostre soluzioni di streaming a bitrate adattivo, potete utilizzare questo link per richiedere fino a 5.000 dollari di crediti Linode per saperne di più.

Commenti

Lascia una risposta

Il vostro indirizzo e-mail non sarà pubblicato. I campi obbligatori sono contrassegnati da *