Applicazioni Multimediali Reti per la multimedialità Applicazioni multimediali: audio e video in rete ( continuous media ) 1
Applicazioni Multimediali Tipicamente sensibili a ritardi ed alle variazioni del ritardo (jitter) Ma tolleranti rispetto a perdite di dati: perdite non frequenti causano piccoli disturbi che possono essere parzialmente o completamente dissimulati Antitetiche alle applicazioni tradizionali che operano su 'dati' (programmi, informazioni bancarie, etc.), che sono intolleranti riguardo a perdite ma tolleranti relativamente a possibili ritardi Sessione multimediale: una sessione che contiene diversi tipi di media es., un film contenente audio & video Sessione continuous-media: una sessione in cui l'informazione deve essere trasmessa con continuità es., audio, video, ma non testo Streaming: uso dei dati da parte dell'applicazione durante la loro trasmissione Classi di applicazioni MM Streaming di audio e video memorizzati Streaming audio e video live Real-time interattivo Ogni classe può essere broadcast (multicast) o può semplicemente essere unicast Streaming di audio e video memorizzati I client richiedono dei file audio/video (compressi) dai server ed effettuano in pipeline la ricezione sulla rete e la riproduzione Interattivo: l'utente può controllare l'operazione (come in un VCR: pausa, riavvolgimento, avanzamento rapido, ecc.) Ritardi: dalla richiesta del client sino all'inizio della riproduzione 10 sec OK 1-2 sec perchè il comando abbia effetto OK vincoli di tempo per dati ancora da trasmettere: arrivare in tempo per la riproduzione 2
! " # $ " " % Streaming audio e video live simile alle stazioni radio e TV esistenti, ma la distribuzione è sulla rete Real-Time unidirezionale, non interattivo, solo ascoltare/vedere avanzamento rapido impossibile pausa, riavvolgimento possibili! Real-Time interattivo Conversazione telefonica o videoconferenza Requisiti di ritardo più stringenti di Streaming ed Unidirezionale a causa della natura interattiva real-time Video: < 150 msec accettabile Audio: < 150 msec buono, <400 msec accettabile includono ritardi di livello di applicazione (pacchettizzazione) e ritardi di rete ritardi maggiori precludono l'interattività 3
Internet: best effort La suite TCP/UDP/IP provvede best-effort, nessuna garanzia sul ritardo nè sulla sua variabilità Applicazioni streaming con un ritardo iniziale di 5-10 secondi sono ora comuni, ma le prestazioni si deteriorano se i link sono congestionati Applicazioni Real-Time interattive hanno requisiti rigidi di ritardo e di jitter Jitter è la variabilità dei ritardi di pacchetti entro lo stesso packet stream Il progetto di applicazioni multimediali sarebbe più facile se ci fossero servizi di 1 e 2 classe Ma nella Internet pubblica, tutti i pacchetti ricevono lo stesso servizio I pacchetti contenenenti audio e video interattivo real-time fanno la fila, come tutti gli altri Usare UDP per evitare TCP e la sua fase di slow-start Bufferizzare i contenuti al client e controllare la riproduzione per rimediare al jitter Si possono usare timestamp nei pacchetti, in modo che il receiver sappia quando riprodurre i pacchetti Si possono inviare pacchetti ridondanti per mitigare gli effetti della perdita di pacchetti Adattare il livello di compressione alla bandwidth disponibile Jitter Il jitter di una coppia di pacchetti è la differenza tra l'intervallo dei tempi di ricezione e l'intervallo dei tempi di trasmissione # & # & & ( ' & Intervallo di tempo desiderato: S i+1 S i ; ricevuto: R i+1 - R i Jitter tra i pacchetti i ed i+1: (R i+1 - R i ) - (S i+1 - S i ) 4
Approccio non streaming Audio: in file inviati come oggetti HTTP Video (audio ed immagini interleaved in un file, o due file separati ed il client sincronizza il display) inviati come oggetti HTTP Una semplice architettura è il Browser che richiede gli oggetti e dopo averli ricevuti completamente li passa al media player per il display Media player rimuove il jitter decomprime corregge errori realizza una graphical user interface con controlli per l'interattività audio, video non streamed, non pipelining, lunghi ritardi per la riproduzione! Streaming da Web Il Web browser richiede e riceve un Meta File (un file descrivente l'oggetto) invece di ricevere il file stesso; Il Browser lancia l'appropriato Player e gli passa il Meta File; Il Player attiva una connessione TCP con il Web Server ed effettua download e streaming del file Inconvenienti: - il Media player comunica su HTTP, che non è progettato con comandi pause, fast forward e rewind - può voler fare streaming su UDP e non su TCP 5
Streaming server Questo permette di evitare HTTP e dà la possibilità di scegliere fra UDP e TCP Se si usa UDP Il Server invia ad una velocità costante d (Compressione e Trasmissione) appropriata per il client, incurante della congestione. Per ridurre il jitter, il Player bufferizza inizialmente per 2-5 secondi, quindi inizia la presentazione La velocità di riempimento x(t) è costante ed uguaglia d eccetto quando c'è una perdita ) " *+, ) " 6
Se si usa TCP Il sender invia alla massima velocità permessa sotto TCP e ritrasmette quando un errore è incontrato x(t) ora fluttua notevolmente. Il Player deve usare un buffer molto grande per fare 'smoothing' della velocità di consegna di TCP e deve iniziare a riprodurre dopo un ritardo maggiore ) " *+, ) " Buffering e ritardo di riproduzione al client +(, Il buffering ed il ritardo di riproduzione dal lato client compensano il ritardo aggiunto dalla rete ed il jitter 7
Copie multiple -. / / 0 Come trattare differenti capacità di ricezione da parte dei client? linea telefonica da 28.8 Kbps 100Mbps Ethernet Il server immagazzina e trasmette copie multiple di video, codificate a differenti velocità RTSP - Real Time Streaming Protocol HTTP I progettisti di HTTP avevano in mente media fissi: HTML, immagini, applets, etc. HTTP non è orientato a media continui memorizzati RTSP Protocollo di strato di applicazione client-server fra media player e server Permette all'utente di controllare la presentazione: riavvolgimento, avanzamento rapido, pausa, ripristino, riposizionamento, ecc Cosa non fa: non definisce come l'audio/video è incapsulato per lo streaming sulla rete (ci pensa RTP) non vincola su come i media streamed debbono essere trasportati; essi possono essere trasportati su UDP o TCP non specifica come il media player bufferizza l'audio/video I messaggi di controllo RTSP usano un numero di porta differente da quelle del media stream, e sono perciò inviati fuori banda 8
Il browser Web richiede (HTTP GET) ed ottiene una descrizione della presentazione dal server Web (meta file), che può contenere riferimenti (URL rtsp://) a diversi file di media continui (track), appartenenti allo stesso group, e le direttive per la loro sincronizzazione (lipsync). Nell esempio, il media player può switch tra un track audio di tipo lofi ed uno di tipo hifi. 1 '' ' Il client inizia una sessione RTSP con una richiesta di <title>twister</title> SETUP, ed il server <session> risponde alla richiesta con <group language=en lipsync> un identificatore di sessione <switch> (Session) che verrà usato <track type=audio e="pcmu/8000/1" da tutti i messaggi successivi. src = "rtsp://audio.example.com/twister/audio.en/lofi"> Il client invia una richiesta <track type=audio di PLAY, per es. di un audio e="dvi4/16000/2" pt="90 DVI4/8000/1" a bassa fedeltà (lofi) che src="rtsp://audio.example.com/twister/audio.en/hifi"> verrà trasmesso dal server </switch> <track type="video/jpeg" nel proprio canale in banda. src="rtsp://video.example.com/twister/video"> Il client può inviare richieste </group> di PAUSE ed altri messaggi </session> di controllo, ed infine termina la sessione con una richiesta di TEARDOWN. Meta file Il client inizia una sessione RTSP con una richiesta di SETUP, fornendo l URL del file da scaricare, la versione di RTSP, il numero di porta del client a cui il media stream deve essere inviato ed il protocollo da utilizzare (Transport). Il client usa numeri di sequenza (Cseq) che verranno confermati dal server nelle sue risposte. Il server risponde alla richiesta con un identificatore di sessione (Session) che verrà usato da tutti i messaggi successivi. Il client invia una richiesta di PLAY, per es. di un audio a bassa fedeltà (lofi) che verrà trasmesso dal server nel proprio canale in banda. Il client può inviare richieste di PAUSE ed altri messaggi di controllo, ed infine termina la sessione con una richiesta di TEARDOWN. C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Cseq: 1 Transport: rtp/udp; compression; port=3056; mode=play S: RTSP/1.0 200 OK Cseq: 1 Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Range: npt=0- (npt = normal play time) Cseq: 2 Session: 4231 S: RTSP/1.0 200 OK Cseq: 2 Session 4231 C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 Cseq: 3 Session: 4231 S: RTSP/1.0 200 OK Cseq: 3 Session 4231 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Cseq: 4 Session: 4231 S: RTSP/1.0 200 OK Cseq: 4 Session 4231 9
Streaming caching Il caching di messaggi di RTSP response ha poco senso, ma è desiderabile effettuare caching di media stream Molto del controllo di cache HTTP/1.1 è stato adottato da RTSP Header di controllo di cache possono essere posti in RTSP SETUP request e response: If-modified-since:, Expires:, Via:, Cache-Control: Una proxy cache può cominciare a servire un client dalla sua cache locale, e quindi dover connettersi al server originario e riempire il materiale mancante, sperabilmente senza introdurre gap al client Quando il server originario sta inviando uno stream ad un client, e lo stream passa attraverso un proxy, il proxy può usare TCP per ottenere lo stream; ma il proxy ancora invia messaggi di controllo RTSP al server originario Applicazioni real-time interattive: Telefonia Internet Telefonia fra PC e PC, fra PC e telefono, videoconferenza, Webcam Applicazioni di telefonia Internet generano pacchetti ad intervalli costanti durante i periodi di conversazione la bit rate è di 64 kbps ogni 20 msec l'applicazione genera un pezzo di 160 byte = 8 kbyte/sec * 20 msec un header è aggiunto al pezzo; quindi pezzo+header è incapsulato in un segmento UDP ed inviato alcuni segmenti possono essere persi (tollerabile sino al 20%) ed il ritardo dei segmenti fluttuerà il receiver deve determinare quando riprodurre un pezzo (ritardo di riproduzione fisso o adattativo), e decidere cosa fare se ci sono pezzi mancanti (pacchetti ridondanti possono aiutare) 10
Ritardo di riproduzione fisso Il receiver tenta di riprodurre ciascun pezzo esattamente q msec dopo che il pezzo è stato generato: se il pezzo è time stamped t, il receiver riproduce il pezzo all'istante t+q. Se il pezzo arriva dopo il tempo t+q, il receiver lo scarta Il sender genera pacchetti ad intervalli costanti durante un periodo di parlato supponiamo che il primo pacchetto sia ricevuto al tempo r la schedulazione per la riproduzione inizia da p scegliendo un valore di q in modo da avere un ritardo iniziale p r piccolo: alcuni pacchetti arrivano in ritardo rispetto alla schedulazione prevista la schedulazione per la riproduzione che inizia da p sceglie un valore di q maggiore in modo da avere un ritardo iniziale p r maggiore: tutti i pacchetti arrivano prima della schedulazione prevista q piccolo: migliore esperienza interattiva q grande: meno perdite di pacchetti packets packets generated r packets received p p' loss playout schedule p' - r playout schedule p - r time Ritardo di riproduzione adattativo Si stima il ritardo corrente della rete per ogni pacchetto ricevuto, e si aggiusta il ritardo di riproduzione all'inizio di ciascun periodo di parlato Stima dinamica del ritardo medio e della deviazione media al receiver dopo aver ricevuto il pacchetto i-esimo: di = ( 1 u) di 1 + u( ri ti ) v 1 u) v + u r t d i = ( i 1 i i i ( t i = timestamp del pacchetto i-esimo) le stime d i e v i sono calcolate per ogni pacchetto ricevuto, sebbene siano usate solo all'inizio dei periodi di parlato periodi di silenzio possono essere compressi o allungati senza che l'utente se ne accorga I pezzi sono ancora riprodotti ad intervalli costanti durante i periodi di parlato Per il primo pacchetto nel periodo di parlato, il tempo di riproduzione è: p i = ti + di + Kvi Per questo stesso pacchetto, il ritardo è: qi = pi ti Per il pacchetto j nello stesso periodo di parlato, riprodurlo a p = t + q j j i 11
Come determinare se un pacchetto è il primo in un periodo: Se non ci fossero mai perdite, il receiver potrebbe semplicemente guardare i successivi timestamp differenza dei successivi stamp > 20 msec, comincia un periodo di parlato ma, poichè le perdite sono possibili, il receiver deve guardare sia i timestamp che i numeri di sequenza differenza di successivi stamp > 20 msec e numeri di sequenza senza gap, comincia un periodo di parlato Recupero da perdite di pacchetti Perdita: un pacchetto non arriva mai o arriva più tardi del suo tempo di riproduzione schedulato forward error correction (FEC): 1 schema per ogni gruppo di n pezzi creare un pezzo ridondante mediante exclusive OR degli n pezzi originari mandare n+1 pezzi, incrementando l uso di banda di un fattore 1/n si può ricostruire gli n pezzi originari se c'è al più un pezzo perso fra gli n+1 pezzi il ritardo di riproduzione è necessario che sia uguale al tempo per ricevere tutti gli n+1 pacchetti aumentando n si spreca meno banda, ma il ritardo di riproduzione è più lungo e più alta è la probabilità che 2 o più pezzi siano persi 12
2 schema FEC : piggyback di stream di più bassa qualità Per es., invia audio stream di più bassa risoluzione come informazione ridondante: stream nominale PCM a 64 kbps e stream ridondante GSM a 13 kbps. Il sender crea il pacchetto prendendo l'n-esimo pezzo dallo stream nominale ed attaccando l'(n-1)-esimo pezzo dallo stream ridondante. Quando ci sono perdite non consecutive, il receiver può nasconderle. Solo due pacchetti debbono essere ricevuti prima della riproduzione. Si può aggiungere anche l'(n-1)-esimo e l'(n-2)-esimo pezzo a bassa bit rate. Interleaving I pezzi sono suddivisi in più piccole unità per es., 4 unità di 5 msec per pezzo 'interleave' i pezzi così come è mostrato un pacchetto ora contiene piccole unità da differenti pezzi si riassemblano i pezzi al receiver se il pacchetto è perso, si ha ancora la maggior parte di ogni pezzo Riparazione basata sul receiver produce una sostituzione di un pacchetto perso che è simile all'originale può dare buone prestazioni per bassi tassi di perdite e piccoli pacchetti la più semplice: ripetizione più complicata: interpolazione 13
RTP Real Time Protocol RTP specifica una struttura per pacchetti che portano dati audio e video Il pacchetto RTP fornisce identificazione del tipo di payload (i sender possono cambiare codifica durante una conferenza) numeri di sequenza di pacchetti (si può riconoscere il primo pacchetto di un periodo) timestamping RTP sta negli end system I pacchetti RTP sono incapsulati in segmenti UDP Interoperabilità: se due applicazioni di telefonia Internet differenti eseguono RTP, allora possono funzionare insieme RTP sul top di UDP: Le librerie RTP forniscono una interfaccia a livello di trasporto che estende UDP RTP permette che a ciascuna sorgente (per esempio, una telecamera o un microfono) sia assegnato il suo stream indipendente di pacchetti RTP Per esempio, per una videoconferenza tra due partecipanti, quattro stream RTP potrebbero essere aperti: due stream per trasmettere l'audio (uno in ciascuna direzione) e due stream per il video (di nuovo, uno in ciascuna direzione) Tuttavia, alcune popolari tecniche di codifica -- come MPEG1 ed MPEG2 riuniscono l'audio ed il video in un singolo stream durante il processo di codifica Se è usato un mixer 0 4 8 16 31 V P X CC M Payload type Sequence number Timestamp Synchronization source (SSRC) identifier Contributing source. (CSRC) identifier. Contributing source. (CSRC) identifier P: padding segue il payload, l'ultimo ottetto è il numero di ottetti di padding X: segue un extension header (uno solo) CC, CSRC Count: numero di identificatori CSRC M, Marker: segna l'inizio o la fine (di un frame video per es.) Payload Type: 7 bit, che forniscono 128 possibili tipi differenti di codifica Sequence Number: 16 bit Timestamp: 32 bit; dà l'istante di campionamento del primo byte audio/video nel pacchetto Il timestamp è derivato da un sampling clock al sender Ad esempio, per l'audio il timestamp clock incrementa di uno per ciascun periodo di campionamento (ogni 125 microsecondi nel caso di un sampling clock di 8 KHz); se l'applicazione audio genera pezzi consistenti di 160 campioni codificati, allora il timestamp aumenta di 160 per ogni pacchetto RTP quando la sorgente è attiva. Il timestamp clock continua ad aumentare ad una velocità costante anche se la sorgente è inattiva Synchronization SouRCe (SSRC) identifier: 32 bit; un id per la sorgente di uno stream, assegnato a caso dalla sorgente Contributing SouRCe (CSRC) identifier: 32 bit; se viene usato un mixer 14
Relay, Mixer, Translator Un relay è un sistema intermedio che agisce sia come destinazione che come sorgente in un trasferimento dati Un mixer è un relay RTP che riceve stream di pacchetti RTP da una o più sorgenti, li combina in un nuovo stream che invia ad una o più destinazioni. Il mixer fornisce il timing del nuovo stream e diviene la Synchronization source. Questa è seguita dagli identificatori delle sorgenti che hanno contribuito al nuovo stream (Contributing source) Un translator è un relay che cambia il formato dei dati nel pacchetto (per es. da video di qualità superiore a video di qualità inferiore, o trasforma un pacchetto multicast replicandolo ad un certo numero di destinazioni unicast) RTCP - Real-Time Control Protocol Lavora in congiunzione con RTP Ciascun partecipante in una sessione RTP trasmette periodicamente pacchetti di controllo RTCP a tutti gli altri partecipanti. Ogni pacchetto RTCP contiene dei report del sender e/o del receiver che riportano statistiche utili all'applicazione Le statistiche includono: numero di pacchetti inviati, numero di pacchetti persi, jitter, ecc. Questo feedback di informazione all'applicazione può essere usato per controllare le prestazioni e per fini diagnostici il sender può modificare le sue trasmissioni in base al feedback. Per una sessione RTP c'è tipicamente un singolo indirizzo multicast; tutti i pacchetti RTP ed RTCP appartenenti alla sessione usano lo stesso indirizzo multicast I pacchetti RTP ed RTCP si distinguono l'uno dall'altro attraverso l'uso di numeri di porta distinti. Tutti i pacchetti RTP sono inviati ad una porta con numero pari, 2p; tutti i pacchetti RTCP sono inviati alla porta 2p+1 15
Sincronizzazione di stream RTCP può essere usato per sincronizzare differenti media stream all'interno di una sessione RTP Si consideri un'applicazione di videoconferenza per cui ciascun sender genera uno stream RTP per video ed uno per audio I timestamp in questi pacchetti RTP sono legati ai clock di campionamento video ed audio, e non al tempo reale, per cui non possono essere usati per sincronizzare i due stream Ciascun pacchetto RTCP di report del sender contiene, per il pacchetto generato più recentemente nello stream RTP associato, il timestamp del pacchetto RTP ed il tempo reale in cui il pacchetto era stato creato. Così i pacchetti RTCP di report del sender associano il clock di campionamento all'orologio del tempo reale I receiver possono usare questa associazione per sincronizzare la riproduzione di audio e video. Bandwidth Scaling RTCP effettua controllo di congestione: tenta di limitare il suo traffico al 5% della banda di sessione Per esempio, supponiamo che ci sia un sender che invia video ad una velocità di 2 Mbps. Allora RTCP tenta di limitare il suo traffico a 100 Kbps Il protocollo dà il 75% di questa velocità, o 75 kbps, ai receiver, ed il rimanente 25%, o 25 kbps, al sender I 75 kbps dedicati ai receiver sono equamente distribuiti tra i receiver. Così, se ci sono R receiver, allora ciascun receiver riesce ad inviare traffico RTCP ad una velocità di 75/R kbps ed il sender può inviare traffico RTCP ad una velocità di 25 kbps Un partecipante (un sender o receiver) determina il periodo di trasmissione di pacchetti RTCP calcolando dinamicamente la dimensione media di pacchetto RTCP (lungo l'intera sessione) e dividendola per la velocità assegnatagli T sender = # senders * avg RTCP pkt size/(.25 *.05 * RTP bandwidth) T rcvr = # receivers * avg RTCP pkt size/(.75 *.05 * RTP bandwidth) Invia a (.5 + rand(0,1)) * T [sender rcvr] 16