Video Over IP (Internet)

Transcript

1 Università degli Studi di Modena e Reggio Emilia Dipartimento di Ingegneria dell Informazione Video Over IP (Internet) Maria Luisa Merani 1

2 INDICE Elementi base della codifica video Costruzione di un background funzionale alla trattazione Ratio Funzionalità chiave in una architettura per il trasporto video, con riferimento a MPEG-4 Adattatività della rate di sorgente e Relativo controllo con feed-back end-to-end Pacchettizzazione Controllo d errore 2

3 Premessa Molto raramente un CODEC video è impiegato in isolamento Al contrario, è spesso parte di un sistema di comunicazione che prevede 1. Operazioni di coding video e audio 2. Combining dei dati codificati 3. Immagazzinamento e/o trasmissione dello stream complessivo CODING COMBINING TRANSMISSION STORING 3

4 RATIONALE Successo di Internet Flessibilità di MPEG-4 Il trasporto di video MPEG-4 su Internet diviene una componente importante per molte applicazioni multimediali che fanno uso della rete. Obiettivo altamente desiderabile: Progettare un sistema di video delivery che massimizzi la qualità percepita in condizioni i i di variabilità (banda d o meglio bit rate, ritardo, jitter, loss rate) tenendo in considerazione i vincoli altamente specifici delle applicazioni video su Internet (ritardo e perdita) e al contempo garantisca un elevato utilizzo delle risorse di rete 4

5 Overview architetturale tt Caso 1: Live video Live video: è possibile impiegare un algoritmo di rate adaptation per controllare la rate r di uscita del codificatore. Si modificano i coefficienti di quantizzazione L encoder è adattativo! 5

6 Caso 2: Video precompresso Rate shaper Video precompresso: è possibile adattare la bit rate dello stream video senza modificare la scala di quantizzazione attraverso diverse tecniche Dynamic rate shaping Selective frame discarding Ulteriore alternativa: codifica FGS Fine Granular Scalability Per tutte queste tecniche non esiste un percorso di comunicazione tra il rate shaper e la sorgente video non è necessario un accesso all encoder video 6

7 Video precompresso Dynamic rate shaping Si tratta di un algoritmo del tipo selective transmission Al termine di ciascun blocco costituente l immagine si elimina quando necessario - un set di coefficienti DCT Selective frame discarding 7

8 FINE GRANULAR SCALABILITY FGS Si tratta di un metodo che consente la codifica di una sorgente video attraverso un Base layer + Enhancement layer questo può venire troncato durante o dopo la fase di codifica per garantire un controllo altamente flessibile sulla bit rate di trasmissione. A scapito della qualità della sequenza decodificata Scenario tipico: Sequenza codificata come un base layer più un enhancement layer ad alta qualità All atto della notifica della disponibilità di una particolare bitrate per la trasmissione, il server di streaming trasmette il livello base più una versione troncata del secondo layer Il grado di troncamento viene scelto in modo da sfruttare appieno la bit rate disponibile per la trasmissione Massimizza la qualità, senza la necessità di ricodificare la sequenza video 8

9 FGS fase di encoding SCHEMA A BLOCCHI SEMPLIFICATO DI UN ENCODER FGS Nel base layer, la texture è trasformata con la FDCT, quantizzata e codificata I coefficienti i i della quantizzazione i subiscono un re-scaling (inverse quantised) e vengono sottratti dai coefficienti DCT per ottenere un set di coefficienti differenza I coefficienti differenza di ciascun blocco vengono codificati come una serie di bitplanes: dapprima, i coefficienti differenza sono riordinati. I bit più significativi di ciascun coefficiente sono codificati per primi, e poi a scalare fino ai bit meno significativi 9

10 e di decodingdi Entrambi il base layer e l enhancement layer vengono decodificati I coefficienti differenza vengono sommati ai coefficienti del base layer e su di essi viene attuata una operazione di trasformazione inversa per ottenere la sequenza enhancement decodificata difi Se questa è stata troncata, l accuratezza dei coefficienti differenza è ridotta 10

11 Arricchimenti ulteriori i per FGS È inoltre possibile attuare un selective enhancement Bitplanes di MB selezionati dei frame costituenti il video vengono shiftati prima della codifica, così da ricevere una più alta priorità ed una probabilità più elevata di essere inclusi nel bitstream troncato Si tratta dei MB più significativi dell immagine frequency weigthing Coefficienti DCT a bassa frequenza (sono i più significativi a livello di percezione visiva) subiscono uno shift prima della codifica, con i medesimi i obiettivi i indicati in precedenza 11

12 Live video Lato sender: Primo stadio: codificatore MPEG-4 adattativo Valuta la banda disponibile ibil sulla rete operando sulla base di feedback ottenuti dal receiver Una possibile modalità operativa: L encoder comprime opportunamente - l informazione visuale e genera degli stream elementari (ESs) che contengono la rappresentazione codificata dei Visual Objects (VO) che MPEG-4 prevede In altri termini, lo stream di bit video è suddiviso in VOs Ciascun VO è codificato separatamente Gli stream codificati dei diversi VO sono o pacchettizzati a prima della multiplazione 12

13 Gli ESs sono pacchettizzati come SyncLayer (SL)-packetized streams Tali stream garantiscono» informazioni temporali e di sincronizzazione» informazioni sulla frammentazione Vengono multiplexati in uno stream dal TransMux Layer e poi passati a RTP Encoder guidati dal feedback di rete Struttura di un encoder MPEG-4 13

14 Soluzione possibile A fronte di un certo target bit budget dipendente dalla bit rate dettata dal controllo di congestione, oltre che dal valore minimo della bit rate che la sorgente video richiede e dalla dimensione dei buffer impiegati in trasmissione No overflow o underflow Si attribuisce a ciascun VO una frazione di tale budget Ad esempio in misura proporzionale alla complessità del suo contenuto ed all importanza percettiva che gli si associa 14

15 Formattazione dei dati 15

16 In ricezione i Lato receiver: Ricezione dei pacchetti che non sono andati perduti Persi nei router lungo il path verso destinazione (congestione) Persi nelle tratte radio (per errori di natura trasmissiva) Persi a destinazione (ritardo eccessivo) Attraversamento in ordine speculare dei moduli RTP/UDP/IP Monitor di QoS, deputato a rilevare lo stato di congestione della rete basandosi sulla modalità di arrivo dei pacchetti Stima della packet loss e del delay Feedback alla sorgente 16

17 I pacchetti ricevuti sono trasferiti all interfaccia di demultiplexing e da qui al FlexMux buffer Il componente per l error-concealment si fa carico di duplicare il VOP precedente se quello corrente è stato corrotto I decodificatori per i VO decodificano i dati e producono le composition units (CU) Struttura di un decoder MPEG-4 17

18 Un architettura tt possibile 18

19 Formato del payload RTP RFC 3640 e 3016 Con riferimento i a stream MPEG-4 Visual, la filosofia adottata t dall Internet Society sulla frammentazione ed il mapping degli stream video nei pacchetti RTP è la seguente: Poichè MPEG-4 Visual viene impiegato su reti eterogenee, non è opportuno adottare un approccio estremamente restrittivo del tipo a single video packet shall always be mapped on a single RTP packet Anche una frammentazione che non tenga conto delle caratteristiche della rete sottostante è tuttavia inappropriata Degrado della robustezza agli errori della trasmissione video Uso inefficiente della banda 19

20 RFC 3016 Pacchettizzazione i RTP Un bitstream MPEG-4 Visual viene mappato direttamente nei pacchetti RTP Senza l aggiunta di campi header extra Senza rimozione di elementi sintattici 20

21 Sequence number: incrementato di uno per ogni pacchetto RTP inviato valore iniziale random Motivi di sicurezza Timestamp: indica l istante di campionamento del VOP contenuto nel pacchetto RTP. Per motivi di sicurezza, viene aggiunto al corrispondente valore un offset costante Se più VOP in un pacchetto Il timestamp t indica l istante t di campionamento del VOP più datato t Le indicazioni di timestamp dei VOP successivi sono ottenute dai loro VOP header Risoluzione i di default del timestamp: t 90 KHz 21

22 RFC 3016 Alcune regole di frammentazione 1. VOP diversi dovrebbero should - essere frammentati in pacchetti RTP diversi Pacchetto RTP può comunque contenere i. un solo VOP ii. più VOP se la loro dimensione è modesta iii. Parte/i di un VOP i. Si può trattare di pacchetti video generati dall encoder ii. Frammenti di dimensione arbitraria del VOP se la funzione di pacchettizzazione dell encoder risulta disabilitata o non supportata 22

23 Continua Caso iii. Il numero ottimale di pacchetti video in un pacchetto RTP e la dimensione del pacchetto RTP sono funzione della packet loss rate p bit-rate B r della rete sottostante 23

24 Continua 2. Si raccomanda - it is recommended - di inviare ogni singolo pacchetto video tra quelli costituenti un VOP come un singolo pacchetto RTP La dimensione del pacchetto dovrebbe essere settata ad un valore <= path-mtu Soluzione adeguata anche quando la packet loss rate p della rete sottostante è relativamente elevata Se viene perduto il pacchetto RTP contenente il VOP header, gli altri pacchetti possono essere comunque decodificati, sfruttando il loro header (Video Packet VP header) 24

25 Continua 3. Se nella configurazione dell encoder la funzione di pacchettizzazione video (video packet) è disabilitata, o i coding tools non la supportano, un VOP può - may - essere splittato in corrispondenza di multipli arbitrari di byte Configurazione di encoder e frammentazione di pacchetto RTP sconsigliata in ambienti error-prone, presenta una scarsa resilienza agli errori OK se la rete sottostante viene garantita come error-free 25

26 RFC 3640 A livello terminologico MPEG definisce le Access Units per il trasporto di dati audio-visivi Una Access Unit (AU) MPEG è la più piccola entità dati cui viene attribuita it una informazione i temporale Caso audio: l AU è un frame (campione) audio Segnale stereo a 64 kbit/s, con codifica AAC, un frame audio è costituito da circa 200 byte Caso video: l AU è un VOP 26

27 Alcune delle specifiche fornite Concatenazione di Access Units Frammentazione di Access Units Interleaving Entrambe già presenti nell RFC 3016 Novità! Quando il pacchetto RTP trasporta una sequenza contigua di AU, la perdita del pacchetto si traduce in un decoding gap per l utente Come alleviare il problema? Eseguire un interleaving delle AU Costo implementativo e di latenza modesto Esempio: pacchetto RTP contenente 3 AU, interleaving group length pari a 9 27

28 Continua Informazione di Time Stamp Il time stamp dell RTP deve indicare l istante di campionamento della prima AU nel pacchetto RTP Il payload può essere configurato così da trasportare il time stamp di ciascuna a AU Indicazione di stato per gli stream MPEG-4 Il payload RTP consente - come opzione - il trasporto dell indicazione dello stato di stream per ciascuna AU che contiene Impiegato ad es. per segnalare AU cruciali, la cui perdita non può essere tollerata Indicazione di random access Accesso in ricezione ai dati audio-video MPEG-4 è possibile in corrispondenza ad alcune AU degli stream elementari MPEG-4, non a tutte Opzione nell RTP payload: segnalare la possibilità di accesso con un random access point flag per ogni AU Altre 28

29 Struttura tt globale l del formato del payload Non definita nelle specifiche dell RFC 3640 La AU Header Section, quando presente. Gli AU header sono a loro volta specificati nell RFC E la Access Unit data section 29

30 La dimensione ed il numero di AU all interno della data section dovrebbero essere individuati così che il risultante pacchetto RTP non sia più grande della MTU della rete sottostante Per gestire pacchetti di ampie dimensioni, è necessario appoggiarsi ai livelli più bassi (tipicamente IP) per la frammentazione, che può tuttavia tradursi in prestazioni ridotte 30

31 Ma RFC 3016 non affermava che il mapping avveniva senza l inserimento di header ulteriori? AU header??? RFC 3016 proposed standard RFC 3640 standard Il suo payload può essere configurato in maniera pressochè identica a quello precisato nell RFC 3016 Ricevitori che sono conformi all RFC 3016 possono decodificare il payload RFC 3640 Ricevitori conformi all RFC 3640 dovrebbero (SHOULD) essere in grado di decodificare payload, nomi e parametri per l MPEG-4 così come definiti nell RFC

32 Proposta di approfondimento Analizzare la problematica dei ritardi introdotti dall operazione di interleaving, basandosi sull RFC 3640, Section e Appendix A 32

33 Il Feedback dalla rete Come osservato in precedenza, le applicazioni video per Internet hanno specifiche richieste in termini di Ritardo Perdita Tuttavia, Internet è ancora, nella stragrande maggioranza dei casi, una rete che garantisce servizi best-effort La banda disponibile non è nota a priori varia nel tempo 33

34 Poiché gli switch/router non partecipano attivamente al processo di feeback, Internet è trattata alla stregua di una black box Il controllo viene interamente spostato sugli end-system e consiste in Un meccanismo che a livello di sorgente consente A.di rilevare lo stato della rete e B.di modificare conseguentemente la rate di output del video 34

35 Perché un feedback dalla rete è necessario lato applicazione? R: Perché, ad esempio in termini i di banda, esistono valori (requisiti) diversi e corrispondentemente diversi livelli di qualità 35

36 Più precisamente Il problema su Internet non è: ottimizzare la qualità video ad una bit rate data ma piuttosto: per un certo range di bit rate 36

37 Effetti della perdita di pacchetti sulla qualità video Gli stream video sono molto suscettibili agli effetti della rete: La perdita di pacchetti può causare la perdita di parti o di interi frame Poiché il contenuto informativo di un frame video viene tipicamente distribuito su più pacchetti, e gli stream video tipici contengono frame interpolati, la corrispondenza tra perdita di frame e di pacchetti è di questo tipo: CASO MPEG 37

38 Effetti del jitter e importanza del buffer Gli effetti del jitter sono simili a quelli sperimentati da una applicazione VoIP Si impiega un jitter buffer per compensare moderate variazioni di ritardo Nulla da decodificare POOR VIDEO 38

39 Streaming e video conferenza Streaming video Il ritardo massimo tollerabile è significativo Il jitter buffer può avere una profondità notevole setting di default: ms (valori indicativi) Video conferenza L interattività necessita di un ritardo contenuto Pacchetti che giungono al ricevitore troppo tardi sono scartati e appaiono come pacchetti perduti Profondità del jitter buffer: Default: 80 ms, non adattativo (valore indicativo) 39

40 E perché un controllo risulta necessario anche lato rete? Sorgenti UDP aggressive Sorgenti TCP disciplinate Il concetto di controllo di congestione è nativo in TCP! Suddivisione unfair della banda in presenza di congestione UN ESEMPIO DI UNFAIRNESS Time (s) TCP per tutti tti i tipi i di applicazioni? i i? R: Impraticabile, overhead eccessivo se non si è interessati all accuratezza dei dati che il TCP garantisce (three ways handshake, fase di connection termination, ) 40

41 Più propriamente Ed anche in termini più ampi, si parla di CONTROLLO DI CONGESTIONE, impiegando tale termine per definire le operazioni atte a regimare un applicazione multimediale, UDP-based, che sulla rete dovrà coesistere pacificamente con applicazioni TCP-based 41

42 Approcci possibili Soluzione network-centric I router/switch della rete concorrono attivamente a garantire determinati valori di banda end-to-end a prevenire elevati valori di ritardi e di packet loss Non è ciò che Internet consente di fare oggi Soluzione end-to-end L end-system impiega tecniche di controllo adeguate per massimizzare la qualità video, o più in generale dell applicazione multimediale garantire una coesistenza fair con le applicazioni TCP-based garantire un utilizzo efficiente delle risorse di rete senza supporto di QoS dalla rete 42

43 Ancora Tra le soluzioni classificabili come end-to-end, le strategie di controllo vengono ulteriormente suddivise in WINDOW-BASED alla stregua del TCP adottano una finestra per il controllo di congestione, lato sender o lato receiver Diverse le leggi di crescita/decrescita (no AIMD), per garantire una evoluzione smooth, alternativa al saw-tooth del TCP 43

44 RATE -BASED Tale genere di approcci stima dinamicamente la send rate della sorgente sulla base di indicatori dello stato della rete: loss rate RTT Il più popolare è il TFRC (TCP Friendly Rate Control Protocol) Basato sull equazione di Padhye per la stima della send rate del TCP s X = RTT bp + t min 1,3 bp RTO p( p ) 3 8 dove: X send rate in byte/s, s packet size, RTT round trip time stimato, t RTO retransmission time-out, b numero di pacchetti confermati da ogni ACK, p packet loss rate Per questo si parla anche di controllo EQUATION-BASED 44

45 Al contrario di quel che accade per i controlli a finestra, questo tipo di controlli non contempla l impiego degli acknowledgment Al loro posto: Feedback packets rappresentano lo strumento attraverso il quale veicolare al sender informazioni sullo stato corrente della connessione Il loro ruolo non è tuttavia direttamente paragonabile a quello degli Ack nel TCP o nei controlli a finestra Non è la ricezione o la non ricezione dei feedback l evento che fa immediatamente scattare l aggiornamento della velocità con cui la sorgente inietta dati nella rete 45

46 RATE-BASED: a quale livello? ll Il controllo di congestione RATE-BASED e dunque la regimazione della sorgente video può essere attuato A livello intermedio tra trasporto e applicazione: Si lavora con feedback packets che specifiche soluzioni propongono (feedback packets del TFRC, ad esempio) Continuando ad appoggiarsi a UDP A livello applicazione In quest ultimo caso saranno i pacchetti RTCP di feedback a veicolare alla sorgente informazioni sullo stato della rete L azione di rate control sarà attuata dalla sorgente alla ricezione di ciascuno di tali pacchetti 46

47 Un esempio in quest ultimo caso Si tratta di un algoritmo ratebased che impiega esclusivamente il feedback sulla packet loss rate P loss IR = initial rate MR = minimum rate PR = peak rate L output dell encoder è regolato da leggi AIMD implementate a livello applicazione 47

48 Con quale tipo di risultati ti Con riferimento alla seguente topologia Esaminando condizioni di variabilità di banda: SMOOTH??? D. Wu et al. On End-to-End Architecture for Transporting MPEG-4 Video Over the Internet, IEEE Trans. On Circuits and Systems for Video Technology, Vol.10, No.10, Settembre

49 Un altra proposta: SFRAM SFRAM (Smooth and Fast Rate Adaptation Mechanism) Rate-based Pesantemente basato sul TFRC Richiede stima di RTT, p, TO Con questo tipo di risultati sul fronte della responsiveness e della smoothness: Sorgenti video H.263 e dumbell topology Y.K. Kim et al. TCP_Friendly Internet Video with Smooth and Fast Rate Adaptation and Network- Aware Error Control, IEEE Trans. On Circuits and Systems for Video Technology, Vol.14, No.2, Febbraio

50 Approfondimento Leggere e commentare criticamente l articolo: J. Viéron, C. Guillemot Real-Time Constrained TCP-Compatible Rate Control for Video over the Internet, t IEEE Trans. On Multimedia, Agosto 2004, Vol.6, No.4, pp

51 Nella realtà L esatta modalità con cui opera il controllo di congestione in applicazioni streaming proprietarie Realplayer Windows Media Player non è noto in maniera diffusa Probabilmente è basato su algoritmi del tipo AIAD sui layer che costituiscono le immagini video 51

52 Lo stato t dell arte Le applicazioni di streaming video non richiedono necessariamente l object based coding Tradizionalmente si associa allo streaming su Internet o su reti a pacchetto l adozione dell FGS Peraltro l object-based based coding non è largamente supportato dalle applicazioni commerciali che implementano lo standard MPEG-4 52

53 Qualità video - Considerazioni i i generali Gli standard d per codifica video sono caratterizzati ti da un significativo grado di flessibilità lato encoder/decoder Numerosi i trade-off possibili tra complessità implementativa hw/sw e prestazioni Ciò rende intrinsecamente difficile affrontare con metodo il seguente problema: Come quantificare gli effetti negativi introdotti dall encoder e dalla rete sulla qualità del video trasmesso? Non è semplice! 53

54 Una semplice metrica oggettiva PSNR Peak Signal-to-Noise i Ratio (2 1) PSNR db = 10log 10 MSE n 2 n bit per campione all interno dell immagine MSE: Mean Squared Error tra l immagine originale e quella impaired, di cui si desidera stimare la qualità (2 n -1) 2 : quadrato del valore di segnale più alto possibile all interno dell immagine 54

55 Ed i suoi limiti iti (a) Originale i (b) 30.6 db (c) 28.3 db db 55

56 Esempio di impiego i del PSNR su una rete Con riferimento al controllo ed alla topologia citati in precedenza In condizioni di variabilità di banda D. Wu et al. On End-to-End Architecture for Transporting MPEG-4 Video Over the Internet, IEEE Trans. On Circuits and Systems for Video Technology, Vol.10, No.10, Settembre

57 PSNR e packet loss rate MPEG-2 e dumbell topology G. Davini et al. Perceptually Evaluated Loss-Delay Controlled Adaptive Transmission of MPEG Video Over IP, IEEE InfoCom 2003, pp PSNR (db) Intervallo temporale (s) Valor medio Deviazione standard MPEG 2 Video over IP MPEG 2 Video over IP

58 Esercitazione i in laboratorio! Valutazione del PSNR per video trasmessi attraverso Internet Codec MPEG-4 e H.264 simulazione via ns2 di diverse condizioni di rete Packet loss rate p variabile perdite random e a burst Banda variabile Jitter variabile 58