Mentre i dollari pubblicitari e gli spettatori continuano ad allontanarsi dalla televisione tradizionale, i proprietari di contenuti e le emittenti stanno cercando di trasmettere in streaming eventi live supportati dagli annunci per coinvolgere nuovi spettatori e aumentare le entrate attraverso lo streaming OTT (Over-the-Top) . L’OTT offre nuove opportunità di distribuzione, che consentono a un editore di trasmettere e monetizzare contenuti concessi in licenza che in precedenza non avevano posto nelle trasmissioni televisive. Tuttavia, prima che un editore possa iniziare a trasmettere in streaming eventi live, è necessario considerare gli ostacoli tecnici nella prima fase del flusso di lavoro dello streaming video:
- La qualità della connessione e la disponibilità della larghezza di banda tra la sede e il punto di acquisizione possono rappresentare un punto debole nel flusso di lavoro. Ridondanza e affidabilità devono essere integrate.
- I feed live devono essere codificati in vari formati e protocolli di bitrate adattivi, come Apple HLS e MPEG-DASH, riducendo al minimo la latenza.
- Le soluzioni di caricamento e codifica devono essere a prova di futuro, affidabili e scalabili per gestire l’emergere di formati 4K e altri formati di alta qualità.
- Il flusso di lavoro dei video dovrebbe essere in grado di supportare l’inserimento di annunci lato server per la migliore esperienza di visualizzazione e le strategie di monetizzazione più appropriate.
In questo blog sulla tecnologia, esaminiamo come abbiamo costruito la nostra piattaforma per consentire a un editore di ottimizzare il primo passo nel flusso di lavoro dello streaming video, esaminiamo alcune delle sfide coinvolte e spieghiamo come codifichiamo lo streaming live per consentire lo streaming live ad alte prestazioni, bassa latenza e supportato dagli annunci.
Background: Affettatrice
Prima di immergerci nelle considerazioni tecniche della codifica, dobbiamo spiegare la nostra tecnologia chiamata “affettatrice”. Un potente client software, The Slicer, rampe il live streaming della tua sede sulla nostra piattaforma video cloud. Semplifica un’attività straordinariamente complessa senza sacrificare flessibilità e funzionalità. L’affettatrice è uno dei motivi principali per cui le emittenti con ampie risorse tecniche e quelle prive di risorse possono sfruttare la nostra piattaforma per creare esperienze OTT altamente differenziate.
La affettatrice prepara il contenuto per la codifica, calcola le impostazioni di codifica ideali e gestisce i marcatori di inserimento degli annunci. È possibile eseguire la affettatrice sul proprio hardware sicuro o scegliere il risparmio sui costi e la scalabilità delle ubicazioni indipendenti dal cloud che supportano vari formati, tra cui SDI, video IP, RTP/FEC e RTMP.
Slicer suddivide i tuoi contenuti in piccoli pezzi e li crittografa prima di inviarli al nostro stack di codifica cloud certificato ISO, offrendoti la tranquillità di sapere che i tuoi contenuti sono sempre sicuri. Offre una gamma flessibile di flussi di lavoro, da semplici configurazioni con un solo clic a script più avanzati nel linguaggio di programmazione preferito alla scrittura di funzioni cloud che attivano flussi di lavoro per notifiche, elaborazione dei processi e integrazioni di apprendimento automatico.
“La nostra “Live Slicer”, una versione della Slicer, è ottimizzata per lo streaming di eventi live.” I feed HD-SDI o basati su IP vengono rapidamente acquisiti e suddivisi in segmenti crittografati di 2 o 4 secondi al bitrate più elevato desiderato, riducendo i requisiti di larghezza di banda a 3-5 Mbps per 1080p e circa 15 Mbps per 4K. Il nostro processo conserva automaticamente i metadati e i messaggi in banda e fuori banda per attivare interruzioni di programma e pubblicità o sostituire i contenuti. La nostra architettura plug-in consente di creare script personalizzati che gestiscono i requisiti specifici degli eventi di segnalazione. Live Slicer può anche ascoltare i messaggi SCTE 35 / 104 o ricevere chiamate API per inserire interruzioni pubblicitarie, avvii di contenuti o trigger di blackout.
Un flusso OTT viene generato da un feed live lineare con un investimento iniziale minimo e requisiti di larghezza di banda ridotti.
Riduzione della larghezza di banda
Ora che avete compreso la licenza, vi starete chiedendo perché dovremmo sviluppare un componente software front-end per trasferire i flussi live dagli eventi al cloud. Perché gli editori non potevano inviare un flusso RTMP (Real-Time Messaging Protocol), ad esempio? (Puoi farlo se lo desideri, ma la maggior parte dei nostri clienti trae vantaggio dalla affettatrice). La risposta riguarda le aspettative dei consumatori in merito a flussi live di alta qualità quanto la risoluzione dei problemi legati alla larghezza di banda nei luoghi live. Si tratta di trovare il giusto equilibrio tra molti fattori concorrenti. Da un lato, è necessario conservare la maggior parte del feed originale possibile, con un occhio rivolto a formati di qualità superiore e 4K. D’altra parte, è necessario ottimizzare il flusso in modo che possa essere distribuito in modo efficiente senza doversi impantanare da costi aggiuntivi, come la pubblicità personalizzata. Trovare il giusto equilibrio è fondamentale per questa fase del flusso di lavoro video.
Ecco dove la affettatrice è essenziale. Come indicato in precedenza, riduce significativamente la larghezza di banda richiesta per un dato feed creando il profilo bitrate più alto sul sito e inviandolo solo al cloud. Nella nostra osservazione, basata sullo streaming di milioni di ore di riprese in diretta a miliardi di spettatori in tutto il mondo, l’approccio alternativo di inviare un flusso RTMP significativamente più grande sul cloud non comporta un aumento apprezzabile della qualità dell’esperienza visiva. Ma aumenta notevolmente la larghezza di banda, con un conseguente aumento dei costi.
I costi di backhaul possono aumentare rapidamente. Se le vostre esigenze sono tali da richiedere un uplink satellitare, un camion Ka-band, ad esempio, affitta circa $ 2.000 al giorno e la larghezza di banda costa circa $ 400 all’ora. Date le condizioni incoerenti e limitate in termini di larghezza di banda in alcuni luoghi, come hotel o centri congressi, o anche strutture sportive in tutto il mondo, il risultato è che è sempre una buona idea ridurre al massimo i requisiti di larghezza di banda di upload, garantendo al contempo di offrire ai propri spettatori un’esperienza di tipo broadcast.
Ostacoli alla codifica
Una volta che il feed video live lascia la sede, la fase successiva del flusso di lavoro è la codifica. In questo caso, un encoder video crea più versioni o varianti di audio e video a diversi bitrate, risoluzioni e livelli di qualità. Quindi segmenta le varianti in piccoli file o segmenti multimediali. È necessario eseguire diversi passaggi aggiuntivi, come la creazione di una playlist multimediale per ogni variante contenente un elenco di URL che indichino i segmenti multimediali della variante. La playlist principale risultante è la scelta del giocatore della variante più appropriata per il dispositivo e la larghezza di banda attualmente misurata o disponibile.
Due dei principali protocolli di streaming video aumentano la complessità, mentre altri potrebbero dover essere supportati per coprire la miriade di potenziali dispositivi di riproduzione. HLS è un protocollo di comunicazione per lo streaming multimediale basato su HTTP implementato da Apple. Offre supporto per tutti i dispositivi Apple e per la maggior parte dei browser e dei dispositivi Google, Android, Linux e Microsoft. Quasi tutti, ma non tutti. È inoltre necessario MPEG-DASH, un protocollo di streaming multimediale basato su HTTP concorrente. Potrebbe anche essere necessario aggiungere il supporto per Microsoft Smooth streaming per console di gioco.
La tecnologia DRM può inoltre complicare la codifica richiedendo un proprio set di formati multipli per supportare i requisiti di un pubblico di grandi dimensioni. Ad esempio, i giocatori più anziani che non supportano il DRM hanno bisogno di HLS e AES-128. I dispositivi iOS meno recenti richiedono HLS e FairPlay. I dispositivi iOS più recenti supportano HLS, FairPlay e CMAF CBC. Le versioni precedenti di Windows e Android supportano solo CMAF CTR. Android, Windows e iOS più recenti dovrebbero supportare tutti i formati CMAF. I contenuti devono essere confezionati in più formati per consentire la riproduzione su tutti i dispositivi.
Se questo sembra un sacco di lavoro di codifica, hai ragione. Man mano che le risoluzioni aumentano e i codec diventano più complessi, diventa più difficile codificare una scala di codifica ABR completa su un singolo computer, sia nel cloud che in sede. Se l’hardware di codifica non è all’altezza del compito di stare al passo con il live feed, potrebbe essere necessario ridurre il numero di pioli nella scala di codifica, il che potrebbe in ultima analisi influire sull’esperienza del pubblico.
Per tenere il passo con requisiti di codifica più complessi, il modello tradizionale implica che i produttori devono investire continuamente in nuovo hardware per mantenere velocità e qualità. In definitiva, per un servizio di streaming come Edgio, ex Verizon Digital Media Services, il modello stream-to-encoder 1:1 non è in grado di offrire l’affidabilità, la flessibilità e la scalabilità necessarie per soddisfare le aspettative dei nostri clienti.
Abbiamo invece sviluppato un sofisticato sistema di brokering che consente l’uso di tutti gli encoder necessari, il tutto eseguito in un’infrastruttura basata su cloud. Il sistema di intermediazione riceve i frammenti di contenuto dalle istanze di affettatura e li sposta sul codificatore più ottimale. Questa azione impedisce ai processi di codifica di sovraccaricare una macchina specifica e mantiene i frammenti in movimento attraverso il sistema fino allo storage e agli spettatori.
Il processo di broker aumenta la nostra infrastruttura di encoder cloud in modo fluido e, cosa ancora più importante, automatico.
Nella nostra implementazione, un’istanza di broker funge da manager che parla tra la affettatrice e gli encoder. Il broker assicura che ogni nuova affettatrice venga instradata all’encoder appropriato e verifica che l’encoder sia in grado di gestire il carico di lavoro. Inoltre, disponiamo di un’infrastruttura di scalabilità molto efficiente. Se all’improvviso veniamo scaricati con un milione di ore di contenuti VOD che devono essere codificati, possiamo aumentare rapidamente le istanze dei server e iniziare a elaborare i contenuti. Possiamo anche ridurre la scala in modo altrettanto rapido per risparmiare risorse. Questo processo di intermediazione gestisce l’intera infrastruttura cloud senza problemi e, cosa ancora più importante, automaticamente.
Encoder stateless
Naturalmente, il sistema di intermediazione sarebbe di valore limitato se tutto quello che potrebbe fare è puntare una affettatrice a un singolo encoder che può o meno essere in grado di tenere il passo con le richieste del live streaming, un problema serio con 4K. La soluzione che abbiamo sviluppato prevede l’uso di encoder stateless. Invece di dedicare una singola macchina all’intero flusso, ogni encoder riceve solo un singolo segmento di video di 2 o 4 secondi alla volta. Ogni segmento include informazioni sufficienti per adescare l’encoder in modo da poterlo codificare ed eliminare qualsiasi elemento non necessario per i priming, come le informazioni di lead-in e lead-out. A questo punto, l’intero segmento è completato e pronto per l’uso, liberando l’encoder in modo che possa iniziare a codificare un altro contenuto da un altro canale o da qualsiasi altra cosa.
Questo modello ha anche una notevole quantità di ridondanza integrata nel sistema. Ad esempio, se un encoder si blocca durante l’elaborazione di un segmento, lo stesso segmento si avvia su un’altra macchina e viene eseguito in tempo prima che eventuali problemi vengano notati all’interno del flusso.
Questo approccio consente anche l’uso di hardware più conveniente. Ad esempio, se sappiamo che una macchina più lenta può impiegare 8 secondi per elaborare un file di 4 secondi da una affettatrice, possiamo distribuire il carico di lavoro su più codificatori come mostrato di seguito: Il server A ottiene la sezione 1, il server B riceve la sezione 2 e così via. Poi, i pezzi sono stati consegnati senza problemi perché sono stati tutti completati in un momento prevedibile. Come mostrato nel grafico seguente, questo esempio comporterebbe una latenza di 16-20 secondi rispetto al live.
L’utilizzo di più codificatori nel cloud riduce al minimo la latenza e consente l’utilizzo di server che altrimenti non sarebbero in grado di tenere il passo con un feed live.
In definitiva, il volume dei server nel cloud, anche se i singoli server sono più lenti, significa che i processi di codifica possono sempre stare al passo con le richieste in tempo reale. Se si desidera configurare un’infrastruttura di codifica utilizzando un modello tradizionale, è necessario investire in costose macchine ad alte prestazioni o hardware speciale, ciascuno in grado di elaborare l’intero video in arrivo senza assistenza in tempo reale. Sfruttando la scalabilità del cloud, riduciamo notevolmente i costi di codifica.
Un altro vantaggio della codifica cloud stateless è che possiamo facilmente spostare i carichi di lavoro a provider cloud alternativi, poiché non abbiamo requisiti specifici per i server. Con una rete di oltre 250 Tbps di capacità, un approccio multi-cloud offre vantaggi intrinseci.
Live streaming a costi contenuti
Per i produttori di contenuti live, le considerazioni tecniche per preparare i video live per lo streaming cloud possono presentare ostacoli formidabili. Dovrai affrontare vari problemi che vanno dalle limitazioni della larghezza di banda della sede alle domande complesse relative agli encoder e ai protocolli di streaming. Sebbene non elimini la necessità di una certa connettività presso la sede, un flusso di lavoro semplificato con requisiti di larghezza di banda ridotti sul front-end può ridurre drasticamente le spese iniziali e continue, offrendo al contempo flussi di alta qualità e a bassa latenza che i tuoi spettatori si aspettano.
