CMCDv2: un passo avanti per la telemetria dello streaming video

Nei vari ruoli tecnici che ho ricoperto nel settore dello streaming video, un argomento ricorrente nelle conversazioni con i colleghi (e talvolta anche nelle lamentele condivise) era la duplicazione degli sforzi: ciascuno di noi, lavorando all’interno della propria azienda, finiva di fatto per sviluppare lo stesso software.

Di recente la situazione ha iniziato a cambiare, grazie a un ottimo lavoro per rendere aperti e standardizzare i componenti più comuni dello streaming. In Fastly ci interessano in particolare le iniziative che coinvolgono l’edge, come il controllo degli accessi distribuito con Common Access token e la comprensione dell’impatto delle prestazioni della rete sull’esperienza degli spettatori tramite Common Media Client Data.

Con il recente rilascio della versione 2 dello standard CMCD, abbiamo pensato di cogliere l’occasione per ripercorrere i motivi del successo della versione 1 ed esaminare le possibilità offerte dalla nuova versione.

Breve storia di CMCD

La versione 1 di CMCD offre una soluzione elegante a un problema comune nei servizi di streaming: i log dei player video potevano indicare quando un utente aveva riscontrato problemi di buffering o cali di qualità, mentre i log delle reti di distribuzione dei contenuti potevano segnalare problemi di rete o dei server di origine. Questi due insiemi di log, però, venivano spesso aggregati in luoghi molto diversi e non c’era un modo semplice per correlarli, soprattutto quando erano coinvolte più reti di distribuzione dei contenuti e diversi dispositivi di riproduzione. Per risolvere i problemi di riproduzione, spesso si finiva per cercare di correlare picchi e timestamp tra grafici diversi.

Prima di CMCD: i log dei player e quelli delle reti di distribuzione dei contenuti restavano separati

I due insiemi di log si trovavano spesso in bucket diversi o persino presso provider di storage differenti

CMCDv1 ha standardizzato un insieme di coppie chiave-valore che potevano essere incluse in una richiesta HTTP per un manifest o un segmento multimediale, per poi essere analizzate e registrate insieme agli altri log della Rete di distribuzione dei contenuti relativi a quella richiesta. Questo significa che ora possiamo avere un quadro molto più completo delle sessioni degli utenti nell’intero stack e, se necessario, esaminarle anche singolarmente.

Il formato esatto va oltre l’ambito di questo post, ma il progetto open source dash.js ha realizzato un’ottima pagina dimostrativa che ti permette di vedere gli eventi generati in tempo reale mentre guardi un video di un coniglio insolitamente grande. 

Questo ci offre di fatto un tracciamento dell’intero stack durante le sessioni di riproduzione: ora possiamo vedere cosa accadeva nel player e sul server in qualsiasi momento e rispondere a domande come:

• Un aumento della latenza di origine ha causato buffering o cali della qualità della riproduzione?

• L’esaurimento del buffer varia a seconda del point of presence della rete di distribuzione dei contenuti?

• Alcuni player gestiscono meglio i picchi di latenza?

• Le prestazioni variano a seconda dell’ASN?

Ti permette anche di fornire alla rete di distribuzione dei contenuti indicazioni sulle richieste che potrebbero arrivare in seguito, relative a segmenti o a intervalli all’interno dei file, e di velocizzare le richieste successive tramite il prefetching.

Poiché CMCD è uno standard aperto e ormai ampiamente adottato, puoi integrare qualsiasi player video diffuso e strumento di monitoraggio alle due estremità e ottenere immediatamente osservabilità.

Fastly è particolarmente adatta a fungere da tramite in questa architettura: grazie alla nostra capacità di inviare logging in tempo reale, con formati e valori definiti dall’utente, a un’ampia gamma di piattaforme, gli operatori di live streaming possono reagire immediatamente a qualsiasi problema che si verifichi durante i loro eventi e diagnosticarlo.

Per aiutarti a iniziare, abbiamo preparato questo esempio di analisi dei valori CMCD in VCL. 

Le novità di CMCDv2

Sebbene faccia parte dello stesso protocollo, CMCDv2 rappresenta un vero salto architetturale: punta a sfruttare il successo della modalità richiesta per includere nel quadro anche una ricca telemetria lato client.

La versione 2 è pienamente retrocompatibile con l’arricchimento delle richieste alla rete di distribuzione dei contenuti introdotto nella prima versione (ora denominato modalità di richiesta), ma aggiunge due nuove modalità: modalità di risposta e modalità evento. Consente inoltre di inviare i dati direttamente dal client a domini di terze parti (ad esempio, a un servizio SaaS di aggregazione delle metriche), senza obbligare queste nuove modalità a seguire lo stesso percorso dei dati video.

Oltre alle due nuove modalità, la modalità di richiesta include molte altre coppie chiave-valore, basate su quanto appreso dalle distribuzioni reali di CMCDv1.

Anche questa volta c’è troppo da trattare in un solo post del blog, ma ecco alcune delle nuove metriche che ci entusiasmano di più:

• Dimensione target del buffer: consente agli strumenti di analytics di valutare la dimensione del buffer rispetto a quella ideale, anziché considerarla come un numero astratto. Questo è importante perché implementazioni diverse dei player, dispositivi e tipi di contenuti possono avere dimensioni target del buffer molto differenti. 

• Metriche assolute / relative del degrado: un’interruzione di 3 secondi nell’arco di un video è un’esperienza utente molto diversa da un’interruzione per ogni segmento. Molte delle nuove metriche aiutano a distinguere meglio questi casi

• Distinzione tra tipi di contenuto: il passaggio dal contenuto principale alle interruzioni pubblicitarie è un momento in cui emergono spesso problemi di riproduzione. CMCDv2 consente di distinguere i diversi tipi di contenuti e capire esattamente dove si verificano i problemi.

Modalità di risposta

La modalità di risposta completa i dati trasmessi con la richiesta dei contenuti multimediali nella modalità di richiesta. Viene eseguita dopo che il client ha completato la ricezione del blocco di dati video o audio dalla rete di distribuzione dei contenuti e gli consente di comunicare dati che non aveva al momento della richiesta, come il tempo al primo byte del corpo della risposta, il tempo all’ultimo byte e il codice di risposta HTTP.

Sebbene molti di questi campi siano disponibili nei log della Rete di distribuzione dei contenuti, averli nel player e inviarli direttamente a un endpoint esterno può essere utile, ad esempio, in una configurazione con più Reti di distribuzione dei contenuti: evita di dover normalizzare e aggregare i log e può servire quando alcune Reti di distribuzione dei contenuti non offrono il logging in tempo reale.

Modalità evento

La modalità evento è al centro della maggior parte delle novità e cerca di superare uno dei principali limiti della versione originale: le informazioni potevano essere registrate solo insieme alle richieste dei contenuti multimediali, nonostante durante una sessione di riproduzione possano verificarsi in modo asincrono molti eventi rilevanti (come la messa in pausa, il passaggio in background e la modifica manuale della qualità). Questa nuova modalità permette di acquisire questi eventi (e quelli definiti liberamente dall’utente) insieme all’istante esatto in cui si verificano, senza essere vincolati ai tempi delle richieste HTTP.

Tradizionalmente, questi eventi venivano registrati in metriche definite dal player. Ma i nomi e i parametri di queste metriche variavano a seconda del player utilizzato e non sarebbe stato facile collegarle alle metriche della rete di distribuzione dei contenuti. Se hai seguito le ragioni alla base di CMCDv1, tutto questo dovrebbe iniziare a sembrarti molto familiare!

Se vuoi provare questa nuova modalità ma ti preoccupa il numero di nuovi eventi che raggiungerebbero il tuo server di origine, oppure la necessità di creare una nuova pipeline di dati per acquisirli, Fastly’s Beacon Termination è un’ottima opzione per assorbire il nuovo carico, filtrare gli eventi e inoltrarli agli strumenti di dati di terze parti che utilizzi.

Dovrei quindi iniziare a usare CMCDv2?

È un po’ più complicato! È senz’altro utilizzabile, ma ci sono alcuni aspetti da tenere presenti:

• Si tratta comunque di un’importante aggiunta allo standard, introdotta relativamente di recente, quindi il supporto nativo da parte dei player e degli strumenti di monitoraggio è ancora in fase di sviluppo. La common-media-libreria di SVTA, però, lo supporta ed è in continuo sviluppo: le librerie per player come hls.js e dash.js dispongono quindi del supporto per impostazione predefinita.

• La “modalità evento” può aggiungere molti più dati e una maggiore complessità semantica quando si cerca di ricavarne indicazioni utili su cui agire. Potresti dover ripensare il logging e le pipeline di dati, valutare il campionamento se non lo fai già o, quantomeno, scegliere con attenzione quali eventi acquisire.

• Quando usi la modalità evento per inviare le metriche direttamente a un endpoint di raccolta di terze parti, è più probabile che i sistemi di blocco degli annunci le intercettino, con il rischio di alterare i dati o creare lacune.

Se vuoi capire meglio come funziona prima di decidere se fare commit, dai un’occhiata a questa pagina dimostrativa che abbiamo preparato per mostrare i tipi di eventi generati nella modalità evento durante una sessione di riproduzione. 

Pronto a integrare CMCDv2 nel tuo stack di streaming? La modalità evento richiede di scegliere con attenzione cosa acquisire e pone nuove domande su dove far confluire i dati e come instradarli. Contatta il nostro team per ricevere assistenza nel valutare il logging, la terminazione dei beacon e la normalizzazione tra più Reti di distribuzione dei contenuti per la tua configurazione.