La bassa latenza è un'aspirazione universale nei media. Quando un'azienda come Wowza produce il grafico perfetto per spiegare le tecnologie di streaming a bassa latenza, devi toglierti il cappello e utilizzare il grafico, con attribuzione e alcune piccole modifiche. Presento detto grafico come Figura 1; discutiamo nell'ordine indicato dai numeri evidenziati che ho aggiunto.
1. Applicazioni per bassa latenza
GUIDA AL PRODOTTO
Le migliori telecamere PTZ per lo streaming live
Solo per essere sicuri che siamo tutti sulla stessa pagina, la latenza nel contesto del live streaming significa il ritardo vetro-vetro. Il primo bicchiere è la telecamera dell'evento dal vivo, il secondo è lo schermo che stai guardando. La latenza è il ritardo tra il momento in cui appare nella fotocamera e quando viene visualizzato sul telefono. Contribuiscono alla latenza fattori come il tempo di codifica (all'evento), il tempo di trasporto nel cloud, il tempo di transcodifica nel cloud (per creare la scala di codifica), il tempo di consegna e, in modo critico, quanti secondi il tuo giocatore bufferizza prima di iniziare a giocare.
Il livello superiore mostra le applicazioni tipiche e i loro requisiti di latenza. Applicazioni popolari che mancano di bassa latenza e latenza quasi in tempo reale sono i siti di gioco d'azzardo e di aste.
Prima di immergerti nella nostra discussione sulla tecnologia, tieni presente che minore è la latenza del tuo live streaming, meno resiliente è lo streaming alle interruzioni della larghezza di banda. Ad esempio, utilizzando le impostazioni predefinite, uno stream HLS verrà riprodotto per oltre 15 secondi di larghezza di banda interrotta e, se viene ripristinato a quel punto, lo spettatore potrebbe non sapere mai che c'è stato un problema. Al contrario, un flusso a bassa latenza interromperà la riproduzione quasi immediatamente dopo un'interruzione. Quindi, il vantaggio del tempo di avvio a bassa latenza deve sempre essere bilanciato con il negativo delle interruzioni della riproduzione. Se non hai assolutamente bisogno di una bassa latenza, potrebbe non valere la pena sacrificare la resilienza per ottenerla.
Detto questo, è utile dividere la latenza in tre categorie, come segue.
NEWSLETTER PROAudio + Video + IT. I nostri redattori sono esperti nell'integrazione di audio / video e IT. Ottieni approfondimenti quotidiani, notizie e networking professionale. Abbonati a Pro AV oggi.
- Bello avere - Più veloce è sempre meglio, ma se stai trasmettendo in live streaming una riunione del Board of Education o una partita di football del liceo, potresti decidere che la robustezza dello streaming è più importante della bassa latenza, in particolare se molti spettatori guardano con connessioni a bassa velocità di trasmissione.
- Vantaggio competitivo - In alcuni casi, la bassa latenza fornisce un vantaggio competitivo o la latenza lenta significa uno svantaggio competitivo. Noterai nel grafico che la latenza tipica per la TV via cavo è di circa cinque secondi. Se il tuo servizio di streaming è in competizione con il cavo, devi rientrare in tale intervallo, con una latenza inferiore che fornisce un modesto vantaggio competitivo.
- Comunicazioni in tempo reale - Se sei un sito di giochi a distanza o di aste, o se la tua applicazione richiede comunicazioni in tempo reale, devi assolutamente fornire una bassa latenza.
- Guida comparativa in live streaming
- Come prevedere il successo del codec
Ora che conosciamo le categorie, esaminiamo il modo più efficiente per fornire il livello di bassa latenza necessario.
2/3 Bello avere una bassa latenza
Il numero 2 mostra che Apple HLS e MPEG-DASH distribuiti utilizzando le impostazioni predefinite producono circa 30 secondi di latenza. I numeri sono semplici; se utilizzi segmenti di dieci secondi e richiedi che tre segmenti siano nel buffer del lettore prima che inizi la riproduzione, sei a trenta secondi. In verità, Apple ha cambiato i propri requisiti da dieci secondi a sei secondi pochi anni fa e la maggior parte dei produttori di DASH utilizza segmenti da 4-6 secondi, quindi il numero predefinito è davvero più vicino a 20 secondi.
Tuttavia, il numero 3, HLS Tuned e DASH Tuned, mostra una latenza di circa 6-8 secondi. In sostanza, sintonizzare significa passare da segmenti di 10 secondi a segmenti di 2 secondi che, applicando la stessa matematica, forniscono i 6-8 secondi di latenza. Quindi, quando la latenza è piacevole da avere, puoi ridurre drasticamente la latenza senza tempi o costi di sviluppo o un rischio di consegna significativamente maggiore.
4. Vantaggio competitivo - Tecnologie HTTP a bassa latenza
Quando è necessaria una bassa latenza come vantaggio competitivo, non basta tagliare le dimensioni dei segmenti; dovrai implementare una vera tecnologia a bassa latenza. Qui ci sono due classi; Tecnologie HTTP come HLS a bassa latenza e CMAF a bassa latenza per DASH e soluzioni basate su altre tecnologie, come WebSocket e WebRTC.
Per la maggior parte dei produttori con applicazioni di questa classe, le tecnologie HTTP a bassa latenza offrono la migliore combinazione di convenienza, compatibilità con le versioni precedenti, flessibilità e set di funzionalità. Quindi, tratterò HLS a bassa latenza e CMAF a bassa latenza per DASH in questa sezione e altre tecnologie nella prossima.
Tutti i sistemi a bassa latenza basati su HLS / DASH / CMAF funzionano allo stesso modo di base, come mostrato nella Figura 2. Cioè, invece di aspettare che venga codificato un segmento completo, che in genere richiede tra 6-10 secondi (parte superiore della Figura 2) , il codificatore crea blocchi molto più brevi che vengono trasferiti alla rete CDN non appena sono completi (parte inferiore della Figura 2).
Ad esempio, se il tuo codificatore stava producendo segmenti di sei secondi, avresti almeno sei secondi di latenza; triplicare quello se i tre segmenti normali dovessero essere ricevuti dallo spettatore prima dell'inizio della riproduzione. Se il tuo codificatore ha spinto fuori blocchi ogni 200 millisecondi, tuttavia, e il lettore è stato configurato per avviare la riproduzione immediatamente, la latenza dovrebbe essere molto, molto inferiore. Un vantaggio chiave di questo schema è la compatibilità con le versioni precedenti; poiché i segmenti sono ancora in fase di creazione, i giocatori non compatibili con lo schema a bassa latenza dovrebbero comunque essere in grado di riprodurre i segmenti, anche se con una latenza più lunga. Questi segmenti sono anche immediatamente disponibili per le presentazioni VOD dal live streaming.
Oltre a questi vantaggi, le tecnologie HTTP a bassa latenza supportano la maggior parte delle funzionalità dei loro normali fratelli di latenza, tra cui crittografia, inserimento di pubblicità e sottotitoli, che non sono universalmente supportati nelle tecnologie WebRTC e basate su WebSocket. È probabile che tu possa implementare la tecnologia a bassa latenza selezionata utilizzando il player esistente e l'infrastruttura di distribuzione, riducendo al minimo i costi di sviluppo e altri costi tecnologici.
Scelta di una tecnologia HTTP a bassa latenza
Esistono due standard principali per HTTP Adaptive Streaming, HLS e DASH, oltre a un formato contenitore unificante, CMAF. Una volta che Apple ha annunciato la sua soluzione HLS a bassa latenza, ha immediatamente sostituito diversi sforzi di base ed è diventata la tecnologia preferita per fornire bassa latenza a HLS. Sebbene le specifiche siano ancora relativamente nuove, sono già supportate da fornitori di tecnologia come Wowza e WMSPanel con il loro prodotto Nimble Streamer.
Esiste uno standard DVB per DASH a bassa latenza e il DASH Industry Forum ha approvato diverse modalità a bassa latenza per DASH da includere nelle loro prossime linee guida sull'interoperabilità. In base a tutte queste specifiche, gli sviluppatori di codificatori e lettori e le reti di distribuzione dei contenuti hanno lavorato per diversi anni per garantire l'interoperabilità in modo che tutte le applicazioni a bassa latenza DASH / CMAF dovessero iniziare a funzionare.
Ad esempio, Harmonic e Akamai insieme hanno dimostrato CMAF a bassa latenza fin dal NAB e IBC 2017, mostrando la consegna OTT in tempo reale con una latenza inferiore a cinque secondi. Da allora, Harmonic ha integrato la funzionalità DASH a bassa latenza nei propri prodotti basati su appliance (Packager XOS ed Electra XOS) e nelle soluzioni SaaS (VOS Cluster e VOS260). Molti altri produttori di codificatori e lettori hanno fatto lo stesso.
Sia che tu scelga di implementare HLS a bassa latenza o Bassa latenza per DASH, o entrambi, la transizione dall'architettura di consegna HLS e / o DASH esistente dovrebbe essere relativamente semplice ed economica.
5. Comunicazioni in tempo reale
WebRTC è in genere il motore di un pacchetto integrato che include l'encoder, il lettore e l'infrastruttura di distribuzione. Esempi di soluzioni di streaming su larga scala basate su WebRTC includono Real Time di Phenix, Limelight Realtime Streaming e Millicast di CoSMo Software e Influxis (Figura 3). Puoi anche accedere alla tecnologia WebRTC in strumenti come Wowza Streaming Engine, CoSMO Software e Red 5 Pro Server. I tempi di latenza per le tecnologie di questa classe vanno da 0,5 secondi per il 71% dei flussi (Phenix), meno di 500 millisecondi (Red5 Pro), a meno di un secondo (Limelight). Se hai bisogno di una latenza inferiore ai due secondi, WebRTC è un'opzione che devi considerare.
Se hai bisogno di comunicazioni in tempo reale, probabilmente dovrai implementare una soluzione WebRTC o basata su Websockets. WebRTC è stato formulato per le comunicazioni da browser a browser ed è supportato da tutti i principali browser desktop, su Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 e BlackBerry 10, quindi dovrebbe funzionare senza download su nessuna di queste piattaforme. Come suggerisce il nome, WebRTC è un protocollo per la distribuzione di flussi live a ciascun visualizzatore, peer-to-peer o server to peer.
WebSocket è un protocollo in tempo reale che crea e mantiene una connessione persistente tra un server e un client che entrambe le parti possono utilizzare per trasmettere i dati. Questa connessione può essere utilizzata per supportare sia la trasmissione video che altre comunicazioni, quindi è utile se l'applicazione richiede l'interattività. Come le implementazioni WebRTC, i servizi che utilizzano WebSocket sono generalmente offerti come un servizio che include lettore e CDN ed è possibile utilizzare qualsiasi codificatore in grado di trasportare flussi al server tramite RTMP o WebRTC. Gli esempi includono nanoStream Cloud di Nanocosmos e Streaming Cloud di Wowza con latenza ultra bassa. Wowza sostiene una latenza inferiore a 3 secondi per la loro soluzione, mentre Nanocosmos sostiene circa un secondo, vetro su vetro.
Altre tecnologie a bassa latenza
Esiste una quarta categoria di prodotti meglio denominata "altro" che utilizza tecnologie diverse per fornire una bassa latenza. Questa categoria include THEO Technologies High Efficiency Streaming Protocol (HESP), un protocollo di streaming adattivo HTTP proprietario che secondo THEO offre una latenza inferiore a 100 millisecondi riducendo la larghezza di banda di circa il 10% rispetto ad altre tecnologie a bassa latenza. HESP utilizza codificatori standard e CDN ma richiede supporto personalizzato nel packager e nel lettore (Figura 4). Puoi leggere di più su HESP in un white paper disponibile per il download, qui.
Di seguito è riportato un elenco di domande da considerare quando si decide quale tecnologia a bassa latenza implementare e come farlo.
Costruire o acquistare?
Se implementi tu stesso la tecnologia, assicurati di rispondere a tutte le domande elencate di seguito prima di scegliere una tecnologia. Se scegli un fornitore di servizi, utilizzalo per confrontare i diversi fornitori di servizi.
Stai scegliendo uno standard o un partner?
Abbiamo delineato le diverse tecnologie per ottenere una bassa latenza sopra, ma le implementazioni variano da fornitore di servizi a fornitore di servizi. Quindi, non tutta l'implementazione di LL HLS includerà la consegna ABR, almeno non all'inizio. La maggior parte delle applicazioni di tipo broadcast tradizionali migreranno probabilmente verso standard basati su HTTP come HLS / DASH / CMAF a bassa latenza, mentre le applicazioni che richiedono una latenza ultra bassa come le scommesse e le aste graviteranno verso le altre tecnologie. In entrambi i casi, quando si sceglie un fornitore di servizi è più importante determinare se può soddisfare i propri obiettivi tecnologici e di business rispetto alla tecnologia che effettivamente implementa.
Può scalare ea quale costo?
Uno dei vantaggi delle tecnologie basate su HTTP è che scalano a prezzi standard utilizzando la maggior parte dei CDN. Al contrario, la maggior parte delle tecnologie basate su WebRTC e WebSocket richiedono un'infrastruttura di distribuzione dedicata implementata dal fornitore di servizi. Per questo motivo, i servizi non basati su HTTP possono essere più costosi da fornire rispetto a HLS / DASH / CMAF. Quando si confrontano i fornitori di servizi, accertarsi del costo minimo dell'evento, inclusi ingresso, transcodifica, larghezza di banda, creazione di file VOD, configurazioni una tantum o per evento e simili.
Problemi relativi all'implementazione?
Poni le seguenti domande relative all'implementazione e all'utilizzo della tecnologia.
- Qual è la latenza ottenibile su una scala pertinente alla dimensione del tuo pubblico e alla distribuzione geografica?
- Ci sono limitazioni di qualità - alcune tecnologie potrebbero essere limitate a determinate risoluzioni massime o profili H.264.
- I pacchetti passeranno attraverso un firewall? I sistemi basati su HTTP utilizzano protocolli HTTP, che sono compatibili con il firewall. Altri usano UDP, che potrebbe non passare automaticamente attraverso i firewall. Se UDP, ci sono canali di ritorno da consegnare agli spettatori bloccati?
- Quali piattaforme sono supportate? Presumibilmente computer e dispositivi mobili, ma per quanto riguarda STB, dongle, dispositivi OTT e smart TV?
- Il sistema può scalare per soddisfare i numeri di spettatori target? L'infrastruttura CDN è privata e, in caso affermativo, può fornire a tutti i telespettatori rilevanti in tutti i mercati rilevanti? Quali sono i costi previsti per il ridimensionamento?
- Puoi usare il tuo lettore o devi usare il lettore del sistema? Se il tuo, quali modifiche sono necessarie e quanto costerà?
- Cosa è necessario per la riproduzione su dispositivi mobili? Gli stream verranno riprodotti in un browser o è necessaria un'app? Se è necessaria (o desiderabile) un'app, sono disponibili gli SDK?
- Quali encoder può utilizzare il sistema? La maggior parte dovrebbe utilizzare qualsiasi codificatore in grado di supportare le connessioni RTMP nel transcodificatore cloud, ma controlla se sono necessari altri protocolli.
- Il contenuto può essere riutilizzato per VOD o sarà necessaria la ricodifica? Non è un grosso problema poiché costa circa $ 20 / ora di video per transcodificare in una scala di codifica ragionevole ma costoso per trasmissioni frequenti.
- Quali sono le opzioni di ridondanza e quali sono i costi? Per le trasmissioni mission-critical, ti consigliamo di sapere come duplicare il flusso di lavoro di codifica / trasmissione in caso di guasto di qualsiasi componente del sistema durante l'evento. Questa ridondanza è supportata e qual è il costo?
Quali funzionalità sono disponibili e su quale scala?
Ci sarà un'ampia varietà di offerte di funzionalità dai diversi fornitori, che possono includere o meno:
- Streaming ABR - quanti flussi e ci sono limiti di velocità in bit o di risoluzione rilevanti?
- E le funzionalità del DVR? Gli spettatori possono interrompere e riavviare la riproduzione senza perdere alcun contenuto.
- Sincronizzazione video - Il sistema può sincronizzare tutti i visualizzatori nello stesso punto dello stream? I flussi possono spostarsi su posizioni e dispositivi e, senza questa funzionalità, gli utenti su alcune connessioni potrebbero avere un vantaggio per le aste o il gioco d'azzardo.
- Quale protezione dei contenuti è disponibile? Se sei un produttore di contenuti premium, potresti aver bisogno di un vero DRM. Altri possono cavarsela con l'autenticazione o altre tecniche simili.
- I sottotitoli sono disponibili? I sottotitoli sono legalmente richiesti per alcune trasmissioni ma generalmente sono utili per tutti.
- E per quanto riguarda l'inserimento di pubblicità o altri schemi di monetizzazione? La tecnologia / fornitore di servizi lo supporta?
In generale, se sei un negozio di streaming che cerca di soddisfare o battere i tempi di trasmissione nell'intervallo da 5 a 6 secondi, una tecnologia HTTP basata su standard è probabilmente la soluzione migliore, poiché si avvicinerà di più a supportare le stesse funzionalità che hai impostato " stai attualmente utilizzando, come la protezione dei contenuti, i sottotitoli e la monetizzazione. Se hai un'applicazione che richiede una latenza molto più bassa, probabilmente avrai bisogno di una soluzione basata su WebRTC o Websockets o una tecnologia HTTP proprietaria. In entrambi i casi, porre le domande sopra elencate dovrebbe aiutarti a identificare la tecnologia e / o il fornitore di servizi che meglio soddisfa le tue esigenze.