3. Reea INTERNET multimedia 3.1. Stiva de protocoale pentru reeaua IP multimedia In fig.3.1.

este prezentat stiva protocoalelor folosite n Internet.

Fig.3.1. Stiva de protocoale pentru reeaua IP multimedia Stiva de protocoale a reelei IP utilizeaz modelul de referin OSI (Open System Interconnection) care a avut n vedere asigurarea compatibilitii i interoperabilitatea ntre diverse tehnologii furnizate de firme diferite. Un protocol este un set de reguli care determin formatul i modalitatea n care datele sau informaia pot fi trimise sau primite. Stiva de protocoale a reelei IP pune n eviden modalitatea n care informaia este trimis i recepionat prin reea. Fiecare strat are asociate funcii specifice.

Fig.3.2. Transmiterea informaiei prin stiva de protocoale a reelei IP. Nivelele inferioare ale reelei realizeaz funcii privind tratarea informaiei primit de la stratul imediat superior. Funciile unui strat sunt realizate prin comunicare pe orizontal ntre sursa i destinaia informaiei, comunicare numit pear-to-pear. 41

Fig.3.3. Comunicarea pear-to-pear. 3.2. Nivelele inferioare ale reelei IP Nivele inferioare ale stivei de protocoale sunt nivelul fizic (nivel 1) i nivelul legtur de date date (nivel 2). Acestea pot fi realizate folosind urmtoarele tehnologii (fig.3.1): LAN Ethernet Linie telefonic asociat cu un modem, care execut protocolul PPP (Point-toPoint Protocol) Un modem DSL (Digital Subscriber Line) care folosete modul de transfer asincron ATM reea de acces radio IEEE 802.11. Nivelul 1 (Physical Layer) definete legtura fizic ntre calculatoare la nivel optic, electric, mecanic, procedural i funcional. Exemple de tipuri de specificaii pentru acest nivel sunt: EIA-232D (specific interfeele i semnalul ntre DTE i DCE), Ethernet, IEEE 802.3 (asemntor cu Ethernetul dar standardizat public) IEEE 802.5 (forma standardizat de IEEE pentru Token Ring). Nivelul 2 (Data Link Layer) sau nivelul legtur de date, controleaz transferul informaiei transmis de aplicaie prin nivelele 4 i 3, n mediul fizic prin care este trimis informaia (cablu, fibr optic sau unde radio). Acest strat controleaz fluxul de date n mediul de transport fizic i folosete tehnologiile care asigur diferite topologii logice ale reelelor (Ethernet, IEEE 802.3, IEEE 802.5, FDDI, Token Ring etc.). La acest nivel pot fi folosite protocoale de tip: HDLC, LAPB, LAPD, PPP, SLIP. Multe dintre acestea definesc modalitatea de ncapsulare a cadrelor de semnal generate de nivelul 2 n liniile seriale.

42

3.3. Nivelul reea Nivelul 3 (Network Layer) este nivelul de reea care are ca principal rol rutarea pachetelor ctre destinaie pe baza adresei IP. Se folosete n acest scop protocolul IP care va fi prezentat n continuare. Controlul rutrii impune folosirea de protocoale de rutare care permit stabilirea i actualizarea tabelelor de rutare pe baza crora se face ndrumarea pachetelor (ex. IGP, IS-IS, IGRP, EIGRP, RIP). Nivelul utilizeaz protocolul IP (Internet Protocol) pentru ndrumarea pachetelor prin reeaua IP, pe baza adresei IP a destinaiei. IP este un protocol care furnizeaz un serviciu fr conexiune (connectionless) de tip Best Effort. Pachetele IP pot fi pierdute, ntrziate sau recepionate ntr-o ordine diferit de cea n care au fost transmise. Fiecare pachet al unui flux este ndrumat pe o cale proprie, folosind antetul IP. Protocolul IP a fost dezvoltat n dou versiuni IPv4 i IPv6. Deosebirile ntre cele dou variante, vizibile n modul de organizare al antetului IP, sunt urmtoarele: - dimensiunea cmpului adresei de reea crete de la 4 octei la IPv4 la 16 octei la IPv6. Spaiul de adresare crete substanial (3,4 x 1038 noduri adresabile), ceea ce permite furnizarea unui numr suficient de adrese IP globale unice pentru fiecare dispozitiv de reea, care va acoperi cererile exponeniale prin dezvoltarea exploziv a reelei Internet; - antetul la IPv6 este simplificat i are dimensiune fix. Se permite folosirea de antete opionale atunci cnd este necesar; - n IPv6 se elimin verificarea antetului IP (IP header checksum)

Fig.3.4 . Structura antetelor IPv4 i IPv6 IP furnizeaz un serviciu pentru TCP de transmitere i recepie de segmente de lungimi variabile asociate informaiei aplicaiilor, folosind n acest scop datagrame Internet. Datagrama furnizeaz o cale de adresare a TCP surs i destinaie din reele diferite. Este cerut fragmentarea i reasamblarea segmentelor TCP necesare asigurrii transportului datagramelor prin reele multiple.

43

IP transport informaia referitoare la prioritate, securitate i comportament al segmentelor TCP. Cea mai simpl form de clasificare a pachetelor se obine prin folosirea cmpului ToS (Type of Service) din datagrama IPv4 sau TC (Traffic Class) din datagrama IPv6.

Fig.3.5. Definiia cmpului ToS din antetul IPv4. Cmpul Precedence indic prioritatea sau importana relativ cu care trebuie tratat un pachet particular. In tabelul 3.1. se indic valorile i numele asociate pentru IP Precedence

3.4. Protocoale utilizate la nivel transport Protocoalele de nivel 4 (Transport) sunt protocoale de transport, care au ca scop principal definirea modului n care trebuie s circule datele ntre echipamente. Funciile principale ale stratului transport sunt urmtoarele: definete caracteristicile transportului ntre noduri, realizeaz segmentarea n nodul surs i reasamblarea informaiei la destinaie, asigur transportul datelor la destinaie, stabilete, menine i termin circuite virtuale, detecteaz i remediaz erorile care au aprut n procesul de transport, controleaz fluxul de date. In continuare vor fi prezentate dou tipuri de protocoale de transport: TCP i UDP. 3.4.1. TCP TCP (Transmission Control Protocol) este un protocol de nivel 4 pentru controlul transmisiei pachetelor de date. Acest protocol host-to-host furnizeaz un serviciu de comunicaie proces-proces n reeaua Internet alctuit din multiple reele. TCP asigur interfaa ntre un proces al aplicaiei i protocolul IP (Internet Protocol).

44

Interfaa dintre un proces al aplicaiei i TCP controleaz deschiderea i nchiderea conexiunilor, necesare pentru transmiterea i recepia datelor aplicaiilor. Rolul principal al TCP este s asigure un circuit logic ntre perechile de procese ale aplicaiei. TCP trebuie s asigure transferul unui ir continuu de octei n fiecare direcie ntre utilizatori. In acest sens, TCP realizeaz la emisie, segmentarea informaiei transmis de aplicaie i adugarea unui antet TCP (TCP header) pentru formarea pachetului TCP. Segmentele de date sunt transmise n pachete TCP ctre nivelul IP pentru transmitere n reeaua Internet. Din pachetele recepionate prin nivelul de reea IP se vor extrage segmentele de date, care vor fi asamblate pentru formarea datelor destinate procesului aplicaiei. TCP asigur verificarea la recepie a corectitudinii segmentelor recepionate. Se pot detecta n acest sens, erori de transmisie, pierderi de segmente, duplicarea sau furnizarea segmentelor ntr-o ordine diferit de cea n care au fost transmise n reea. Pentru realizarea acestor verificri se folosete numrul secvenei SN i cererea de confirmare pozitiv (ACK) de la TCP receptor. Erorile pot fi corectate prin retransmitere. Pentru ordonarea segmentelor i eliminarea duplicrilor se folosete SN.

Fig.3.6. TCP Header Pentru diminuarea congestiei n reea, TCP realizeaz un control al fluxului prin faptul c poate decide cantitatea de date transmis de emitor. TCP poate controla printr-un mecanism de tip fereastr glisant numrul de octei dup care se ateapt o confirmare ACK. n cazul n care nivelul inferior indic congestie, TCP reduce dimensiunea ferestrei, astfel c dac nu se primete confirmarea ACK nu se emit noi date. In acest fel traficul transmis poate fi redus. Deoarece mai multe procese dintr-o Gazd (Host) pot folosi facilitile de comunicare simultan ale TCP, serviciul trebuie s furnizeze o multitudine de adrese sau porturi. TCP poate indica pentru fiecare comunicaie securitatea i prioritatea cerute de utilizatori.

45

3.4.2. UDP Protocolul UDP (User Datagram Protocol) specificat n RFC 768 este o variant simplificat de protocol de transport n comparaie cu TCP. UDP asigur interfaa ntre procesele aplicaiei i TCP i asigur controlul conexiunii logice ntre procesele aplicaiei. UDP este orientat pe tranzacie, dar nu garanteaz furnizarea datelor i nici nu asigur protecie la erori i duplicare. Singura verificare realizat de UDP este controlul recepiei corecte a antetului cu ajutorul cmpului de control (checksum) din antet. Utilizarea UDP este recomandat pentru transmitere de mesaje la alte programe sau pentru transmitere de voce i video prin Internet. Transmisiunile de timp real (voce, video) impun reelei o reducere la minim a ntrzierii n reea. Prin eliminarea verificrii corectiitudinii recepiei i a coreciei erorilor, UDP reduce ntrzierea pentru pachetele de voce i video la nivel de transport.

Fig.3.7. Structura pachetului UDP 3.4.3. Controlul congestiei Controlul congestiei previne excederea capacitii reelei de ctre surs prin ncercarea de adaptare a ratei transmisiei acesteia, scopul fiind de prentmpinare a congestiei n router-e, pe link-uri, sau la destinaie. Mecanismele, de baz, de control a congestiei suportate de TCP prezentate n cele ce urmeaz sunt: start-lent (slow-start), prevenirea congestiei (congestion avoidance), retransmisie rapid (fast retransmission), recuperare rapid (fast recovery). Start-lent (low-Start) Cnd o conexiune TCP este stabilit, sursa TCP nu transmite o fereastr integral de segmente receptorului. n acest fel, sursa mpiedic apariia congestiei, prin excederea capacitii reelei, prin transmiterea doar a ctorva pachete la nceput, pentru care se ateapt confirmrile ACK, urmate de creterea exponenial a ratei transmisiei. Se permite astfel sursei TCP s testeze reeaua n scopul determinrii limii de band n mod curent disponibile pentru conexiunea acceptat. Mecanismul este utilizat: la iniierea unei conexiuni, la restartarea unei conexiuni TCP dup o perioad lung de inoperabilitate, la restartarea unei conexiuni TCP dup expirarea contorului de retransmisie. Figura 3.8 ofer o imagine asupra modului n care mecanismul acioneaz. Astfel, sursa TCP iniiaz slow-start prin transmiterea unui segment i ateapt confirmarea prin ACK. Dac se primete ACK, sursa mrete dimensiunea ferestrei cwnd la valoarea 2, astfel nct vor fi expediate 2 segmente. Se ateapt confirmrile destinaiei i se mrete dimensiune la 4, 8, 16, etc. Se remarc o cretere exponenial a cwnd 46

pn cnd fie valoarea excede fereastra destinaiei fie pachetele sunt eliminate de ctre reea prin echipamentele aflate n congestie, neajungnd la destinaie. Urmtorul mecanism prevenirea congestiei, descrie modalitatea n care sursa TCP rspunde la acest ultim caz - de pierdere a pachetelor.

Fig.3.8. Mecanism slow-start Sursa TCP poate determina pierderea pachetului n 2 moduri: expirarea contorului de recepie pentru ACK respectiv duplicarea ACK. Absena unui segment n interiorul unei ferestre de transmisie produce la destinaie generarea a dou semnale ACK identice. TCP nu lucreaz cu NACK sau cu ACK-uri cu numere de pachete. Destinaia TCP acumuleaz segmentele ce au fost recepionate n secven, rspunznd, fie cu ACK pentru fiecare segment fie cu ACK pentru segmente multiple. De exemplu dup recepia unui segment de 1000 octei se rspunde cu ACK 1001 iar pentru urmtorul segment de 1000 octei se rspunde cu ACK 2001 sau, n a doua variant, se rspunde cu ACK 2001 dup 2 segmente consecutive recepionate corect. Se precizeaz prin confirmare ACK c recepia a fost corect i se ateapt octetul 1001 respectiv 2001. Dac segmentul este pierdut ntr-un router aflat n congestie, destinaia continu s memoreze pachetul care sosete dar, nerecepionnd segmentul ateptat, rspunde iar cu ACK 2001. Astfel ACK este dublat. Se poate decide retransmisia segmentului pierdut sau se mai poate atepta un ACK 2001 (al treilea) i apoi se retransmite, dup cum vom vedea la retranmiterea rapid. Pierderea ultimului segment produce expirarea contorului de retransmisie setat n momentul expedierii segmentului i nu duplicarea ACK, deoarece n acest caz nu mai exist un segment succesiv cruia s i se rspund cu ACK. n fapt contorul este pornit pentru fiecare transmisie de segment ateptndu-se identificarea ACK n timpul predefinit, timp a crui valoare poate fi diferit suportndu-se retransmisii adaptive, ncrcarea n reea modificndu-se n permanen. n cazul n care contorul a expirat se presupune c segmentul a fost corupt sau pierdut i se iniiaz retransmisia.

47

Prevenirea congestiei (congestion avoidance) Cnd sursa TCP desoper eliminarea unui pachet de ctre reea, se seteaz o variabil ssthresh (slow-start threshold) egal cu jumtate din valoarea curent a cwnd. Sursa reduce rata transmisiei prin revenirea la modul slow-start, dar n acest moment se crete exponenial rata transmisiei pn cnd noul cwnd devine egal cu valoarea ssthresh. Din acest punct, emitorul crete cwnd liniar (un segment pe RTT round trip times), permind creterea lent a ratei transmisiei n ncercarea de apropiere de valoarea anterioar a lui cwnd care a provocat pierderea pachetelor. Cnd valoarea cwnd este mai mic ca ssthresh, sursa TCP este n mod slow-start; cnd cwnd este mai mare dect ssthresh sursa TCP este n mod prevenire congestie (figura 3.9).

Fig.3.9. Mecansim de prevenire a congestiei Startul-lent cu prevenirea congestiei permite sursei TCP s-i reduc n permanen la jumtate valoarea cwnd pentru cazurile n care se constat pierderea pachetelor. Pentru o stare de congestie de durat, sursa va avea un volum de trafic injectat n reea i o rat de transfer diminuate exponenial ceea ce va conduce la un moment dat la oprirea transmisiei i n consecin eliberarea router-elor. Retransmisia rapid (fast retransmission) Dup cum s-a precizat, TCP presupune c un pachet a fost pierdut cnd se recepioneaz un ACK duplicat. Totui, segmentul putea s nu fie pierdut ci doar s nu fi ajuns la destinaie n ordinea de la emisie. O retransmisie a sa ar nsemna n acest caz o duplicare a segmentului n reea i o ncrcare ineficient a acesteia. Astfel, o variant mai bun const n a atepta 3 ACK-uri identice dup care se poate iniia retransmisia segmentului considerat a fi fost eliminat sau corupt. Retransmisia rapid mbuntete performanele TCP astfel: elimin retransmisia inoportun a pachetelor, permite utilizarea la maxim a canalului i minim a ncrcrii n reea, permite TCP s nu atepte ca un timer de retransmisie s expire nainte de a reexpedia un potenial segment pierdut.

48

Recuperarea rapid (fast recovery) Mecanismul recuperare rapid (figura 3.10) previne ca sesiunea TCP s devin complet liber dup retransmisia rapid a unui singur segment pierdut. Se mbuntete performana sesiunii TCP prin eliminarea nevoii de revenire la start-lent i apoi umplerea lent a sesiunii dup pierderea doar a unui pachet din fereastra de date. Recuperarea rapid are rezultate foarte bune pentru cazul n care se pierde doar un pachet dar nesemnificative atunci cnd multiple pachete sunt n aceeai situaie.

Fig.3.10. Mecanism recuperare rapid Controlul congestiei pentru TCP, dezvoltat puternic n ultimii ani, are la baz algoritmi diveri dintre care enumerm: TCP Tahoe implementat n 1988 i propus de Van Jacobson nclude start-rapid, prevenire congestie i retransmisie rapid, TCP Reno implementat n 1990 mbuntete TCP Tahoe cu recuperare rapid, TCP Vegas prezentat n 1994 are la baz TCP Reno dar mbuntete performanele controlului congestiei prin creterea respectiv descreterea dinamic a dimensiunii ferestrei de transmisie n conformitate cu analiza RTT (cea mai bun estimare a circuitului dusntors ctre destinaia n discuie) asupra pachetelor de date anterior expediate i n cazul start-lent, cwnd crete fa de TCP Tahoe i Reno respectiv este dublat pentru fiecare ACK pozitiv, TCP-SACK TCP cu confirmare selectiv propus n 1996 (RFC 2018), TCP New Reno propus n RFC 2582 n aprilie 1999, TCP D-SACK specificat n RFC 2883 n ianuarie 2000 ce permite identificarea de ctre emitor a sosirii la destinaie a unor segmente duplicate i ca atare se revine rapid la cwnd anterior, The Limited Transmit extension specificat n RFC 3042 n ianuarie 2001, etc.

49

DCCP (Datagram Congestion Control Protocol) Protocolul de control al congestiei datagramelor (DCCP) implementeaz controlul congestiei pentru conexiuni unicast, bidirecionale, nesigure pentru transportul datagramelor . DCCP (RFC 4340) este indicat pentru aplicaii precum transport de voce sau fluxuri media pentru care ntrzierea i livrarea la destinaie n ordine sunt extrem de restrictive. TCP nu este potrivit datorit ntrzierilor apreciabile ce pot apare n cazul controlului congestiei prin mecanismele obinuite. UDP evit ntrzierile lungi dar aplicaiile UDP au propriile mecanisme de evitare a congestiei implementate. DCCP ofer control al congestiei incorporat, suport pentru ECN (Explicite Congestion Notification), setare i eliberare a conexiunilor sigure i capaciti de negociere, evitndu-se ntrzierile arbitrare asociate TCP. Aplicaiile DCCP pot alege mecanismul de control al congestiei, cele 2 pri ale conexiunii putnd fi guvernate de mecanisme diferite. Mecanismele sunt identificate printr-un identificator de control al congestiei de 1 octet denumit CCID (Congestion Control IDentifier). Capetele conexiunii negociaz CCID-urile la iniierea conexiunii. Fiecare CCID descrie modul n care emitorul limiteaz rata de transfer a pachetelor, modul n care receptorul expediaz mesajele de reacie de confirmare, etc. Sunt definite 256 de moduri dar se utilizeaz n mod curent CCID 2 i 3, restul fiind rezervate. CCID 2 (RFC 4341) identific mecanismul TCP like Congestion Control, similar cu cel al TCP. Emitorul implementeaz o fereastr de congestie i expediaz pachetele pn ce fereastra se umple. Pachetele sunt confirmate de receptor. Pachetele pierdute i ECN (RFC 3168) indic apariia congestiei. Rspunsul n acest caz const n a njumtii dimensiunea ferestrei. Confirmrile conin numere n secven ale tuturor pachetelor din fereastr similar cu TCP SACK. CCID 3 (RFC 4342) identific mecanismul TCP Friendly Rate Control (TFRC) care realizeaz un control al congestiei cu un rspuns mult mai neted. Emitorul menine o rat a transmisiei care este modificat utiliznd estimarea receptorului asupra posibilitii de pierdere a pachetelor.

50

3.5.

Protocoale utilizate la nivel aplicatie

Nivelul 5 aplicaiei (Application Layer) are rolul de a face legtura dintre aplicaie i serviciile oferite de reea pentru acea aplicaie. Pentru aplicaiile de timp real se realizeaz transformarea informaiilor n formate pe care mainile care comunic le pot nelege. Semnalele vocale analogice sunt transformate n semnale digitale folosind diferite scheme de codare a voce. Semnalul video este de asemenea transformat n semnal digital prin codare i compresie a semnalului analogic video. Pentru realizarea pachetizrii i controlul pachetelor de voce i video transmise prin reeaua IP sunt folosite protocoalele RTP (Real Time Protocol) i RTCP (Real Time Control Protocol). De asemenea, este necesar ca la nivel de aplicaie s se realizeze controlul semnalizrilor privind stabilirea, meninerea i eliberarea conexiunilor pentru comunicaiile telefonice, control realizat n reelele IP prin folosirea protocoalelor SIP (Session Initiation Protocol) sau H.225.0 (Call signalling protocols and media stream packetization for packet based multimedia communication systems) i H.245 (Control protocol for multimedia communication). 3.5.1. Protocoale de tratare a serviciilor de timp real: RTP, RTCP. RTP (Real Time Protocol) (RFC 1889) RTP este un protocol care furnizeaz servicii pentru date cu caracteristici de timp real, exemplu serviciile interactive de voce i video (IETF RFC 1889 i RFC 3550). RTP controleaz formarea pachetelor RTP prin includerea n cmpul payload a octeilor de voce furnizai de codecul audio sau de date corespunztoare semnalului video comprimat.

V = Version CC = CSRC count

P = Pading M = Marker

X = Extension PT = Payload Type

Fig.3.11. Antetul pachetului RTP Pachetul RTP conine payload (informaie util) i header (antet). Antetul (fig.3.11.) ofer capabiliti pentru detecia unor imperfeciuni introduse de reea n transportul pachetelor RTP: pierderea de pachete, variaia ntrzierii pachetelor unui flux, schimbarea ordinii secvenelor de pachete la destinaie, rutarea asimetric.

51

Pierderea de pachete poate fi detectat prin analiza numrului de secven (SN). Corecia poate fi rrealizat de codec i anume: codecul video poate cere repetarea pachetului video pierdut, n timp ce codecul audio poate genera un zgomot de fond pentru informaia de voce din pachetul pierdut. Intrzierea i jitterul pot fi determinate prin utilizarea cmpului TimeStamp. RTP este un protocol folosit pentru comunicaii media care permit identificarea tipului de informaie transmis prin pachetul RTP, folosind n acest scop cmpul care definete tipul informaiei aplicaiei (Payload Type). Tabelul 3.3. Exemple de Payload Type n pachetele RTP
Payload Type 0 2 3 8 9 14 15 26 31 32 33 Codec PCMU G721 GSM PCMA G722 MPA G728 JPEG H261 MPV MP2T Frecven de eantionare [Hz] 8000 8000 8000 8000 8000 90000 8000 90000 90000 90000 90000 Descriere ITU-T G.711 PCM -Low Audio 64 Kbps ITU-T G.721 ADPCM Audio 32 Kbps European GSM Audio 13 Kbps ITU-T G.711 PCM A-Low Audio 64 Kbps ITU-T G.722 Audio MPEG-1 sau MPEG-2 Audio Only ITU-T G.728 Audio 16 Kbps JPEG video ITU H.261 Video MPEG-1 si MPEG-2 Video MPEG-2 Transport Video

ntr-o sesiune RTP se definete un set de participani care comunic cu RTP. Pentru fiecare participant, sesiunea RTP definete o pereche de adrese de transport destinatare (o pereche de porturi pentru RTP i RTCP). SSRC este sursa fluxului (stream-ului) de pachete RTP. Toate pachetele unei surse de sincronizare au aceleai Timing i SN (Sequence Number), folosite la recepie pentru sincronizare. CSRC indic sursele care contribuie la generarea unui pachet, produse de un mixer RTP. Un exemplu de astfel de aplicaie este o conferin audio unde un mixer indic toi vorbitorii a cror voce a fost combinat pentru producerea pachetului transmis n reea. Pachetele RTP folosesc la nivel de transport protocolul UDP.

52

RTCP (Real Time Control Protocol) (RFC 1889) RTP are asociat protocolul RTCP, care transport periodic pachete de control despre sesiunea RTP curent. Pachetele RTCP conin informaii despre canalele RTP (cantitatea de date transmis i recepionat) RTCP permite participanilor ntr-o sesiune RTP s transmit unul altuia rapoarte i statistici referitoare la calitatea distribuiei datelor prin controlul fluxurilor i a congestiei. Utilizarea rapoartelor SR (Sender Report) i RR (Receiver Report) permite luarea unor msuri n cazul deteriorrii calitii comunicaiei. Aceste rapoarte conin informaii despre numrul de pachete transmise i recepionate, numrul de pachete pierdute, jitter. De asemenea se pot folosi mesaje pentru descrierea sursei (SDES Source Description), care conin informaii despre participantul la sesiune (adres e-mail, numr de telefon). Un pachet RTCP conine un antet similar pachetului RTP i un cmp payload al crui coninut depinde de tipul pachetului RTCP. O aplicaie care recepioneaz pachete RTCP transmise de participani ntr-o sesiune RTP, are la dispoziie rapoarte de recepie pe baza crora poate estima calitatea curent a serviciului pe baza monitorizrii, a diagnozei deranjamentelor i a statisticilor pe termen lung. Tipurile de pachete folosite de RTCP sunt: SR, RR, SDES, BYE (indic sfritul participrii la sesiune). 3.5.2. Scheme de codare a vocii Schema clasic de codare a vocii este conform cu Rec. G.711 ITU-T. n urma conversiei analog-digital a semnalului vocal se realizeaz transmisia periodic n reea de octei (asociai valorii eantioanelor de semnal analogic vocal) cu o perioad de 0,125 sec (frecven 8 KHz). Rezult n acest fel o rat binar de transmisie de 64 kbps (8 bii x 8 kHz). In vederea utilizrii eficiente a reelei IP, au fost create diverse scheme de codare, ale cror caracteristici sunt prezentate n tabelul 3.4. Tabelul 3.4. Relaia ntre codare i calitatea transmisiei vocii
Standard G.711 G.726 G.727 ITU-T G.728 G.729 G.723.1 ETSI GSM-FR GSM-FHR GSM-EFR Tipul codrii Rata binar vocii (kbps) a codecului PCM 64 16 ADPCM 24 32 40 LD-CELP 12,8 16 CS-ACELP 8 ACELP 5,3 MP-MLQ 6,3 RPE-LPT 13 VSELP 5,6 ACELP 12,2 Durata transm. cadrului vocal [Frame Size] (ms) 0,125 Calitatea R (Rating) 94,3 44,3 69,3 87,3 92,3 74,3 87,3 84,3 75,3 79,3 74,3 71,3 89,3

0,125 0,625 10 30 20 20 20

53

PCM ADPCM LD-CELP CS-ACELP ACELP MP-MLQ RPE-LTP VSELP

= Pulse Code Modulation = Adaptive Differential Pulse Code Modulation = Low Delay- Code Excited Liniar Predictive = Conjugate Structure-Algebric Code Excited Liniar Predictive = Algebric Code Excited Liniar Predictive = Multi Pulse - Maximum Likelihood Quantization = Regular Pilse Excited-Long Term Prediction = Vector Sum Excited Linear Prediction

Imperfeciunile introduse de echipamente influeneaz calitatea comunicaiei evaluat prin Rating. Efectul acestor imperfeciuni este definit prin parametrul Ie (cap.2.5.2.1). Codecurile cu rata binar redus afecteaz calitatea convorbirii evaluat prin Rating, prin parametrul le, aa cum rezult din tabelul.3.5. In cazul utilizrii VAD (Voice Activity Detection) n vederea suprimrii pauzelor de vorbire se obine o reducere a ncrcrii cu trafic a reelei de 60% (jumtate de timp utilizatorul ascult semnalul vocal al corespondentului, la care se adaug pauzele dintre cuvinte). In cazul eliminrii pauzelor de vorbire, la recepie trebuie generat un zgomot de comfort pentru ca utilizatorii s nu interpreteze pauzele de vorbire ca ntrerupere a circuitului de comunicaie. Imperfeciunile de reea, care definesc parametrul Ie, pot determina apariia pierderilor de pachete, care afecteaz Ratingul. Efectul codrii/decodrii asupra ntrzierii transmiterii semnalului vocal este prezentat n tabelul 3.6 (ITU-T Rec. G.114). Tabelul 3.5. Ratingul n funcie de Ie i ntzierea total (end-to-end delay) (G.108)
Ie= 0 G.711 5 GSMEFR 7 G.726 @32 G.728 @16 ms ~0 50 100 150 200 250 300 350 400 450 94 93 92 90 87 80 74 68 63 59 87 85 82 75 69 63 58 54 87 86 85 83 80 73 67 61 56 52 83 82 80 77 70 64 58 53 49 77 75 72 65 59 53 48 44 74 73 71 68 61 55 49 44 40 73 71 68 61 55 49 44 40 72 70 67 60 54 48 43 39 67 66 64 61 54 48 42 37 33 10 G.729 15 G.723.1 @6.3 19 G.729A +VAD w/2% loss 19 G.723.1 @5.3 G.723.1@ 6.3+VAD w/1% loss 20 GSM-FR 26 G.729A +VAD w/4% loss

IS-54

54

Tabelul 3.6. Valorile ntrzierii (delay) introduse de codecurile de semnal vocal

Rata binar (kbit/s) 64 40 32 24 16 16 12.8 8 13 5.6 12.2 5.3 6.3 Dimensiune cadru (ms) 0.125 0.125 0.125 0.125 0.125 0.625 0.625 10 20 20 20 30 30 Lookahead (ms) 0 0 0 0 0 0 0 5 0 0 0 7.5 7.5 Inrziere (msec) (codare+decodare) 0.25 0.25 0.25 0.25 0.25 1.25 1.25 25 40 40 40 67.5 67.5 G.711, G.712 G.726, G.727 G.721, G.726, G.727 G.726, G.727 G.726, G.727 G.728 G.728 G.729 GSM 06.10, Full-rate GSM 06.20, Half-rate GSM 06.60, Enhanced FR G.723.1 G.723.1 Standard de referin

Tip coder PCM ADPCM ADPCM ADPCM ADPCM LD-CELP LD-CELP CS-ACELP RPE-LTP VSELP ACELP ACELP MP-MLQ

3.5.3. Pachetizarea semnalului vocal Pentru transmisia vocii prin Internet (VoIP) este necesar transmisia octeilor de voce prin pachete IP. In fig.3.12 se prezint structura unui pachet IP de voce pentru cazurile n care la nivel 2 se folosesc protocoalele Ethernet i PPP (Point to Point Protocol).

Fig.3.12. Structura unui pachet de voce care folosete IPv4. Pentru utilizarea eficient a reelei IP este necesar s grupm ntr-un pachet de voce mai muli octei de voce. Se definete n acest sens o ntrziere de pachetizare/depachetizare evaluat n msec care reprezint intervalul de timp n care se colecteaz octeii transmii printr-un pachet IP de voce. In fig. 3.13. se prezint traficul generat de aplicaia de voce n linkurile Ethernet i PPP, considernd schema de codare G.711 i intervalul de pachetizare egal cu 4, 10, 20 i 30 msec. Gruparea octeilor de voce ntr-un cadru IP de voce determin o ntrziere egal cu 2 x intervalul de pachetizare, precum i o variaie a transmiterii octeilor de voce, generai periodic i transmii ntr-un pachet. Se constat c prin mrirea intervalului de pachetizare se obine o mbuntire a utilizrii reelei, dar va crete ntrzierea (delay-ul) introdus de terminal, deoarece ntrzierea introdus de codarea i decodarea vocii este egal cu 2 x intervalul de pachetizare .

55

a. Link Ethernet

b. Link PPP

Fig.3.13. Traficul generat de aplicaia telefonic n reeaua IP n fig. 3.14. este prezentat efectul schemelor de codare G.711, G.726, G.728, G.729 i G.723.1 asupra gradului de ncrcare cu trafic a link-urilor reelei IP de tip Ethernet i PPP, considerd intervalul de pachetizare de 30msec,. Se constat o reducere substanial a traficului n cazul utilizrii schemelor de codare cu rat binar redus G.729 i G.723.1.

Fig.3.14. Traficul generat de pachetele de voce pentru diferite scheme de codare ntrzierea introdus de codarea i decodarea semnalului vocal este mare (65 msec pentru G.729, 67,5 msec pentru G.723.1 i 60 msec pentru restul schemelor de codare), ceea ce impune condiii mai restrictive pentru ntrzierea introdus de reeaua IP. Intrzierea total admis de la sursa de semnal la receptorul telefonic trebuie s fie cel mult 150 msec pentru a avea o calitate bun a comunicaiei.

56

3.5.4. Multimedia Aplicaiile web au permis dezvoltarea aplicaiilor multimedia, obinute prin generarea, transmiterea i recepia de fluxuri media care conin dou sau mai multe media (date, audio, video). Multimedia, n mod special aplicaiile audio (muzic) i video (filme) necesit o lime de band mare, astfel c a fost necesar dezvoltarea de tehnici de codare i compresie a semnalelor audio i video. 3.5.4.1 Codarea i compresia semnalului audio

Transmisia digital a semnalelor audio este posibil prin conversia analogdigital a semnalelor audio la transmisie i prin conversia digital-analogic la recepie. Conversia analog-digital folosete un semnal de eantionare cu frecvena egal cu cel puin 2 x frecvena maxim a semnalului audio. n acest fel este posibil reconstituirea semnalului analogic din eantioanale de semnal. Pentru semnalul telefonic unde banda de frecven este 3003400 Hz, frecvena de eantionare este aleas prin standarde la valoarea de 8 KHz. Dup eantionare se realizeaz cuantizarea prin asocierea unei valori fiecrui eantion de semnal vocal, cuprins ntre -127 . . .+ 127. Aceste valori pot fi reprezentate n binar, astfel c valoarea unui eanion este codificat prin 8 bii. Banda solicitat pentru transmiterea semnalului vocal va fi 8 bii/eantion x 8 KHz frecvena de transmitere a eantioanelor adic 64 kb/s. Pentru semnalele audio folosite n transmisia muzicii, banda de frecven folosit este 2020000 Hz. Frecvena de eantionare a semnaleor audio este de 44.100 eantioane/sec, ceea ce permite captarea frecvenelor pn la 22.050 Hz. Eantioanele sunt reprezentate prin cuvinte de 16 bii. Lrgimea de band necesar pentru transmiterea muzicii este n consecin de 705,6 Kbii/sec (16 bii/eantion x 44100 eantioane/sec) pentru transmisiile mono i 1,411 Mbii/sec pentru transmisiile stereo. Rezult c pentru transmiterea semnalelor stereo n format necomprimat banda necesar pentru transmiterea n reea este mare, astfel c se impune utilizarea compresiei. MP3 (MPEG-1 Audio Layer 3), specific un tip de format de codare audio. Compresia folosit de MP3 ndeprteaz pri ale semnalului care sunt sub pragul de audibilitate uman. Se folosesc de asemenea modele psihoacustice pentru a permite eliminarea componentelor mai puin audibile i se nregistraz informaia rmas ntr-o manier mai eficient. Datorit dimensiunilor mai reduse pentru fiierele audio, MP3 este n prezent cel mai popular n privina formatui audio. Cel mai simplu fiier MP3 folosete o singur rat de bit pentru ntregul fiier (Constante Bit Rate) ceea ce asigur o codare simpl i rapid. Este posibil crearea de fiiere n care rata de bit s se modifice. Aceste fiiere sunt numite VBR (Variable Bit Rate). Se permite adaptarea transmisiei la caracteristicile semnalului audio care poate conine pauze sau muzic cu mai puine instrumente, care poate fi mai uor de comprimat n raport cu alte pri unde compresia este mai dificil. Ratele binare standardizate n MP3 sunt: 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 and 320 kbit/s, iar frecvenele de eantionare folosite sunt 32, 44.1 i 48 kHz. Cea mai folosit frecven de eantionare este de 44.1 kHz cerut de CD audio. Prin contrast, n cazul folosirii nregistrrii pe compact disc a semnalelor audio necomprimate, rata binar este de 1378.125 kbit/s (16 bii/eantion 44100 eantioane/s 2 canale / 1024).

57

3.5.4.2

Codarea i compresia semnalului video

Pentru codarea semnalului video sunt recomandate urmtoarele standarde:

Standard H.261 JPEG MPEG-1 MPEG-2 / H.262 MPEG-4 / H.26L JPEG 2000 H.263 H.264 / MPEG-4v10 MPEG-7 MPEG-21 Organism de standardizare ITU-T ISO/IEC 10918 ISO/IEC 11172 ISO/IEC 13818 ISO/IEC 14496 ISO/IEC N2000 ITU-T ITU-T ISO/IEC 15938 ISO/IEC 21000 Perioada in lucru 1984-1990 1984-1989 1988-1991 1990-1994 1993-2000 1997-2000 1993-2001 1997-2003 1996-2005 1999-2007 Utilitate Video prin ISDN, p x 64 kb/s Imagini fixe Audio/video pe CD-ROM, 1.5 2 Mb/s HDTV / DVB, 4 9 Mb/s Comunicaii mobile Imagini fixe Video prin PSTN, < 64 kb/s Comunicaii mobile Specificare descriptori standard

Tabelul 3.6. Standarde pentru codarea video

Figura 3.15. Evoluia standardelor pentru codarea video Att ISO (International Standardisation Organisation) ct i ITU (International Telecommunication Union) au fost intersate n dezvoltarea de recomandri pentru codarea imaginilor i semnalelor video ncepnd cu 1985. Primul standard a fost JPEG anunat de ISO n 1989 i ulterior de ITU-T. n 1991 ISO ofer prima versiune a MPEG-1 pentru nregistrarea semnalului audio pe CD-ROM la 1.5-2 Mbps. n 1990, CCITT, ulterior ITU-T anun H.261 primul standard pentru codare video pentru comunicaii cu rat de bit sczut prin ISDN la p x 64 kbps. H.261 dezvoltat de ITU-T cunoscut i ca MPEG-2 a fost elaborat n 1994 ca standard pentru codare video n HDTV la 49 Mbps. n 1996 a aprut prima versiune a H.263 pentru comunicaii cu rat de bit sczut prin reeaua PSTN la rate de bit sub 64 kbps. Ulterior versiunea iniial a fost mbuntit n H.263+ i H.263++ n 1998 respectiv 1999. n 1998 un grup de lucru al ISO MPEG, AVT (Audio Video Transport) a dezvoltat MPEG-4 pentru comunicaii AV n sisteme mobile (GPRS). Acesta a fost primul algoritm de codare care utilizeaz strategii bazate pe obiecte n structura sa de nivele prin 58

comparaie cu variantele anterioare ce utilizau structura de cadre bazat pe blocuri. n martie 2000, ISO public JPEG2000. ncepnd cu MPEG-7, MPEG a lsat deoparte algoritmii de compresie tradiionali pentru a adresa descriptorii media. Prima versiune a aprut n 2001 la 5 ani dup nceputul cercetrilor, iar pn n 2005 s-a tot dezvoltat. MPEG-21 ncearc s ofere o tehnologie de integrare pentru o varietate de obiecte digitale denumite Digital Items. Pn n 2007 a fost dezvoltat un numr impresionant de recomandri, parte dintre acestea suferind transformri ulterioare. Formate video Cea mai simpl reprezentare a semnalului video digital este o secven de cadre, fiecare constnd dintr-o gril dreptunghiular de elemente de imagine, numite pixeli. O camer video scaneaz o imagine prin explorarea linie cu linie, fiecare linie coninnd o succesiune de pixeli. In transmisiile alb-negru, fiecare pixel este reprezentat prin 8 bii pentru a reprezenta 256 de nivele de gri. n transmisiile color, la scanarea liniilor se folosesc trei raze, cte una pentru fiecare din cele trei culori primare (RGB = Red, Green, Blue). Reprezentarea unui pixel se va face cu 24 bii (trei culori primare x 8 bii/pixel). Transmisia semnalului video se face pe un singur canal, astfel c se impune combinarea semnalului ntr-un singur semnal (composite). O scen video se compune din multiple obiecte fiecare cu propriile caracteristici de form, adncime, textur i iluminare. Culoarea i strlucirea unei scene video se modific imaginea avnd tonuri continue. Caracteristicile unei imagini relevante pentru procesare i compresie video sunt spaiale (variaia texturii, numrul i forma obiectelor, culoare, etc) i temporale (micarea obiectelor, schimbri n iluminare, micarea camerei, etc).

Figura 3.16. Eantionare spaial i temporal Imaginea video digital este reprezentarea eantioanelor video n form digital. Fiecare eantion spaio-temporal (pixel) este reprezentat ca un numr sau set de numere care descriu strlucirea (luminana) i culoarea. Imaginea video n micare este capturat printr-o serie de snapshot-uri asupra semnalului la intervale regulate de timp. O rat de cadru de 10 cadre/s este adesea utilizat pentru comunicaii cu rat de bit sczut, dar micarea este n acest caz neclar i nenatural. ntre 10 i 20 de cadre/s este mult mai bine dar n prile n care micarea este rapid reproducerea este deficitar. Eantionnd ntre 20 i 30 de cadre/s cu sau fr ntreesere trecem i peste acest impediment, dar cretem rata de bit necesar pentru transmiterea unui numr foarte mare de octei.

59

Un semnal video poate fi eantionat ca o serie complet de cadre (eantionare progresiv) sau ca o secven de cmpuri ntreesute (eantionare ntreesut). n al doilea caz, doar jumtate din datele unui cadru (doar un cmp) sunt eantionate n fiecare inteval temporal. Un cmp cuprinde fie liniile impare fie cele pare ale unui cadru, iar o secven video ntreesut cuprinde o serie de cmpuri, fiecare reprezenatnd jumtate din informaia unui cadru complet video. Avantajul n acest caz const n posibilitatea de a expedia de dou ori mai multe cmpuri pe secund dect numrul de cadre din eantionarea progresiv la aceeai rat de bit, oferind aparena de micare continu. O imagine monocrom cere nregistrarea doar a unui numr care s indice strlucirea, n timp ce o imagine color necesit o valoare care include 3 numere referitoare la luminan i culoare. n spaiul culorilor RGB (Red, Green, Blue) un eantion este reprezentat prin 3 numere care indic proporia relativ de rou, verde i albastru existent n valoarea eantionat. Capturarea unei imagini RGB implic 3 filtre pentru cele 3 culori. n spaiul RGB, cele 3 culori sunt la fel de importante astfel nct toate trebuie memorate la aceeai rezoluie dar este posibil s se reprezinte o imagine mai eficient separnd strlucirea de componentele de culoare i reprezentnd luminana cu rezoluie mai mare, deoarece sistemul vizual uman este mai puin sensibil la variaia culorii dect la variaia strlucirii. Spaiul culorilor YCbCr (sau variaii precum YUV n cazul sistemului NTSC) reprezint o variant mai eficient de reprezentare. Luminozitatea Y poate fi calculat prin: Y = krR + kgG + kbB Informaia de culoare poate fi reprezentat ca diferen de culori (crominan), unde fiecare component de crominan este diferena dintre R,G sau B i Y. Cb = B Y, Cr = R Y, Cg = G Y Componente de crominan au valori semnificative doar acolo unde diferenele dintre R,G sau B i Y sunt mari. Deoarece Cb +Cr+Cg este constant este suficient s se memoreze doar 2 din cele 3 componente de crominan, a treia fiind calculat din celelalte. O imagine RGB este convertit dup captur n imagine YCbCr n scopul reducerii spaiului de memorie necesar. ITU-T recomand n BT.601, kb = 0.114 i kr = 0.299 astfel nct vom avea: Y = 0.299R + 0.587G + 0.114B Cb = 0.564 (B Y) Cr = 0.713 (R Y) R = Y + 1.402Cr G = Y 0.344Cb 0.714Cr B = Y + 1.722Cb

Exist 3 forme de eantionare pentru Y, Cb i Cr suportate de, spre exemplu, MPEG-4 i H.264. Prima form este 4 :4 :4 n care cele 2 componente de crominan au aceai rezoluie pe vertical i pe orizonatal ca i Y. Numerele indic rata de eantionare relativ a fiecrei componente, sau altfel spus la fiecare 4 eantioane de luminan, 3 sunt pentru Cb i Cr. Se pstreaz astfel ntreaga fidelitate asupra celor dou componenete de crominan.

60

Al doilea format este 4 :2 :2 (adesea numit YUY2) pentru care componentele de crominan au aceai rezoluie vertical ca i luminozitatea dar au doar jumtate din rezoluia orizontal, fiind utilizat pentru reproducera de nalt calitate. n fine, ultimul format este 4 :2 :0 (YV12) unde Cb i Cr au fiecare jumtate din rezoluia pe vertical i pe orizontal a luminanei. Este un format popular deoarece majoritatea aplicaiilor de vidoconferin, televiziune digital sau de nregistrare DVD l utilizeaz. Formatul 4 :2 :0 necesit jumtate din capacitatea necesar lui 4 :4 :4. De exemplu pentru o rezoluie de 720 x 576 pixeli, n care Y are 720 x 576 eantioane codate pe 8b, formatul 4 :4 :4 necesit 720 x 576 x 8 x 3 = 9953280 bii pentru cele 3 componente n timp ce 4 :2 :0 necesit (720 x 576 x 8) + (360 x 288 x 8 x 2) = 4976640 bii. Utiliznd formatul 4 :4 :4, un total de 12 eantioane este cerut pentru fiecare component din cele trei ceea ce conduce la un total de 96 bii, respectiv de o medie de 96/4 = 24 bii/pixel. n cazul 4 :2 :0 doar 6 eantioane sunt necesare, 4 pentru Y i cte unul pentru Cb i Cr ceea ce conduce la un total de 48 bii respectiv la o medie de 12 bii/pixel. n secvena video ntreesut 4 :2 :0 cele 3 componente corespunztoare unui cadru complet video sunt alocate n 2 cmpuri. Standardele de compresie video pot compresa o larg varietate de formate video. n practic este indicat capturarea cadrului video, conversia acestuia la unul din formatele indicate i ulterior compresia i transmisia sa. La baza acestor formate st CIF (Common Intermediate Format) cu rezoluie de 352 x 288 pentru luminan respectiv 1216512 bii/cadru, care a fost dezvoltat ulterior n variantele SQCIF (128 x 96), QCIF (176 x 144), 4CIF (704 x 576), 16CIF (1408 x 1152). Alegerea rezoluiei cadrului depinde de aplicaie i de capacitatea de memorare sau de transmisie disponibil. Spre exemplu 4CIF este mai indicat pentru DVD-video, CIF i QCIF pentru videoconferin, QCIF i SQCIF pentru aplicaii multimedia mobile. O gam larg de formate este indicat n recomandarea ITU-T BT.601. Componenta de luminan este eantionat la 13.5 MHz iar cea de crominan la 6.75 MHz pentru a produce semnalul Y :Cb :Cr n format 4 :2 :2. Parametrii semnalului digital eantionat depind de rata de cadru (30Hz la NTSC i 25Hz la PAL/SECAM). Rata ridicat de cadru de 30Hz a NTSC este compensat printr-o rezoluie spaial sczut astfel nct rata total de bit este aceeai n cele dou cazuri i anume de 216 Mb/s. Fiecare eantion are o posibil valoare ntre 0 i 255, nivelele 0 i 255 fiind rezervate pentru sincronizare, semnalul de luminan activ fiind restricionat n gama 16 (negru) 235 (alb). Concepte de codare video Am vzut c pentru a transmite 1s de video de calitate sunt necesari 216 Mbii, astfel nct compresia este absolut necesar. Compresia implic prezena a 2 circuite complementare un codor i un decodor. Perechea codor / decodor poart denumirea de CODEC. Compresia este realizat prin eliminarea redundanei (componentele care nu sunt absolut necesare pentru reproducerea fluxului de date). Multe tipuri de date conin redundan statistic i pot fi efectiv compresate utiliznd compresia fr pierderi (lossless), astfel nct reconstrucia la decodor este o copie perfect a sursei de la codor. Din nefericire rata de compresie cea mai bun obinut n astfel de cazuri, spre exemplu utiliznd JPEG-LS, este de 3 :1 sau 4 :1. Pentru a realiza o compresie nalt este necesar compresia cu pierderi (lossy). Astfel de sisteme au la baz principiul eliminrii redundanei subiective, adic a elementelor care nu afecteaz semnificativ

61

percepia vizual sau calitatea semnalului video. Dar majoritatea metodelor de codoare exploateaz ambele redundane spaial i temporal. n domeniul temporal exist o mare similaritate ntre cadrele video care sunt capturate n jurul acelai moment de timp. Cadre adiacente temporale au o nalt corelaie, n special dac rata de eantionare temporal este ridicat. n domeniul spaial exist o mare corelaie ntre pixelii apropiai. n imaginea 3.17 este prezentat schema unui codor video. Acesta are 3 uniti funcionale principale : modelul temporal reduce redundana temporal, n mod uzual construind o predicie a cadrului curent; ieirea modelului temporal este un cadru rezidual (diferena dintre cadrul curent i cel prezis) i un set de parametrii de model, n mod tipic un set de vectori de micare care descriu modalitatea n care micarea a fost compensat, modelul spaial - se utilizeaz o transformat asupra eantioanelor reziduale urmat de cuantizarea rezultatelor; ieirea este constituit dintr-un set de coeficieni de transformare cuantizai, iar n final de un modul de codare entropic care reduce redundana statistic din cadrul fluxului de date; ieirea o reprezint o secven compensat format din parametrii vectorului de micare, coeficenii reziduali codai i informaia antetului.

Figura 3.17. Schem bloc codor n cadrul modelului temporal, diferena dintre cadrul curent i cadrul prezis conduce la un cadru rezidual care poate avea nc zone semnificative de energie datorate obiectelor n micare, micrii camerei video, etc. Deoarece aceste zone necesit o compresie performant este de dorit o predicie mai bun care este regsit n literatur sub forma tehnicilor de compensare a micrii. Este posibil estimarea micrii pixeli-lor din cadre adiacente, ceea ce conduce la formarea unui cmp al traiectoriilor acestora cunoscut sub denumirea de flux optic (optic flow). O metod practic de compensare a micrii const n compensarea a 4 blocuri ale aceluiai cadru. Macroblocurile (zone de 16 x 16 pixeli ale aceluiai cadru) reprezint unitatea de baz pentru predicia asupra compensrii micrii ntr-un numr semnificativ de standarde. Predicia spaial este adesea descris ca DPCM (Differenial Pulse Code Modulation). Asupra imaginilor reziduale rezultate se aplic o transformare din domeniul timp n domeniul frecven. Amplitudinile spectrale astfel rezultate sunt ulterior prelucrate. Multe astfel de transformate au fost propuse dealungul timpului n special bazate pe blocuri precum KLT (Karhunen-Love Transform), SVD (Singular Value Decomposition) sau DCT (Discrete Cosine Transform). Fiecare dintre acestea opereaz asupra blocurilor de dimeniune N x N ale eantioanelor imaginilor sau eantioanelor reziduale. Este necesar o dimensiune a memoriei sczut, dar sufer de artefacte la marginile blocurilor (blockiness), sau bazate pe imagini precum DWT (Discrete Wavelet Transform). 62

Cuantizarea este procesul prin care utiliznd o hart de valori de cuantizare, valorile Y sunt reduse astfel nct acestea s se ncadreze ntr-un interval de cuantizare bine stabilit i cu valori rezonabil de mici. ntlnim o cuantizare scalar i o cuantizare vectorial. Coeficienii rezultai n urma cuantizrii sunt reordonai ntr-o variant ct mai compact pentru a fi ulterior codai. Se obine un vector cu o mulime de valori de zero poziionate n special ntr-o parte a acestuia (figura 3.18).

Figura 3.18. Scanare n zig-zag pe cadru (stnga), pe cmp (dreapta) Semnalul astfel rezultat este aplicat codorului entropic care are rolul de a convertii seria de simboluri ce reprezint elementele secvenei video ntr-un flux de bii compresat. Simbolurile de intrare pot include coeficienii transformatei cuantizai (runlevel sau zerotree), vectorii de micare, marker-ii, antetele (macroblocurilor, imaginilor, secvenelor, etc) i informaia suplimentar. Se realizeaz o precodare predictiv, urmat de o codare entropic de tip Huffman sau de una aritmetic. n figura 3.19 se evideniaz un model generic de codor hibrid DPCM/DCT.

Figura 3.19. Codor video DPCM/DCT

63

Standardul JPEG JPEG (Joint Photographic Experts Group) este capabil s codeze o imagine color cu un raport de copresie mediu de 15 :1. Codorul este parametrizabil, astfel nct se dovedete destul de flexibil pentru diferite rapoarte compresie/calitate necesare unei multitudini de aplicaii. JPEG poate fi utilizat deasemenea n codarea video, la baz fiind ideea c semnalul video reprezint o succesiune de imagini fixe. n acest caz procesul se numete micare JPEG, fiind destul de bine adaptat reelelor cu comutaie de pachete cu rat de bit nespecificat UBR (Unspecified Bandwidth Rate). Un astfel de exemplu este, bineneles Internetul, unde congestia poate apare o perioad ndelungat de timp, datorit ncrcrii nepredictibile. Pentru video JPEG fiecare cadru este codat independent. JPEG2000 a fost dezvoltat ca rspuns la creterea accentuat a cererilor pentru multimedia, Internet precum i a unei largi varieti de aplicaii pentru imagini digitale. Cele dou standarde sunt foarte diferite in ceea ce privete metodele de compresie. Standardul JPEG suport compresia imaginilor fixe utiliznd transformata 8 x 8 DCT urmat de cuantizare, reordonare, codare run-level i n final codare entropic. JPEG2000 elimin DCT dar utilizeaz transformata Wavelet discret (DWT).

Figura 3.20. Procesarea imaginii n cazul JPEG Standardul H.261 Definete metodele de codare i decodare pentru transmisii video prin ISDN la viteze de bit de p x 64 kb/s cu p ntre 1 i 30. Structura codorului este asemntoare cu cea a codorului generic beneficiind de o tehnic de codare intercadru bazat pe transformata DCT. Standardul H.263 inta principal a standardului o constituie codarea video pentru rat de bit sczut sau foarte sczut, pentru aplicaii n reele radio, PSTN i N-ISDN. Se utilizeaz SQCIF i QCIF. Principalele diferene fa de H.261 i MPEG-1 se refer la modalitatea de codare a coeficienilor transformatei i vectorilor de micare. Cu privire ca codarea coeficienilor, dac n variantele anterioare se utiliza scanarea n zig-zag aici se utilizeaz reprezentarea coeficienilor sub forma unui arbore tridimensional (last, run, level) iar cu privire la codarea vectorilor de micare H.263 se bazeaz pe un vector de micare pentru un macrobloc de 16 x 16 pixeli cu precizie de jumtate de pixel. H.263+ i H.263++ reprezint ncercri reuite de adaptare la rate de bit foarte sczute de 24 kb/s.

64

Standardul MPEG-1 Standardul MPEG-1 a fost dezvoltat de grupul MPEG (Moving Pictures Expert Group) i standardizat ncepnd cu ISO-IEC/JTC1SC29 (MPEG-1). Fluxul video este reprezentat ca o succesiune de imagini individuale legate ntre ele temporal. Codarea video include 2 tipuri de compresii: spaial elimin informaiile redundante n spaiu, este vorba de interiorul unei imagini; temporal elimin informaiile temporale redundante n timp, fiind vorba de o suit de imagini ale unei secvene video. Compresia temporal se poate face fie ntre imaginea prezent i cea anterioar, fie ntre imaginile prezent, anterioar i ulterioar.

Algoritmul de codare opereaz n 2 etape : codare la surs compresia spaial i temporal a eantioanelor semnalului video; codare entropic reduce rata de bit rezultat prin codarea la surs, utiliznd proprieti statistice. Astfel, se atribuie cuvintelor lungi, valorile celor mai puin prezente variabile, iar cuvintelor scurte, valorile celor mai frecvente variabile. Se optimizeaz astfel numrul biilor de cod.

Imaginea este tratat ca o matrice bidimensional de elemente de imagine pixeli. Pentru a fi comprimat, aceasta este secionat n benzi, macro-blocuri (16x16 pixeli) i blocuri (8x8 pixeli). Compresia spaial se realizeaz asupra blocurilor, convertite printr-o transformare de tip cosinus discret (DCT), ntr-o matrice 8x8 de coeficieni de frecvene spaiale orizontale i verticale. Blocul poate fi reconstruit aplicnd transformarea, de tip cosinus inversat, discret (IDCT) coeficienilor si. Coeficienii sunt, n continuare, cuantizai i codai, utiliznd codarea entropic. Diferena ntre valorile cuantizate i valorile reale poart denumirea de zgomot de cuantizare. Pentru anumite valori ale pasului de cuantizare sistemul vizual uman nefiind sensibil, se poate reduce astfel informaia generat. Compresia temporal are la baz compensarea micrii ntre dou sau mai multe imagini. Compensarea modeleaz o imagine ca o translaie temporal de imagini vecine. Modelarea se realizeaz prin calcularea vectorilor micrii aplicai asupra macro-blocurilor. Vectorii, pentru 2 dimensiuni, determin deplasarea macro-blocurilor fa de poziia iniial. Un macro-bloc deplasat fa de o imagine cunoscut devine o predicie a macro-blocului imaginii codate. Interesul acestei tehnici, este c, n general, pentru o scurt secven de imagini, majoritatea obiectelor rmn nemicate, altele deplasndu-se pe distane scurte, ceea ce reduce semnificativ cantitatea de informaie generat.

65

Se definesc 3 tipuri de imagini: intra-picture (I) imagini ce sufer doar o compresie spaial; predicted-picture (P) imagini ce sufer o compresie spaial i una temporal cu o imagine I sau cu o alt imagine P din trecut; bidirectionally-predicted pictures (B) imagini ce sufer o compresie spaial i una temporal cu o imagine (P) sau (I) din trecut i o imagine (P) sau (I) din viitor;

Exist cel puin 2 consecine ale algoritmului : debitul de informaie generat este variabil, consecin a codrii sursei (diferite imagini au redundane diferite) i codrii entropice, metoda direct de control al debitului const n modificarea pasului de cuantizare, sau pentru decodarea imaginilor B se cere decodarea imaginilor din viitor care au servit la codarea acestora. Sistemul de codare permite multiplexarea multiplelor fluxuri media i codarea fluxului rezultat precum i ncapsularea acestuia ntr-o structur de date. Codarea sistemului furnizeaz sintaxa necesar i suficient pentru sincronizare la decodare i prezentare pentru informaiile video i audio. Se asigur astfel c buffer-ele decodoarelor nu vor fi goale sau pline. Informaiile de sincronizare sunt codate utiliznd tampilele temporale. Se furnizeaz momentele de decodare, de prezentare i de livrare a informaiilor diferitelor buffer-e i valorile de frecven ale ceasului codorului. Standardul MPEG-2 Din punct de vedere al profilurilor i al nivelelor MPEG-2 ofer rezoluii care variaz de la SIF (352 x 288 x 25 sau 30) pn la HDTV cu 1920 x 1250 x 60. Multe dintre aceste imagini sunt intreesute n timp ce la MPEG-1 imaginile sunt scanate n mod progresiv (nentreesut). Codarea imaginilor intreesute este prima diferen major manifestat la nivelul schemelor de codare. Astfel, fiecare macrobloc n modul progresiv include 6 blocuri n format 4 :2 :0 i 12 n format 4 :4 :4. Dimensiunea unei uniti de blocuri utilizat pentru estimarea/compensarea micrii se poate modifica. n cazul imaginilor intreesute, ct timp numrul de linii per cmp este jumtate din numrul de linii per cadru, estimarea micrii impune utilizarea unor blocuri de tip 16 x 8 ceea ce conduce la jumtate din numrul de blocuri utilizat n cadrul scanrii progresive. O a doua diferen major const n noua funcie de scalabilitate. Se intenioneaz oferirea de interoperabilitate diferitelor servicii sau de acomodare la capabiliti variate ale diferitelor receptoare i reele unde opereaz un singur serviciu Au fost introduse i diferene minore, n scopul creterii eficienei codrii. Prima dintre acestea se refer la alegerea ca metod de reordonare a uneia diferite de zig-zag. A doua diferen se manifest la nivelul cuantizrii DCT, n cazul MPEG-2 fiind suportat o cuantizare att liniar ct i neliniar. Cuantizarea neliniar mrete precizia de cuantizare pentru rate mari de bit prin angajarea unor valori de cuantizare reduse. Se mbuntete astfel calitatea imaginilor n zonele de contrast redus. Exist i diferene de sintax, precum conceptul diferit de GOP (Group Of Picture) sau controlul nepotrivirilor IDCT.

66

Standardele MPEG-4 i H.264 Scopul proiectului H.264 ITU-T a fost acela de a crea un standard care s asigure o bun calitate a imaginii n condiiile unor rate de codare a informaiei net inferioare (ex: jumtate sau chiar mai puin) fa de ceea ceea ce necesitau standardele anterioare (ex: fa de MPEG-2, H.263, sau MPEG-4), i asta far s mreasc prea mult complexitatea implementrilor care ar fi dus la preuri ridicate pentru implementrile practice. Un scop adiacent a fost acela de a asigura un mecanism flexibil care s permit standardului s fie utilizat pentru o gam larg de aplicaii (pentru transmisii cu rate de transfer att reduse ct i nalte, pentru rezoluii video nalte sau joase) i de a funciona bine cu o plaj ct mai larg de reele i sisteme (ex: transmisii broadcast, stocri pe suportDVD, reele cu comutare RTP/IP, i sisteme telefonice multimedia ITU-T). Au fost introduse mai multe caracteristici noi precum comutaia adaptativ ntre transformatele pe ntreg ntre 44 i 88, matrice de cuantizare cu pondere perceptual specific pentru codri, codare eficient fr pierderi ntre imagini, suport pentru spaii de culori adiionale, i o transformat de culoare rezidual. MPEG-4 i H.264 au viziuni semnificativ diferite. Ambele se apleac asupra compresiei fluxului video dar MPEG-4 ofer flexibilitate n timp ce H.264 eficien i protecie sporit. MPEG-4 ofer tehnici de codare i resurse flexibile, fcnd posibil lucrul cu o gam larg de tipuri de date (tabel 3.7). Totodat, ofer posibilitatea de lucru cu clase de profiluri - simple, bazate pe obiecte, scalabile, studio. Prin contast, H.264, se concentreaz pe compresia i transmisia eficient a cadrelor video. Utilizeaz doar 3 profiluri de baz, extins i principal, prin comparaie cu cele peste 20 ale MPEG-4.
Capabiliti Tipuri de date suportate MPEG-4 Cadre i cmpuri video rectangulare, obiecte video cu form arbitrar, obiecte video hibride, obiecte 2D i 3D 19 medie Codare scalabil 8x8 jumtate sau sfert de pixel 8 x 8 DCT H.264 Cadre i cmpuri rectangulare video

Numr de profiluri Eficiena compresiei Suport pentru fluxuri video Dimensiunea minim a blocului pentru compensarea micrii Acurateea vectorului de micare Transformat

3 nalt comutarea segmentelor (slice) 4x4 sfert de pixel 4 x 4 DCT

Tabelul 3.7. Diferene ntre MPEG-4 i H.264 MPEG-4 a fost finalizat la finele anului 1998 nceputul anului 1999, moment n care ITU-T evalua propunerile pentru un nou standard H.26L (L Long term). Modelul de test al acestui standard a fost adoptat ca model de baz pentru MPEG-4 versiunea a 10-a n anul 2001.

67

Modelul de codare video definete un set de profile care sunt adaptate pentru diverse aplicaii:

Baseline Profile (BP): n principal pentru aplicaiile de cost redus, cu resurse de calcul limitate, videoconferin i aplicaii mobile; Main Profile (MP): scopul original fiind al unui profil pentru aplicaii de transmitere i stocare, dar importana a sczut cnd a fost dezvoltat HiP pentru acest tip de aplicaii; Extended Profile (XP): cu scop pentru transmitere video, acest profil are compresie relativ mare i este protejat mpotriva pierderilor de date; High Profile (HiP): principalul profil pentru aplicaii de transmitere i stocare pe disc, n particular pentru aplicaii n televiziunea de nalt definiie (stocare filme pe discuri HD DVD i Blu-ray D); High 10 Profile (Hi10P): depete capabilitile produselor destinate consumatorului obinuit, avnd la baz High Profile a adugat suport pentru mrirea preciziei imaginii decodate; High 4:2:2 Profile (Hi422P): destinat aplicaiilor profesionale; High 4:4:4 Predictive Profile (Hi444PP): are la baz High 4:2:2, dar adaug codare zonal fr pierdere i codarea fiecrei imagini ca trei plane color separate. Standardul MPEG-7

Scopul principal al MPEG-7 este de a specifica un set standard de descriptori care s poat fi utilizai pentru a descrie diferite tipuri de informaii multimedia codate cu codecuri standard. Combinaia de descriptori i scheme de descriere va fi asociat cu propriul coninut pentru a permite o metod rapid i eficient de cutare pentru informaia de interes. Informaia audio-video asociat MPEG-7 poate fi indexat i cutat. Dezvoltrile s-au concentrat pe indexare i interogare, descriptori de culoare (spaiul culorilor, cuantizare, culoare dominant, scalabilitate, structur, distribuie spaial i GOP), descriptori de textur (omogenitate, caracterizare perceptual, histogram de contur), descriptori de form (bazate pe regiuni, bazate pe contur i tridimensionale), descriptori de micare (micarea camerei, traiectoria micrii, modele de micare parametric, activitatea micrii), localizare (zonal, spaio-temporal), etc. Standardul MPEG-21 Scopul standardului MPEG-21 multimedia framework este de a oferi interfee i protocoale care s activeze creaia, manipularea, cutarea, acesul, memorarea, livrarea i utilizarea informaiei. Are la baz 2 concepte eseniale: definiia unei uniti fundamentale pentru distribuie i tranzacie respectiv coceptul utilizatorilor ce interacioneaz prin DI-iuri (obiectul interaciunii dintre utilizatori). MPEG-21 identific 7 elemente arhitecturale necesare pentru a suporta aplicaii multimedia i definete relaiile de legtur dintre acestea precum i operaiile suportate.

68

Transportul semnalelor audio i video prin RTP Dup cum s-a menionat anterior, RTP este un protocol care furnizeaz servicii pentru date cu caracteristici de timp real, prin includerea n cmpul payload a octeilor de voce furnizai de codecul audio sau de date corespunztoare semnalului video comprimat. Astfel, RFC 2250, specific 2 formate pentru cmpul payload al RTP pentru MPEG-1/2 corespunztoare celor 4 sisteme finale specificate: TIU (Transmitting Interworking Unit), RIU (Receiving Interworking Unit), TAES (Trasmitting Internet EndSystem) i RAES (Receving Internet End-System). Fluxul elementar MPEG-1, ES (Elementary Steams) este ncapsulat mpreun cu tampilele temporale PTS (Presentation Time Stamps) de decodare i referina ceasului sistemului. Pentru MPEG-2 exist 2 formate pentru fluxul sistemului: flux de transport, MTS (MPEG2 Transport Stream) respectiv fluxul programului, MPS (MPEG2 Program Stream). Fiecare pachet RTP conine a tampil temporal derivat din ceasul de referin al emitorului, de 90kHz. Aceasta nu va fi prelucrat de decodorul MPEG, funcia sa fiind oarecum diferit de a tampilelor temporale MPEG. Scopul su este de a permite, estimarea i reducerea jitter-ului din reea, respectiv sincronizarea echipamentelor aflate n comunicare. Multiple pachete MTS (in mod obinut de 188 octei) sunt introduse ntrun acelai pachet RTP. MPS i ES nu au restricie de mpachetare. Sunt tratate precum un pachet de octei. Cmpurile header-ului RTP (RFC 1890)sunt utilizate dup cum urmeaz: - PT: 32 (MPEG-1 si MPEG-2 video), 33 (MPEG-2 Transport) (Tabel 3.3) - M: 1 (tampil temporal cu valoare discontinu) permite receptorului s ignore diferenele dintre 2 tampile temporale consecutive - timestamp: 32 bii timpul de transmisie pentru primul octet al pachetului. Antetul secvenei video MPEG trebuie s fie inclus integral ntr-un singur pachet RTP, astfel nct dimensiunea minim a acestuia trebuie s fie de 261 octei, avnd n vedere cazul MPEG-2 unde antetul secvenei video este urmat de antetul extensiei de secven video. Acest antet are urmtoarele structuri:

Figura 3.21. Antet secven video MPEG-1

MBZ: T: TR: AN: N: nespecificat; 0 n mod curent 1 - specific prezena antetului de extensie pentru MPEG-2 referin temporal; valoare constant pentru toate pachetele RTP ale aceleiai imagini; 0 pentru MPEG-1 payload, setat 1 cand urmtorul bit, N, este utilizat pentru a semnaliza modificarea antetului imaginii n cazul MPEG-2 0 pentru MPEG-1; utilizat pentru a semnaliza prezena unui antet nou n cazul MPEG-2. setare n cazul n care informaia coninut n imaginea anterioar nu poate fi utilizat pentru a reconstrui antetul imaginii curente; acest lucru apare cnd imaginea curent este codat utiliznd un set diferit de parametrii relativ la imaginea anterioar de acelai tip.

69

S: B: E: P: FBV: BFC: FFV: FFC:

1 - pentru a detecta prezena antetului de secven n pachetul RTP 1 atunci cnd apare nceputul unei tieturi n imagine (slice) 1 indic prezena sfritului tieturii din imagine indic tipul imaginii (I,P,B sau D) full_pel_backward_vector backward_f_code full_pel_forward_vector forward_f_code

Figura 3.22. Antet extensie secven video MPEG-2

X: nespecificat; 0 in mod curent f_[0,0]: forward horizontal f_code f_[0,0]: backward horizontal f_code DC: intra_DC_precision T: top_field_first C: concealment_motion_vectors V: intra_vlc_format R: repeat_first_field G: progressive frame E: indic prezena extensiilor f_[0,0]: forward vertical f_code f_[0,0]: backward vertical f_code PS: picture_structure P: frame_predicted_frame_dct Q: q_scale type A: alternate scan H: chroma_420_type D: composite_display_flag

MPEG-4 reprezint un standard de codare cu caracteristici precum eficien n codare sporit, protecie la erori mbuntit, codare bazat pe obiecte pentru forme multiple i arbitrare, etc. Se acoper o gam larg de rate de bit de la kbps la Mbps precum i o larg varietate de reele de la cele care garanteaz rata erorii de bit la cele mobile mai puin restrictive, pentru moment, din acest punct de vedere. Este de dorit, ca restriciile de fragmentare s fie minimale iar regula un singur pachet video trebuie mapat ntotdeauna ntr-un singur pachet RTP improprie. Regulile de fragmentare trebuie s fie flexibile astfel nu mai mult de un pachet video intr-un pachet RTP. MPEG-4 poate genera VOP-uri de dimensiune mic, caz n care un pachet video gol (vop_coded = 0) conine doar antetul VOP (Video Object Plane) sau o form arbitrar VOP cu un numr mic de blocuri codate. Pentru a reduce supraantetul (overhead) ce apare n asemenea cazuri, regula de fragmentare permite concatenarea multiplelor VOP ntr-un pachet RTP.

Figura 3.23. Antet i payload RTP n figura 3.23 este evideniat antetul RTP i configuraia cmpului payload.

70

Un flux video MPEG-4 este mapat direct n pachete RTP fr existena cmpurilor extra-antet sau eliminnd elemente de sintax. Fluxul combinat de configurare i elementar trebuie s fie utilizat astfel nct informaia de configurare s fie transportat spre acelai port RTP ca i fluxul elementar. Urmtoarele reguli se aplic pentru fragmentare: 1. informaia de configurare i cmpul grupul planului obiectelor video (GOV) trebuie s fie plasate la nceputul zonei payload a RTP (imediat dup antet) sau imediat dup antetul funciei nivelului superior; 2. dac unul sau mai multe antete exist n zona payload a RTP, aceasta trebuie s nceap cu antetul funciei de nivel ridicat; 3. un antet nu poate fi divizat n mai multe pachete RTP 4. diferite VOP-uri pot fi divizate n diferite pachete RTP astfel nct un pachet RTP cuprinde octeii de date asociate unei unice instane temporale VOP, cu excepia n care multiple i consecutive VOP-uri pot fi transportate n acelai pachet n ordinea de decodare dac dimensiunea VOP-urilor este mic; 5. este recomandat ca un singur pachet video s fie expediat ntr-un singur pachet RTP; dimensiunea pachetului video poate fi ajustat n asemenea fel nct pachetul RTP rezultat s nu fie mai mare dect MTU. Figura 3.24. ofer exemple de pachete RTP generate avand la baz criteriile anterioare:

Figura 3.24. Exemple clasice de pachetizare MPEG-4 a. exemplu de prim pachet RTP ce cuprinde informaii de configurare; n conformitate cu criteriul 1, antetul VOS (Visual Object Sequence) este plasat la nceput, precednd antetele VOH (Visual Object Header) i VOL (Visual Object Layer);

71

b. pachet RTP coninnd informaii de configurare; aici pachetul RTP conine deja un pachet video n VOP ce urmeaz informaiei de configurare; se utilizeaz ct timp lungimea cmpului alocat informaiilor de configurare este mic, iar pachetul RTP conine doar informaii de configurare ceea ce poate crete dimeniunea supra-antetului; c. pachet RTP coninnd GOV; urmrind criteriul 1, GOV este plasat la nceputul zonei payload a pachetului RTP; GOV are 7 octei i este urmat de VOP; d. un pachet video este mpachetat ntr-un pachet RTP; acest tip de pachetizare este recomandat cnd rata de pierdere a pachetelor n reea este ridicat; chiar cnd un pachet RTP coninnd un antet VOP este perdut din reea, alte pachete RTP pot fi decodate utiliznd HEC (Header Estension Code); e. mai mult de un pachet video se introduce n acelai pachet RTP; este o situaie indicat pentru a minimiza supra-antetul RTP/IP cnd rata de pierdere a pachetelor n reea este sczut; numrul optim de pachete video ce pot fi introduse i lungimea pachetului RTP se determin lund n consideraie rata de pierdere a pachetelor i rata de bit a reelei; f. un pachet video este inactivat de setarea marker-ului de resincronizare n antetul VOL; n acest caz VOP poate fi distribuit pe mai multe pachete RTP cu poziie arbitrar a octeilor; este utilizat cnd reeaua nu are erori Figura 3.25 exemplific cazuri speciale de pachete RTP care nu respect regulile anterioare. Fragmentarea antetului n multiple pachete RTP, cazul 3.25a, nu doar va crete supra-antetul RTP/IP dar va i micora rata de recuperare a erorilor. Cnd se concateneaz mai mult de un pachet video ntr-un pachet RTP, antetul VOP nu trebuie plasat la mijlocul zonei payload a RTP. Pachetizarea, cazul 3.25b, nu este permis dectre criteriul 2 datorit aspectelor legate de protecia la erori. Comparnd acest exemplu cu cel din figura 3.24d unde 2 pachete video sunt mapate n 2 pachete RTP, n ambele cazuri, protecia la erori este diferit. Astfel, dac al doilea pachet RTP este pierdut, ambele pachete sunt pierdute n cazul 3.24b n timp ce doar pachetul 2 este pierdut n cazul 3.24d.

Figura 3.25. Exemple speciale pentru pachetizare MPEG-4

72

De ataat la bibliografie
1. Chuck Semeria, Supporting Differential Service Classes: TCP Congestion Control Mechanisms, 2002, Juniper Networks Inc. 2. Kohler E., Handley M., Floyd S., Datagram Congestion Control Protocol (DCCP), RFC 4340, Martie 2006, Network Working Group 3. Kohler E., Handley M., Floyd S., Designing DCCP: Congestion Control Without Reliability, 2003 4. Santiago Alvarez, QoS for IP/MPLS Networks, Cisco Press, iunie 2006, ISBN 978-1-58705-233-0 5. Video Codec for audiovisual services AT p x 64 kb/s, Recomandare ITU-T, H.261, Geneva 1990 6. Schulzrinne H., RTP Profile for Audio and Video Conferences with Minimal Control, RFC 1890, ianuarie,1996 7. Hoffman D., Fernando G., Gozal V., Civanlar M., RTP Payload Format for MPEG1/MPEG2 video, RFC 2250, ianuarie 1998 8. Berc L., Fenner W., Frederick R., McCanne S., Stewart P., RTP Payload Format for JPEG compressed video, RFC 2435, octombrie 1998 9. Kikuchi Y., Nomura T., Fukunaga S., Matsui Y., Kimata H., RTP Payload Format for MPEG-4 Audio/Video Streams, RFC 3016, noiembrie 2000 10. Video coding for low bit rate communication, Recomandare ITU-T, H. 263, ianuarie 2005 11. Advanced video coding for audiovisual services, Recomandare ITU-T, H.264, martie 2005 12. Examples for H.263 encoder/decoder implementation, Recomandare ITU-T, H.263, Appendix III, iunie 2005 13. Coanda H.G., Sisteme de comunicatii Reele ATM si reele locale, Editura Bibliotheca, Targovite, 2004, ISBN 973-712-035-3 14. Richardson I.E.G, H.264 and MPEG-4 Video Compression Video Coding for Next-generation Multimedia, John Willey & Sons, 2003, ISBN 0-470-84837-5 15. Burnett I.S, Pereira F., Van de Walle R., Koenen R., The MPEG-21 Book, John Wiley & Sons, 2006, ISBN 978-0-470-01011-2

73