Streaming adattativo e DASH

In questa pagina 8

Uno streaming video funziona se i dati arrivano al ritmo con cui vengono riprodotti. Ma la rete non garantisce un throughput costante, e il bit-rate di un video compresso è deciso prima, spesso quando nessuno sa a che velocità lo vedrà ciascun utente. Questa nota spiega il problema, perché le soluzioni "ingenue" falliscono, come lavora lo streaming adattativo (ABR, adaptive bitrate), come si modella il buffer del client, come si misura la QoE di uno streaming e che cosa è MPEG-DASH. Gli esercizi numerici sono in Esercizio - Buffer di riproduzione e streaming adattativo (domande ed esercizi del corso). Prerequisiti: Servizi multimediali e loro requisiti, Codifica video - stima del moto, MPEG e H.264, Protocolli per i servizi multimediali.

1. Il problema: $R_C\le S$

Come si sceglie il tasso di codifica $R_C$ di un video? La QoE cresce con $R_C$ (in tutti gli esperimenti MOS e metriche oggettive come PSNR, SSIM, VMAF aumentano con $R_C$ per un dato codec): converrebbe il valore più grande possibile. Il limite è il throughput a lungo termine a livello applicazione: $\boxed{R_C\le S.}$ Il tasso di codifica si può controllare con le tecniche di rate control, che regolano dinamicamente il passo di quantizzazione del codec per inseguire un tasso obiettivo. Il tasso è però raramente costante frame per frame (le I costano molto più delle P e B, Codifica video - stima del moto, MPEG e H.264); si può considerare circa costante a livello di GOP.

La cattiva notizia: non si controlla $S$ . Il throughput non è sotto il controllo dei fornitori; spesso non è noto quando si codifica (codifica e trasmissione in momenti diversi; eccezioni: live e real-time, dove $S$ si può stimare); cambia molto in fretta durante la trasmissione, in particolare per gli utenti mobili; nei servizi broadcast ogni utente ha un throughput diverso. Quindi è molto difficile garantire $R_C\le S$ in tutte le situazioni.

1.1 Che cosa succede se $S<R_C$

I pacchetti arrivano con velocità $R_C$ maggiore di quella con cui partono ( $S$ ): si accumulano nei buffer dei router, che si riempiono; a quel punto i pacchetti devono essere scartati e non arrivano più al client. Rischio di congestione e ulteriore incremento dei ritardi.

Approfondimento (modello di latenza; marcato "non in programma" nelle slide). Un modello a un solo hop calcola, per il frame $n$ acquisito al tempo $nT_F$ : istante di inizio trasmissione $T_T(n)=\max\bigl\{nT_F+T_c(n),\ T_T(n-1)+\frac{B(n-1)}{S(n-1)}\bigr\}$ (il frame è pronto dopo la codifica $T_c$ , ma parte solo quando il canale ha finito il frame precedente), istante di fine ricezione $T_R(n)=T_T(n)+\frac{B(n)}{S(n)}+P(n)+T_d(n)$ ( $P$ propagazione, $T_d$ decodifica), latenza $L(n)=T_R(n)-nT_F$ . (In una delle due versioni delle slide il primo termine del massimo è scritto $(n-1)T_F$ : è un refuso, la frase accanto dice $nT_F+T_c(n)$ .) Esempio: 25 fps ( $T_F=40$ ms), un frame I da 400 kbit seguito da P da 40 kbit, $S=2$ Mbit/s ( $R_C<S$ in media), $T_c=T_d=P=0$ . L'I dura $0{,}2$ s di trasmissione, ogni P $0{,}02$ s: la latenza dell'I è $200$ ms; la prima P è pronta a $40$ ms ma parte solo a $200$ ms ( $L=180$ ms); e così via con $L(n)=0{,}2-0{,}02\,n$ finché alla frame 9 la coda si svuota e $L=20$ ms. Con $R_C>S$ invece l'eccesso non si riassorbe e la coda cresce.

1.2 Rimedi che non funzionano

Compressione estrema (tasso molto piccolo): semplice e senza modifiche alla rete, ma la qualità è bassa per tutti, anche per chi ha una buona rete (approccio "pessimistico").
Packet drop nei router: il router scarta i pacchetti in eccesso. Il risultato sulla QoE è fuori controllo: il router non sa quali pacchetti contano (le frame di riferimento: perdere una I distrugge l'immagine per secondi); i video statici sono più robusti di quelli dinamici.
Transcoding in rete: il router decodifica e ricodifica a un tasso inferiore. Efficace per la QoE ma troppo costoso (ogni router ispeziona il contenuto, decide, transcodifica) e incompatibile con la cifratura end-to-end (HTTPS, QUIC).

Conclusione: la rete è "stupida"; l'intelligenza per adattarsi deve stare ai margini, nel server o nel client.

1.3 Server più rete: codifica scalabile (SVC)

Il video è codificato dal server con la codifica scalabile: livello base decodificabile da solo (basso tasso, qualità ridotta) più livelli di enhancement che migliorano frame rate, risoluzione o qualità. In congestione un nodo intelligente può scartare gli enhancement senza corrompere il base: il client riceve comunque un flusso valido. Pro: degrado di qualità sotto controllo, QoE simile al transcoding, router senza operazioni complesse. Contro: a parità di qualità un codificatore scalabile richiede circa il 5-15% di bit-rate in più per ogni strato aggiuntivo; i router vanno comunque aggiornati. Oggi molto usata in WebRTC per le videoconferenze di gruppo, meno nello streaming VoD (che preferisce DASH).

2. Streaming adattativo (ABR)

Lo streaming video adattativo è oggi la soluzione più diffusa al problema "tasso di codifica contro throughput" per lo streaming stored e live. Si basa su modifiche a server e client, senza requisiti per la rete: facile da realizzare (solo il livello applicazione) e con ottima QoE. La chiave è la collaborazione: il server mette a disposizione molte versioni di ogni contenuto e il client sceglie dinamicamente quella che massimizza la QoE.

2.1 Modello di sistema

Il modello è tirato dal client (pull): l'intera sequenza è divisa in segmenti di durata $T_S$ (tipicamente da 1 a 10 secondi); ognuno degli $N$ segmenti è codificato in modo indipendente (quindi decodificabile in modo indipendente). Ogni segmento $n\in\{1,\dots,N\}$ è codificato in $K$ versioni o livelli di qualità $k\in\{1,\dots,K\}$ , ciascuno caratterizzato da tasso di codifica $R_C(k)$ , risoluzione e frame rate, gli stessi per tutti i segmenti. Per ottenere tassi diversi (specie piccoli) non si agisce solo sulla quantizzazione: si può cambiare anche la risoluzione spaziale e il numero di immagini al secondo. Si assume che a un bit-rate maggiore corrisponda una qualità percepita maggiore.

	Segmento 1	Segmento 2	Segmento 3
Livello 3	url(1,3)	url(2,3)	url(3,3)
Livello 2	url(1,2)	url(2,2)	url(3,2)
Livello 1	url(1,1)	url(2,1)	url(3,1)

Come fa il client a conoscere le informazioni? Con un file di descrizione, l'MPD (Media Presentation Description, MDF nelle slide), messo a disposizione dal server: contiene il numero di segmenti $N$ , la durata $T_S$ , il numero di livelli $K$ , i bit-rate $R_C(k)$ , le risoluzioni e i frame rate, e l'URL di ogni segmento $\mathrm{url}(n,k)$ . Esempio dalle slide: $N=1500$ , $T_S=1$ s (25 minuti), $K=5$ , bit-rate $200$ kbit/s, $500$ kbit/s, $1$ , $2$ , $5$ Mbit/s, risoluzioni da $270\times480$ a $2160\times3840$ , frame rate 25 o 50.

Una versione sintetica di un MPD in formato XML (esempio costruito sul modello della sintassi standard):

xml

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" type="static"
     mediaPresentationDuration="PT25M" minBufferTime="PT2S"
     profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period>
    <AdaptationSet mimeType="video/mp4" segmentAlignment="true">
      <SegmentTemplate duration="1" timescale="1" startNumber="1"
                       initialization="init_$RepresentationID$.mp4"
                       media="seg_$RepresentationID$_$Number$.m4s"/>
      <Representation id="1" bandwidth="200000"  width="480"  height="270"  frameRate="25"/>
      <Representation id="2" bandwidth="500000"  width="960"  height="540"  frameRate="25"/>
      <Representation id="3" bandwidth="1000000" width="960"  height="540"  frameRate="50"/>
      <Representation id="4" bandwidth="2000000" width="1920" height="1080" frameRate="50"/>
      <Representation id="5" bandwidth="5000000" width="3840" height="2160" frameRate="50"/>
    </AdaptationSet>
  </Period>
</MPD>

2.2 Il ciclo del client

Il client scarica l'MPD e conosce le opzioni.
Per ogni segmento $n$ sceglie il livello $q(n)$ e lo richiede con HTTP (GET su $\mathrm{url}(n,q(n))$ ): la richiesta HTTP passa nella maggior parte dei firewall.
La richiesta del segmento $n$ parte appena il segmento $n-1$ è stato scaricato completamente: così un singolo client non forma code nei router.
Riproduce i segmenti nell'ordine di arrivo (FIFO) dal playout buffer.

Obiettivi della scelta: scaricare alla qualità più alta possibile, evitare lo stallo (rebuffering), stabilizzare la qualità (i cambi continui infastidiscono). Problema di ricerca: qual è la strategia migliore per decidere il livello del segmento successivo? È un campo di ricerca aperto; il client deve stimare lo stato del sistema (throughput $S(t)$ stimato dai download precedenti, e stato del buffer $B(t)$ ).

Perché HTTP e non RTSP/RTMP. Vedi Protocolli per i servizi multimediali: HTTP è stateless (modello pull: il server risponde a GET isolate e lo stato sta nel client), attraversa NAT e firewall su porte standard, tratta i segmenti come file normali, quindi cache e CDN danno scalabilità a basso costo (Livello applicazione - HTTP, Caching, autenticazione, tipi MIME e URI in HTTP). Il trasporto oggi tende a essere HTTP/3 su QUIC, senza head-of-line blocking e con 0-RTT (WebSocket, QUIC e HTTP-3).

2.3 Tempo di download

Il segmento $n$ al livello $k$ pesa $T_S\,R_C(k)$ bit. Se durante il download il throughput è $S_n$ (costante), il tempo di download è $\boxed{T_D(n,k)=\frac{T_S\,R_C(k)}{S_n}\quad\Longrightarrow\quad\frac{T_D}{T_S}=\frac{R_C(k)}{S_n}.}$ Se $R_C(k)<S_n$ il segmento si scarica più in fretta di quanto dura: il buffer cresce; se $R_C>S_n$ occorre più tempo della durata del segmento: il buffer cala.

3. Il playout buffer

Definizione. $B(t)$ è il numero di secondi di video ricevuti ma non ancora riprodotti all'istante $t$ . Si misura in secondi di video, non in bit o byte. È l'autonomia del player: se la rete "muore" all'istante $t$ , il video continua per esattamente $B(t)$ secondi. Quando $B(t)=0$ la riproduzione si ferma: freezing, stallo o rebuffering.

Si chiama rebuffering perché la riproduzione riprende solo quando i successivi $M$ segmenti sono stati completamente scaricati. All'inizio il buffer è vuoto, quindi tecnicamente lo streaming parte sempre con un rebuffering, ma gli utenti tollerano molto di più un'attesa prima dell'avvio: perciò nel primo rebuffering si scaricano $L\ge M$ segmenti.

Parametri del modello: $T_S$ (durata di un segmento), $S_n$ (throughput durante il download del segmento $n$ ), $q(n)$ (livello richiesto), $B(t)$ , $L$ (segmenti scaricati prima di cominciare la riproduzione, quindi tempo di buffering iniziale; $t_{ST}$ è l'istante di inizio riproduzione), $M$ (nuovi segmenti da scaricare prima di riprendere dopo uno stallo).

3.1 Andamento di $B(t)$

Si usa un modello semplificato a tempo continuo (più semplice da trattare del tempo discreto dei singoli pacchetti), con $S$ costante durante il download di un segmento. Allora $B(t)$ è lineare a tratti. Due stati:

Stallo / buffering (non si riproduce): si ricevono $S$ bit/s; in un intervallo $\Delta T$ si ricevono $S\Delta T$ bit, che valgono $\frac{S\Delta T}{R_C}$ secondi di video (si divide per i bit al secondo del video). Nulla viene consumato, quindi $\Delta B=\frac{S\Delta T}{R_C}$ e $B'_{\text{rebuff}}(t)=\frac S{R_C}\ge0.$
Riproduzione (playout): si ricevono $S\Delta T$ bit e se ne consumano $R_C\Delta T$ (si riproducono $\Delta T$ secondi di video, che costano $R_C\Delta T$ bit): $\Delta B=\frac{S\Delta T-R_C\Delta T}{R_C}$ , quindi $B'_{\text{playout}}(t)=\frac S{R_C}-1.$

Il rapporto incrementale non dipende da $\Delta T$ (per questo il modello è lineare a tratti). In riproduzione il buffer si riempie se $S>R_C$ , si svuota se $S<R_C$ , resta costante se $S=R_C$ . È la stessa condizione " $R_C\le S$ " del problema iniziale.

Come si usa. Per ogni intervallo di $S$ costante si calcola il valore di $B$ all'inizio e la pendenza; si segue l'evoluzione fino al prossimo cambio. Se in riproduzione $B$ arriva a 0, inizia lo stallo e si passa a $B'=\frac S{R_C}$ finché $B=M\,T_S$ (cioè $M$ segmenti pieni): allora si riprende.

Esempio con numeri (video con $R_C=1$ Mbit/s). (a) $S=1{,}2$ Mbit/s: $B'=\frac{1{,}2}1-1=0{,}2>0$ : il buffer si riempie di $0{,}2$ s per ogni secondo di riproduzione. (b) $S=0{,}8$ Mbit/s con un buffer iniziale di $B_0=5$ s: $B'=\frac{0{,}8}1-1=-0{,}2$ ; il buffer si svuota quando $5-0{,}2\,t^*=0$ , cioè $t^*=25$ s. (c) $R_C=2$ Mbit/s, buffer iniziale nullo e riproduzione immediata: per i primi 10 s $S=3$ Mbit/s e $B'=\frac32-1=0{,}5$ , quindi $B(10)=5$ s; poi $S=1$ Mbit/s, $B'=\frac12-1=-0{,}5$ , si svuota dopo $\frac5{0{,}5}=10$ s: stallo a $t=20$ s, in un video che dura 50 s: c'è re-buffering.

3.2 Esempio con più segmenti (dalle slide)

Si considera $L=2$ , $M=1$ , $N=6$ ; il client sceglie sempre lo stesso livello ( $R_C$ costante); i tempi di download dei 6 segmenti (l'ingresso del sistema) dipendono dalla rete. La riproduzione inizia a $t_{ST}$ , quando sono stati scaricati $L=2$ segmenti. L'andamento di $B(t)$ :

fino a $t_{ST}$ il buffer si riempie (buffering iniziale) con pendenza $\frac S{R_C}$ ; la pendenza aumenta quando il secondo segmento si scarica più in fretta;
dopo $t_{ST}$ comincia la riproduzione; finché $T_D<T_S$ ( $R_C<S$ ) il buffer continua a crescere, lentamente;
il throughput cala bruscamente: $T_D$ del segmento 4 è molto grande; in questo intervallo $\frac S{R_C}<1$ e il buffer si svuota;
quando $B=0$ la riproduzione è bloccata: stallo; il buffer ricomincia a riempirsi (lentamente, poi più in fretta quando il throughput risale); la riproduzione riparte quando un nuovo segmento ( $M=1$ ) è stato scaricato completamente;
i segmenti successivi sono scaricati con $S>R_C$ e il buffer cresce; quando l'ultimo segmento è stato ricevuto, il buffer si svuota con $B'=-1$ (si riproduce senza più ricevere).

Con $L=1$ il buffering iniziale è più corto: all'istante $t_{ST}$ il buffer è più piccolo e, quando $S$ cala, si svuota prima e ci mette di più a riempirsi di nuovo: stalli più probabili e più lunghi. Un buffering iniziale lungo peggiora la QoE meno di uno stallo.

3.3 Esempio svolto: due strategie a confronto

Sistema con $T_S=1$ s, tre livelli $R_C(1)=0{,}5$ , $R_C(2)=1$ , $R_C(3)=2$ Mbit/s, $L=2$ , $M=1$ , e throughput $S=1{,}5$ Mbit/s per $t\in(0,2)$ , $S=0{,}1$ Mbit/s per $t\in(2,3)$ , $S=1{,}8$ Mbit/s per $t>3$ (secondi). Soluzione completa in Esercizio - Buffer di riproduzione e streaming adattativo (domande ed esercizi del corso); qui l'essenziale.

Strategia A: sempre il livello 3 ( $R_C=2$ Mbit/s, ogni segmento pesa 2 Mbit). Per partire servono $L=2$ segmenti, cioè 4 Mbit: nei primi 2 s se ne scaricano $1{,}5\cdot2=3$ , nel secondo successivo $0{,}1$ , restano $0{,}9$ Mbit che a $1{,}8$ Mbit/s richiedono $0{,}5$ s: la riproduzione parte a $t_{ST}=3{,}5$ s con $B=2$ s. Poi $S<R_C$ : $B'=\frac{1{,}8}2-1=-\frac1{10}$ , il buffer si svuota in $20$ s ( $t=23{,}5$ s). Lo stallo dura il tempo di scaricare un segmento ( $M=1$ ): $\frac2{1{,}8}=\frac{10}9\approx1{,}11$ s; si riprende con $B=1$ s, che a $-0{,}1$ s/s dura 10 s: stallo ogni $11{,}\overline1$ s, ciascuno di $1{,}11$ s.

Strategia B: livello 3 tranne i segmenti con $n\bmod5=3$ (livello 2). Il segmento 3 al livello 2 si scarica in $\frac{1}{1{,}8}=\frac59$ s con $B'=\frac{1{,}8}1-1=0{,}8$ : il buffer sale a $2+\frac59\cdot0{,}8=2{,}\overline4$ s; i quattro segmenti successivi al livello 3 durano $4\cdot\frac{2}{1{,}8}=4{,}\overline4$ s con $B'=-0{,}1$ : il buffer scende a $2{,}\overline4-0{,}4\overline4=2$ s e il ciclo ripete (periodo di 5 s, 5 segmenti). Nessuno stallo: $B$ oscilla tra 2 e $2{,}\overline4$ s.

Grafico interattivo: Strategia A (sempre livello 3): il buffer cresce fino a 2 s all'avvio (t = 3,5 s), poi cala di 0,1 s per secondo e a t = 23,5 s si svuota; ogni stallo (pendenza +0,9) dura 1,11 s e poi il ciclo si ripete ogni 11,11 s

Grafico interattivo: Strategia B (livello 2 per un segmento su cinque): dopo l'avvio il buffer oscilla tra 2 s e 2,44 s e non tocca mai zero: nessuno stallo, a prezzo di un livello di qualità più basso ogni cinque segmenti

Confronto di QoE. B non ha stalli; ha $\frac45N$ segmenti a livello 3 e $\frac N5$ a livello 2, con due cambi di livello ogni cinque segmenti: $\sum k_n=\frac{14}5N$ e $\sum|k_n-k_{n-1}|=\frac25N$ , quindi (trascurando $T_{ST}$ che è uguale per le due strategie) $J_B\approx\frac{14}5N\lambda_1-\frac25N\lambda_2$ . La strategia C "sempre livello 2" non ha stalli né cambi: $J_C=2N\lambda_1$ . $J_B-J_C\approx N\left(\frac45\lambda_1-\frac25\lambda_2\right)>0$ se e solo se $\lambda_1>\frac{\lambda_2}2$ : la scelta migliore dipende dai pesi, fissati con esperimenti soggettivi.

4. Misurare la QoE di uno streaming

La QoE globale è influenzata da quattro fattori:

qualità video per segmento: $Q(n)=f(R(k_n))$ con $f$ funzione crescente. Poiché è molto difficile modellare la relazione tra MOS e bit-rate (dipende dal contenuto: alcune immagini sembrano perfette a 0,5 bpp, altre mostrano artefatti a 1 bpp; il PSNR è solo un proxy), si adottano modelli semplici: $Q(n)=R(k_n)$ o anche $Q(n)=k_n$ ;
numero e durata dei rebuffering: indicando con $\Delta_n$ la durata del rebuffering durante il segmento $n$ (zero se non c'è); poiché dopo uno stallo si scarica almeno un segmento intero, non può esserci più di un rebuffering per segmento. Il rebuffering è molto dannoso indipendentemente dalla durata: la penalità è $\phi(\Delta)$ con $\phi(0)=0$ ma $\phi(0^+)$ relativamente grande, poi crescente lentamente: $\phi(\Delta)=a\Delta+b$ per $\Delta>0$ , con $a$ piccolo e $b$ grande;
numero e ampiezza delle variazioni di qualità: qualsiasi variazione, in su o in giù, è di per sé fastidiosa: meglio una qualità costante, anche un po' bassa, che cambiare spesso;
durata del buffering iniziale: gli utenti lo accettano se riduce i rimbalzi successivi, ma se troppo lungo riduce la QoE.

La QoE sul segmento $n$ è $J(n)=\lambda_1k_n-\lambda_2\,\lvert k_n-k_{n-1}\rvert-\phi(\Delta_n),$ che cresce con il livello, cala con i cambi di livello e crolla se c'è uno stallo. A livello di sequenza: $J=\sum_{n=1}^NJ(n)-\lambda_3T_{ST},$ dove $T_{ST}$ è il tempo per scaricare $L$ segmenti al livello scelto dalla strategia. I pesi $\lambda_i$ e $\phi$ sono difficili da fissare: $\lambda_3$ è relativamente piccolo (buona tolleranza al ritardo iniziale), $\phi$ ha una discontinuità in zero (anche il più piccolo stallo è fastidioso). (Un'altra scrittura nelle slide: $J=\sum_nq(n)-\lambda\sum_n\lvert q(n)-q(n-1)\rvert-\mu\sum_nT_{\text{stall}}(n)$ , con $\mu$ tipicamente altissimo.) Il client ABR cerca di massimizzare $J$ .

5. Algoritmi di adattamento (ABR)

L'ABR di norma non è standardizzato perché è implementato solo nel client (lo è il protocollo di comunicazione con il server): ogni client può usare un algoritmo diverso, più "aggressivo" (livello alto con più rischio di stallo) o più "cauto" (qualità ridotta per diminuire la probabilità di stallo). Famiglie:

basati sul throughput: stimano il throughput e scelgono il livello in modo che il tempo di download sia inferiore al tempo di riproduzione del segmento (esempi: PANDA, FESTIVE, SQUAD);
basati sul buffer: scelgono in base al riempimento del buffer: buffer alto/basso significa che il video arriva più veloce/più lento di quanto è consumato, quindi la qualità può essere aumentata/ridotta (esempi: BBA, BOLA);
ibridi: usano throughput e buffer (esempi: ELASTIC, MPC, ABMA+, DYNAMIC).

5.1 Un algoritmo di esempio (dalle slide)

Il client sceglie il livello $k_n$ per massimizzare $J=\lambda_1k_n-\lambda_2|k_n-k_{n-1}|-\phi(\Delta_n)$ conoscendo il livello precedente $k_{n-1}$ , il buffer $B_0>0$ (secondi non ancora riprodotti) e una stima del throughput $\hat S$ . Per ogni livello candidato $\ell=1,\dots,K$ :

$R=R_C(\ell)$ ; $\beta=\frac{\hat S}R-1$ è la pendenza del buffer; durante il download $B(t)=B_0+\beta t$ .
Se $\beta\ge0$ il buffer non si svuota: $\Delta=0$ .
Se $\beta<0$ il buffer diventa vuoto a $t_0$ con $B_0+\beta t_0=0$ : $t_0=\frac{B_0}{1-\hat S/R}=\frac{RB_0}{R-\hat S}$ . Secondo le slide: se $t_0>T_S$ non c'è stallo ( $\Delta=0$ ); altrimenti ci sono ancora $T_R=T_S-\frac{RB_0}{R-\hat S}$ secondi del segmento da scaricare e lo stallo dura il tempo di scaricare il resto più $M$ nuovi segmenti, $\Delta=T_R+MT_S\frac R{\hat S}$ .
Si valuta $J(\ell)=\lambda_1\ell-\lambda_2|\ell-k_{n-1}|-\phi(\Delta)$ e si tiene il livello con $J$ massimo.

Due avvertenze di lettura. (a) Una delle due versioni delle slide inizializza $J_{\min}=\infty$ e sceglie se $J<J_{\min}$ : così sceglierebbe il livello peggiore; la versione corretta usa $J_{\max}=-\infty$ e sceglie se $J>J_{\max}$ (obiettivo: massimizzare). (b) Nel modello a fluido il confronto naturale per decidere se c'è stallo è tra l'istante $t_0$ in cui si svuota il buffer e la durata del download $T_D=T_S\frac R{\hat S}$ del segmento (non la sua durata di riproduzione $T_S$ ): lo stallo c'è se $t_0<T_D$ . L'algoritmo delle slide è comunque una semplificazione didattica.

Limiti dichiarati dell'algoritmo: throughput costante durante il download e anche durante lo stallo; $R_C$ costante durante la riproduzione (mentre le I richiedono più bit); nessun margine di sicurezza su $B$ (se non si svuota durante il segmento corrente, non si fa nulla per prevenire lo stallo successivo).

6. MPEG-DASH

Limiti delle implementazioni di streaming adattativo: rischio di freezing o bassa qualità se il RTT è grande (e diventa più difficile stimare il throughput); le decisioni dipendono solo dal client, che ha una visione parziale delle condizioni del canale; con più client DASH o strategie aggressive l'adattamento può essere subottimo; file size e bit-rate non sono gli unici aspetti che influiscono sulla qualità.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) è lo standard per consentire lo streaming dinamico su HTTP. È una tecnologia abilitante: fornisce i formati (MPD, segmenti) per rendere possibile uno streaming efficiente e di alta qualità. Non è un sistema, un protocollo, un codec né una specifica del client. È una possibile soluzione: aperta e standardizzata, ma esistono soluzioni proprietarie (come HLS di Apple, simile nel principio).

Principi: riutilizza tecnologie esistenti (container, codec); sfrutta le CDN HTTP, perché HTTP tipicamente non è filtrato dai nodi intermedi; punta a una QoE elevata (avvio rapido, niente rebuffering); sceglie la qualità in base a condizioni di rete, capacità del dispositivo e preferenze dell'utente; permette di passare da un server a un altro senza interruzioni; sposta l'intelligenza dalla rete al client, il che favorisce la concorrenza tra le implementazioni.

Architettura. Lato server DASH: un server HTTP standard con la Media Presentation Description e i segmenti video a più qualità (alta, media, bassa nel tempo). Lato client DASH: client HTTP, adaptation engine (sceglie la qualità dei segmenti massimizzando la QoE) e media engine (decodifica e riproduce).

7. Riepilogo

Lo streaming adattativo trasforma il vincolo $R_C\le S$ da obbligo statico (impossibile da garantire) a adattamento dinamico: video diviso in segmenti a più livelli (MPD), client che sceglie $q(n)$ in base a throughput e buffer, su HTTP (CDN, firewall, QUIC), con QoE modellata da qualità, stalli, variazioni e buffering iniziale.

Domande d'esame

1. Nello streaming video adattativo un video è diviso in segmenti di uguale lunghezza e qualità diverse (vero o falso)? Chi decide la qualità? Traccia: vero: $N$ segmenti da $T_S$ secondi, ciascuno in $K$ versioni a tassi diversi; il client decide il livello segmento per segmento (modello pull su HTTP), usando l'MPD per conoscere URL e tassi.

2. Un video ha $R_C=1$ Mbit/s e 25 fps con frame di 40 kbit; il throughput è 0,8 Mbit/s e il buffer iniziale è di 5 s. Dopo quanto tempo dall'inizio della riproduzione si svuota il buffer? Traccia: $R_C=25\cdot40$ kbit $=1$ Mbit/s; $B'=\frac{0{,}8}1-1=-0{,}2$ s/s; $5-0{,}2\,t^*=0\Rightarrow t^*=25$ s.

3. Perché per lo streaming si usa HTTP e non RTSP o RTMP? Quali vantaggi ha QUIC rispetto a TCP? Traccia: HTTP è stateless e passa NAT e firewall, i segmenti sono file normali e si cachano su CDN; RTSP e RTMP sono stateful, push, su porte non standard o UDP spesso bloccato. QUIC elimina l'head-of-line blocking (stream indipendenti), offre 0-RTT e connection migration.

Versione ripasso

Problema. QoE cresce con $R_C$ ; vincolo $R_C\le S$ (throughput a lungo termine a livello applicazione). $R_C$ si controlla (rate control: passo di quantizzazione; circa costante a livello di GOP), $S$ no (non noto alla codifica, varia in fretta, diverso per ogni utente). Se $S<R_C$ : i pacchetti si accumulano nei buffer dei router, perdite, congestione, latenza crescente. (Modello a coda, non in programma: $T_T(n)=\max\{nT_F+T_c,T_T(n-1)+\frac{B(n-1)}{S(n-1)}\}$ , $T_R=T_T+\frac BS+P+T_d$ , $L=T_R-nT_F$ ; esempio I da 400 kbit su 2 Mbit/s: latenza 200 ms che scende di 20 ms a frame fino a 20 ms alla frame 9.)

Rimedi. Compressione estrema: bassa qualità per tutti. Packet drop nei router: QoE fuori controllo (si perdono frame di riferimento). Transcoding in rete: costoso, incompatibile con la cifratura end-to-end. La rete è "stupida": l'intelligenza ai margini. SVC: livello base + enhancement, i nodi scartano gli enhancement; costo 5-15% per strato, router da aggiornare; usata in WebRTC, poco nel VoD.

ABR. Modello pull del client: $N$ segmenti da $T_S$ (1-10 s), indipendenti; $K$ livelli per segmento con $R_C(k)$ , risoluzione, fps uguali per tutti i segmenti; l'MPD elenca $N$ , $T_S$ , $K$ , $R_C(k)$ , risoluzioni, fps, $\mathrm{url}(n,k)$ (esempio $N=1500$ , $T_S=1$ s, $K=5$ : 200 kbit/s, 500 kbit/s, 1, 2, 5 Mbit/s). Il client scarica l'MPD, richiede ogni segmento con HTTP GET appena finito il precedente, sceglie $q(n)$ massimizzando la QoE: qualità alta, niente stalli, qualità stabile. Tempo di download $T_D(n,k)=\frac{T_SR_C(k)}{S_n}$ , $\frac{T_D}{T_S}=\frac{R_C}{S_n}$ . Perché HTTP: stateless/pull, NAT e firewall, cache e CDN, HTTP/3 su QUIC (stream indipendenti, 0-RTT, connection migration).

Buffer. $B(t)$ = secondi di video ricevuti e non riprodotti (non bit); $B=0$ = stallo (freeze, rebuffering). Parametri: $T_S$ , $S_n$ , $q(n)$ , $L$ (segmenti prima dell'avvio, $t_{ST}$ = istante di avvio), $M$ (segmenti prima di riprendere dopo lo stallo; $L\ge M$ ).

Stallo: $B'=\frac S{R_C}$ . Riproduzione: $B'=\frac S{R_C}-1$ (riempie se $S>R_C$ , svuota se $S<R_C$ , costante se $S=R_C$ ). Lineare a tratti con $S$ costante per segmento; dopo uno stallo si riprende quando $B=M\,T_S$ .
Esempi ( $R_C=1$ Mbit/s): $S=1{,}2\Rightarrow B'=0{,}2$ ; $S=0{,}8$ , $B_0=5$ s $\Rightarrow B'=-0{,}2$ , vuoto a $t^*=25$ s. $R_C=2$ Mbit/s, $S=3$ Mbit/s per 10 s ( $B'=0{,}5$ , $B(10)=5$ ) poi $S=1$ ( $B'=-0{,}5$ ): stallo a 20 s.
$L$ piccolo: stalli più probabili e lunghi; buffering iniziale lungo disturba meno di uno stallo.

QoE. Fattori: qualità per segmento ( $Q=R(k_n)$ o $k_n$ ), rebuffering ( $\phi(0)=0$ , $\phi(\Delta)=a\Delta+b$ , $b$ grande), variazioni di qualità, buffering iniziale. $J(n)=\lambda_1k_n-\lambda_2|k_n-k_{n-1}|-\phi(\Delta_n)$ ; $J=\sum J(n)-\lambda_3T_{ST}$ . Il client massimizza $J$ .

Algoritmi ABR. Non standardizzati (client). Throughput-based (PANDA, FESTIVE, SQUAD: tempo di download minore del tempo di riproduzione); buffer-based (BBA, BOLA); ibridi (ELASTIC, MPC, ABMA+, DYNAMIC). Esempio: per ogni livello $\ell$ : $\beta=\frac{\hat S}{R}-1$ ; $\beta\ge0\Rightarrow\Delta=0$ ; $\beta<0\Rightarrow t_0=\frac{RB_0}{R-\hat S}$ ; stallo se $t_0$ minore del tempo di download ( $T_S\frac R{\hat S}$ ); $\Delta=T_R+MT_S\frac R{\hat S}$ ; si sceglie il livello con $J$ massimo (una versione delle slide ha il segno invertito). Limiti: throughput costante, $R_C$ costante, nessun margine di sicurezza su $B$ . Aggressivo contro cauto.

DASH. Standard (MPEG) per lo streaming dinamico su HTTP: formati (MPD, segmenti), non sistema, né protocollo, né codec, né client. Principi: riuso di container e codec, CDN HTTP, QoE alta, selezione in base a rete, dispositivo e preferenze, cambio di server senza interruzioni, intelligenza al client. Server: HTTP + MPD + segmenti. Client: client HTTP, adaptation engine, media engine. Limiti dell'ABR: RTT elevato, visione parziale del client, più client aggressivi. HLS: soluzione proprietaria simile.

Esempio svolto (sistema con $T_S=1$ s, livelli 0,5/1/2 Mbit/s, $L=2$ , $M=1$ ; $S=1{,}5$ Mbit/s per $t\in(0,2)$ , $0{,}1$ per $(2,3)$ , $1{,}8$ poi). Sempre livello 3: 4 Mbit servono per partire $\Rightarrow$ $t_{ST}=3{,}5$ s; poi $B'=\frac{1{,}8}2-1=-0{,}1$ , $B(t_{ST})=2$ s: vuoto dopo 20 s; ogni stallo dura $\frac{2}{1{,}8}=\frac{10}{9}$ s, poi 10 s di riproduzione: periodo $11{,}\overline1$ s. Con il livello 2 ogni quinto segmento ( $n\bmod5=3$ ): il buffer oscilla tra 2 e $2{,}\overline4$ s, nessuno stallo; $J_1-J_2\approx N(\frac45\lambda_1-\frac25\lambda_2)>0\iff\lambda_1>\frac{\lambda_2}2$ .

Errori tipici: misurare $B(t)$ in bit; usare $\frac S{R_C}$ anche in riproduzione (manca il $-1$ ); dimenticare che dopo lo stallo $B$ riparte da $M\,T_S$ ; confondere $L$ ed $M$ ; dire che il client DASH è standardizzato; dire che la qualità la sceglie il server; massimizzare $J$ con il segno sbagliato.

Collegamenti: Protocolli per i servizi multimediali, Qualità del servizio (QoS) e qualità dell'esperienza (QoE), Esercizio - Buffer di riproduzione e streaming adattativo (domande ed esercizi del corso).

Come ragiona il client (ciclo). (1) Scarica l'MPD. (2) Stima $S$ (dai download precedenti) e legge $B(t)$ . (3) Sceglie $q(n)$ : livello più alto per cui $T_D=\frac{T_SR_C(q)}{\hat S}<T_S$ senza svuotare $B$ (strategia a throughput), o in base al livello di $B$ (a buffer), o entrambi (ibrida). (4) Richiede $\mathrm{url}(n,q(n))$ con HTTP GET appena finito il segmento precedente. (5) Ripete fino alla fine; se $B=0$ stalla e riprende dopo $M$ segmenti.

Effetto dei parametri. $L$ grande: avvio lento ma meno stalli; $L$ piccolo: avvio rapido ma stalli più probabili e lunghi. $M$ grande: stalli più lunghi ma meno frequenti. $T_S$ grande: meno richieste HTTP, adattamento più lento. $K$ grande: adattamento più fine ma più spazio sul server.

Numeri tipici dalle slide. Tolleranze: VoD 1-3 s di avvio, live sotto 10 s, real-time sotto 150 ms, cloud gaming sotto 50 ms. Segmenti da 1 a 10 s. MPD d'esempio: $N=1500$ , $T_S=1$ s, $K=5$ (200 kbit/s, 500 kbit/s, 1, 2, 5 Mbit/s). SVC: 5-15% di bit-rate in più per strato.

Domande tipiche.

Buffer in secondi o in bit? In secondi di video; $B'=\frac S{R_C}$ (stallo) e $\frac S{R_C}-1$ (riproduzione).
Chi sceglie la qualità? Il client, segmento per segmento (pull su HTTP): il server tiene solo l'MPD e i segmenti.
Perché HTTP: stateless, NAT e firewall, cache e CDN; con QUIC niente head-of-line blocking, 0-RTT, migrazione di connessione.
Esempio rapido: $R_C=1$ Mbit/s, $S=0{,}8$ Mbit/s, $B_0=5$ s $\Rightarrow$ $B'=-0{,}2$ , vuoto a $t^*=25$ s.

Streaming adattativo e DASH

1. Il problema: $R_C\le S$

1.1 Che cosa succede se $S<R_C$

1.2 Rimedi che non funzionano

1.3 Server più rete: codifica scalabile (SVC)

2. Streaming adattativo (ABR)

2.1 Modello di sistema

2.2 Il ciclo del client

2.3 Tempo di download

3. Il playout buffer

3.1 Andamento di $B(t)$

3.2 Esempio con più segmenti (dalle slide)

3.3 Esempio svolto: due strategie a confronto

4. Misurare la QoE di uno streaming

5. Algoritmi di adattamento (ABR)

5.1 Un algoritmo di esempio (dalle slide)

6. MPEG-DASH

7. Riepilogo

Domande d'esame

Esercizi su questo argomento

Teoria collegata

Streaming adattativo e DASH

1. Il problema: RC≤SR_C\le SRC​≤S

1.1 Che cosa succede se S<RCS<R_CS<RC​

1.2 Rimedi che non funzionano

1.3 Server più rete: codifica scalabile (SVC)

2. Streaming adattativo (ABR)

2.1 Modello di sistema

2.2 Il ciclo del client

2.3 Tempo di download

3. Il playout buffer

3.1 Andamento di B(t)B(t)B(t)

3.2 Esempio con più segmenti (dalle slide)

3.3 Esempio svolto: due strategie a confronto

4. Misurare la QoE di uno streaming

5. Algoritmi di adattamento (ABR)

5.1 Un algoritmo di esempio (dalle slide)

6. MPEG-DASH

7. Riepilogo

Domande d'esame

Esercizi su questo argomento

Teoria collegata

1. Il problema: $R_C\le S$

1.1 Che cosa succede se $S<R_C$

3.1 Andamento di $B(t)$