Esperienze di visione personalizzate a livello 1:1, stanno trasformando l’esperienza TV. Invece di un formato unico, gli spettatori ottengono pubblicità mirata e altamente pertinente, contenuti personalizzati, raccomandazioni per nuovi programmi e una gestione precisa di DRM/blackout, il tutto in base al tipo di dispositivo, alla posizione, alla storia, ai dati demografici e ad altri dati degli spettatori.
Ma scalare flussi video personalizzati a milioni di spettatori, specialmente per programmi live come lo sport, è difficile quasi quanto colpire per il ciclo del baseball. I volumi degli spettatori possono oscillare vertiginosamente, aumentando di centinaia di migliaia di spettatori in momenti imperdibili come il calcio d’inizio, gli straordinari e durante le partite più strette. Supponiamo che la tua infrastruttura per supportare la personalizzazione non sia abbastanza adattabile e scalabile. In tal caso, la tua esperienza personalizzata sarà completamente sospesa e l’intera azienda potrebbe essere a rischio nel mondo OTT.
Il ruolo centrale del server manifesto nella personalizzazione
La personalizzazione OTT si basa sulle prestazioni del server manifest per generare una playlist unica di contenuti, annunci e istruzioni di riproduzione. Il server manifest deve affrontare le seguenti dipendenze:
- Latenza server ad: La comunicazione con i server ad può aggiungere latenza che deve essere fattorizzata nel flusso di lavoro, soprattutto quando sono coinvolti più hop.
- Monetizzazione/reporting: Una volta riprodotto l’annuncio, è necessario inviare un beacon ai server degli annunci per misurare le impressioni degli annunci e abilitare la monetizzazione.
- Aspetti senza stato di Internet: Affinché i manifesti personalizzati funzionino su larga scala, lo stato deve essere mantenuto attraverso più richieste per ogni spettatore.
- DRM/autenticazione: Il server manifest deve tenere sotto controllo la gestione dei diritti digitali (DRM), la crittografia a livello di sessione e l’autenticazione.
- Diritti e restrizioni di blackout/contenuti: In base alla posizione dell’utente, i contenuti in streaming possono essere soggetti a varie regole di blackout, che devono essere gestite con precisione.
- Consigli sui contenuti: Gli spettatori online si aspettano che tu li conosca e personalizzi i tuoi consigli per aiutarli nel processo di ricerca e scoperta.
- Localizzazione dei contenuti: Per gli eventi più importanti, è fondamentale fornire agli utenti le opportune variazioni regionali, tra cui tracce audio, sottotitoli e sottotitoli.
Personalizzazione dei flussi in tempo reale
Come descritto nella parte 1 di questa serie di blog, un feed live o VOD viene ingerito, codificato e confezionato dall’applicazione software Slicer. È possibile inserire dei limiti per consentire ai proprietari di contenuti di personalizzare l’esperienza dello spettatore. Man mano che gli annunci vengono acquisiti, vengono elaborati anche tramite una affettatrice in esecuzione nel cloud per un’esperienza di riproduzione più simile a quella delle trasmissioni televisive.
Quando la affettatrice inizia ad acquisire il flusso live o VOD, comunica continuamente con la nostra infrastruttura back-end, mantenendo aggiornato il database sul numero di segmenti disponibili. I server manifest utilizzano tali dati per personalizzare l’esperienza di ciascun visualizzatore. Quando un lettore richiede un flusso, il server manifest determina quali segmenti video e audio devono essere elencati nel file manifest, che funge da playlist. La possibilità di modificare o personalizzare dinamicamente il manifesto a livello di utente consente di personalizzare l’esperienza di visualizzazione. Nel caso di video live, viene richiesto un nuovo manifesto ogni pochi secondi, consentendo l’applicazione dinamica delle regolazioni da parte dei server manifesti al variare delle condizioni di visualizzazione.
Il ruolo centrale del server manifesto nella personalizzazione dei flussi video
Come mostrato sopra, il fulcro della personalizzazione manifesta è la comunicazione. Con la maggior parte dei requisiti aziendali OTT, ciò significa comunicazioni con i server pubblicitari per fornire annunci mirati e personalizzati in tempo reale. I dati individuali, tra cui l’indirizzo IP, la posizione e il tipo di dispositivo dello spettatore, essenzialmente tutte le informazioni che possiamo acquisire rispettando le rigide regole e normative PII, vengono forniti al sistema decisionale degli annunci. La soluzione risultante è abbastanza robusta da imparare cosa è rilevante per uno spettatore quando distribuisce annunci durante i live streaming. Il sistema è inoltre sufficientemente robusto da far fronte a sfide quali la gestione delle restrizioni di blackout e dei diritti sui contenuti per utente, supportando al contempo importanti funzionalità di personalizzazione, come consigli sui contenuti e altre localizzazioni.
Architettura dell’infrastruttura manifesta su scala
Nella nostra piattaforma video, il server manifest è responsabile della generazione di un manifesto di streaming personalizzato per ogni visualizzatore. Deve inoltre essere a conoscenza di altri requisiti sopra indicati, come le restrizioni sui contenuti e le raccomandazioni. In questo modello, inviamo un flusso integrato, il che significa che non ci sono problemi di “buffer wheel” mentre i client sono in attesa del caricamento degli annunci nel mezzo del flusso.
Per creare un sistema di distribuzione dei manifesti resiliente, manteniamo cluster di server di generazione dei manifesti nel cloud distribuiti in diverse aree geografiche in tutto il mondo. Negli Stati Uniti, ad esempio, questi server sono organizzati in cinque regioni in tutto il paese. Quando arriva una richiesta di un nuovo flusso da un giocatore statunitense, tale richiesta viene inviata in modo casuale a una delle zone statunitensi.
La sfida del «fragore»
Ciò può sembrare controintuitivo, ma viene fatto per evitare che le modalità di errore si sovrappongano. La maggior parte degli spettatori statunitensi si trova nella parte orientale del paese. Se dovessimo indirizzarli tutti verso la zona più vicina a loro e il nostro provider di servizi cloud si fosse verificato un fallimento in quella regione, la maggior parte dei nostri spettatori si troverebbe di fronte a questo fallimento. A complicare il problema, se tutti questi spettatori aggiornassero lo streaming e ora stiamo indirizzando gli spettatori verso la loro prossima zona sana più vicina, avremmo un problema di “branca di fragorosi” in cui tutti gli spettatori dalla zona fallita si ritrovano ora nella zona più vicina. Il conseguente picco di traffico imprevisto potrebbe potenzialmente causare un guasto secondario finché i nostri sistemi nella nuova zona non saranno in grado di scalare per soddisfare la domanda aggiuntiva.
Invece, distribuire in modo casuale i nostri spettatori statunitensi aiuta a mitigare l’effetto di qualsiasi guasto iniziale e ci consente di distribuire uniformemente il traffico di failover al resto delle zone sane.
Nella nostra piattaforma di streaming, distribuiamo il carico del server manifesto in tutte le zone. In questo modo si evita il sovraccarico di una zona specifica durante i picchi di pubblico, soprattutto se gli spettatori vengono improvvisamente spostati in una zona adiacente durante il failover.
Ciascuna delle nostre zone dispone di un archivio dati separato dedicato alla memorizzazione dei dati di sessione associati. Una volta indirizzato un visualizzatore a una zona, creiamo una sessione per quel visualizzatore e la salviamo nel cluster di sessione della zona. La sessione è un insieme di dati sul visualizzatore e i parametri forniti dal cliente su come vorrebbe personalizzare la sessione per quel visualizzatore. Per superare la sfida presentata dalla natura stateless di Internet, i server manifest costruiscono URL per ogni sessione inclusa nel manifesto restituiti al giocatore. Le richieste successive del giocatore vengono indirizzate direttamente alla zona in cui è stata creata e memorizzata la sessione del visualizzatore (invece di essere instradate casualmente ad una delle altre zone).
Come mostrato nei tre grafici seguenti, eventi diversi possono avere molti requisiti diversi a seconda delle dimensioni del pubblico e se il pubblico è locale o geograficamente disperso. Date un’occhiata ai tre esempi che illustrano le sfide infrastrutturali che le emittenti devono affrontare nel sostenere gli eventi live.
Nel primo scenario, abbiamo presentato un concorso di cibo-mangiare (sì, ne abbiamo trasmesso uno in live streaming) perché illustra una dimensione del pubblico distribuita ma ridotta. Forse arriverà il giorno in cui i concorsi per il cibo diventeranno mainstream, ma per ora rimangono un evento di nicchia che attira un piccolo numero di spettatori in un’ampia area geografica. Il carico del server manifesto viene distribuito facilmente tra più zone e cluster di server manifesto. Ecco dove il valore della personalizzazione diventa evidente rendendo facile inserire annunci appropriati per ogni regione e anche la possibilità di gestire diritti e blackout.
Lo scenario cambia notevolmente per i campionati di football dello stato del Texas, dove un gran numero di spettatori si trova nella stessa area geografica. Gestiamo la cosa in un paio di modi. Come discusso in precedenza, abbiamo scoperto che possiamo assegnare agli spettatori server manifesti situati in zone al di fuori della geografia immediata senza influire sull’esperienza dello spettatore. Inoltre, disponiamo di un sistema che monitora i livelli di visualizzazione in ogni zona e può attivare automaticamente i server di generazione dei manifesti in base alle necessità.
Potremmo prescalare in base alle visualizzazioni previste per grandi eventi come le finali NBA. Tuttavia, abbiamo avuto più eventi in cui i nostri sistemi di scalabilità automatica gestivano quasi un milione di spettatori senza richiedere alcun preriscaldamento. Oltre ad aumentare la scalabilità, la possibilità di distribuire istantaneamente il carico tra i server manifest in modo indipendente dalla zona migliora significativamente l’affidabilità e la ridondanza in tutta la rete.
Richieste del giocatore e beaconing degli annunci
Una serie di cambiamenti e tendenze nel settore stanno rendendo la scalabilità del cloud più importante che mai. Un fattore determinante è l’intervallo di riduzione tra le richieste del lettore. La nostra richiesta standard live-lineare di 8 secondi “What’s Next” del giocatore viene portata a 5 secondi e può essere breve quanto ogni 2 secondi per i flussi in cui è importante una bassa latenza. Ciò influisce principalmente sull’utilizzo della CPU perché il server deve rispondere a un numero di richieste 4 volte superiore (a intervalli di 2 secondi rispetto agli intervalli di 8 secondi). Inoltre, i consigli sui contenuti e i blackout ora devono essere controllati con maggiore frequenza rispetto al passato per evitare errori.
Allo stesso modo, il mondo ad-tech sta diventando sempre più complesso ed esigente. Per ogni annuncio inserito in un flusso, un server pubblicitario avrà almeno cinque beacon utilizzati a scopo di reporting. È necessaria una soluzione SSAI (Server-Side Advertising) per garantire che invii tali beacon in modo che i clienti vengano pagati dai loro inserzionisti. Mentre cinque fari sono il minimo, CE ne possono essere molti altri. In effetti, abbiamo visto casi in cui un singolo annuncio ha da 30 a 100 beacon su cui riferire.
Inoltre, reti complesse di server pubblicitari stanno diventando sempre più comuni nelle campagne dei nostri clienti. Più hop di rete ad possono iniziare a causare problemi di latenza. “Ad esempio, la rete n. 1 potrebbe dire: “Ecco l’elenco degli annunci in questa pausa,” solo per scoprire che l’annuncio n. 2 in quella pausa richiede una richiesta a un’altra rete.” L’annuncio n. 3 introduce altri due luppoli e così via.
Nell’esempio precedente, le interruzioni pubblicitarie possono raddoppiare o triplicare l’utilizzo della CPU. Le richieste dei lettori video live possono aggravare questo fattore del 10-30%.
Looking avanti: Microservizi e scalabilità
Con l’aumento della complessità, uno dei passaggi che abbiamo intrapreso è separare i diversi carichi di lavoro precedentemente gestiti dai server manifesti in microservizi più piccoli. Il primo passo che abbiamo fatto è spostare le comunicazioni del server pubblicitario e il beaconing al proprio servizio, aiutando ad affrontare la sfida della latenza del server pubblicitario. Questo servizio di proxy degli annunci offre diverse funzionalità avanzate di cui parleremo più approfonditamente in un prossimo post sul blog.
In futuro, continueremo a sviluppare altri microservizi per rimuovere più lavoro dai server manifesti e offrire un approccio più mirato alla scalabilità. Presto, aggiungeremo zone di più provider cloud per diventare resilienti ai guasti di un singolo provider.
Associando SSAI scalabile ai microservizi, possiamo ottimizzare i costi dei server, la struttura della nostra base di codice e altre caratteristiche specifiche del traffico pubblicitario. Inoltre, possiamo superare diverse sfide chiave, tra cui la latenza del server pubblicitario, le restrizioni di blackout e la monetizzazione. Allo stesso tempo, diffondendo il carico di elaborazione in più zone, il nostro servizio di streaming video live è in grado di espandersi su vasta scala e superare le sfide principali, consentendoci di distribuire in modo affidabile milioni di flussi personalizzati simultanei senza mettere a dura prova la nostra rete di distribuzione.
