Home Articoli tecnici Codifica video nel cloud per lo streaming di eventi live su larga scala
Applications

Codifica video nel cloud per lo streaming di eventi live su larga scala

About The Author

Outline

Mentre gli spettatori e i dollari della pubblicità continuano ad allontanarsi dalla televisione tradizionale, i proprietari di contenuti e le emittenti stanno cercando lo streaming di eventi live supportati dagli annunci per coinvolgere nuovi spettatori e aumentare i ricavi attraverso lo streaming OTT (Over-the-Top). 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 nella trasmissione televisiva. Tuttavia, prima che un editore possa iniziare a trasmettere eventi live in streaming, è 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 anello debole nel flusso di lavoro. La ridondanza e l’affidabilità devono essere integrate.
  • I feed live devono essere codificati in vari formati e protocolli di velocità di trasmissione 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 video dovrebbe essere in grado di supportare l’inserimento di annunci sul 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 il live streaming per consentire lo streaming live ad alte prestazioni, bassa latenza e supportato da annunci pubblicitari.

‍Background: L’affettatrice

Prima di approfondire le considerazioni tecniche della codifica, dobbiamo spiegare la nostra tecnologia chiamata “Slicer”. Un potente client software, The Slicer, mette in onda il live streaming della tua sede sulla nostra piattaforma video cloud. Semplifica un’attività straordinariamente complessa senza sacrificare flessibilità e funzionalità. Slicer è un motivo fondamentale per cui le emittenti con ampie risorse tecniche e quelle senza alcuna risorsa possono sfruttare la nostra piattaforma per creare esperienze OTT fortemente differenziate.

L’affettatrice prepara i contenuti per la codifica, calcola le impostazioni di codifica ideali e gestisce i marcatori di inserimento degli annunci. È possibile eseguire l’affettatrice sul proprio hardware sicuro o scegliere il risparmio sui costi e la scalabilità delle posizioni 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, per offrirti la tranquillità di sapere che i tuoi contenuti sono sempre al sicuro. Offre una gamma flessibile di flussi di lavoro, dalle semplici configurazioni con un solo clic agli script più avanzati nel linguaggio di programmazione prescelto alla scrittura di funzioni cloud che attivano flussi di lavoro per notifiche, elaborazione dei lavori e integrazioni di apprendimento automatico.

“La nostra “Live Slicer”, una versione di The Slicer, è ottimizzata per lo streaming di eventi live.” I feed HD-SDI o basati su IP vengono rapidamente acquisiti e suddivisi in segmenti crittografati da 2 o 4 secondi con il 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 programmi e annunci 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 messaggi SCTE 35 / 104 o ricevere chiamate API per inserire interruzioni pubblicitarie, avvio di contenuti o trigger di blackout.

Un flusso OTT viene generato da un feed lineare live con un investimento iniziale minimo e requisiti di larghezza di banda ridotti.

Riduzione della larghezza di banda

Ora che conoscete il livello Dilicenza, vi chiederete perché dovremmo sviluppare un componente software front-end per spostare i live streaming dagli eventi al cloud. Perché gli editori non potevano inviare tramite un flusso RTMP (Real-Time Messaging Protocol), ad esempio? (Potete farlo se volete, ma la maggior parte dei nostri clienti si avvale di The Slicer.)la risposta ha tanto a che fare con le aspettative dei consumatori per i live streaming di alta qualità quanto con la risoluzione dei problemi relativi alla larghezza di banda nei live event. Si tratta di trovare il giusto equilibrio tra molti fattori concorrenti. Da un lato, è necessario preservare il più possibile la quantità di mangime originale, 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 essere bloccato da costi aggiuntivi, come ad esempio la pubblicità personalizzata. Trovare il giusto equilibrio è fondamentale per questa fase del flusso di lavoro video.

Ecco dove l’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 inviando solo quel profilo al cloud. Secondo la nostra osservazione, basata sullo streaming di milioni di ore di filmati live 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 significativo della qualità dell’esperienza di visione. Ma aumenta significativamente la larghezza di banda, con conseguente aumento dei costi.

I costi di backhaul possono aumentare rapidamente. Se le vostre esigenze sono tali che avete bisogno di un uplink satellitare, un camion in banda Ka, ad esempio, affitta per circa $ 2.000 al giorno e la larghezza di banda costa circa $ 400 all’ora. Date le condizioni incoerenti e vincolate alla larghezza di banda in alcune sedi, come alberghi o centri conferenze, o anche nelle sedi sportive di tutto il mondo, il risultato è che è sempre una buona idea ridurre al massimo i requisiti di larghezza di banda per il caricamento, garantendo al tempo stesso un’esperienza di tipo broadcast ai tuoi spettatori.

Codifica degli ostacoli

Una volta che il feed video live lascia la sede, il passaggio successivo del flusso di lavoro è la codifica. In questo caso, un codificatore video crea più versioni o varianti dell’audio e del video a diversi bitrate, risoluzioni e livelli di qualità. Quindi segmenta le varianti in piccoli file o segmenti multimediali. Devono essere eseguite diverse fasi aggiuntive, ad esempio la creazione di una playlist multimediale per ciascuna variante contenente un elenco di URL che indichino i segmenti media 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 principali protocolli di streaming video aumentano la complessità e altri potrebbero dover essere supportati per coprire la miriade di potenziali dispositivi di riproduzione. HLS è un protocollo di comunicazione di streaming multimediale basato su HTTP implementato da Apple. Offre il supporto per tutti i dispositivi Apple e per la maggior parte dei browser e dei dispositivi Google, Android, Linux e Microsoft. La maggior parte, ma non tutte. È inoltre necessario disporre di MPEG-DASH, un protocollo di streaming multimediale basato su HTTP concorrente. Potrebbe inoltre essere necessario aggiungere il supporto per Microsoft Smooth streaming per le 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 DRM hanno bisogno di HLS e AES-128. I dispositivi iOS meno recenti richiedono HLS e FairPlay. I dispositivi iOS più recenti supportano HLS e FairPlay e CMAF CBC. Le versioni precedenti di Windows e Android supportano solo CTR CMAF. Le versioni più recenti di Android, Windows e iOS dovrebbero supportare tutti i formati CMAF. I contenuti devono essere confezionati in più formati per consentire la riproduzione su tutti i dispositivi.

Se questo suona come 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 una singola macchina, sia nel cloud che in sede. Se l’hardware di codifica non è all’altezza del compito di stare al passo con il feed live, potrebbe essere necessario ridurre il numero di pioli sulla scala di codifica, il che potrebbe influenzare l’esperienza del pubblico.

Per stare al passo con requisiti di codifica più complessi, il modello tradizionale implica che i produttori devono continuamente investire in nuovo hardware per mantenere velocità e qualità. In definitiva, per un servizio di streaming come Edgio, precedentemente Verizon Digital Media Services, il modello 1:1 stream-to-encoder 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 i codificatori necessari, tutti eseguiti in un’infrastruttura basata su cloud. Il sistema di intermediazione riceve i frammenti di contenuto dalle istanze Slicer e li sposta sull’encoder ottimale. Questa azione impedisce ai processi di codifica di sovraccaricare una macchina specifica e fa sì che i pezzi si spostino attraverso il sistema fino allo storage e agli spettatori.

Il processo di intermediazione consente di scalare la nostra infrastruttura di codificatori cloud in modo fluido e, cosa ancora più importante, automatico.

Nella nostra implementazione, un’istanza di broker agisce come un manager che parla tra Slicer e gli encoder. Il broker garantisce che qualsiasi nuova affettatrice riceva i dati al codificatore appropriato e verifica che l’encoder sia in grado di gestire il carico di lavoro. Inoltre, disponiamo di un’infrastruttura di scalabilità molto efficace. Se improvvisamente 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 ridimensionare la nostra attività in modo altrettanto rapido per conservare le risorse. Questo processo di intermediazione gestisce l’intera infrastruttura cloud senza problemi e, cosa ancora più importante, automaticamente.

Codificatori stateless

Naturalmente, il sistema di intermediazione sarebbe di valore limitato se tutto quello che potrebbe fare è puntare una Slicer a un singolo encoder che può o non può essere in grado di tenere il passo con le richieste del live streaming, un grave problema con 4K. La soluzione che abbiamo sviluppato prevede l’uso di codificatori stateless. Invece di dedicare una singola macchina all’intero flusso, ogni encoder riceve solo un singolo segmento video di 2 o 4 secondi alla volta. Ogni segmento include informazioni sufficienti per eseguire il priming del codificatore in modo che possa codificare quel segmento e scartare tutto ciò che non è necessario per i primings, come le informazioni di ingresso e uscita. A questo punto, l’intero segmento è completato e pronto per l’uso, liberando l’encoder in modo che possa iniziare a codificare un altro pezzo di contenuto da un altro canale o altro.

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 altro computer e viene eseguito in tempo prima che vengano rilevati problemi all’interno del flusso.

Questo approccio consente inoltre di utilizzare hardware più conveniente. Ad esempio, se si sa che un computer più lento può impiegare 8 secondi per elaborare un file di 4 secondi da un’affettatrice, è possibile distribuire il carico di lavoro su più codificatori, come mostrato di seguito: Il server A ottiene la sezione 1, il server B la sezione 2 e così via. Quindi, i pezzi sono stati consegnati senza problemi perché tutti sono stati completati in un orario prevedibile. Come mostrato nella tabella seguente, questo esempio comporterebbe una latenza in ritardo di 16-20 secondi.

L’utilizzo di più codificatori nel cloud riduce al minimo la latenza e consente l’uso 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 entrata senza assistenza in tempo reale. Sfruttando la scalabilità del cloud, riduciamo in modo significativo i costi di codifica.

Un altro vantaggio della codifica cloud senza stato è che possiamo trasferire facilmente i carichi di lavoro a provider cloud alternativi, poiché non abbiamo requisiti server specializzati. 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 il 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. Anche se non elimina 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 allo stesso tempo flussi di alta qualità e a bassa latenza che gli spettatori si aspettano.