%20(1).webp)
Nel 2009, Apple ha introdotto HTTP Live Streaming (HLS) come un modo per trasmettere in streaming contenuti audio e video live e su richiesta su Internet. È adesso il protocollo di streaming video più utilizzato in tutto il mondo, con supporto per tutti i principali browser e dispositivi.
In questo blog approfondiremo il motivo per cui è stato creato LL-HLS, cos'è, in cosa differisce da ll hls vs hls, quali sono le sue caratteristiche salienti, come si comporta rispetto a LL-DASH e alcune cose da tenere a mente mentre lo implementiamo.
Come discusso in precedenza, HLS è un protocollo di distribuzione multimediale in streaming che utilizza HTTP per fornire contenuti video e audio su Internet. È un protocollo piuttosto popolare utilizzato dai fornitori di servizi OTT e da altri principali browser e dispositivi.
D'altra parte, ll hls è una variante di HLS ottimizzata per lo streaming a bassa latenza. Riduce il tempo che intercorre tra il momento in cui un utente avvia la riproduzione e il momento in cui vede o ascolta il contenuto (noto come "latenza"). Ciò può essere particolarmente importante per i live streaming, dove anche pochi secondi di ritardo possono rendere l'esperienza meno piacevole per gli spettatori.
La principale differenza tecnica tra hls e hls a bassa latenza è il protocollo utilizzato da entrambi per gestire lo streaming. Lo streaming live HTTP utilizza un meccanismo di buffering unico che attende il download dell'intero segmento prima dello streaming. Ciò può influire sulla latenza, poiché gli spettatori devono attendere il download dell'intero segmento prima di poter godersi i contenuti video.
Lo streaming a bassa latenza di hls utilizza il push del server che contribuisce a ridurre la latenza. Ciò significa che il server invia i segmenti del video al destinatario. La riproduzione del video inizia non appena vengono scaricati i primi segmenti del video. Alla fine riduce la latenza perché gli spettatori possono guardare il video mentre vengono scaricati gli altri segmenti.
Poiché hls a bassa latenza utilizza la codifica di trasferimento in blocchi, riduce la latenza. Pertanto, la bassa latenza di HLS è in genere di circa 2-5 secondi, rispetto ai 6-30 secondi di HLS. Ciò rende lo streaming a bassa latenza HLS una scelta migliore per le applicazioni di streaming live in cui la latenza è fondamentale.
Ora passiamo al sodo.
HLS, il predecessore di LL-HLS, è stato lanciato per lo streaming di contenuti di alta qualità su larga scala su dispositivi e piattaforme. Tuttavia, la sua architettura di streaming orientata alla scala ha avuto un prezzo, ovvero la latenza. Per chi non lo sapesse, la latenza è il tempo necessario dalla creazione del video (su una fotocamera) alla sua riproduzione finale (sul dispositivo dell'utente), chiamata anche "latenza glass-to-glass". Nel frattempo, questo flusso video deve essere codificato (sia audio che video), segmentato, confezionato, elencato, scaricato, consegnato, decodificato, sincronizzato con le labbra e memorizzato nel buffer prima della sua riproduzione. Il protocollo di streaming (come HLS) gestisce tutto questo lavoro pesante.
Sebbene HLS abbia svolto un ottimo lavoro in termini di qualità e compatibilità, nel corso degli anni il suo sviluppo ha costantemente compromesso la latenza. E aveva senso. Allora la latenza non era un problema. Tuttavia, non è più così. Con l’avvento dei social media e del live streaming, le persone ora vogliono contenuti in tempo reale. Non vogliono aspettare ancora a lungo. Qui un ritardo di 30-50 secondi è semplicemente insopportabile.
È logico che Apple (che mantiene HLS) alla fine trovi una soluzione ottimizzata per lo streaming a bassa latenza. Quindi lo hanno fatto! Nel 2019, al WWDC, Apple ha annunciato HLS a bassa latenza o LL-HLS. È stato costruito sulla base delle specifiche HLS esistenti con alcune modifiche per ottenere una bassa latenza (<5 s). Diamo un'occhiata a come LL-HLS esegue questa operazione senza compromettere la qualità o la compatibilità:
LL-HLS apporta alcune modifiche importanti alle specifiche HLS esistenti. Queste modifiche includono:
In LL-HLS, i segmenti sono ulteriormente divisi in parti (segmenti parziali HLS), che riducono le dimensioni dei singoli file. Ciò rende possibile avviare la riproduzione anche prima che l'intero segmento venga scaricato (a differenza di HLS in cui è necessario attendere il segmento completo).
La playlist viene aggiornata in LL-HLS con costi di trasferimento inferiori rispetto a HLS. Questo viene fatto richiedendo al server di fornire aggiornamenti delta, che aggiornano le parti rilevanti della playlist già disponibili con il client.
La richiesta HTTP GET di un giocatore può contenere "Direttive di consegna" in LL-HLS. Si tratta di parametri di query speciali che richiedono un segmento futuro nella risposta della playlist. Il server blocca quindi questa richiesta finché il segmento specificato non è disponibile. Elimina il polling delle playlist e, di conseguenza, libera la larghezza di banda del server e della rete.
Per ridurre ulteriormente la latenza, LL-HLS introduce suggerimenti di precarico. Sono tag speciali nella playlist che indicano al lettore di iniziare a recuperare un segmento ancor prima che sia necessario per la riproduzione. Pertanto, il segmento può essere riprodotto immediatamente senza alcun ritardo quando necessario.
LL-HLS riduce al minimo il numero di andata e ritorno durante l'adattamento della velocità in bit. Questo viene fatto aggiungendo i tag EXT-X-RENDITION-REPORT per tutte le playlist multimediali in una playlist multivariante. Questi tag forniscono informazioni, come l'ultimo numero di sequenza multimediale e l'ultima parte attualmente nella playlist multimediale. In questo modo, il client può richiedere le parti richieste dal server senza dover recuperare una playlist multimediale completamente nuova.
Ci sono alcune differenze chiave tra loro che dovresti conoscere prima di decidere quale è migliore per il tuo caso d'uso.
Ecco alcune differenze e somiglianze tra LL-HLS e HLS:
Come abbiamo visto, la differenza più grande tra LL-HLS e HLS è la latenza. Con LL-HLS, Apple è riuscita a ridurlo significativamente (a meno di 5 secondi) rispetto al normale HLS (che ha una latenza di circa 30 secondi. Questa latenza è addirittura inferiore a quella dello streaming TV via cavo HD. Di conseguenza, LL-HLS offre agli utenti un'esperienza di visualizzazione quasi in tempo reale e dovrebbe avere la priorità se la latenza è importante per un determinato caso d'uso.
Non vi è alcuna differenza evidente nella qualità tra i flussi LL-HLS e HLS. Entrambi forniscono streaming video di alta qualità su larga scala. Tuttavia, LL-HLS non è la soluzione migliore per condizioni di larghezza di banda di rete ridotta.
Uno degli aspetti migliori di HLS e LL-HLS è la loro compatibilità con tutti i principali browser e dispositivi. Alcuni dei i browser più diffusi che supportano LL-HLS includono AVPlayer (iOS), Exoplayer (Android), THEOPlayer, JWPlayer, HLS.js, VideoJS e AgnoPlay. Quindi, a differenza di altri protocolli, non devi preoccuparti se i tuoi spettatori saranno in grado di guardare il tuo streaming o meno.
L'implementazione di un HLS regolare è più economica di un LL-HLS.
L'implementazione di LL-HLS è più complessa di HLS a causa delle sue funzionalità aggiuntive (come suggerimenti di precaricamento e report di rendering). Pertanto, dovrai avere una buona comprensione di come funziona prima di poterlo implementare.
Ora, diamo un'occhiata ad alcuni vantaggi e svantaggi dell'utilizzo di LL-HLS per lo streaming a bassa latenza:
I vantaggi derivanti dall'utilizzo di LL-HLS per lo streaming a bassa latenza includono:
Come risulta chiaro dal nome, LL-HLS è stato progettato pensando alla latenza. Il protocollo di streaming offre un'esperienza di visione da vetro a vetro quasi in tempo reale. In alcuni scenari, utilizzando LL-HLS, è possibile ottenere anche una latenza <2 secondi. Ciò lo rende ideale per i live streaming, come sport in diretta, notizie, streaming di giochi, ecc. dove ogni secondo è importante.
Un altro vantaggio dell'utilizzo di LL-HLS è che non sacrifica la qualità a favore della latenza. Utilizza gli stessi codec (come H.264 e H.265) del normale HLS e fornisce un'esperienza di streaming video di alta qualità nelle condizioni di rete desiderate.
La sfida con la maggior parte dei protocolli di streaming, soprattutto quelli che comportano una bassa latenza, è che sono difficili da scalare. Questo non è il caso di LL-HLS. Si basa su HLS e utilizza il packaging HLS standard, che lo rende notevolmente facile da implementare e scalare. Di conseguenza, puoi coinvolgere migliaia di utenti simultanei senza problemi.
Uno degli aspetti migliori di LL-HLS è che è compatibile con tutti i principali browser e dispositivi, inclusi iOS, Android, macOS, Windows, tvOS e così via. Questa compatibilità consente di raggiungere un pubblico più vasto con i tuoi live streaming senza doversi preoccupare se potranno guardarlo o meno.
LL-HLS è un nuovo protocollo di streaming e quindi non gode di un supporto così ampio come il suo predecessore. Ciò può rendere difficile la ricerca di determinate informazioni o la risoluzione dei problemi che potresti incontrare durante la distribuzione del protocollo.
Un altro svantaggio dell'utilizzo di LL-HLS è che la sua implementazione è più complessa rispetto al normale HLS a causa delle sue funzionalità aggiuntive. A parte le principali soluzioni alternative già menzionate, LL-HLS dispone di diverse ottimizzazioni che a volte possono diventare piuttosto travolgenti.
Anche il costo coinvolto nell'implementazione di LL-HLS è superiore a quello del normale HLS a causa dell'infrastruttura aggiuntiva richiesta per lo streaming a bassa latenza. Tuttavia, questo costo vale la pena se il tuo caso d'uso richiede la distribuzione di contenuti in tempo reale.
Sebbene LL-HLS venga spesso paragonato anche a WebRTC, il suo unico confronto equo è con LL-DASH.
Ecco un rapido confronto tra i due protocolli di streaming:
LL-HLS utilizza HTTP Live Streaming (HLS) che è un protocollo proprietario Apple, mentre LL-DASH utilizza lo standard aperto Dynamic Adaptive Streaming over HTTP (DASH).
LL-HLS è progettato specificamente per i dispositivi Apple. Tuttavia, poiché è retrocompatibile con i lettori HLS, gode anche del supporto multipiattaforma e multidispositivo. LL-DASH non è supportato dai dispositivi Apple.
La latenza di LL-HLS e LL-DASH è paragonabile. Tuttavia, a seconda del caso d'uso e del calcolo richiesto, entrambi possono avere una latenza maggiore o minore.
Mentre le "parti" LL-HLS sono indirizzabili individualmente (come piccoli file o intervalli di byte nell'intero segmento), i "pezzi" (o "frammenti") LL-DASH non lo sono. Ciò significa che in LL-DASH il client non deve attendere che il server codifichi completamente il segmento prima di inviare i blocchi precedenti.
Nel protocollo HLS e DASH, il client interroga il server a intervalli regolari (diciamo 10 secondi) per verificare la presenza di aggiornamenti al fine di recuperare nuovi contenuti. Tuttavia, è possibile ottenere l'aggiornamento della playlist senza alcun polling da parte dei client sia in LL-HLS che in LL-DASH. Mentre LL-HLS lo fa con le sue direttive di consegna (_HLS_msn= , _HLS_parte= , & _HLS_skip=YES|v2), LL-DASH non dipende dall'aggiornamento del manifest affinché un giocatore possa dare un senso a un nuovo pezzo.
.webp)
In entrambi i protocolli LL-HLS e LL-DASH, la protezione del contenuto utilizza gli standard MPEG-CENC (Common Encryption). Entrambi questi protocolli supportano anche il Common Media Application Format (CMAF). In termini di codec, mentre LL-DASH è indipendente dal codec, LL-HLS consente solo codec specifici per la codifica.
Entrambi i protocolli offrono streaming con bitrate adattivo. Aiutano i giocatori a passare automaticamente tra più interpretazioni in base alle mutevoli condizioni della rete senza interrompere l'esperienza di riproduzione per gli spettatori. Tuttavia, LL-HLS è diverso in quanto dispone di più flussi per bitrate e risoluzioni diversi. LL-DASH ha solo un flusso per un bitrate e una risoluzione particolari.
Un ulteriore vantaggio di LL-HLS rispetto a LL-DASH è legato al meccanismo di protezione del contenuto, ovvero come fai a sapere se il tuo codificatore ha prodotto un file crittografato con firme valide? Per verificarlo, il protocollo HLS utilizza i tag EXT–X–KEY mentre DASH si basa su box PSSH all'interno di file MP4 o segmenti di init separati all'esterno di MP4 chiamati xlink: entrambi i metodi richiedono viaggi di andata e ritorno di rete aggiuntivi che possono introdurre ritardi significativi durante gli eventi di streaming live. Per risolvere questo problema e rendere le cose più semplici ed efficienti, Apple ha trovato una soluzione in cui includeva i valori KEY ID e IV direttamente nella playlist m3u8 in modo che i giocatori potessero convalidarli prima di scaricare qualsiasi segmento, senza bisogno di richieste/risposte aggiuntive!
LL-HLS è un'ottima scelta per lo streaming a bassa latenza se stai cercando un protocollo compatibile con tutti i principali browser e dispositivi. Tuttavia, è importante tenere presente che la sua implementazione è più complessa rispetto al normale HLS.
Nel caso avessi bisogno di aiuto, sentiti libero di contattarci.
Ti è piaciuta questa lettura?