Instant Audio Video Streamer
CUPRINS
1 INTRODUCERE…………………………………………………………
1.1 Scurtă istorie a Internetului………………………………………………………
1.2 Succesul Internetului…………………………………………………………..
1.3 World Wide Web………………………………………………………………
1.4 Scurtă istorie a WWW…………………………………………………………
1.5 Puncte forte ale Web……………………………………………………………
1.6 Multimedia……………………………………………………………………..
1.7 Protocoale de comunicare pe Internet…………………………………………
1.7.1 Transmission Protocol……………………………………………….
1.7.2 User Datagram Protocol………………………………………………
1.7.3 Real Time Transfer Protocol…………………………………………
1.7.3.1 RTP Data Transfer Protocol………………………………..
1.7.3.2 RTP Control Protocol………………………………………
1.7.4 Hyper Text Transfer Protocol……………………………………………
1.7.5 Real Time Streaming Protocol…………………………………………
1.8 Controlul Congestiilor și Procesarea media……………………………………
1.8.1 RTP și DCCP…………………………………………………………
1.8.2 RTCP pentru pachete RTP cu transport pe DCCP…………………………
1.8.3 Negocierea RTP peste DCCP utilizând SDP…………………………………
2 TEHNOLOGII UTILIZATE ÎN TRECUT PENTRU STREAMING
MULTIMEDIA……………………………………………………………………………..
2.1 Primele experiențe cu pachetele audio-video……………………………………………..
2.2 Network Voice Protocol (NVP-II)……………………………………………………………
2.2.1 Mesaje de control în NVP-II………………………………………………………
2.2.2 Protocoale de date pentru NVP-II……………………………………………….
2.3 Streaming Protocol (ST-II)…………………………………………………………………….
2.3.1 Concepte de bază în ST-II………………………………………………………….
2.3.2 Interacțiunea dintre o aplicație și agentul ST………………………………..
2.3.3 SCMP……………………………………………………………………………………..
2.3.4 Configurarea unui stream utilizând SCMP…………………………………..
2.4 Audio-Video pe Internet…………………………………………………………………………
2.5 Tipuri de transmisii………………………………………………………………………………..
2.5.1 Transmisia Unicast……………………………………………………………………
2.5.2 Transmisia Multicast…………………………………………………………………
2.5.3 Transmisia Concast…………………………………………………………………..
2.5.4 Transmisia Multipeer/Multiport………………………………………………….
2.6 Unicast vs Multicast……………………………………………………………………………….
2.7 Constrangeri în utilizarea multicast………………………………………………………….
2.7.1 Transmiterea nesigură de pachete……………………………………………….
2.7.2 Duplicarea pachetelor……………………………………………………………….
2.7.3 Congestia rețelei………………………………………………………………………
2.8 Mbone………………………………………………………………………………………………….
2.8.1 Tool-uri multimedia pentru Mbone…………………………………………….
2.8.2 BGMP…………………………………………………………………………………….
3 MULTIMEDIA ÎN TIMP REAL…………………………………………………..
3.1 RTSP…………………………………………………………………………………………………….
3.2 Mesaje RTSP…………………………………………………………………………………………
3.2.1 Mesaje RTSP tip cerere……………………………………………………………..
3.2.2 Mesaje RTSP tip răspuns……………………………………………………………
3.2.3 Setarea unei sesiuni utilizând RTSP…………………………………………….
3.3 Session Description Protocol……………………………………………………………………
3.4 Session Initiation Protocol (SIP)………………………………………………………………
3.4.1 Mesajele și formatele SIP…………………………………………………………..
3.4.2 Cererile de tip SIP……………………………………………………………………..
3.4.3 Răspunsurile de tip SIP………………………………………………………………
3.4.4 Headerele de tip SIP………………………………………………………………….
3.5 Session Announcement Protocol (SAP)…………………………………………………….
3.5.1 Anunțarea și ștergerea unei sesiuni SAP………………………………………
3.5.2 Formatul pachetelor SAP……………………………………………………………
3.6 Mică istorie a RTP………………………………………………………………………………….
3.7 RTP Data Transfer Protocol…………………………………………………………………….
3.8 RTP Control Protocol……………………………………………………………………………..
4 TEHNOLOGII MULTIMEDIA ÎN DEZVOLTARE……………………..
4.1 IPTV…………………………………………………………………………………………………….
4.2 Diferența între IPTV și Internet TV………………………………………………………….
4.3 Privire de ansamblu asupra infrastructurii IPTV………………………………………..
4.3.1 IPTV Data Center…………………………………………………………………….
4.3.2 Rețeaua de distribuție broadband………………………………………………..
4.3.3 IPTV Consumer Device (IPTVCD)…………………………………………….
4.3.4 Rețele locale…………………………………………………………………………….
4.4 Codarea în timp real și transmisia IPTV……………………………………………………
4.4.1 Introducere în codarea în timp real……………………………………………..
4.4.2 Metode de compresie………………………………………………………………..
4.4.2.1 Compresia MPEG……………………………………………………….
4.4.2.2 Compresia audio…………………………………………………………
4.4.3 Microsoft Windows Media și VC-1……………………………………………
4.5 DVB-H…………………………………………………………………………………………………
4.6 Conceptul MBMS………………………………………………………………………………….
4.6.1 Serviciile și aplicațiile MBMS……………………………………………………
4.6.2 Arhitectura sistemului MBMS……………………………………………………
4.7 Internet Multimedia Subsystem (IMS)………………………………………………………
4.7.1 Arhitectura IMS și componente cheie………………………………………….
5 TEHNOLOGII UTILIZATE………………………………………………………..
5.1 Java Media Frameworks…………………………………………………………………………
5.2 Tipuri de date suportate de către JMF……………………………………………………….
5.3 Structura API-ului………………………………………………………………………………….
5.3.1 Clase cheie în JMF API…………………………………………………………….
5.4 Utilizarea JMF pentru RTP……………………………………………………………………..
5.4.1 Formate RTP în cadru JMF………………………………………………………..
5.4.2 Utilizarea claselor RTP din JMF…………………………………………………
5.5 Utilizarea JMF în conjuncție cu alte API-uri………………………………………………
5.6 Direcții de viitor ale JMF…………………………………………………………………………
5.7 Recepția și prezentarea streamurilor RTP utilizând JMF……………………………..
5.8 Transmisia streamurilor RTP utilizând JMF………………………………………………
5.9 Captura conținutului media utilizând JMF…………………………………………………
5.10 Procesarea media utilizând JMF………………………………………………………….
5.10.1 Configurarea unui procesor……………………………………………………..
5.11 Implementarea tehnică a aplicației utilizând JMF………………………………….
5.11.1 Captura de pe dispozitivele de intrare……………………………………….
5.11.2 Transmisia streamurilor…………………………………………………………..
5.11.3 Recepția și prezentarea streamurilor………………………………………….
5.12 Soluții de server side pentru real time streaming pe Internet…………………..
6 MANUAL DE UTILIZARE………………………………………………………….
6.1 Meniu-ul File…………………………………………………………………………………………
6.1.1 Open RTP Session…………………………………………………………………….
6.1.2 Capture……………………………………………………………………………………
6.1.3 Transmit…………………………………………………………………………………..
6.1.4 Preferences………………………………………………………………………………
6.2 Meniu-ul Player……………………………………………………………………………………..
6.2.1 Cazul aplicației ce efectuează transmisia……………………………………..
6.2.2 Cazul aplicației ce efectuează recepția…………………………………………
6.2.3 RTP Session Control…………………………………………………………………
7 CONCLUZII………………………………………………………………………………..
8 BIBLIOGRAFIE………………………………………………………………………….
86 pagini
=== lucr ===
CUPRINS
1 INTRODUCERE………………………………………………………… 6
1.1 Scurtă istorie a Internetului………………………………………………… 6
1.2 Succesul Internetului………………………………………………………….. 7
1.3 World Wide Web……………………………………………………………… 7
1.4 Scurtă istorie a WWW………………………………………………………… 7
1.5 Puncte forte ale Web…………………………………………………………… 8
1.6 Multimedia…………………………………………………………………….. 8
1.7 Protocoale de comunicare pe Internet………………………………………… 9
1.7.1 Transmission Protocol………………………………………………. 9
1.7.2 User Datagram Protocol…………………………………………… 9
1.7.3 Real Time Transfer Protocol……………………………………… 10
1.7.3.1 RTP Data Transfer Protocol……………………………… 10
1.7.3.2 RTP Control Protocol……………………………………… 10
1.7.4 Hyper Text Transfer Protocol……………………………… 10
1.7.5 Real Time Streaming Protocol………………………………… 10
1.8 Controlul Congestiilor și Procesarea media…………………………………… 11
1.8.1 RTP și DCCP………………………………………………………… 11
1.8.2 RTCP pentru pachete RTP cu transport pe DCCP… 11
1.8.3 Negocierea RTP peste DCCP utilizând SDP… 12
2 TEHNOLOGII UTILIZATE ÎN TRECUT PENTRU STREAMING
MULTIMEDIA… 13
2.1 Primele experiențe cu pachetele audio-video… 13
2.2 Network Voice Protocol (NVP-II)… 13
2.2.1 Mesaje de control în NVP-II… 14
2.2.2 Protocoale de date pentru NVP-II… 15
2.3 Streaming Protocol (ST-II)… 15
2.3.1 Concepte de bază în ST-II… 16
2.3.2 Interacțiunea dintre o aplicație și agentul ST… 17
2.3.3 SCMP… 17
2.3.4 Configurarea unui stream utilizând SCMP… 18
2.4 Audio-Video pe Internet… 19
2.5 Tipuri de transmisii… 20
2.5.1 Transmisia Unicast… 20
2.5.2 Transmisia Multicast… 21
2.5.3 Transmisia Concast… 21
2.5.4 Transmisia Multipeer/Multiport… 22
2.6 Unicast vs Multicast… 22
2.7 Constrangeri în utilizarea multicast… 23
2.7.1 Transmiterea nesigură de pachete… 24
2.7.2 Duplicarea pachetelor… 24
2.7.3 Congestia rețelei… 24
2.8 Mbone… 24
2.8.1 Tool-uri multimedia pentru Mbone… 26
2.8.2 BGMP… 26
3
3 MULTIMEDIA ÎN TIMP REAL… 28
3.1 RTSP… 28
3.2 Mesaje RTSP… 28
3.2.1 Mesaje RTSP tip cerere… 29
3.2.2 Mesaje RTSP tip răspuns… 30
3.2.3 Setarea unei sesiuni utilizând RTSP… 30
3.3 Session Description Protocol… 31
3.4 Session Initiation Protocol (SIP)… 32
3.4.1 Mesajele și formatele SIP… 32
3.4.2 Cererile de tip SIP… 33
3.4.3 Răspunsurile de tip SIP… 34
3.4.4 Headerele de tip SIP… 35
3.5 Session Announcement Protocol (SAP)… 35
3.5.1 Anunțarea și ștergerea unei sesiuni SAP… 36
3.5.2 Formatul pachetelor SAP… 36
3.6 Mică istorie a RTP… 37
3.7 RTP Data Transfer Protocol… 37
3.8 RTP Control Protocol… 38
4 TEHNOLOGII MULTIMEDIA ÎN DEZVOLTARE… 40
4.1 IPTV… 40
4.2 Diferența între IPTV și Internet TV… 40
4.3 Privire de ansamblu asupra infrastructurii IPTV… 41
4.3.1 IPTV Data Center… 41
4.3.2 Rețeaua de distribuție broadband… 41
4.3.3 IPTV Consumer Device (IPTVCD)… 41
4.3.4 Rețele locale… 42
4.4 Codarea în timp real și transmisia IPTV… 42
4.4.1 Introducere în codarea în timp real… 42
4.4.2 Metode de compresie… 43
4.4.2.1 Compresia MPEG… 43
4.4.2.2 Compresia audio… 44
4.4.3 Microsoft Windows Media și VC-1… 45
4.5 DVB-H… 45
4.6 Conceptul MBMS… 46
4.6.1 Serviciile și aplicațiile MBMS… 47
4.6.2 Arhitectura sistemului MBMS… 47
4.7 Internet Multimedia Subsystem (IMS)… 49
4.7.1 Arhitectura IMS și componente cheie… 49
5 TEHNOLOGII UTILIZATE… 51
5.1 Java Media Frameworks… 51
5.2 Tipuri de date suportate de către JMF… 51
5.3 Structura API-ului… 53
5.3.1 Clase cheie în JMF API… 54
5.4 Utilizarea JMF pentru RTP… 55
5.4.1 Formate RTP în cadru JMF… 55
5.4.2 Utilizarea claselor RTP din JMF… 56
5.5 Utilizarea JMF în conjuncție cu alte API-uri… 57
4
5.6 Direcții de viitor ale JMF… 58
5.7 Recepția și prezentarea streamurilor RTP utilizând JMF… 58
5.8 Transmisia streamurilor RTP utilizând JMF… 59
5.9 Captura conținutului media utilizând JMF… 60
5.10 Procesarea media utilizând JMF… 61
5.10.1 Configurarea unui procesor… 61
5.11 Implementarea tehnică a aplicației utilizând JMF… 62
5.11.1 Captura de pe dispozitivele de intrare… 62
5.11.2 Transmisia streamurilor… 64
5.11.3 Recepția și prezentarea streamurilor… 65
5.12 Soluții de server side pentru real time streaming pe Internet… 68
6 MANUAL DE UTILIZARE… 71
6.1 Meniu-ul File… 71
6.1.1 Open RTP Session… 71
6.1.2 Capture… 72
6.1.3 Transmit… 73
6.1.4 Preferences… 77
6.2 Meniu-ul Player… 78
6.2.1 Cazul aplicației ce efectuează transmisia… 78
6.2.2 Cazul aplicației ce efectuează recepția… 79
6.2.3 RTP Session Control… 82
7 CONCLUZII… 84
8 BIBLIOGRAFIE… 86
5
CAPITOLUL 1 – INTRODUCERE
Internetul se schimbă: se renunța la conținutul static în favoarea streamingului video, textul este înlocuit de către muzică și cuvinte vorbite, iar conținutul audio-video devine un lucru comun. Ideea folosirii rețelelor gen Internet pentru transmiterea conținutului audio video nu este noua. Acest gen de experimente au o istorie destul de îndelungată începând cu anii 1970. Primul RFC pe acest subiect – Network Voice Protocol (NVP) – datează incă din anul 1977. Partea de video a apărut mai târziu dar sunt totuși zece ani de experiență cu conferințele audio-video pe Internet.
1.1 Scurtă istorie a Internetului
Cuvântul Internet a apărut din nevoia de a descrie rețelele interconectate iar protocolul
fundamental al acestora a luat denumirea de IP (Internet Protocol). Strict înrudit cu IP este
TCP (Transmission Control Protocol) care împreună cu IP au format binecunoscutul protocol
TCP/IP.
În mijlocul anilor 1980 NSF (United States National Science Fundation) a început dezvoltarea NSFNET care furniza un punct de sprijin pentru serviciile de comunicație existente pe Internet. Viteza de tranfer pe această rețea era de 50kbps. Același lucru l-au facut si NASA si DE (American Deparment of Energy) cu rețelele NSINET și ESNET.
La sfârșitul anilor 1980, numărul de implementări ale protocolului TCP/IP, dezvoltate de către institutii publice și organizații private ajunsese la o sută. La sfârșitul anului 1991 existau integrate în Internet 5000 de rețele răspândite in peste 40 de tări care găzduiau peste 700.000 de computere folosite de patru milioane de utilizatori.
Tot în anul 1991 a fost dezvoltată prima interfată „friendly” a Internet-ului de către cercetătorii de la Universitatea din Minnesota. Universitatea a dorit dezvoltarea unui meniu simplu pentru accesul facil la fișierele de pe rețea.
În 1989 un alt eveniment major a avut loc. Tim Berners-Lee și alți cercetători de la CERN au pus bazele unui nou protocol de schimb informațional. Acesta a devenit World Wide Web mai tarziu în anul 1991.
Dezvoltarea în 1993 a primului browser grafic Mosaic, de către Marc Andreessen și colaboratorii săi de la NCSA a dus la dezvoltarea extrem de rapidă a acestui protocol. Creierul Mosaic a pus bazele Netscape Corp, cel mai de succes browser Web până la dezvoltarea Microsoft Internet Explorer de către firma Microsoft.
Având în vedere că bazele Internetului au fost puse de către guvernul american, acesta a
fost folosit în scopuri de cercetare, educație sau activitați guvernamentale. Orice utilizări
comerciale erau interzise, ele fiind permise doar în scopuri de cercetare. Acest lucru a fost
valabil până la începutul anilor 1990, când o serie de rețele comerciale au început să se
dezvolte. A devenit posibilă trecerea de la un site la altul fară a mai traversa reteaua NSF.
Primul serviciu comercial online care a oferit servicii contra-cost clienților săi s-a numit Delphi. Toate aceste restricții cu privire la serviciile comerciale au dispărut in 1995, când NSF și-a retras sponsorizarea.
În istoria Internetului finanțarea a trecut de la nivel guvernamental, la cel privat. La momentul actual Internetul a devenit într-adevar un fenomel mondial cu o răspândire geografică majoră.
6
1.2 Succesul Internetului
Unul dintre punctele esențiale ale Internetului este că, în afară de conținutul multimedia,
folosește resurse marginale. Aceasta înseamnă utilizarea resurselor care altfel ar fi irosite,
care este realizată spărgând datele ce trebuie transmise în pachete și trimiterea acestora pe o
rută posibilă. În plus, costul real al puterii de procesare și a stocării de date au continuat să
scadă.
În același timp există o reorientare către procesare mobilă, având în vedere că calculatoarele personale devin mai mici si mai puternice. Multe surse prezic că modul de acces la Internet va continua să evolueze. Aceiași factori vor continua să alimenteze succesul Internetului și în viitor.
1.3 World Wide Web
World Wide Web poate fi considerat o cauză și un efect al erei informaționale. Este foarte mult un proces al erei informaționale care a început acum un deceniu. WWW-ul deși este foarte ușor de folosit totuși poate fi extrem de puternic. Dar ce este mai exact WWW? Pentru a răspunde la această întrebare trebuie să ne uităm pe scurt la istoria acetuia.
1.4 Scurtă istorie a World Wide Web
Din exterior Web a fost conceput pentru a rezolva o problemă de care s-au lovit mai mulți
cercetători din diverse locații ale lumii. Fizicienii care lucrau la CERN au dorit un mod de a
face schimb informațional rapid (utimele descoperiri teoretice sau date obținute din
experimente practice). Au dorit să facă acest lucru cât mai rapid și să poată include mai mulți participanți de la mii de kilometri depărtare.
Acest lucru a început în 1989 odată cu propunerea lui Berners-Lee a unui spațiu universal
hypertext în care fiecărui document să i se asociere un UDI (Universal Document Identifier).
Acesta a scis în 1990 un program denumit „WorldWideWeb”, un editor hyper-text care rula
pe o mașină Next. De asemenea a mai fost inclus și un mic browser în linie de cod dezvoltat
de către Nicola Pellow care putea rula pe absolut orice calculator. Specificațiile UDI-urilor
care acum se cheama URI-uri precum și HTML(HyperText Markup Language) și HyperText
Transport Protocol (HTTP) au fost publicate pe primul server cu scopul de a fi adoptate și
discutate într-o maniera largă.
Primii trei ani au fost necesari pentru a convinge companiile asupra posibilitațiilor oferite de acest nou concept. Între anii 1991 si 1994, încarcarea primului server web (info.cern.ch) a dus la o crestere cu un factor de zece în fiecare an a traficului. În septembrie 1994 s-a format World Wide Web Consortium cu sedii la M.I.T în America, INRIA în Franța și Universitatea Keio din Japonia.
Deși World Wide Web nu a fost folosit decât pentru puțin timp ca un motor de tranfer
pentru fișierele hyper-text, acesta a cunoscut o dezvoltare extraordinară atât către conținut
static (text) cât și dinamic (conținut multimedia). În acest scos au fost dezvoltare atât
programe speciale denumite servere web cât si uneltele necesare accesării informațiilor gazduite pe aceste servere (browsere).
În mod normal un browser web reprezintă o legătură între utilizator și computer în timp ce un serverul web este o legătură între computer și Internet.
7
1.5 Punctele forte ale Web
Din perspectiva utilizatorului, Web facilitează posibilitatea accesării informațiilor cu ajutorul unor echipamente care pot fi achiziționate de un număr foarte mare de utilizatori. Web permite utilizatorilor diseminarea informațiilor pe glob cu cunoștiințe minime.
Poate că cel mai important factor care a contribuit la succesul Web este ideea de
modelare a acestuia ca o rețea interconectată de resurse. Aceasta înseamnă că toți cei care
sunt conectați la Internet au acces la resursele rețelelor interconectate, nu doar aparținătorii
rețelelor.
Alți factori care au contribuit semnificativ la dezvoltarea Web includ limbaj de
formatare, conținut multimedia, interactivitate, limbajul de programare Java și URL
(Universal Resource Locator). Primul, și încă cel mai folosit limbaj de formatare, HTML este
foarte simplu de utilizat. O pagină Web poate fi făcută dinamică în așa fel încât să
interacționeze cu intrările calculatorului fără a mai fi nevoi de reîncărcarea sa pentru fiecare
intrare a utilizatorului. Acest lucru a fost posibil cu ajutorul limbajului de programare Java.
Sun Microsystems a dezvoltat Java în anul 1995, făcându-l extrem de flexibil și
implementând posibilitatea de rulaj independent de sistemul de operare.
URL este în principal un simplu mecanism de adresare care ajută la identificarea documentelor web. El coține informații de genul: adresa serverului gazdă, locația conținutului pe server și tipul documentului. Acesta nu numai că identifică un anumit document pe gazdă dar și conduce utilizatorul către acel document.
1.6 Multimedia
Prin multimedia s-a făcut un mare pas înainte în consolidarea relației dintre utilizator și
calculator și indirect dintre utilizator și Internet. Acest fenomen a dus la dezvoltarea mult mai
prolifică a WWW. Prin multimedia întelegem o combinație de formate audio și video care fac
navigarea interactivă. Astăzi, odată cu dezvoltarea explozivă a noilor tehnologii de rețea, multimedia a devenit indispensabilă pentru Internet.
Există două tipuri de multimedia:
Multimedia statică care este folosită doar pentru a crea o interfată user-friendly
sau pentru prezentări de genul Powerpoint.
Multimedia dinamică care este folosită pentru a crea o interfață user-friendly și
interactivă în același timp (și în care intră și conținutul audio-video).
Datele multimedia spre deosebire de tipul tradițional de date au câteva caracteristici
unice:
Prima, aplicațiile multimedia necesită o lărgime de bandă destul de mare. Un
clip de 25 de secunde la o rezoluție de 320X240 poate ocupa 2.3MB,
echivalentul la o mie de ecrane de text simplu.
A doua caracteristică, majoritatea aplicațiilor au constrângeri de genul: transfer
în timp real.
Conținutul audio și video trebuie redat în timp real cu viteza cu care a fost
înregistrat.
Conținutul multimedia se redă sacadat datorită dinamicii diferite a diferitelor
tipuri de media.
Telefonia VoIP și conferințele în timp real fac parte din multimedia în timp real. Acest domeniu cunoaște o dezvoltare de mai bine de zece ani.
8
1.7 Protocoale de comunicare pe Internet
Rolul protocoalelor de comunicare pe Internet în transmiterea conținutului multimedia este arătat în figura de mai jos:
Figura 1.1 Layerele superioare în Internet
Protocoalele de transport TCP și UDP sunt cu un layer mai sus față de IP. TCP oferă un
serviciu de transmitere orientat pe flux de date cu sistem de corecție si detecție a erorilor, în
timp ce UDP oferă transmiterea de datagrame fără stabilirea unei conexiuni “end-to-end”.
RTP care este construit pentru transmiterea fluxurilor în timp real, de obicei rulează
peste UDP/IP dar poate rula și peste TCP/IP. Pe aceste două protocoale mai rulează și două
dintre cele mai importante protocoale orientate pe aplicații HTTP și RTSP.
1.7.1 Transmission Protocol
TCP este un protocol orientat pe conexiune și este folosit pentru transmisii de date în siguranța peste Internet. El împarte informația în pachete mici de date înainte de transmitere. Aceste pachete de date vor fi reasamblate la destinație. Calculatorul care recepționează informația trebuie să genereze un cod checksum care va fi comparat cu cel din header-ul de date al pachetului pentru a verifica consistența transmisiei.
În eventualitatea unei erori, receptorul cere retransmisia pachetului până când acesta
este recepționat corect. Pentru a garanta transmisia corectă a datelor, TCP are un mecanism
de handshaking care asigură stabilirea corectă a conexiunii între transmițator și receptor.
Totuși în cazul unei aplicații în timp real, întarzierea generată de retransmisia pachetelor este
inaceptabilă.
Prin urmare, TCP este potrivit pentru aplicații care tolerează acest tip de întârzieri și pentru care cel mai important lucru este trimiterea corectă a pachetelor.
1.7.2 User Datagram Protocol
UDP oferă transmisie de date nesigure pe Internet dar cu o latență minimă. Acesta nu oferă nici un mecanism de control al corectitudinii transmisiei. Prin urmare, o parte din date pot fi pierdute, pot ajunge alterate sau duplicate. Totuși latența scăzută și întârzierile minime îl fac foarte potrivit pentru aplicații în timp real.
Protocolul UDP folosește 16 biți pentru numerotarea porturilor de la 0 la 65.535. Portul 0 este rezervat, porturile de la 1 la 1023 sunt foarte des folosite pe sistemele Unix, porturile de la 1024 la 49.151 sunt porturi înregistrate iar porturile de la 49.152 până la 65.535 sunt utilizate de clienți pentru a se conecta la servere.
9
1.7.3 Real Time Tranfer Protocol
RTP oferă servicii de livrare end-to-end pentru date cu caracteristici real-time, precum live audio și video. Aceste servicii includ mecanisme de identificare a sarcinii utile (a tipului de date care este transmis), numerotarea de secvențe, time-stamping și monitorizare transmisiei. Având în vedere ca RTP nu se adresează rezervării de resurse și nu oferă QoS pentru servicii în timp real, rulează de obicei peste UDP pentru a folosi serviciile de multiplexare si checksum. RTP este alcătuit din două părti strâns legate: RTP Data Transfer Protocol și RTP Control Protocol.
1.7.3.1 RTP Data Transfer Protocol
RTP Data Transfer Protocol transmite date cu caracteristici real-time. El definește
formatul pachetelor de bază pentru a putea susține transferul de date real-time, dar nu
definește mecanisme de control sau algoritmi. Acest protocol este mai degrabă integrat în
operațiile de procesare ale aplicației, decât definit ca un layer separat. Formatele pachetelor
oferă informații necesare pentru transferul datelor multimedia. Numerele secvențelor pot fi
folosite pentru detecția pierderilor pe pachete, sau pentru determinarea unui frame într-o
secvența video.
1.7.3.2 RTP Control Protocol
RTCP monitorizează QoS și informațiile de control pentru fluxurile de date real time transmise prin intermediul RTP Data Transfer Protocol. Cele mai importante elemente de control predefinite sunt rapoartele transmițătorului și receptorului. Ambele conțin informații despre QoS-ul curent a streamurilor și pachetelor recepționate. Fiecare bloc recepționat conține statistici de recepție despre fluxul de date precum numărul maxim de secvențe recepționate, fracțiune de pachete pierdute de la ultimul raport și număr cumulativ de pachete pierdute. Raportul transmițătorului include NTP (Network Time Protocol) și time-stamp-uri RTP, numărul de pachete deja transmise.
1.7.4 HyperText Transfer Protocol
HTTP este un protocol la nivel de aplicație pentru sisteme de informații hypermedia
colaborative și distribuite. Acesta funcționează peste TCP sau orice protocol de transmisie
fără pierderi. Protocolul implică un mecanism client-server de tipul browser (client) și server
web (server). Fiecare cerere a browserului pornește o noua conexiune TCP. Acest mecanism
este evident ineficient deoarece consumă foarte mult timp. Acest dezavantaj a fost înlăturat
odată cu apariția HTTP 1.1 care permite existența unei singure conexiuni pentru mai multe
transferuri prin definirea unor metode de genul OPTIONS, PUT, DELETE și TRACE.
1.7.5 Real Time Streaming Protocol
RTSP este un protocol de control pentru o prezentare multimedia client-server. RTSP
este construit pentru transmiterea eficienta a fluxurilor multimedia peste rețelele IP.
RTSP ofera unelte foarte puternice pentru construcția transmisiilor la cerere a
conținutului în timp real. Sursele de date pot include atât fluxuri de date audio/video în timp
real cât și înregistrate. Acest protocol a fost dezvoltat în așa fel încât utilizatorul să poată
10
alege între TCP, UDP unicast și UDP multicast. Acesta utilizează RTP pentru transmisia de
date și protocoale precum SIP și SAP pentru controlul și anunțarea sesiunilor în timp real.
1.8 Controlul congestiilor și procesarea media
O bine cunoscută problemă în congestia audio-video este adaptarea ratei de transfer
pentru streaming-uri. Codecurile media au o oarecare restricție în adaptabilitate, atât în
variația ratei de transfer cât și la adaptarea în funcție de regulile impuse de mecanismul de
control al congestiilor. În momentul în care codecul se poate adapta la regulile de control a
congestiilor, există situații în care acest lucru nu este întotdeauna dezirabil din punct de
vedere uman. O situație de acest gen se poate întâmpina în momentul în care utilizatorul nu
este dispus să sacrifice calitatea conținutului. DCCP nu îngreunează cu nimic aceste aspecte
fața de celelalte mecanisme de control a congestiilor, însă nu le face nici mai ușor de rezolvat.
1.8.1 RTP și Datagram Congestion Control Protocol (DCCP)
Protocolul RTP este intens folosit pentru streaming video în timp real, servicii de
telefonie real-time și alte aplicații în timp real pe rețea. El poate rula pe o serie de protocoale
lower-layer de transport, și performanța unei aplicații folosind acest protocol este foarte
puternic influențată de utilizarea acestor protocoale. Protocolul de control al congestiilor
(DCCP) este un protocol nou specificat, care oferă propietățiile dorite pentru aplicații în timp
real. Odată cu adoptarea la scară foarte largă a RTP s-a pus problema aplicațiilor care nu au
implementate controlul congestiilor și care pot duce la o potențială avariere a rețelei.
Proiectanții RTP au recunoscut această problemă spunând că: ”Receptorii RTP ar trebui să
monitorizeze pierderile de pachete pentru a se asigura că acest fenomen decurge în parametrii
normali. Pierderile de pachete sunt considerate aceeptabile dacă un flux TCP pe aceeași cale
de rețea și care întâmpină aceleași condiții va avea o tranzitie medie, măsurată pe o scară de
timp rezonabilă, care nu este mai mică decât cea atinsa de fluxul RTP”[21]. Această condiție
poate fi satisfăcută prin implementarea unor mecanisme de control a congestiei pentru
adaptarea ratei de transmisie sau prin decuplarea unui receptor din sesiune, în cazul în care
pierderile sunt prea mari.
Doua abordări au fost utilizate pentru a oferii control al congestiilor peste RTP:
Dezvoltarea de noi profiluri RTP care sa încorporeze controlul congestiilor
Oferirea de mecanisme care să ruleze RTP peste protocoale care oferă controlul
congestiilor
În mod normal RTP poate rula și pe TCP însă mai potrivită este rularea RTP peste DCCP, deoarece DCCP oferă un mecanism de control al congestiilor. Acesta oferă posibilitatea aplicațiilor să seteze parametrii transportului pentru nevoile lor lasând partea de complexitate a implementării către sistemul de operare. Dacă DCCP va fi disponibil la scară largă, este crezut că vor fi avantaje serioase.
Fiecare pachet de date RTP trebuie convertit la o singură datagramă DCCP. Câmpurile din headerul RTP trebuie interpretate conform specificațiilor RTP, prin oricare profil aplicabil sau prin specificarea formatului de date. Procesarea headerului nu este afectată de încadrarea DCCP.
O conexiune DCCP este stabilită când un sistem receptor se conectează la o sesiune RTP și rămâne deschisă pe întreaga durată a conexiunii. Pachetele RTP trebuie să se supună regulilor de control al congestiilor dictate de DCCP. Extensiile RTP care oferă control al congestiilor la nivel de aplicație pot interfera cu DCCP ducând la apariția de erori.
11
1.8.2 RTCP pentru pachetele RTP cu transport pe DCCP
Protocolul RTCP este folosit într-o manieră standard peste DCCP. Pachetele de tip
RTCP sunt grupate în pachete compuse pentru care este transferată o singură datagramă
DCCP.
Uzualele reguli de timming se aplică și în cazul acesta, cu condiția să se supună regulilor specifice DCCP. Aceasta poate evita situația în care un participant poate transmite pachete RTCP și după expirarea sesiunii. Pachetele RTCP reprezintă o mică parte a pachetelor transmise într-o întreagă sesiune RTP. Prin urmare, în majoritatea cazurilor nu există întârzieri în transmiterea acestora datorită controlului congestiilor.
Dacă totuși capacitatea conexiunii DCCP este mult sub lărgimea de bandă a sesiunii, pachetele RTCP pot fi suficient întârziate încât participanți să declare time-out datorită inactivitații. În astfel de cazuri este necesară renegocierea parametriilor sesiunii astfel încât să fie cât mai apropiați de adevărata capacitate a rețelei.
1.8.3 Negocierea RTP peste DCCP folosind SDP
Pentru negocierea sesiunilor RTP se folosește SDP (Session Description Protocol).
Protocolul SDP folosește o linie media de genul („m=”) pentru a încadra informații despre formatul media folosit și tipul de protocol de transport. Sintaxa ABNF a unei linii media arată în felul urmator:
media-field = %x6d "=" media SP port ["/" integer] SP proto 1*(SP fmt)
CRLF.
Câmpul proto indică protocolul de transport folosit în timp ce câmpul port indică portul pe care urmează să fie transmise toate datele.
Identificatorul protocolului DCCP este similar cu cele ale protocoalelor TCP și UDP și denotă protocolul DCCP, nu layer-ul superior. O linie SDP de tip „m=” care specifică un protocol de tip DCCP trebuie sa specifice layer-ul protocolului la nivel de de aplicație folosind un identificator „fmt”. Un singur port DCCP este folosit după cum e precizat de câmpul port din linia media.
Profilurile RTP disponibile peste DCCP sunt următoarele:
DCCP/RTP/AVP
DCCP/RTP/SAVP
DCCP/RTP/AVPF
DCCP/RTP/SAVPF
În cazul acestor profiluri protocolul DCCP este înregistrat pe portul 5004 și trebuie să fie portul predefinit pentru aplicațiile care folosesc aceste profiluri. Dacă există multiple sesiuni RTP disponibile de pe aceeași adresă, se pot folosii porturi dinamice în același spațiu de adrese pentru numerotarea sesiunilor.
12
CAPITOLUL 2 – TEHNOLOGII UTILIZATE ÎN TRECUT PENTRU STREAMING MULTIMEDIA
2.1 Primele Experiente cu pachete audio-video
Dezvoltatorii inițiali ai NVP au fost cercetători care transmiteau pachete prin
ARPANET, predecesoarea Internet. Aceasta oferea un serviciu de streaming (analog
TCP/IP), dar se introducea prea multă întarziere. Ca urmare al acestui lucru s-a dezvoltat un nou protocol fără mecanismul de control al pachetelor, asemănător UDP/IP-ului de astăzi. NVP-ul era construit direct pe acest protocol, mai târziu, experimentele au fost extinse dincolo de ARPANET pentru a interpola cu Packet Radio Network și Atlantic Satellite Network (SATNET).
Toate aceste experimențe timpurii erau limitate la unul sau două canale de voce, de către lărgimea de bandă extrem de redusă a retelelor. În anii 1980 odată cu crearea rețelei Wideband Satellite Network de 3Mb, s-au putut îngloba nu numai mai multe canale audio, dar și pachete video. Pentru a accesa serviciile multicast ale rețelei s-a dezvoltat protocolul ST (Streaming Protocol). Atât o a doua versiune a NVP denumită NVP-II cât și un protocol video companion denumit Packet Video Protocol erau transmise peste ST pentru a furniza un prototip de protocol orientat pe conferințe.
În 1989-1990, rețeaua de satelit a fost înlocuită cu Terrestrial Wide Band Network și o rețea experimentală denumită DARTnet iar ST a evoluat in ST-II. Sistemul de conferințe orientat pe pachete a fost introdus în producția de serie pentru a susține conferințele la distanțe foarte mari ale cercetătorilor.
ST și ST-II au operat în paralel cu IP pe layer-ul de inter-rețea dar au avut o dezvoltarea limitată pe rețele guvernamentale sau de cercetare. Ca o alternativă, oferirea inițiala a sistemelor de conferințe peste IP a început cu DARTnet, permițand conferințe multiutilizator cu NVP-II transmise peste UDP/IP multicast. La întalnirea din martie 1992 a IETF, audio a fost transmis peste Internet către 20 de locații de pe 3 continente prin canale multicast. La aceeași întâlnire a început dezvoltarea RTP.
2.2 Network Voice Protocol (NVP-II)
NVP-II a fost gandită ca un înlocuitor pentru NVP-I care funcționa încă din 1974. Îmbunătățirile aduse odată cu aceasta se regăsesc în urmatoarele arii:
Operaționalitate pe inter-rețelele ARPA.
Facilitați de conferențiere îmbunătățite.
Facilitarea uneltelor necesare pentru ”stream-setup”.
Control flexibil pentru eventuala adăugare a unor noi extensii multimedia.
NVP-II, ca și NVP-I este împărțit în Control Protocol (CP) și Voice Data Protocol (VP). Modulul care implementează CP se numeste CM. Principalele sale obiective sunt:
Monitorizarea și stabilirea căilor de comunicare.
Susținerea unei interfațe cu utilizatorul convenabile.
NVP-II codează pachetele voce de date într-un mod diferit față de NVP-I. El suportă următoarele tipuri de conexiuni:
Point-to-Point (PTP) full duplex. Comunicarea în doi (fără a face diferența între
sursă și destinatar).
Destinații multiple half-duplex (MDHD). Comunicarea de tip conferință.
Acest protocol poate fi folosit de către utilizatorii cu suport pentru IP și ST.
13
Un utilizator al NVP-II este identificat prin intermediul unei adrese de inter-rețea, exprimată pe 32 de biți, căreia i se poate atribui și un NICKNAME.
Comunicarea protocolului se face prin intermediul ST, care poate fi folosit în trei
moduri de bază:
IP.ST – datagramă pentru o singură destinație (înainte de a stabili o conexiune
ST)
ST.DG – datagramă pentru o singură destinație (după stabilirea unei conexiuni
ST)
ST.ST – streamuri multi-destinație
2.2.1 Mesaje de control în NVP-II
Mesajele de control sunt precedate de către un checksum pe 16 biți. Această valoare este calculată conform specificațiilor protocolului ST.
Fiecare instrucțiune de control NVP-II este alcătuită din 3 câmpuri, primul este un bit
„op-code” urmat de un bit Data.Length urmat de N rânduri de date, unde N este evident între
0 și 255. Biții „op-code” și Data.Length sunt legați într-un singur cuvânt.
Modulul de control al receptorului procesează aceste informații exact în ordinea în care
au fost comunicate. Este de așteptat ca acesta să ignore instrucțiunile pe care nu le
recunoaște.
Lista instrucțiunilor de control este următoarea:
[ 0] UNUSED AT THIS TIME
[ 1] [I-AM-READY]
[ 2] [BYE] <REASON>
[ 3] [I-AM-RINGING]
[ 4] [VOCODING] <VOCODER-CODE>
[ 5] [PRECEDENCE] <VALUE>
[ 6] [PLEASE-ECHO] <REFERENCE>
[ 7] [ECHO-REPLY] <REFERENCE>
[ 8] [CONNECTION-NAME] <NAME>
[16] [TELL-ABOUT-USER] <USER-ID> <USER-ID>…<USER-ID>
[17] [USER-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION>
[18] [ALTERNATIVE-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> [19] [NICKNAME] <USER-ID> <NICKNAME>
[20] [ARBITRARY-TEXT] <STRING>
[21] [ARBITRARY-CODE] <VALUE> <VALUE> …<VALUE> [22] [WHAT-ARE-YOUR-CAPABILITIES?]
[23] [PLEASE-SEND-YOUR-COMMUNICATION-STATISTICS] [24] [HERE-IS-MY-STATISTICS] <DATA>
[25] [PLEASE-DIAL] <DIALING SEQUENCE>
[32] [PLEASE-JOIN-A-CONFERENCE]
[33] [I-WANT-TO-JOIN-THE-CONFERENCE]
[34] [CONFERENCE-ID] <CONF-ID>
[35] [CONFERENCE-CONNECTION-NAME] <CID> [36] [CONFERENCE-PASSWORD] <PW>
[37] [CONFERENCE-ACCESS] <INFO-FOR-AC> [38] [CONFERENCE-STYLE] <STYLE>
[39] [CONFERENCE-BIT-MAP] <USER-ID> <NP> <BM> [40] [PLEASE-GIVE-ME-THE-CONFERENCE-STATUS] [41] [USER-IS-OUT] <USER-ID>
[48] [I-AM-TALKING-NOW]
[49] [I-AM-DONE]
[50] [NET-MEASUREMENT-TIMESTAMP] <VALUE> <HOST> <EXT>
14
O descriere detaliată a acestor mesaje o găsiți în lucrarea „A Network Voice Protocol NVP-II” scrisă de Danny Cohen[25].
2.2.2 Protocolul de date al NVP-II
Protocolul de date al NVP-II este alcătuit dintr-un header de două cuvinte urmate de o serie de opțiuni (dacă există) plus datele codate.
Cuvintele din header au următoarele patru câmpuri:
SEQUENCE-NUMBER: Câmp de 6 biți pentru o secvență de numere modulo
64. Nu este necesară eliberarea acestui câmp și începerea fiecărei comunicare de voce de la SEQ=0.
TIME-STAMP: Câmp de zece biți care indică timpul la care s-a creat primul
element al acestui mesaj. Acesta este măsurat in vcoder-frames.
CHECKSUM: Câmp de un bit pentru a proteja headerul de date al NVP. Acesta
este calculat conform specificațiilor de calcul pentru ST.
TOKEN-LENGTH: Câmp de un bit care specifică instrucțiunile de control
NVP ce urmează. Lungimea este exprimată ca un cuvânt de la 0 la 255 de biți.
Opțiunile care urmeză după cuvântul din header sunt instrucțiunile de control NVP-II. Datele care urmeză sunt conforme cu specificațiile vcoding.
2.3 Streaming Protocol (ST-II)
Este un protocol experimental orientat pe conexiune. Oferă mecanisme orientate pe aplicație pentru a cere rezervarea unor resurse din rețea. Poate oferii un framework pentru gestiunea QoS.
ST-II , la fel ca IP, este alcătuit din două protocoale:
ST pentru transportul de date.
SCMP pentru scopuri de control.
Modulul de date și modulul de control pentru ST-II arată ca în figura 2.1:
Figura 2.1 Modulul de date și modulul de control pentru ST-II
Protocolul ST-II este pe același nivel cu IP, singura diferență între ele fiind că primul
furnizează transfer de date în timp real orientat pe conexiune în timp ce al doilea oferă
servicii optime fără conexiune. Așa cum TCP și UDP sunt protocoale de transport construite
15
peste IP, RTP sau protocoalele de transport specializate, precum, PVP (Packet Video
Protocol) și NVP (Network Voice Protocol) sunt protocoale de transport construite peste STII. Headerele ST-II și IP diferă prin câmpul număr versiune (IP este versiunea 4 sau 6 în timp ce ST-II e versiunea 5).
RTP poate fi folosit atât pe TCP/UDP pentru transmisia optimă a streamurilor real-time. Mai poate fi folosit și împreună cu ST-II pentru transmiterea traficului în timp real cu QoS garantat. În plus pachetele ST-II pot fi încapsulate în pachetele IP pentru a trece de porțiunile de rețea non-ST-II.
Figura 2.2 Relația de conlucrare între ST-II și IP
2.3.1 Concepte de bază în ST-II
Conceptele de bază ale ST-II sunt:
Fluxul de date (stream): Un flux de date reprezintă o conexiune unidirecțională
de tip point-multi point cu transmițătorul ca nod rădăcină și receptorii în locul
frunzelor (dupa cum este arătat în figura 2.3). Nodurile din graf sunt ori gazde,
ori routere care suportă ST-II. Orice entitate (fie că e gazdă sau router) care
poate executa protocolul ST-II se numește agent ST. Un stream este setat și
menținut cu ajutorul SCMP.
Transfer de date: Odată ce un stream este setat, fiecare agent ST menține
informații complete despre acesta și îl identifică cu ajutorul unui stream
identifier (SID). Pachetele care aparțin unui stream conțin un header ST-II cu
versiunea 5, care le diferențiază de pachetele IP, și stream id (SID) care poate fi
folosit de către agenții ST intermediari pentru a stabilii cărui stream aparțin.
Pachetul maxim de date este stabilit în timpul setării conexiunii, aplicația
emițătoare fiind înștiințată că numai pachetele de acea mărime sunt lăsate să
treacă.
Specificațiile fluxului și configurarea streamului: O aplicație emițătoare, în mod
normal oferă unui agent ST specificațiile Qos folosind parametrii ca: viteza de
16
tranzitare, întârzierea de la un cap la altul (end-to-end delay) și jitter. SCMP este folosit pentru a căra aceste informații între agenți.
Figura 2.3 Flux de date (stream)
2.3.2 Interacțiunea dintre o aplicație și un agent ST
O aplicație emițătoare poate executa una dintre următoarele instrucțiuni:
Crearea unui stream nou (OPEN).
Extinderea unui stream existent (ADD) prin adăugarea unor noi aplicații de
recepție.
Reducerea unui stream existent (DROP) prin deconectarea uneia sau mai multor
aplicații receptoare.
Schimbarea parametrilor QoS a unui stream existent (CHG). Trimitere de date către stream (DATA).
Ștergere unui stream (CLOSE).
O aplicație ce recepționeză poate executa următoarele comenzi:
Alăturarea la un stream deja existent (JOIN).
Recepția de date de la un stream (DATA).
Părăsirea unui stream (LEAVE).
2.3.3 SCMP
SCMP este protocolul de control folosit de către agenții ST pentru crearea și setarea streamurilor.
Există trei tipuri de stream-uri definite în ST-II:
Streamuri inițiate de către emițător: aplicația emițătoare trebuie să ofere
agentului ST corespunzător lista de receptori astfel încât un stream inițiat de
17
către emițător să poată fi stabilit. Adăugarea sau ștergerea unui receptor poate fi
făcută doar de către emițător. În plus, acesta are control total asupra streamului.
Streamuri inițiate de către receptor: Aplicația receptoare, crează un stream gol,
iar receptorii i se alătură acestuia, independent. În plus alăturarea sau părăsirea
unui stream ține în totalitate de receptor iar emițătorul nu are nici un control.
Stream mixt: Aplicația emițătoare crează un stream cu câțiva receptori.
Receptorii adiționali se pot alătura streamului, independent. În plus, deși un
stream mixt este inițiat de către un emițător, acesta nu are controlul deplin
asupra streamului.
Streamurile ințiate de către receptor și streamurile mixte sunt de obicei de încărcătură ușoară, în sensul că fiecare agent, incluzând emițătorul, nu au informații complete asupra tuturor receptorilor.
2.3.4 Configurarea unui stream folosind SCMP
Configurarea unui stream folosind SCMP implică următorii pași:
Informațiile de la aplicație: aplicația ce emite oferă agentului ST următoarele
informații:
o Lista de receptori (ținte).
o Informații de flux conținând Qos-ul dorit.
o Informația de grup: Un grup este reprezentat de un set de streamuri și o
relație și este identificat de un nume. Există patru tipuri de relații într-un
grup:
1. bandwith sharing: streamurile asociate aceluiași grup împart
aceeași bandă.
2. fate sharing: dacă un stream aparținând acestui grup este șters,
celelalte stream-uri sunt la rândul lor șterse.
3. route sharing: stream-urile aparținând acestui grup au aceeași cale.
4. subnet resource sharing: același resurse de layer MAC pot fi
împărțite de către toate streamurile aparținând aceluiași grup.
o Opțiuni de stream: există două opțiuni posibile:
1. no recovery: un agent ST nu trebuie să încerce recuperarea unui
stream dacă această opțiune este setată.
2. join authorization level: aceasta determină politica adoptată pentru
noi receptori care se alătură unui stream.
Configurarea unui stream la început: Agentul ST, la recepția de informații de la
aplicație, efectuează următoarele operații:
o Alocă un id de stream (SID).
o Se uită pe tabelul de routare pentru a determina setul de noi gazde pentru
stream.
o Invocă managerul de resurse locale (LRM) pentru a rezerva resursele
necesare.
o Crează o intrare nouă în bază pentru a stoca informațiile legate de noul
stream.
o Propagă cererea de setup a streamului cu specificațiile noului stream luate
din tabelul de routare.
Propagarea și procesarea a mesajelor CONNECT: Agenții ST propagă mesajele
CONNECT care conțin SID, opțiunile streamului, specificațiile de flux și
următoarele routere. Fiecare agent ST intermediar răspunde cu un ACK. Este
necesar și LRM pentru rezervarea resurselor.
18
Procesarea mesajelor CONNECT de către receptori: Când un agent ST la
destinație primește un mesaj CONNECT, trimite un ACK către gazda precedentă,
invocă LRM ca să rezerve resursele după care interogheză aplicația de recepție
dacă vrea sau nu să primească conexiunea stabilită. Aplicația receptoare primește
prametrii de conectare din mesajul CONNECT incluzând SID, opțiunile
streamului, emițătorul (originea), flowspec (specificațiile de flux), lista de
receptori și grupul din care face parte. Bazată pe decizia aplicației de recepție, agentul ST trimite un mesaj de ACCEPT sau de REFUSE.
Procesarea mesajului ACCEPT pe un agent ST intermediar: Un agent ST
intermediar trimite un mesaj ACK către următoarea gazdă și returnează mesajul
ACCEPT către precedenta gazdă pe aceeași cale indicată de mesajul CONNECT.
Procesarea mesajelor ACCEPT de către emițător: Atunci când aplicația emitoare
primește mesajul ACCEPT de la fiecare aplicație de recepție, are cunoștiință
despre toate resursele alocate cu succes pe întreaga cale, de către fiecare receptor.
Aplicația emitoare poate folosii aceste informații ca sa ocupe/elibereze parți din
stream pentru fiecare receptor.
Procesarea mesajului REFUSE de către un agent ST intermediar: acesta trimite un
mesaj ACK catre următoarea gazdă, invocă LRM ca să elibereze resursele, șterge
înregistrarea corespunzătoare din baza de date locală și returnează mesajul
REFUSE către agentul ST anterior.
Procesarea mesajului REFUSE de către emițător: Când mesajul REFUSE a ajuns
la emițător el trimite un mesaj ACK la agentul ST următor și informeză aplicația
emițătoare că respectivul receptor nu mai face parte din stream.
Modificarea unui stream existent:
o Când aplicația emițătoare dorește să adauge un receptor, agentul ST
corespunzător dă drumul la un mesaj CONNECT similar celui emis la
prima configurare a sistemului. Mesajul CONNECT este ACK-t, propagat
și resursele de rețea sunt rezervate.
o Dacă aplicația emițătoare dorește să deconecteze niste receptori, agentul
ST corespunzător trimite DISCONNECT către următorii agenți ST. Un
agent ST intermediar trimite un mesaj ACK către precedentul agent ST,
modifică rezervarea sa de resurse, șterge înregistrarile din baza locală și
propagă mesajul DISCONNECT la sursele anterioare.
o Dacă un receptor dorește să se alăture unui stream, agentul ST
corespunzător generează un mesaj JOIN care se propagă spre emițător. Un
agent intermediar ST trimite un mesaj ACK către agentul de la care a
primit mesajul după care execută ori un CONNECT ori un JOIN-REJECT
pe care îl trimite către emițător.
2.4 Audio-Video peste Internet
Ca urmare a acestor experimente timpurii, interesul către conferințele video a crescut in anii 1990. Cam în același perioada, puterea de procesare si capabilitațile multimedia ale PCurilor a crescut deasemenea suficient de mult pentru a permite captura, compresia și redarea streamurilor audio și video. În paralel, dezvoltarea multicast-ului peste IP a permis transmiterea de date către orice număr de calculatoare conectate la Internet.
Sistemul de video conferințe și streaming multimedia erau aplicații multicast bine
executate. Grupurile de cercetare au dezvoltat aplicații genul vic și vat (implementat de către
laboratoarele Lawrence Berkeley), sistemul INRIA (dezvoltat de către Xerox PARC) și rat
(de către Colegiul Universitar Londra). Aceste tool-uri au avut o abordare nouă asupra
19
tehnologiilor aplicate în conferințe, cu un layer ajustabil destul de subțire pentru transport.
Multicast a fost folosit atât pentru transmisia de date pe suprafețe extinse cât și ca un
mecanism de comunicare inter-proces între aplicații pe același calculator. Mediul colaborativ
rezultat este format din aplicații ușor legate între ele și participanți divers distribuiți.
Sistemul de conferințe multicast (Mbone) a avut un impact semnificativ, a dus la o înțelegere pe un nivel mult mai larg a problemelor aduse de către multimedia în timp real pe rețelele IP, controlul erorilor și a congestiilor. Acesta a influențat și dezvoltarea directă a câtorva standarde și protocoale esențiale.
RTP a fost dezvoltat de către IETF în perioada 1992-1996, pe NVP-II și pe protocolul inițial folosit pe vat. Tool-urile pentru conferințele multicast au folosit RTP ca unic protocol de transmisie de date și control; RTP conținând nu numai facilitați de transport media cât și management pentru utilizatori, sincronizare și reportare pentru calitatea recepției.
Pe lângă RTP care a fost folosit pentru transmiterea multimedia în timp real, au trebuit
dezvoltate alte protocoale pentru coordonarea și controlul streamurilor multimedia. Session
Anounced Protocol (SAP) a fost dezvoltat pentru a face cunoscute existența streamurilor
multicast. Anunțurile sesiunilor erau la rândul lor de tip multicast, și orice gazdă compatibilă
multicast putea să primeasca sesiuni SAP, și să cunoască ce transmisii și conferințe au loc.
Comunitatea de dezvoltare a mediului Mbone a dus la dezvoltarea protocolului SIP
(Session Initiation Protocol). Acesta a fost dezvoltat ca un mod ușor de inițiere a unei sesiuni
multicast cu un set specific de participanți. În versiunile sale de început SIP includea foarte
puține module de control și negociere a legăturii deoarece nici Mbone nu includea așa ceva.
2.5 Tipuri de transmisii
În contextul unui grup de comunicare, se pot diferenția mai multe tipuri de transmisii în funcție de numărul de emițători și numărul de receptori.
Se poate face o separare a transmisiilor în următoarele tipuri:
Unicast (1:1)
Multicast (1:n)
Concast (m:1)
Multipeer/Multipoint (m:n)
Notațiile din paranteze vor fi interpretate după cum urmează. Primul reprezintă numărul de emițători iar al doilea număr reprezintă numărul de receptori.
2.5.1 Transmisia Unicast
Unicast este echivalent cu transmisia tradițională point-to-point în care există exact un
emițător și un receptor. Ca o consecință, datele sunt schimbate într-un mod unidirecțional.
Transmisia bidirecțională necesită existența a două conexiuni unicast. Totuși, deși datele
efective, într-o transmisie unicast, circulă într-o singură direcție, datele de control care sunt
necesare controlului tehnic al sistemului pot fi transmise și în direcție inversă. Acest lucru
înseamnă ca receptorul poate transmite emițătorului confirmarea de primire cu succes a
datelor.
Termenul unicast, de cele mai multe ori, nu este folosit într-un sens foarte precis. În literatură, schimbul de date bidirecțional între două calculatoare este definit ca unicast. Dacă unicast este folosit pentru construcția unui grup de comunicare, trebuie stabilite cel puțin două astfel de conexiuni între doi parteneri ai grupului. Dacă avem un grup de mărime n acesta produce un număr de n(n-1) relații de comunicare unicast și n(n-1)/2 de tip multicast. Aceasta nu este o opțiune fezabilă în cazul grupurilor mari.
20
2.5.2 Transmisia Multicast
Într-o transmisie multicast o singură sursă transmite date către una sau mai multe destinații. În cazul în care avem decât un singur destinatar, se aplică regulile de bază unicast. La fel ca în cazul unicast datele propriu-zise pot circula doar într-o singură direcție.
Pentru implementarea unui grup cu transmisie bidirecțională care va avea n participanți,
sunt necesare n relații de transmisie multicast-câte una per membru.
Un exemplu clasic de utilizare multicast îl reprezintă implementarea unei conferințe cu
suport audio-video. Multicast poate fi folosit deasemenea pentru lucru în echipă și împărțirea
resurselor.
Deși este considerată o tehnologie a anilor 1990, ea oferă câteva avantaje demne de luat în seamă în implementarea conferințelor multimedia la distanțe mari. Printre aceste avantaje trebuie să amintim conservarea lărgimii de bandă. Stabilirea unei singure conexiuni de tip multicast pentru n număr de utilizatori este echivalentă cu stabilirea a câte unei conexiuni de tip unicast, pentru fiecare utilizator în parte (n conexiuni unicast), lucru care poate fi văzut ca problemă în funcție de configurația hardware a sursei.
În protocolul TCP/IP spațiul de adrese Ipv4 de la 224.0.0.0 până la 239.255.255.255 este rezervat pentru transmisii multicast. Aceste adrese sunt referite ca adrese de clasă D. Fiecare datagramă IP a cărei adresă de destinație începe cu secvența de biți 1110 reprezintă o datagramă IP multicast. Următorii 28 de biți din adresă identifică grupul multicast la care este trimisă datagrama.
În interiorul blocului de adrese de clasă D, spațiul de adrese de la 224.0.0.0 și
224.0.0.255 sunt rezervate pentru protocoalele de routare, protocoale de descoperire a topologiei și protocoalele de mentenanță.
Unul dintre marile dezavantaje ale multicast este că utilizatorii trebuie să se înregistreze pentru a primii un flux de date multicast. O altă limitare este aceea că nu toate routerele sau gazdele nu suportă specificațiile multicast, cu level 0 care reprezintă fără suport, level 1 care indică suport pentru trimitere multicast dar nu și pentru recepție și level 2 care reprezintă suport total pentru multicast IP.
2.5.3 Transmisia Concast
Într-o transmisie concast mai multe surse pot trimite date către un singur destinatar. Aceasta implică o relație m:1 unidirecțională în care datele sunt trimise de la sursă către destinatar.
Un exemplu de concast este atunci când în timpul unei simulări o serie de computere centralizează datele pe un singur terminal.
Având în vedere că multicast-ul copiază același stream pentru fiecare utilizator care s-a abonat la sesiune, concast face exact inversul acestui lucru. Ia o serie de streamuri din mai multe surse și le combină după niște reguli care pot fi programate pentru a crea un stream care în final să ajungă la destinatarul final.
Concast este similar cu multicast în anumite privințe, utilizatori trebuie să se înregistreze în rețea înainte de folosirea serviciului, iar datagramele concast trebuie recunoscute de router pentru a fi procesate în drum către destinație.
Pe de altă parte concast diferă în anumite privințe de multicast. În primul rând nu necesită capabilități de routare sau de adresare în afară de „forward”-are de tip unicast. Acest tip de transmisii este încă în dezvoltare și constituie un punct de dezvoltarea a tehnologiei media pe viitor.
21
2.5.4 Transmisia Multipeer/Multipoint
Transmisiile multipeer se realizează în momentul în care o serie de surse pot transmite date către același set de destinatari. Aceasta corespunde unui set de transmisii de tip m:n și este des întâlnită drept transmisia multipoint.
Multipeer este cea mai diversă formă de comunicare în grup deoarece nu are nici o
restricție asupra numărului de surse și de destinatari. În astfel de transmisii fiecare membru al
grupului este un potențial emițător și un receptor pentru toate datele transferate pe rețea.
Transmisiile multipeer pot fi foarte greu de implementat dar pot fi emulate prin executarea concomitentă a mai multor transmisii multicast. Această implementare tehnică este aleasă des ca o opțiune în zilele noastre. Deoarece mai multe transmisii multicast idenpendente sunt rulate concomitent, pot apărea situații în care destinatarii pot primii datele de la diferite surse în diferite secvențe de timp.
Dacă situații de acest gen nu sunt acceptabile de către aplicație, trebuie oferite mecanismele adiționale pentru controlul ordinii în care se fac transmisiile.
Majoritatea sistemelor din ziua de azi folosesc transmisii unicast pentru structura de
bază și dacă incorporează multicast sau multipeer o fac ca pe o extensie.
2.6 Unicast vs Multicast
IP este un în principal un protocol unicast. A fost proiectat să mute datele dintr-o parte în alta peste rețea. Totuși găzduiește și un spațiu de adrese multicast. Există adrese care reprezintă mai mult decât un sistem destinație. Protocolul IGMP manageriază fluxurile de date multicast.
Prin multicast o singură sursă trimite date către mai multe destinații instantaneu. Fiecare canal de transmisie va avea un IP de grup unic. Utilizând protocolul IGMP, clienții pot routa streamul de date deja recepționat către alte dispozitive. Deși multicast-ul salvează lărgime de bandă, nu există nici un mecanism de control al pachetelor astfel încât pachetele odată pierdute nu mai pot fi recuperate.
Această economie de bandă devine extrem de importantă în cazul grupurilor de transmisii cu un număr de extrem de mare de destinatari. O sesiune multicast cu n utilizatori este echivalentă cu n sesiuni unicast între server și fiecare utilizator în parte.
Pentru a exemplifica această diferență luăm exemplu unei companii media care
transmite un show radio pe Internet cu lărgimea de bandă a streamului de 8kbps. Diferența în
ocuparea de bandă prin transmisie unicast, față de multicast este prezentată în figura 2.4.
Figura 2.4 Diferența de ocupare de bandă pentru o transmisie unicast/multicast audio
22
În cazul în care compania dorește să-și extindă serviciile cu un streaming video compresat de 120kbps care să ruleze în paralel cu cel audio, diferența de ocupare de bandă va arăta ca în figura 2.5.
Figura 2.5 Diferența de ocupare de bandă pentru o transmisie unicast/multicast
video
Având în vedre că transmisiile multicast reduc drastic necesarul de lărgime de bandă, acest principiu nu se aplică întotdeauna și pe traficul de rețea.
În figura 2.6 este prezentată încarcarea rețelei în cazul serverului companiei media când există trei utilizatori conectați.
Figura 2.6 Numărul de streamuri
existente pe rețea în cazul
unicast/multicast
În cazul multicast se poate observa că
routerul de lângă server primește decât un
singur stream. Se mai poate observa
deasemea că acest router clonează stream-ul
pentru a-l transmite mai departe către
celelalte routere. Procesul de clonare încarcă
procesarea de date a routerului. Acest aspect
trebuie luat în considerare în momentul în
care este gândită rețeaua. Dacă routerul nu
are un mecanism de replicare foarte eficient,
încărcarea acestuia poate atinge cote
alarmante în cazul în care numărul de interfețe de ieșire este foarte mare.
De exemplu, o implementare mai veche a protocoalelor multicasting codul de forwarding impunea routerului să cloneze pachetul de date pentru fiecare interfață de ieșire. Acest proces presupunea alocarea de buffer în plus necesar pentru copierea și trimiterea pachetelor mai departe către următoarele puncte intermediare. Noile versiuni ale codului evită această situație prin trimiterea unui pointer către datele originale la fiecare destinatar în parte. Acest algoritm permite destinatarilor să împartă același buffer.
23
2.7 Constrângeri în utilizarea trasferurilor multicast
Deși avantajele folosirii tehnologiei multicast sunt demne de luat în seamă există câteva limitări ale acestui tip de transfer care metrită amintite.
2.7.1 Trimiterea nesigură de pachete
IP multicast ca și IP unicast sunt protocoale nesigure. Doar prin utilizarea TCP pe Layer
4 putem să facem transmisiile IP unicast sigure. Totuși, pentru că IP multicast a fost proiectat
pentru transmisii către mai mulți utilizatori, nu poate utiliza mecanismul end-to-end
implementat pe protocolul TCP. Pachetele IP multicast de obicei folosesc UDP (User
Datagram Procesor) care este optimizat. Prin urmare, o aplicație care utilizează multicasting IP trebuie să se aștepte la pierderi ocazionale de pachete.
Dr Deering susține în teza sa de doctorat că: „În timpul perioadelor în care căile se
schimbă imediat după o schimbare în arhitectură, pachetele multicast care se găsesc în tranzit
au o probabilitate mai mică să-și atingă destinația decât pachetele unicast”. Deering continuă
prin a explica cum că, chiar dacă există informații de routare unicast pe anumite routere în
timpul schimbării de arhitectură, rețeaua poate avea eventual succes în routarea pachetelor
până la destinația dorită. Motivul pentru care acest fenomen se întâmplă se datorează
mecanismului de routare unicast care încearcă să trimită pachetul mai departe către destinație
în timpul modificării topologiei, profitând de calea ocolitoare. Pe de altă parte, mecanismul
de routarea a pachetelor IP multicast se bazează pe adresa de IP a sursei și pentru a prevenii
buclele, pachetul este anulat în cazul în care nu ajunge la destinația care să confirme primirea.
Ca o concluzie este important de reținut că routarea IP-urilor multicast se folosește de IP-ul sursei, spre deosebire de routarea multicast care se folosește de IP-ul destinației.
2.7.2 Duplicarea pachetelor
Pachetele duplicate, exact ca în cazul UDP unicast, sunt un lucru destul de
întâlnit.Totuși o diferență cheie între routarea unicast și multicast este că routerele trimit
intenționat copii ale unui pachet multicast către mai multe interfețe. Acest lucru amplifică
probabilitatea recepționării mai multor copii ale aceluiași pachet. De exemplu, în anumite
topologii de rețele redundante în care există mai multe căi către destinatar, pot apărea pachete
duplicate până când protocolul de routare multicast converge și le elimină. În mod normal,
asta înseamnă că doar un pachet ocazional poate fi duplicat în interiorul rețelei.
2.7.3 Congestia rețelei
În cazul TCP unicast, mecanismele slow-start și backoff ajustează automat viteza
transferului de date și prin urmare oferă un grad de evitarea a congestiilor pe rețea. Deoarece
multicastingul IP nu poate folosi TCP (nu există un mecanism de evitare a congestiilor)
2.8 Mbone
Pentru o lungă perioadă, majoritatea providerilor de Internet nu au avut la dispoziție protocoale multicast pe routerele din rețea. Motivul pendula de la lipsa de suport pe routerele mai vechi și o precauție naturală față de activarea unor funcții netestate fără suficient interes din partea consumatorului până la frica de necunoscut. Cum a reușit multicast-ul să se impună pe Internet?
24
Routarea multicast a crescut în rețelele private (de obicei în rețele acadamice sau ale corporațiilor). Aceste rețele experimentau cu trafic multicast pentru streaming audio-video și rulau protocoale multicast în interior. A devenit interesantă o eventuală alăturare la aceste rețele pentru a oferii o distribuție cât mai largă a traficului în timp real. Ca o încurajare IETF a început sa ruleze stream-uri audio-video la întâlnirile oficiale.
Conexiunea mai multor rețele multicast a fost denumită Mbone (Multicast Backbone). La început Mbone era formată dintr-o rețea multicast impusă pe Internet și alcătuită din calculatoare care rulau unul sau mai multe protocoale de routare multicast. Pentru a avea funcționalitatea unor routere multicast, având în vedere că scheletul în sine nu suporta protocoalele de routare multicast, aceste calculatoare erau legate între ele prin legături virtuale (sau tunele) pentru a forma propria rețea denumită Mbone.
Dacă nodurile care suportau Mbone erau extrase din Internet și conectate doar prin legăturile virtuale, ar fi arătat ca o rețea standard. Nucleul rețelei rula DVMRP, dar și alte protocoale de routare precum PIM și MOSPF erau folosite la marginea rețelei atât pentru valori reale cât și experimental. RFC 2715 oferă câteva adnotări folositoare pentru routerele care trebuie să împartă informații de routare multicast între protocoale.
Legăturile virtuale între routerele Mbone pot forța o cantitate mare de trafic să treacă prin legăturile interioare ale rețelei deoarece aplicațiile multicast conțin date audio-video de dimensiuni mari. Acest lucru se putea agrava în momentul în care o sursă trebuia să trimită datele până la un router din rețeaua Mbone, care la rândul său retrimitea datele către un receptor adiacent sursei. Dacă o aplicație Mbone era activată un provider de Internet putea să vadă instantaneu o creștere dramatică a nivelului de date transferate pe anumite căi ale rețelei. Din acest motiv rețeaua Mbone a stagnat în dezvoltare.
În 1995 existau 901 routere care participau la implementarea Mbone în peste 20 de țări. Ca o proporție față de numărul de 48500 de subrețele operând peste Internet la acel timp, numărul este destul de mic. Cifrele au crescut brusc iar în anul 1999 existau 4178 de routere în rețeaua Mbone. Punctul de interes atunci ca și acum era transferul de conținut multimedia în timp real utilizând Real Time Transfer Protocol. Dezvoltarea formatelor media gen mp3 au făcut acest concept și mai popular.
Experimentarea cu multicast a fost de mare beneficiu pentru providerii de Internet care vroiau să ofere noi servicii clienților lor și care aveau de profitat din reducerea consumului de lărgime de bandă pe termen lung.
IETF a format Mbone Deployment Working Group (MBONED) ca un forum de discuții care ajuta la coordonarea Mbone pe Internet. Responsabilitatea administrării rețelelor multicast a fost restructurată astfel încât să
urmeze ierarhia Internetului. Folosirea de
tunele pentru routere non-locale care să
ofere cereri multicast era depreciată.
Odată cu evoluția fulminantă a
rețelei majoritatea vechilor protocoale nu-
și mai făceau treaba pentru care fuseseră
create. În 1999, IETF a format un nou
grup de cercetare pentru dezvoltarea
MSDP (Multicast Source Descovery
Protocol). La formarea acestui grup IETF
a recunoscut că avea să fie o soluție
intermediară, soluția finală fiind BGMP
(Border Gateway Multicast Protocol) a
cărui dezvoltare va dura mai mult. MSDP
25
încă mai este folosit în mod curent pentru înlocuirea DVMRP.
Pe scurt, MSDP operează prin formarea unor relații de rudenie între routerele din fiecare domeniu participant. Aceste relații funcționează peste conexiuni TCP și formează schimburi de informații point-to-point între domenii.
O țesătură plină de astfel de conexiuni permit fiecărui domeniu să descopere sursele multicast din celelalte domenii și să le adauge la arborele său de surse.
2.8.1 Tool-uri multimedia pentru Mbone
Deși Mbone reprezintă rețeaua ce rulează peste Internet pentru a furniza servicii multicasting, ea a devenit sinonimă cu aplicațiile care rulează peste ea.
O parte a acestor aplicații sunt reprezentate de:
Session Directory tool (sd, sdr)
Audio Conferencing tool (vat, nevot, rat)
Video Conferencing tool (nv, ivs, vic, nevit) Shared Whiteboard tool (wb)
Network Text Editor (nte)
Majoritatea acestor aplicații sunt implementate utilizând Real Time Transfer Protocol (RTP) care rulează peste UDP/IP. Whiteboard și Network Text Editor sunt implementate direct pe UDP/IP. Toate aceste tool-uri sunt disponibile gratuit pe Internet.
2.8.2 BGMP
S-a știut că MSDP va avea un ciclu de viață relativ scurt. Adevărata soluție pentru routarea multicast peste Internet va fi dată de către BGMP. Standardul BGMP a ajuns la a șasea versiune în care protocolul și-a atins stabilitatea. Va veni în curând momentul în care poviderii de Internet trebuie să dezvolte strategii de tranfer de la MSDP la BGMP.
BGMP-ul recunoaște dezavantajele în protocoalele existante de routare multicast care le fac inaplicabile pe rețeaua globală denumită Internet. Chiar și când tehnicile de tunneling ale Mbone-ului timpuriu au fost înlocuite, protocoalele de routare multicast existente pun un stres suplimentar pe provideri de Internet.
BGMP este proiectat ca un protocol de routare multicast scalabil care se adresează preocupărilor providerilor de Internet și facilitează multicast pe rețele multi-domeniu. Acesta folosește o cale globală pentru arborele de distribuție multicast (exact ca PIM-SM) , dar în BGMP acea cale este un întreg domeniu în loc de un singur router. BGMP construiește arbori bidirecționali, care sunt alcătuiți din domenii, nu din routere.
Ideile de bază ale BGMP pot fi sintetizate după cum urmează:
BGMP construiește un arbore multicast bidirecțional folosit de către routerele de
la marginea domeniului cu permisiunea de a atașa ramuri specifice ca scurtături
pentru a evita întârzierile cauzate de arhitectura arborelui.
BGMP interoperează cu alte protocoale de routare multicast intra-domenii
precum DVMRP, PIM-DM, PIM-SM, CBT și MO-SPF.
BGMP alege un domeniu root bazat pe prefixul grupului de adrese multicast dat
de către MASC și utilizează MBGP care cară prefixurile grupurilor multicast
între routerele de graniță ale domeniului.
BGMP a trebuit să lege între ele diverse protocoale de routare care funcționează pe intra-domeniu.
Ca acest lucru să fie posibil, BGMP trebuie să fie protocolul de routare multicast folosit
peste rețelele autonome. Figura 2.7 arată arhitectura BGMP care este alcătuită din
următoarele componente:
26
Domenii sau sisteme autonome
Routere de graniță cu două componente
o Componentă BGMP
o Componentă M-IGP (Multicast Interior Gateway Protocol) care poate fi
una dintre DVMRP, CBT, MOSPF, PIM-DM sau PIM-SM.
Figura 2.7 Arhitectura BGMP
27
CAPITOLUL 3 – MULTIMEDIA ÎN TIMP REAL
3.1 RTSP
Mărirea lărgimii de bandă și dezvoltarea tehnicii de calcul accesibile utilizatorului de
Internet au făcut posibilă inglobarea conținutului audio-video în cadrul paginilor web.
Cererea cât mai mare pentru acest gen de conținut a dus la dezvoltarea unui nou protocol
RTSP. Acesta a fost standardizat în 1998 și este construit pe protocoale deja existente: se
aseamănă foarte mult cu HTTP în funcționare, folosește SDP pentru descrierea sesiunilor si
RTP pentru transportul media.
Acest protocol suportă următoarele operatii:
Vizionarea de conținut multimedia de pe un server dedicat: Clientul poate
solicita descrierea prezentării de pe server prin intermediul protocolului HTTP.
Dacă prezentarea este multicast, serverul va furniza in descrierea prezentării
adresele multicast si porturile care trebuie folosite. În cazul în care prezentarea
este transmisă în modul unicast, clientul furnizează destinatia din motive de
securitate
Invitarea unui server multimedia la o conferința: Pentru redarea de conținut
multimedia în prezentare sau înregistrarea unui anumit subiect din toata
conferința. Acest mod este foarte util în aplicații de e-learning
Deși se aseamănă foarte mult cu HTTP, există totuși o serie de difențe:
Serverele RTSP sunt obligate să-și mențină starea între majoritatea tranzacțiilor
spre deosebire de HTTP care este de cele mai multe ori fără o stare definită
RTSP definește noi metode și un identificator de protocol.
În RTSP partea de server poate să facă la rândul ei o serie de cereri, spre
deosebire de HTTP unde clientul face cererile și serverul răspunde la ele.
În RTSP majoritatea datelor sunt cărate în afara canalului pe alt canal de date, de
obicei RTP. În HTTP datele sunt cărate ca răspunsuri la cererile formulate.
RTSP folosește identificatori de resurse absoluți (URI); aceasta pentru a elimina
problemele introduse de către URL în versiunile de început ale HTTP
3.2 Mesajele RTSP
În figura 3.1 este prezentată sintaxa
unui mesaj RTSP. Există decât două tipuri
de mesaje RTSP: cerere și răspuns. Toate
mesajele RTSP sunt de tip text și folosesc
standardul ISO-10648 UTF-8. Prima linie
a mesajului identifică tipul acestuia.
Pentru mesajele cerere prima linie se
numește linia de cerere iar pentru cele
raspuns se numește linia de status.
Headerele de mesaj urmează după linia de
cerere sau de status. Acestea furnizeză
informații adiționale care sunt critice
pentru interpretarea corectă a mesajelor. În
mod final mesajele pot coține și un corp al
mesajului
Figura 3.1 Exemplu de sintaxă RTSP
28
Pentru mai multe detalii referitoare la sintaxa RTSP este recomandată secțiunea 15 din RFC 2326[22].
3.2.1 Mesajele RTSP tip cerere
Linia cerere din fiecare mesaj asociat are o instrucțiune care indică algorimul care
trebuie executat asupra resursei specificate de către „Request URI”. În RFC 2326[22] sunt
definite unsprezece metode, fiecare proiectate pentru un algoritm diferit. Mai departe există o
mică de scriere a celor 11 metode (pentru mai multe detalii se va consulta secțiunea 10 din
RFC 2326):
DESCRIBE este o metodă recomandată care poate fi trimisă decăt de partea
client. Serverul de obicei trimite o decriere detaliată a resursei indetificate de
„Request-URI”. Această descriere este înglobată în corpul mesajului. Nu este
întotdeauna necesar ca descrierea sesiunii să fie obținută utilizănd această
metodă. Alte mecanisme pot fi folosite în cazul în care serverul nu suportă
această metodă. Sesiunea poate fi descrisă utilizând protocolul SDP sau alte
protocoale.
ANNOUNCE este o metodă opțională care poate fi trimisă de client sau de
server. Când este trimisă de la client la server, updatează obiectul media
identificat de către „Request-URI”. În momentul în care este trimisă de la server
la client, descrierea sesiunii este updatată în timp real.
SETUP este o metodă obligatorie care poate fi trimisă decât de la client. Acesta
specifică mecanismul de transport care va fi folosit pentru un stream media
(identificat de Request-URI). Metoda SETUP poate fi folosită de asemenea
pentru a schimba parametrii streamului care deja rulează.
PLAY este o metodă obligatorie care este trimisă de la client către server.
Aceasta trasmite serverului comanda să înceapă trimiterea de date printr-un
stream configurat printr-o anterioară metodă SETUP. PLAY este o metodă
versatilă, permițând un control foarte precis al streamurilor media ce urmează să
fie rulate. Serverul nu este obligat să ruleze toate cererile clientului. Cererea
PLAY este deasemenea folosită pentru a relua un stream oprit.
PAUSE este o metodă recomandată care este întotdeauna trimisă de la client
către server. Această metodă îi ordonă serverului să oprească temporar un
stream care rulează (sau set de streamuri depinzând de Request-URI). Dacă o
comandă PAUSE este rulată, toate comenzile PLAY care urmau să fie rulate
sunt anulate. O nouă comandă PLAY trebuie efectuată pentru a se relua rularea
streamurilor.
Metoda OPTIONS este folosită de către emițător pentru a interoga informațiile
legate de opțiunile de comunicare disponibile pe resursele identificate de către
„Request-URI”; de exemplu, poate fi folosită de către un client pentru a interoga
tipul de metode suportate de către server pentru un stream dat. Deși acest mesaj
poate fi trimis atât de către client cât și de server, implementarea este absolut
obligatorie decât pentru server.
Metoda TEARDOWN oprește trimiterea streamului identificat de Request-URI.
Toate cererile stocate sunt anulate și toate resursele asociate sunt eliberate.
Metoda TEARDOWN este întodeauna trimisă de la client către server și este o
metodă obligatorie.
29
Metoda REDIRECT informează clientul că trebuie să contacteze altă locație de
server. Dacă clientul vrea să continue trimiterea și/sau recepționeze conținutul
media, trebuie să trimită o cerere TEARDOWN pentru sesiunea curentă și să
trimită o noua cerere de tip SETUP către serverul identificat de comanda
REDIRECT. Mesajul REDIRECT este întotdeauna trimis de la server către
client, suportul este opțional.
Metoda RECORD inițiază înregistrarea unei porțiuni multimedia specificate de
Request-URI. Această descriere putea fi făcută disponibilă printr-o metodă
anterioară ANNOUNCE. Cererea RECORD este trimisă de la client la server iar
implementarea sa este opțională atât pentru client cât și pentru server.
Metoda GET PARAMETER returneză valorile parametrilor unei prezentări.
Parametrii doriți sunt specificați în corpul mesajului, care poate servii ca un fel
de aplicație de PING pe RTSP. GET PARAMETER este o metodă opțională
care poate fi folosită în ambele sensuri, atât de la client la server cât și de la
server la client.
Metoda SET PARAMETER este folosită pentru setarea valorii unui parametru
dintr-o prezentare sau dintr-un stream identificat prin „Request-URI”. În cerere
poate fi specificat decât un singur parametru astfel încât în eventualitatea unui
eșec nu există ambiguități în privința cărui parametru nu este setat. Ca și în cazul
GET PARAMETER această metodă poate fi apelată în ambele sensuri iar
implementarea este opțională atât pentru server cât și pentru client.
3.2.2 Mesajele RTSP tip răspuns
Linia de status din fiecare mesaj de răspuns include un cod de status, specificând răspunsul la cerere. Un număr de trei cifre reprezintă fiecare cod de status. Mesajele de răspuns sunt clasificate în două categorii diferite: răspunsuri provizorii și răspunsuri finale. Toate codurile de status ale mesajelor de forma 1xx (de la 100 la 199) sunt considerate răspunsuri provizorii și indică că destinatarul procesează cererea, dar nu s-a luat acțiunea finală, deci cererea este considerată încă activă. Toate celelalte mesaje de status indică răspuns final. Există patru categorii: codurile de status de forma 2xx indică o procesare cu succes a cererii, codurile de forma 3xxx indică redirecționare, 4xx indică eroare de client și 5xx indică eroare de server.
Deși metoda, jetonul și codul de status sunt
folositoare în identificarea cererii și răspunsului, în cele
mai multe cazuri destinatarul unui mesaj, nu poate
determina adevărata natură a unui task care trebuie
executat după o cerere sau înțelesul complet al unui
răspuns fără a se uita la celelalte headeruri incluse în
mesajului; uneori corpul unui mesaj trebuie interpretat
înainte ca mesajul să fie total înțeles de către destinatar.
3.2.3 Setarea unui sesiuni folosind RTSP
Figura 3.2 arată interacțiunea normală dintre un client
RTSP și un server RTSP pentru stabilirea unei sessiuni.
Figura 3.2 Caz de interacțiune între serverul RTSP și clientul RTSP
30
Odată ce clientul ia cunoștiință de anumite resurse RTSP, în acest caz „rtsp://resource-
name.server” trimite o cerere de tip DESCRIBE către server pentru a căpăta mai multe informații despre această resursă. Serverul trimite înapoi descrierea unei sesiuni corespunzătoare resursei identificate. Dacă clientul este interesat, trimite o cerere de SETUP, cerând serverului să facă modificările necesare pentru stabilirea unei sesiuni. În caz de succes, clientul poate iniția o cerere de tip PLAY pentru a începe transferul streamului media. Dacă sesiunea necesită o configurație QoS specială, de genul rezervării de resurse, clientul execută aceste configurații înainte să formuleze cererea. Dacă cererea PLAY se execută cu succes, conținutul media începe să fie transferat. Clientul poate manipula acest stream utilizând diferite cereri RTSP.
Odată ce sesiunea este completă sau clientul își pierde interesul de a mai participa, acesta trimite o cerere de tip TEARDOWN pentru terminare sesunii.
3.3 Session Description Protocol (SDP)
Protocolul SDP este foarte folosit pentru descriere de sesiuni și prezentări. Acest protocol este specificat în standardul IETF RFC 2327. SDP oferă un format bine definit care conține suficientă informație despre sesiunea multimedia pentru a permite destinatarilor din descrierea sesiunii să participe la aceasta. Informația este facută publică cu ajutorul protocolului SAP care anunță o sesiune multimedia prin transmiterea periodică a unui pachet anunț la o bine cunoscută adresă multicast. Alternativ sesiunea multimedia poate fi anunțată prin email sau pe WWW .
SDP anunță următoarele informații:
Numele sesiunii și scopul
Media conținută în sesiune
o Tipul media (video, audio)
o Protocolul de transport (RTP/UDP/IP) o Formatul media (MPEG4, H.261) o Adrese și numere de port
Numărul de ori în care sesiunea este activă
Descrierea sesiunii folosind SDP constă într-o serie de linii de text. Fiecare linie este de
forma „<type>=<value>”. <type> este reprezentat de un singur caracter. <value> este în
general un număr de cămpuri delimitate de către un singur spațiu sau un string neformatat.
O descriere de sesiune tipică utilizând SDP are trei părți:
Session Description: Această parte descrie sesiunea și oferă informații despre
aparținătorii acesteia. Tipurile obligatorii incluse în această parte sunt: version
(v), owner (o) și session name (s) , alte câmpuri opționale includ session
information (i), URI (u), adresă de email (e), număr de telefon (p), connection
information (c), bandwith (b), setări timezone (z), chei de encriptare (k), și
linia de atribute cu câmp type (a).
Timing Information: Această parte are un singur câmp obligatoriu (t) care
indică momentul în care sesiunea devine activă. Partea poate include opțional
mai multe timpuri de repetare (r).
Media Description: Această parte descrie tipul și restul parametrilor pentru
streamurile media. Este inclusă o linie obligatorie pentru fiecare stream în care
este salvată numele și adresa de transport; această linie este precedată de „m.”.
Adițional liniile opționale pentru fiecare stream includ: media title (i),
connection information (c), bandwith information (b), cheie de encriptare (k),
și zero sau mai multe linii atribut fiecare începând cu „a.”. Dacă toate
31
streamurile media împart o adresă de conectare comună, ea poate fi menționată o singură dată în partea de descriere media.
Figura 3.3 ilustreză părți din descrierea unei sesiuni cu SDP utilizând un exemplu luat direct din RFC 2327.
Figura 3.3 Descrierea unei sesiuni cu Session Description, Timming Information și
Media Description
3.4 SIP
Atunci când VoIP a fost implementat, existau multe probleme de rezolvat în susținerea comunicațiilor de voce într-un mediu dezvoltat în principal pentru date. Provocarea venea tocmai din diferența între date și voce.
Într-un mediu orientat pe date, transportul nu trebuie să fie real time și nu este neapărat
necesară confirmarea de primire a datelor. Un exemplu în acest sens îl constituie un server de
mail care nu poate trimite imediat un anumit email, fiind nevoit să îl stocheze local o
perioadă de timp până ce acest lucru este posibil. Un alt exemplu concludent îl reprezintă un
client de instant messenger a cărui întârziere în trimiterea mesajelor este acceptabilă.
3.4.1 Mesajele și formatele SIP
Întârzierile în trimiterea de pachete voce nu este aceeptabilă deoarece duce la mari perioade de liniște între cei doi participanți pe perioada legăturii.
Din acest motiv IETF a început proiectarea unui protocol special pentru controlul
comunicațiilor multimedia în timp real. Intenția a fost să construiască un protocol de control,
bazat pe sesiune, capabil să suporte toate tipurile de conexiune, fără să țină cont de tipul
media.
Au existat diferite versiuni de protocoale de control al apelurilor, dezvoltate în acest scop, încă de la VoIP. SIP a devenit favorit datorită posibilității sale de a suporta majoritatea tipurilor media.
SIP este derivat din HTTP. Există multe proprietăți ale acestuia care sunt foarte
asemănătoare cu cele ale HTTP. Este pe bază de text, caracteristică ce îl face mult mai ușor
de înțeles decât majoritatea protocoalelor orientate pe bit. Există anumite aspecte ale SIP care sunt derivate din SMTP.
32
Este foarte important de înțeles că o entitate SIP nu este un lucru „fizic”. Entitățile SIP
sunt logice. Într-adevăr, o entitate fizică, cum este un server suportă mai multe entități de tip
logic.
Fiecare gazdă SIP din rețea trebuie să fie capabilă de procesarea mesajelor SIP în etape
denumite layere. Nu toate gazdele SIP sunt capabile de procesare tuturor layerelor, însă e
obligatoriu să le poată procesa pe primele două. Layerele SIP sunt împărțite după cum
urmează:
Sintaxă și procesare
Layer de transport
Layer de tranzacții
User de tranzacții
Sintaxă și procesare este layerul de bază în SIP, foarte important pentru înțelegerea și procesarea oricărui mesaj SIP.
Funcția de transport este un proces de bază în fiecare gazdă care are nevoie să creeze un mesaj și de a-l trimite peste rețea către altă gazdă. Toate gazdele SIP au un protocol de transport. Prin acest protocol se definește modul în care se efectuează transmisia între două gazde cu ajutorul TCP și SCTP. În momentul în care s-a stabilit o conexiune între două calculatoare, layerul de transport crează un index către conexiune utilizând adresa de IP, numărul de port și protocolul de transport.
În momentul în care conexiunea este stabilită, indexul este format din IP destinatarului, portul și protocolul de transport. Când layerul de transport acceptă o conexiune, el este alcătuit din IP-ul sursei, portul și protocolul de transfer.
O trazacție este definită drept o cerere trimisă de către un client SIP către un server utilizând un transport layer. Layerul de tranzacții este responsabil pentru starea retransmisiilor, corelarea răspunsurilor cu cererile echivalente, și timeout-uri.
Toate gazde SIP care crează tranzacții SIP sunt considerate gazde de tranzacții. Acestea
sunt capabile de crearea mesajelor de tip INVITE precum și de anularea anumitor tranzacții.
Orice comunicare într-o rețea necesită o tranzacție. O tranzacție nu este același lucru cu
un dialog. Un dialog este stabilit doar după ce o secvență de tranzacții a fost realizată
3.4.2 Cererile de tip SIP
O cerere este trimisă de la un client SIP către un server. Formatul de cerere conține o linie de start cu următoarele informații:
METHOD (space) REQUEST URI (space) SIP VERSION (crlf)
Câmpul METHOD identifică tipul de cerere care este trimis. Există o serie de metode suportate. Există și alte metode definite de diverși producători însă cele de bază sunt următoarele:
REGISTER utilizată pentru a înregistra un utilizator. INVITE utilizată pentru a invita un user la o sesiune. ACK confirmarea cererii de stabilire a unei sesiuni. CANCEL anulează o tranzacție.
BYE terminarea unei sesiuni sau a unei tranzacții.
OPTIONS interogheză serverul pentru a îi afla capabilitățile.
INFO utilizat pentru a tranzacționa informații în timpul unei convorbiri.
MESSAGE utilizat pentru suportul serviciilor cu mesaje scurte sau instant
messaging.
33
NOTIFY utilizat pentru a notifica entitățile abonate asupra noutăților din lista de
abonați.
SUBSCRIBE utilizat pentru a se abona la notificările de evenimente.
UDATE permite unui dispozitiv să updateze informațiile de sesiune în timpul
acesteia fără retrimiterea unei invitații.
Adresele în rețelele SIP se numesc Universal Resource Identifiers (URI). Directiva REQUEST-URI este folosită pentru a routa mesajele SIP în rețea, deci conține adresa următoarei gazde.
Ultima directivă din mesaj este SIP VERSION care reprezintă versiunea de SIP care rulează.
O linie tipică de start într-o cerere arată în felul următor:
INVITE sip:[anonimizat] SIP/2.0
După linia de start într-o cerere sunt headerele mesajului, un carriage return (CRLF), și un corp opțional al mesajului.
Există cereri care sunt specifice anumitor tipuri de sesiuni. Un bun exemplu îl constituie metoda MESSAGE, care conține un mesaj text. Nu este nevoie de nici o sesiune sau dialog deoarece conținutul este oferit în corpul mesajului. Destinatarul poate alege să accepte mesajul sau să nu răspundă.
3.4.3 Răspunsurile de tip SIP
Răspunsurile sunt trimise de către un server SIP către un client ca un răspuns la o
cerere. Răspunsurile sunt identificate de către destinatar cu ajutorul liniei de status, care este
formată diferit de liniile de start a cererilor. Linie de starea a răspunsului conține următoarele
informații:
SIP VERSION (space) STATUS CODE (space) REASON PHRASE
(crlf)
STATUS CODE este un cod numeric utilizat de către receptor pentru a identifica statusul unei cereri. Este un cod de trei cifre urmat de către un câmp text care descrie partea numerică a codului.
Codurile de status sunt definite în funcție de clase, prima cifra indică clasa codului. Există deocamdată șase clase definite:
1xx Provisional
2xx Success
3xx Redirection
4xx Client error
5xx Server error
6xx Global Failure
Există procese care sunt asociate cu fiecare dintre aceste clase. Clasa Provisional indică recepția unei cereri care este în curs de procesare. Acesta este un răspuns normal la o cerere, servind ca o confirmare. Scopul este de a preveni retransmisia unei cereri
Clasa Success indică procesarea cererii și ducerea acțiunii la bun sfârșit.
Redirection este trimis în momentul în care o sesiune este redirecționată către altă adresă pentru același abonat. De exemplu o cerere poate fi trimisă la adresa unui abonat, dar abonatul și-a setat serviciile să redirecționeze mesajele către alt dispozitiv. Răspunsul redirection va indica motivul pentru redirecționare și va oferi detalii adiționale despre locația unde este redirecționat mesajul.
34
Client Error indică faptul că clientul a trimis o cerere cu sintaxă eronată sau alt tip de eroare, iar serverul SIP nu este capabil să proceseze eroarea.
Codul de stare Server error indică o eroare la destinatarul mesajului, sau a serverului SIP. Cererea în sine a fost validă însă din motivul indicat în mesajul de eroare, serverul nu a fost capabil să proceseze cererea.
În final, Global failure indică imposibilitatea procesării cererii de către oricare server
SIP.
3.4.4 Headerele SIP
Câmpurile header conțin informații detaliate despre cereri sau răspunsuri, aceasta incluzând adresa de origine și destinație a unei cereri precum și informații de routare. Câmpul header utilizează următoarea formă:
header name: header value
Pot exista spații între numele headerului și valoarea sa; totuși standardul nu încurajează în nici un fel folosirea de astfel de spații albe, recomandând totuși existența unui singur spațiu alb între cele două.
Pot exista mai multe apariții ale aceluiași nume de header într-o singură cerere, ca în cazul instrucțiunii ROUTE. În momentul în care aceasta apare de mai multe ori, ordinea nu este specifică, dar este recomandat ca routarea să fie trecută la începutul cererii astfel încât routerele și proxiurile de pe rețea să poată interpreta aceste mesaje repede.
Ideea este că deși standardul recomandă o anumită ordine, aceasta nu este neapărat obligatorie. Entitățile receptoare ar trebui să poată interpreta aceste mesaje chiar dacă ordinea este mixtă.
Conținuturile câmpurilor header nu sunt case sensitive. Excepția de la aceasă regulă este
când valoare este parte a unei „citații”. Acesta este cazul în care un text trebuie afișat pe
ecranul receptorului. În acest caz textul este arătat exact cum a fost găsit în câmpul header.
Există două clasificări ale câmpului header: câmp header pentru cerere și câmp header pentru răspuns. De exemplu anumite cîmpuri header au sens într-o cerere.
Câmpurile header pot fi reprezetate atât în formă lungă, cât și în formă abreviată. RFC a
definit variante abreviate a fiecărui câmp header pentru utilizare în momentul în care lărgimea de bandă este o problemă.
O descriere detaliată a fiecarui câmp header o puteți găsi în lucrarea SESSION INITIATION PROTOCOL (SIP) Controlling Convergent Networks
3.5 Session Announcement Protocol (SAP)
Pentru a asista la distribuirea informațiilor despre conferințele multimedia sau alte sesiuni multicast, și pentru a comunica informațiile relevante despre setarea sesiunilor, a fost necesar un director al sesiunii. O instanță a unui asemenea director al sesiunii transmite permanent pachete multicast care ajung la potențialii clienți.
SAP definește un protocol de anunțare pentru a fi utilizat de către clienții din directorul sesiunii. Sesiunile sunt descrise utilizând protocolul SDP. Descrierea sesiunii reprezintă tipul de date transferate de către SAP (pachetele SAP ca în figură 3.4).
35
Figura 3.4 Formatul pachetelor SAP
3.5.1 Anunțarea și ștergerea unei sesiuni SAP
Anunțarea cu ajutorul protocolului SAP implică trimiterea periodică de pachete la o adresă și un port bine cunoscute.
Un anunț SAP este multicast având același scop ca și sesiunea pe care o anunță, astfel încât destinatarii anunțului să fie eventuali destinatari și ai sesiunii pe care o anunță. Anunțurile SAP sunt făcute în general pe adresa 224.2.127.254.
Intervalul de anunțare este ales astfel încât toată lărgimea de bandă folosită de către
toate anunțurile unui singur grup SAP rămâne sub o limită preconfigurată. Intervalul de bază
dintre anunțuri este derivat din numărul de anunțuri făcute în acel grup, mărimea anunțului și
lărgimea de bandă preconfigurată. Sesiunile care au făcut anunțuri anterior pot fi șterse de
către time-out-ul implicit sau prin ștergerea explicită. Descrierea sesiunii conține informații
legate de momentul de timp în care a fost creată sesiunea și momentul de timp în care aceasta
va fi stearsă. Pachetul de ștergere specifică versiunea sesiunii care va fi ștearsă.
Pachetele de anunț și de ștergere sunt indicate de către câmpul ce speficică tipul mesajului.
3.5.2 Formatul pachetului SAP
Pachetul SAP conține următoarele informații:
V: Version Number – Câmpul Version Number trebuie setat la 1.
A: Address Type – Dacă bitul A este 0, câmpul Originating Source conține o
adresă Ipv4 pe 32 de biți. Dacă bitul A este 1, câmpul Originating Source
conține o adresă Ipv6 pe 128 de biți.
R: Reserved
T: Message Type – Câmpul T este 0 pentru un pachet de anunțare a sesiunii, T
este 1 pentru un pachet de ștergere a unei sesiuni.
E: Encryption bit – Este 1 dacă încăercătura de date a pachetului SAP este
encriptată. Este 0 dacă nu este encriptată.
C: Compressed bit – Este 1 dacă datele sunt compresate cu ajutorul unui
algoritm de compresie de tip zlib. Dacă pachetul trebuie compresat și encriptat,
compresia trebuie efectuată prima.
Auth len: Authentification length – Câmp de 8 biți ce specifică numărul de
cuvinte pe 32 de biți care urmeză după headerul SAP și care includ informațiile
de autentificare. Dacă este zero nu există header de autentificare.
36
Msg id hash: Message Identifier Hash – O cantitate pe 16 biți care foosită în
combinație cu sursa originală, oferă un identificator global unic indicând
versiunea precisă a acestui anunț.
Originating source – Acesta oferă adresa de IP a sursei originale a mesajului.
Dacă este un Ipv4 sau Ipv6 este indicat de către câmpul A.
Optional payload type – Câmpul payload type are conținut MIME care descrie
formatul coținutului
Payload – Dacă pachetul este un pachet de anunțare, încărcătura conține
descrierea unei sesiuni. Dacă pachetul este un pachet de ștergere al unei sesiuni.
Dacă tipul încărcăturii este „application/sdp” mesajul de ștergere este o singură
linie SDP care conține câmpul origine al anunțului ce trebuie șters. Dacă biții E
sau C sunt setați în header, atât tipul încărcăturii cât și încărcătura sunt
encriptate și/sau compresate.
După cum este indicat în formatul pachetului SAP, un anunț poate fi encriptat (setat E=1). Totuși dacă o mare parte din receptori nu au cheia de encriptare este o mare risipă de bandă având în vedere că nu pot accesa anunțul pe care l-au primit. Din acest motiv această opțiune cu anunțuri SAP encriptate este de ocolit
Headerul de autentificare poate fi folosit în două scopuri:
Verificarea care schimbă descrierea unei sesiuni sau ștergerea sa sunt permise Autentificarea creatorului sesiunii
SAP nu este legat de un anumit protocol de encriptare. Formatul precis a datelor de autentificare din pachet depinde de mecanismul de autentificare care este folosit. Protocolul SAP descrie utilizarea PrettyGoodPrivacy (PGP) și a Cryptographic Message Syntax (CMS) pentru autentificarea SAP.
3.6 Mică istorie a RTP
Standardul cheie pentru audio-video în rețelele IP îl constituie RTP împreună cu
profilurile asociate și formaturile de transfer. Scopul RTP este de a oferi servicii de transfer al
conținutului multimedia în timp real. Aceste servicii includ: timming recovery, detecția de
pierderi și corecția lor, identificarea sursei și a conținutului, feedback pentru calitatea
recepției, sincronizare media și managementul utilizatorilor. RTP a fost inițial proiectat
pentru utilizarea în conferințe multicast. De atunci s-a dovedit folositor într-o serie de alte
aplicații
RTP a fost dezvoltat de către grupul de lucru Audio-Video din cadru IETF și de atunci a fost adoptat de către IU pentru standardul H.323 și de către multe alte organizații dezvoltatoare de standarde.
Prima varianta de RTP a apărut în anul 1996. Pentru a fi complet RTP trebuie profilat pe un caz particular. Inițial a fost declarat un asemenea caz impreună cu specificațiile RTP. Momentan sunt în dezvoltare o serie de astfel de cazuri. Dacă sunt însoțite de specificațiile „formatelor de încarcare” ele descriu transportul unui format media particular.
3.7 RTP Data Transfer protocol
Partea de date a protocolului RTP este alcătuită dintr-un singur ADU (Aplication Data
Unit) care este folosit pentru transportul datelor de bază. Structura generală a unei ADU este
prezentată în figura 3.5. Primii doi biți identifică versiunea protocolului (V). Această
informație este urmată de un bit de umplere (P), care poate fi setat „1” în cazul în care mai
există încă un bit de umplere la terminarea pachetului. Acești biți de umplere pot fi necesari
37
anumitor algoritmi de encriptare. Prezența extensiei unui header experimental este semnalată de bit-ul (x).
Pentru a putea identifica emițătorul, un ADU RTP conține o sursă de sincronizare pe 32 de biți (SSRC). Adresa de transport a pachetului în care este conținut ADU-ul nu este suficientă pentru identificare emițătorului inițial având în vedere că pachetul poate fi routat de către sisteme intermediare. Identificatorul SSRC este ales la întâmplare de către fiecare participant cu intenția de a fi unic în sesiune.
Standardul RTP suportă direct prezența mixerelor. Un mixer combină între ele streamuri din mai multe surse într-un singur stream. Acest mecanism poate fi folosit pentru a economisi lărgime de bandă. Identificatorul SSRC a unui stream mixt va fi indentificatorul SSRC al mixerului. Adițional RTP oferă mecanismul de identificare pentru acei emițători care au contribuit la un stream mixt. Acest lucru este posibil prin utilizarea unui CSRC (Contribution Source). Acest câmp poate reține până la 31 identificatori SSRC care au contribuit la streamul produs de mixer. Counterul CSRC (CC) memorează numărul de identificatori CSRC prezenți în unitatea de date RTP.
Implementarea bitului marker (m) este definit în specificațiile saracinei utile pentru transmisia de date. În mod normal, marchează ADU importante, cum ar fi ultimul ADU dintrun singur frame video. După câmpul marker urmează tipul sarcinii utile (PT). Exemple de astfel de sarcini utile pot fi conținut video encodat după standardul H.261 sau conținut audio encodat pentru rețelele GSM.
Câmpul sequence number este incrementat la fiecare ADU trimis de un anumit emițător. El poate fi folosit de către receptori pentru a determina pierderile de pachete sau pentru a restaura ordinea orginală a acestora.
Câmpul timestamp, resprezintă momentul în timp în care conținutul ADU-ului a fost sondat. Valoarea inițială a acestuia este aleasă la întâmplare.
Figura 3.5 Structura unui ADU (Aplication Data Unit) în RTP
3.8 RTP Control Protocol
Protocolul RTP de transfer de date este folosit doar pentru transmiterea datelor utilizatorului, în mod normal prin multicast către toți utilizatorii sesiunii. Un protocol de control separat RTCP funcționează tot prin multicast pentru a oferi feedback de la toate sursele de date precum și de la toți participanții la sesiune. RTCP folosește același protocol de transport ca și RTP (de obicei UDP) dar un port diferit. Fiecare participant trimite periodic câte un pachet RTCP către toți participanții din sesiune. RFC 1889 definește patru funcții efectuate de către RTCP:
Quality of Service (QoS) și Congestion Control – RTCP oferă feedback
asupra calității distribuției de date. Deoarece pachetele RTCP sunt multicast, toți
38
membrii știu cât de bine se efectuează transferul pe fiecare client. Rapoartele expeditor permite receptorilor să calculeze ratele de transfer și calitatea transmisiei. Rapoartele de recepție indică problemele întâlnite de către receptori sau întârzieri excesive.
Identification – Pachetele RTCP cară o descriere textuală persistentă a sursei
RTCP. Aceasta oferă mai multe date despre sursa pachetelor de date decât
identificatorul SSRC și îi permite unui utilizator să asocieze streamuri multiple
din sesiuni diferite.
Estimarea mărimii sesiunii și scalare – Pentru a executa primele două funcții
fiecare utilizator trebuie să trimită periodic pachete RTCP. Rata de transmitere a
unor asemenea pachete trebuie adaptată pe măsură ce numărul de participanți
crește. Într-o sesiune cu puțini participanți, pachetele RTCP sunt trimise cu o
rată maximă de unu la cinci secunde. Obiectivul este limitarea traficului dedicat
RTCP la maxim 5% din traficul total.
Session Control – RTCP oferă opțional informații despre controlul sesiunii
minimale.
O transmisie RTCP este alcătuită dintr-un număr de pachete RTCP separate, încadrate într-o datagramă UDP
Conform RFC 1889 tipurile de pachete sunt următoarele:
Sender Report (SR)
Receiver Report (RR)
Source Description (SDES)
Goodbye (BYE)
Specifice aplicației
În figura 3.6 este prezentat formatul general al unui pachet RTCP.
Figura 3.6 Formatul general al unui pachet RTCP
Descrierea câmpurilor unui pachet RTCP este următoarea:
Version (V) – Câmp de 2 biți care stocheză versiunea curentă (în acest caz
versiunea este 2).
Padding (P) – Câmp de 1 bit, dacă este setat înseamnă că pachetul conține octeți
de umplere la sfârșitul informației de control.
Count (RC) – Câmp de 5 biți care indică numărul blocurilor de raport recepție
conținute într-un pachet RR sau SR, sau numărul de elemente sursă conținute
într-un pachet SDES sau BYE.
Packet Type (PT) – Câmp pe 8 biți care identifică tipul pachetului RTCP
Length (L) – Câmp pe 16 biți, lungimea acestui pachet în cuvinte de 32 de biți,
minus unu.
39
CAPITOLUL 4 – TEHNOLOGII MULTIMEDIA ÎN DEZVOLTARE
4.1 IP TV
IPTV reprezintă transmisie TV de înaltă calitate pe o rețea broadband. În general acesta
este privit ca protocolul de transmisie a televiziuni tradiționale, filmelor și video on demand
peste o rețea privată. Din perspectiva utilizatorului aceasta arată exact ca un serviciu TV
contra cost. Definiția oficială aprobată de către ITU este următoarea: „IPTV este definit ca
serviciu multimedia precum televiziune/video/text/conținut grafic/date trimise peste rețele de
tip IP”. Tipul de servicii oferite în dezvoltarea IPTV se extinde de la cablu și televiziune prin
satelit până la companii foarte mari de telefonie și operatori de rețele private în diferite părți
ale lumii.
IPTV oferă un număr de opțiuni:
Suport pentru TV interactiv – Capacitățile pe două căi ale IPTV oferă
providerilor posibilitatea să ofere o întreagă gamă de aplicații TV interactive.
Tipuri de servicii oferite prin IPTV includ TV live, high definition TV
(HDTV), jocuri interactive și browsing de Internet de mare viteză.
Time shifting – IPTV în combinație cu un recorder video digital permite
decalarea de timp sau programarea conținutului – un mecanism pentru
înregistrarea și stocarea conținutului video pentru vizionare decalată.
Personalization – Un sistem IPTV end-to-end suportă comunicații
bidirecționale și permite utilizatorilor de rând să-și personalizeze obiceiurile
legate de TV prin oferirea opțiunii de a vedea conținutul cum și când vor.
Necesar redus de lărgime de bandă – În loc de a oferii fiecare canal către
fiecare utilizator de rând, tehnologia IPTV permite providerului să ofere decât
canalele care le-a solicitat utilizatorul. Această opțiunea atractivă permite
conservarea de bandă.
Accesibil pe mai multe dispozitive – Vizionarea conținutului IPTV nu este
limitat decât la televiziuni. De multe ori consumatorii folosesc PC-urile
personale sau alte dispozitive mobile pentru a viziona conținut IPTV.
4.2 Diferențe între IPTV și INTERNET TV
IPTV este uneori confundat cu Internet TV. Deși amândouă serviciile se bazează pe
același nucleu de tehnologii, abordările în transferul de conținut TV diferă în următoarele
moduri:
Platforme diferite: Rețelele deținute de către operatorii de telefonie nu sunt
accesibile utilizatorilor de Internet și sunt localizate în locații geografice fixe.
Internetul din acest punct de vedere nu are nici o limitare geografică.
Controlul asupra infrastructurii de rețele: Când conținutul este trimis peste
Internet anumite pachete care au conținut media pot fi întârziate sau pierdute,
pe parcursul rețelelor care formează Internetul. Ca un rezultat, providerii de
televiziune pe Internet nu pot garanta o experiență media comparabilă cu cea a
rețelelor terestre de cablu sau a televiziunii pe Internet. În general IPTV este
oferit de către companiile care dețin infrastructura rețelelor de transmisie.
Mecanismul de acces: Tipul de conținut care este vizionat de pe Internet impuse
tipul software-ului care trebuie instalat pe PC pentru a permite vizualizarea.
40
Pentru suportul acestui mecanism este necesar și un DRM (Digital Rights Management).
Costurile: O cantitate destul de semnificativă din conținutul video distribuit pe
Internet este gratuită. Structura de cost introdusă de companiile ce oferă IPTV
este asemănătoare cu abonamentul lunar plătit către companiile de cablu. Mulți
analiști se așteaptă în viitor ca IPTV și Internet TV să conveargă într-un
aplicație mainstream.
4.3 Privire de ansamblu asupra infrastructurii IPTV
Figura 4.1 arată necesitățile funcționale de nivel înalt ale unui sistem IPTV end-to-end.
Figura 4.1 Necesitățile funcționale de nivel înalt pentru un sistem IPTV
end-to-end
4.3.1 IPTV Data center
IPTV Data Center primește conținut de la o varietate de surse incluzând video local, canale de cablu sau de satelit. Odată recepționate, un număr de componente hardware diferite variind de la encodere și servere video până la routere IP și hardware dedicat pentru securitate sunt utilizate pentru a pregăti conținutul video spre trimitere pe o rețea IP. Adițional, un sistem de management al abonaților este necesar pentru a stoca profilurile și facturile acestora.
4.3.2 Rețeaua de distribuție broadband
Transmiterea serviciilor IPTV necesită o conexiune unu la unu. În cazul unei dezvoltări IPTV serioase, numărul de conexiuni unu la unu crește semnificativ și cererile în materie de lărgime de bandă pot devenii destul de mari. Progresul în tehnologiile de rețea a permis providerilor să-și acopere cererile pentru necesarul de rețele cu bandă largă. Serviciu hibrid de cablu coaxial și fibră pentru transferul TV și telecomunicațiile bazate pe fibră sunt potrivite pentru transmiterea conținutului IPTV
4.3.3 IPTVCD (IPTV Consumer Device)
IPTVCD sunt componente cheie în permiterea oamenilor să acceseze serviciile IPTV.
IPTVCD se conectează la rețeaua broadband și este responsabil pentru decodarea și
procesarea streamului video de intrare. Aceste dispozitive oferă tehnolologii avansate care
elimină virtual problemele cauzate de traficul pe rețea. Având în vedere ca rețelele de tip
41
broadband nu mai sunt o noutate, funcționalitatea IPTVCD a început să se dezvolte către standarde din ce în ce mai sofisticate.
4.3.4 Rețele locale
O rețea locală leagă un număr de dispozitive digitale dintr-o arie geografică destul de restrânsă. Îmbunătățește comunicarea și permite împărțirea de resurse digitale destul de scumpe între membrii unei familii. Scopul unei rețele locale este să ofere acces la informație precum voce, audio, date și enterteinment, între dispozitivele digitale din casă. Cu rețea locală, consumatorii pot economisii bani și timp deoarece perifericele de tip inprimantă sau scaner, precum și conexiunea la Internet pot fi ușor utilizate la comun.
4.4 Codare în timp real și transmisia IPTV
Odată cu convergența televiziuni, telefoniei și a Internetului, diverse tehnologii de
compresie joacă un rol din ce în ce mai important în dezvoltarea de noi produse sau servicii.
În acest subcapitol vor fi prezentate cele trei mari standarde de codare IPTV: MPEG-2,
H.246/AVC, și VC-1.
4.4.1 Introducere în codarea în timp real
Înainte de a discuta de codarea unui conținut video, este esențial să înțelegem cele două
procese care au loc înainte ca conținutul video să ajungă în etapa de codare. Primul proces
este relativ simplu și implică o cameră care să capteze conținutul video. Odată captat, care
este de obicei în format analog, conținutul video trebuie să treacă printr-un alt proces numit
digitalizare pentru a convertii un semnal continuu analog într-o serie de biți. Un convertor
analog-digital este folosit pentru executarea procesului de convertire. Eșantionarea și
cuantificarea sunt aplicate în timpul procesării semnalului. Rata de eșantionare este de obicei
măsurată în baza pe secundă. Cuantificarea este a doua parte a procesului care implica
asignarea unui număr de biți pentru fiecare sample luat din semnal. Odată trecut în format
digital streamul video este gata pentru codare. Procesul de codare într-un IPTV Data Center
are loc în trei pași:
Un stream video este recepționat de la o anumită sursă. Formatul acestui stream
poate varia de la calitate foarte proastă în regim analog până la calitate foarte
bună în regim digital
Odată recepționat, encoderul aplică o schemă de compresie particulară
După compresie conținutul video este gata pentru transmisie. Prepararea
înseamnă împachetarea conținutului în pachete de date. Există o serie de
abordări care implică încapsularea conținutului video.
Codarea unui conținut video pentru o rețea IPTV are numeroase avantaje și dezavantaje. Principalele avantaje ale tehnologiei sunt următoarele:
Reducerea de spațiu pe hard disk necesar pentru stocarea fișierelor video.
Procesarea unui video necompresat necesită o foarte mare putere de calcul.
Aplicarea tehnicilor de compresie pe o bucată de conținut video reduce foarte
mult numărul de instrucțiuni pe procesor necesare pentru procesarea și
rendarea unui cadru.
Având în vedere că un fișier compresat este mai mic ca mărime decăt unul
necompresat, timpul său de trimitere peste rețea este redus semnificativ.
42
Pentru transportul IPTV se pot folosii rețele broadband cu lărgime de bandă
redusă. De exemplu un stream encodat SDTV ocupă până la 1.5Mbps, în timp
ce un stream HDTV poate ocupa până la 8Mbps. Când sunt comparate cu
vechile tehnici de compresie care utilizau 3.5Mbps pentru SDTV și 20 sau
25Mbps pentru HDTV beneficiile noilor standarde de compresie sunt
notabile.
Există totuși și anumite dezavantaje prin utilizarea tehnologiilor de compresie:
Procesul de compresie și decompresie a unui semnal introduce întârzieri.
Având în vedere că anumite informații sunt aruncate în timpul compresiei,
calitatea imaginii va fi mai proastă decât cea a unui stream necompresat.
Trecerea unui semnal dintr-un tip de compresie în alt tip de compresie poate
afecta calitatea acestuia.
4.4.2 Metode de compresie
Compresia permite providerilor de IPTV să emită mai multe canale audio și video de calitate înaltă peste rețele broadband. Realizează acest obiective profitând de imperfecțiunile omului și exploatându-le cu ajutorul unor algoritmi. De exemplu ochiul uman nu poate detecta toate tiparele dintr-o imagine. Prin urmare compresia reduce dimensiunea prin scoaterea tuturor acestor zone. Nivelul de compresie aplicată unui conținut video se numește rată de compresie și este măsurată prin reprezentare numerică. De exemplu, o rată de compresie de 100:1 înseamnă că conținutul original a fost redus de 100 de ori. Metodele de compresie se împart în două categorii: lossless și lossy.
Compresia lossless permite unui IPTVCD să recreeze perfect imaginea originală pe un
ecran plus că nu se înregistrează nici o pierdere de calitate în timpul compresiei și transferului
de conținut. Acest lucru se întâlnește destul de rar pe rețelele IPTV pentru că toate tehnicile
de compresie introduc o anumită pierdere de calitate în timpul codării. Ca o concluzie,
algoritmii de compresie lossless sunt folosiți pentru compresia a pozelor statice și nu a live
video.
Multe dintre metodele de compresie utilizate pentru oferirea de IPTV intră în categoria metodelor lossy. În timpul execuției unei compresii lossy, o parte din materialul video este distrus. Totuși algoritmi lossy din zilele de azi sunt proiectați astfel încât doar o parte limitată din conținutul video să fie distrusă.
Cele mai populare și dominante compresii lossy oferite de către providerii de IPTV comerciali sunt MPEG și VC-1
4.4.2.1 Compresia MPEG
Tehnologia MPEG este un standard de compresie, care este larg folosit de către
sistemele TV terestre, prin cablu sau pe satelit. MPEG este un acronim de la Moving Picture
Expert Group și reprezintă o asociație industrială care a fost înfințată pentru a ajuta la
dezvolta tehnici de compresie potrivite pentru transmisii video. Grupul a fost original creat de
către ISO împreună cu International Engineering Consortium (IEC) pentru a lucra la
dezvoltarea de standarde de compresie audio-video. De la fondarea sa, grupul a produs o familie de standarde de compresie majore − MPEG-1, MPEG-2, MPEG-4 (părțile 2 și 10), MPEG-7, și MPEG-21.
În adiție la cele de sus, grupul de lucru MPEG a produs deasemenea specificații care definesc standarde de descriere a conținutului A/V, transmisie.
43
MPEG-1 a fost primul standard dezvoltat pentru compresie video. Scopul sau inițial a fost pentru a crearea CD-urilor video care erau foarte populare la acea vreme. MPEG-1 mai este folosit și în zilele de azi pentru sisteme de supraveghere cu camere.
MPEG-2 este cel mai predominant standard video în ziua de azi. Este folosit într-o largă
varietate de aplicații incluzând televiziune digitală și televiziune HDTV prin satelit.
Standardul suportă semnale standard NTSC și PAL la rezoluții maxime. Cu ajutorul său este
posibilă multiplexarea mai multor canale de audio și video făcând posibilă televiziunea prin
satelit. MPEG-2 deasemea suportă cinci canale audio (sunet surround) și standardul AAC.
Utilizarea standardului MPEG-2 pe rețele cu lărgime de bandă mai mică de 2.5Mb poate aduce o serie de probleme.
MPEG-4 a apărut în anul 2000, însă până la apariția AVC (Advance Video Coding) acesta nu aducea o îmbunătățire dramatică față de MPEG-2 în compresia stramurilor video în timp real. Acest standard are un număr de avantaje pe conținutul video generat pe calculator și s-a impus destul de categoric pe rețelele de streaming care funcționează pe protocolul IP (de exemplu QuickTime de la Apple a trecut integral pe această tehnologie).
MPEG-4 AVC este o realizare mai curentă a MPEG făcânduși apariția în anul 2004. Această tehnologie are potențialul să inlocuiască complet standardul MPEG-2. Potrivit unui studiu un decodor MPEG-4 va fi de 4 ori mai complex decât un decodor MPEG-2. Providerii de servicii vor trebui să evite anumite funcții mai complexe ale MPEG-4 și să folosească profilurile relativ mai simple.
Ca o concluzie MPEG-4 este o colecție nouă și atractivă de noi tehnologii care permit comprimarea a mai mult conținut video într-o anumită lărgime de bandă dată.
4.4.2.2 Compresia audio
Există trei layere de compresia audio MPEG și există un nou standard de compresia denumit Advance Audio Compresion (AAC). Toate aceste tipuri de compresie audio vor funcționa cu oricare tip de compresie video, cu excepția MPEG-1 care nu recunoaște standardul AAC.
MPEG audio Layer I este cel mai simplu sistem de compresie. Folosește 384 eșantioane de intrare pentru fiecare ciclu de compresie, care corespunde la 8 milisecunde de material audio utilizând o frecvență de eșantionare de 48kHz. Fiecare bandă este procesată separat, iar rezultatele sunt combinate pentru a forma materialul de ieșire. Layer I poate obține o rată de compresie de 4:1 care înseamnă că un fișier de mărimea 1.4Mb poate fi compresat într-un stream de 384kbps fără pierderi notabile de calitate.
MPEG audio Layer II utilizează mai multe eșantioane pentru fiecare ciclu de compresie,
1.152 mai exact. Aceasta corespunde la 24 de milisecunde de conținutul la o rată de samplare
de 48kHz. Aceasta permite frecvențelor să fie reproduse cu mai multă acuratețe. Eliminând
redundanțele de programare din MPEG Layer I acesta obține o rată de compresie de 8:1.
Acesta înseamnă că calitatea unui CD audio poate fi atinsă numai cu o rată de transfer de
192kbps.
MPEG audio Layer III folosește același număr de eșantioane ca Layer II , dar le folosește mult mai eficient. Layer III are un mod audio denumit joint stereo, care capitalizează puternicele similitudini dintre canalele dreapta și stânga ale unui program stereo. Folosește de asemenea codarea cu lungime variabilă (variable length coding) pentru a compresa mult mai eficient indicii audio în streamul de ieșire. Ca un rezultat, encoderele Layer III pot compresa material audio CD în streamuri cu rată de transfer de 128kbps, realizând un raport de copresie de 12:1.
44
MPEG AAC este disponibil doar împreună cu streamuri video MPEG-2 sau MPEG-4. Suportă până la 48 de canale audio incluzând și 5.1. Rezultate calitative foarte bune pe sunet surround pot fi obținute la o rată de transfer de 192kbps.
Dolby AC-3 Audio este cunoscut ca și Dolby Digital. Oferă o experiență audio de înaltă calitate cu caracteristici de compresie acceptabile și a fost aprobat pentru folosirea în DVDuri și în broadcasting-ul de televiziune digitală. Dolby AC-3 este utilizat în anumite versiuni de MPEG-4 și pe majoritatea canalelor de satelit.
Ca o concluzie, MPEG audio este flexibil și nu necesită nici pe departe puterea de procesare tipică formatelor MPEG video. Pe măsură ce numărul layerelor crește, complexitatea atât a softwareului de compresie cât și de decompresie crește, dar acest lucru este valabil și pentru raportul de compresie. Softwareul ce utilizează layer III funcționează fără probleme pe majoritatea computerelor din ziua de azi. Decompresoarele AAC nu sunt la fel de comune, probabil datorită complexității lor. Când se alege o metodă de compresie audio, trebuie ținut minte că lărgimea de bandă trebuie să fie suficient de mare pentru transmiterea atât a conținutului audio-video dar să mai rămână și suficient spațiu astfel încât aplicația să poată funcționa.
4.4.3 Microsoft Windows Media și VC-1
Windows Media Player are o lungă istorie de dezvoltare din partea Microsoft. Cu o versiune recentă Microsoft a făcut doi pași ciudați. Primul, Microsoft a dorit înghețarea dezvoltării decodorului pentru un număr de ani concentrându-se pe implementarea tehnologiei Windows Media pe o varietate de produse mai accesibile. Al doilea, Microsoft a câștigat aprobarea decodorului video ca un standard public denumit SMPTE 421M (cunoscut ca și VC-1) de la Society of Motion Pictures and Television Engineers.
Microsoft dorește să intre pe o secțiune din piața de compresie video cu tehnologia VC-
1. Compania a scos deja o serie de implementări ale acestei tehnologii de la streamuri cu rată de transfer redusă până la proiecția digitală a filmelor pentru cinema.
În adiție la tehnologia de codare video VC-1, Windows Media acoperă alte aspecte ale
pachetului complet incluzând codarea audio, formaturi de streamuri și DRM.
Diferențe notabile între VC-1 și MPEG-4 AVC nu există. O mare majoritate de
producători de codificatoare și decodificatoare își proiectează hardware-ul astfel încât să le
suporte pe amândouă prin folosirea de procesoare de semnal digitale (DSP) și prin
îmbunătățirea firmware-ului.
4.5 Emerging Multimedia Digital Video Broadcasting-Handheld (DVB-H)
Piața de dispozitive mobile a cunoscut în ultima vreme o creștere nemaiîntâlnită,
ajungând să posede tehnologia necesară pentru streaming video în timp real. Aceasta a ridicat
interesul pentru televiziune digitală și aplicații multimedia în timp real pe acest gen de
dispozitive ducând la apariția unor standarde comerciale. Unul dintre aceste standarde este
DVB-H.
Sistemul DVB-H poate fi precis definit ca un sistem de transmisie alcătuit dintr-o serie de alte standarde DVB cu scopul de a oferi servicii multimedia terestre pentru dispozitive mobile, principalul tip de date transmis fiind televiziune digitală. Standardul ETSI EN 302 304 definește un sistem DVB-H ca o combinație de tehnologii ale layerului fizic, layerului data link și informații despre servicii.
Pricipalele standarde care compun sistemul sunt:
ETSI EN 300 744 care este principalul standard DVB-T. DVB-H se bazează pe
DVB-T, în particular folosește layerul fizic pentru transmisie.
45
ETSI EN 301 192 definește standardul DVB de broadcast pentru date. Specifică
un număr de concepte folosite de câteva dacă nu de toate standardele DVB,
incluzând DVB-H.
ETSI EN 300 468 definește formatul serviciului de informații (SI) în sistemele
DVB-H.
La nivelul layerului fizic DVB-H utilizează elementele corespunzătoare ale DVB-T, cu un număr de extensii ce îl adaptează pentru dispozitive mobile. Standardele DVB-T și DVBH sunt compatibile acesta fiind un mare avantaj pentru DVB-H având în vedere că un număr destul de mare de rețele bazate pe DVB-T deja există implementate.
La nivelul layerului data link sunt transmise secțiuni MPE (Multi-Protocol
Encapsulation). Inovațiile majore aduse de DVB-H sunt la acest nivel.
Time slicing o metodă de transmisie de date cu consum de putere scăzut pentru
dispozitivele alimentate de baterii (sau acumulatori).
MPE-FEC care adaugă un nivel adițional de corecție a erorii înainte (FEC)
peste cel deja oferit de către DVB-T.
Deși cele descrise mai sus sunt suficiente pentru definirea întreagă a unui sistem după
standardul ETSI EN 302 304, DVB-H a fost proiectat din start să fie complet compatibil cu
rețelele de date. DVB-H poate servi ca layerul cel mai de bază al unui sistem bazat în
totalitate pe IP, cu condiția ca un număr de componente adiționale să fie specificate. Pentru a
îndeplini aceste cereri a fost introdusă DVB Internet Protocol Dtacast (DVB-IPDC)
4.6 Conceptul MBMS
În mod tradițional principalele conexiuni în rețelele mobile au fost bidirecționale pointto-point. Totuși beneficiile tipului de rețele pont-to-multipoint au fost notate și s-au făcut niște pași în această direcție odată cu apariția standardului 3GPP.
Odată cu apariția standardului 3GPP au fost definite două concepte p-t-m: cell
broadcast service (CBS) și IP multicast support. CBS permite transmisia serviciilor cu rată de transfer redusă către un set predefinit de celulare prin intermediul unui purtător p-t-m.
Datorită limitării ratei de transfer, CBS nu este potrivit pentru transmiterea datelor de
tip multimedia.
După cum spune și denumirea acestuia IP multicast support permite transmiterea de conținut multicast pe rețelele de tip IP utilizând tehnologia 3G. Spre deosebire de CBS, IP multicast support nu limitează tipurile de date ce pot fi transferate, dar permite transmiterea tuturor tipurilor de date care pot fi tranzitate pe rețelele IP. Marele dezavantaj al acestui concept este că în realitate datele sunt întotdeauna transmise prin intermediu rețelelor p-t-p. Din punct de vedere al consumului de resurse nu există diferențe majore între IP multicast și apelurile normal bazate pe pachete.
Pentru a trece peste aceste slabiciuni care există în serviciile p-t-m, 3GPP a lansat un proces de standardizare pentru un nou concept de serviciu. Multimedia boadcast/multicast service (MBMS) este un nou serviciu p-t-m care permite transmisia eficientă unidirecțională de tip p-t-m către abonații mobili. MBMS are două tipuri de operare: modul broadcast și modul multicast.
Utilizatorii trebuie să se aboneze pentru a li se oferi servicii multicast. Atunci când se
dorește pornirea recepției de date în cadrul serviciului, o cerere explicită trebuie trimisă
pentru alăturarea la rețea. Dinpotrivă, în modul broadcast datele serviciului sunt întotdeauna
trimise aria predefinită a rețelei fără cunoștiințe suplimentare despre prezența unor potențiali
receptori. În modul multicast datele pot fi trimise selectiv doar către celularele care conțin
receptori. Cu atât mai mult în modul multicast rapoartele de utilizare pot fi colectate de la
utilizatorii finali spre deosebire de modul broadcast în care acest lucru nu este posibil.
46
Din punct de vedere al standardizării MBMS este un produs al 3GPP versiunea 6.
Efortul de standardizare a MBMS a început în vara anului 2001 prin definirea necesităților
serviciului în SA1 (System Aspects 1). Progresul în alte grupuri de lucru au fost posibile
odată cu atingerea unei stări stabile în toamna anului 2002 prin SA2 (System Aspects 2). SA2
și-a luat responsabilitatea pentru arhitectura și funcționalitatea MBMS. Aspectele privind
securitatea MBMS, care stabilesc soluții în layerul IP sau mai sus au fost definite în SA3.
SA4 a avut responsabilitateta de a face înțeles modul în care MBMS lucrează cu codecuri.
Specificațiile 3GPP evoluează continuu și sunt îmbogățite cu noi tehnologii pentru a constant la curent cu cererea pieței.
4.6.1 Serviciile și aplicațiile MBMS
MBMS este primar un purtător p-t-m unidirecțional pentru pachetele IP ce funcționeză pe sistemele 3GPP. În esență MBMS nu oferă nici un serviciu de conținut dar pot fi folosite diferite tipuri de aplicații pentru a crea servicii noi.
Având în vedere că un purtător MBMS poate fi folosit pentru distribuire diferitelor tipuri de date, suportă și o gamă foarte mare de servicii.
Tipurile de sevicii multicast pot fi împărțite în două categorii: servicii disponibile în așa
zisele hotspot-uri sau servicii disponibile pe anumite zone de rețea mai largi. În amândouă
cazurile utilizatorii trebuie să se aboneze și să se alăture rețelei și informațiile de încarcare
pot fi colectate de la utilizatorii deja abonați. În cazul rețelelor mai largi datele sunt trimise
doar către acele celule de rețea în care abonații locuiesc. Un exemplu tipic al acestui tip de
serviciu, este serviciu de știri în care abonații primesc updateuri de știri pe telefoanele mobile
pe timpul unei zile.
În cazul hotspot un operator și-ar da seama că există prea mulți receptori într-un mediu de servicii în timpul aprovizionării serviciului. Deci datele sunt trimise către celulele din aria serviciului printr-o configurare p-t-m fără a se interesa de o cunoaștere explicită vis a vis de existența receptorilor.
Grupul de receptori poate fi o combinație de dispozitive active și pasive astfel încât o schimare exactă a hotspotului este de natură speficică operatorului sau serviciului. Un exemplu frecvent utilizat este scenariul stadionului de fotbal. Îm acest scenariu un serviciu este oferit spectatorilor pentru a primi reluări ale fazelor importante din meci și informații despre alte meciuri care au loc în același timp.
4.6.2 Arhitectura sistemului MBMS
Punctul de pornire în definirea arhitecturii MBMS a fost eficiența utilizării resurselorreceptori multipli ar trebui să împartă resurse de purtător oricând este posibil. Arhitectura de referință a MBMS este explicată în figura de mai jos.
Figura 4.2 Structura de
referință a MBMS
47
UE – Echipamentul utilizatorului (User Equipment)
UTRAN – Rețea de acces radio terestră (Universal Terrestrial Radio Acces Network) GERAN – Rețea radio de acces GMS/EDGE (GMS/EDGE Radio Acces Network) SGSN – Nod de suport GPRS (Serving GPRS Support Node)
GGSN – Nod de suport GPRS de tip gateway (Gateway GPRS support node)
BM-SC – Centru de serviciu broadcast/multicast (Broadcast/Multicast Service Center) BG – Gateway de margine (Border gateway)
MBMS introduce un nou element: centru de servicii broadcast/multicast (BM-SC). Acest nou element se așează între nucleul rețelei de pachete și furnizorii de conținut. Se comportă ca o sursă de date MBMS și efectuează anumite sarcini de control, de exemplu, inițierea sau terminarea transmisiei MBMS. Arhitectura MBMS face posibilă oferirea de conținut din surse de date fie ele interne sau externe către rețeaua operatorului. Nodul de suport de tip gateway și cele de tip GPRS, nucleul rețelei, efectuează sarcini de tunneling al pachetelor de la BM-SC către nodurile de acces radio potrivite (RAN). În plus, GGSN menține informații despre sesiunile în curs de desfășurare și execută procedurile de control, precum managementul mobilității. Pe partea RAN atât UTRAN și GERAN vor suporta MBMS. Este responsabilitatea acestora să selecteze cel mai eficient mecanism de transport a datelor MBMS către utilizatorii finali.
Alte componente de amintit care au legătură cu MBMS:
CBC care este folosit pentru anunțarea serviciilor MBMS către utilizatori.
SGSN poate utiliza CAMEL pentru a se ocupa de serviciile prepaid.
BM-SC poate utiliza OSA-SCS pentru a interacționa cu software-uri third party.
O posibilă realizarea a unei rețele 3G este prezentată în figura 4.3 incluzând și ierarhia diferitelor elemente de rețea într-un sistem 3GPP
Figura 4.3 Ierarhia diferitelor elemente ale unui sistem 3GPP
48
4.7 Internet multimedia subsystem (IMS)
În ziua de azi, tehnologia tradițională de comunicații scade în popularitate datorită
cererii cât mai mari de VoIP datorate faptului că dezvoltarea, mentenanța și operarea rețelelor
de date bazate pe protocolul IP este mult mai puțin costisitoare decât rețelele de voce
tradiționale. Pe de altă parte există o creștere importantă în conținutul multimedia aducând
împreună aplicațiile Internet cu telecomunicațiile. În concordanță cu aceste trenduri globale
universul comunicațiilor mobile a definit o rețea care să înglobeze rețelele mobile și
Internetul. Această rețea este denumită IMS (Internet multimedia subsystem).
IMS a fost proiectat pentru a oferi servicii atractive utilizând rețele mobile bazate pe protocolul IP și standarde cu accent pe QoS și oferă căi ușoare și eficiente de a integra diferite servicii. IMS gestionează politicile QoS orientate pe evenimente. Aceste sisteme au deasemenea un sistem de taxarea diferită a evenimentelelor. De exemplu dacă două evenimente au nevoie de resursele de la același IP ele pot fi taxate diferit pentru același utilizator din aceeși seasiune. Aceste caracteristici fac din IMS tehnologia de viitor într-o rețea orientată pe aplicații.
IMS a fost standardizat încă de la începutul acestui secol prin varianta 5 și extins în
varianta 6 cu 3GPP și 3GPP2 (care se axează pe tehnologia UMTS/CDMA2000).
Arhitectura IMS face posibilă stabilirea de legături peer-to-peer pe protocolul IP cu
toate tipurile de clienți care suportă QoS și funcționalități complete de transmitere a
serviciilor.
Varianta 6 a IMS repară deficiențele variantei 5 și oferă noi funcționalități ca serviciile de mesagerie, suport pentru conferințe, management de grup și servicii locale. Această variantă a optimizat IMS pentru a oferi aplicația push-to-talk avută în vedere. Standardul IMS a fost implementat pe rețelele 3G în anul 2006. El oferă funcționalități de securitate noi precum protecția identității mesajelor SIP, utilizarea infrastructurii cu chei publice și certificate pentru abonați.
4.7.1 Arhitectura IMS și componente cheie
IMS nu standardizează serviciile specifice dar folosește determinanți standard pentru servicii. În arhitectura IMS, protocolul SIP este utilizat ca protocol standard pentru semnalizarea care stabilește, controlează, modifică sau termină sesiunile video, de voce sau text între doi sau mai mulți participanți. Serverele de semnalizare din arhitectură sunt referențiate ca CSCF-uri (call state control functions) și se diferențiază prin funcționalitatea specifică. Este important de notat
că un sistem IMS compatibil end
user trebuie să ofere suportul
necesar pentru protocolul IMS,
protocolul SIP și codecurile
media care au legătură cu
serviciul împreună cu serviciu de
conectivitate adițional. Figura
4.4 prezintă o diagramă
funcțională IMS bazată pe IP.
Figura 4.3 Diagrama
funcțională generică a IMS
49
O mică descrierea a celor mai importante părți ale arhitecturii IMS:
Proxy Call state Control Function (P-CSCF) – Este primul punct de contact
în interiorul subsistemului din nucleul rețelei multimedia. Adresa sa a fost
descoperită de către activarea contextuală a protocolul de date al UE (PDP –
packet data protocol). P-CSCF se comportă ca un proxy acceptând cererile și
servindu-le intern sau le înaintează mai departe. Efectuează funcții precum
autorizarea resursele purtătorului pentru nivelul de QoS adecvat, apeluri de
urgență, monitorizare, decompresie sau compresie de headere și identificarea I-
CSCF.
Iterrogating Call State Control Function (I-CSCF) – Este punctul de contact
din interiorul rețeiei unui operator pentru toate conexiunile care au ca destinatar
un abonat al acelei rețele, sau un abonat care folosește roaming și care se află în
zona de acoperire a rețelei. Pot exista mai multe I-CSCF-uri în interiorul rețelei
unui operator. I-CSCF poate îndeplini funcții de atribuire a unui S-CSCF unui
utilizator care efectuează o înregistrare SIP și utilizarea de resurse.
Serving Call State Control Function (S-CSCF) – Execută servicii de control a
sesiunii pentru punctul terminal și menține starea sesiunii după cum este necesar
pentru operatorul rețelei pentru suportul de servicii. În interiorul unei rețele
diferite S-CSCF-uri pot avea funcționalități aparte. Funcțiile inportante
executate de către S-CSCF includ înregistrarea utilizatorilor, interacțiunea cu
platformele de servicii pentru susținerea acestora. S-CSCF-ul decide dacă un
server aplicație trebuie să primească informații legate de cererea unei sesiuni
SIP pentru a asigura anumite servicii. Decizia luată de către acest modul este
bazată pe informații de filtru recepționate de la HSS. Aceste informații de filtru
sunt stocate.
Home Subscriber Server – HSS este echivalentul lui HLR (home location
register) în sistemele 2G dar extins cu două puncte Diameter. Este baza de date
principală a unui sistem IMS care stochează profilurile IMS incluzând
informațiile de filtrarea individuale, informații despre starea utilizatorului, și
profilurile serverului aplicație.
Aplication Servers – Oferă platforma de servicii în mediul IMS. Se adresează
interfețelor de administrare (ISC și Sh), și oferă suport pentru protocoalele SIP
și Diameter. Aceasta permite dezvoltatorilor să folosească aproape orice
paradugmă în interiorul unui SIP AS precum CAMEL, servere/gateway-uri
OSA/Parlay, sau orice paradigmă de programare VoIP SIP precum servleturi
SIP, CPL și CGI. SPI AS este activat de către S-CSCF care redirecționează
anumite sesiuni.
50
CAPITOLUL 5 – TEHNOLOGII UTILIZATE
5.1 Java Media Frameworks
Fundamental, JMF este o extensie a Java care lucrează cu conținut audio-video. Mai riguros, API-ul JMF este un API Java opțional care extinde funcționalitatea nucleului Java. Incluse în acest grup de API-uri opționale, oferite gratuit de către Sun, mai sunt și Java 3D și Java Advance Imaging.
Documentația Sun pentru JMF 2.1.1 descrie JMF în felul următor: ”Java Media
Frameworks oferă o arhitectură unificată și protocol de comunicare pentru controlul achiziției, procesării și oferirea de conținut media bazate pe timp. JMF este proiectat pentru a suporta majoritatea conținutului media standard, precum AIFF, AU, AVI, GSM, MIDI, MPEG, QuickTime, RMF, și WAV”[19].
Printre calitățile cheie ale API-ului amintim:
Independența de platformă. Va rula oriunde există platforma Java. Lucru cu media audio și video integrat ca obiecte media.
Suport pentru majoritate de tipuri media audio și video și codecuri. Playback media.
Salvarea conținutului media.
Captarea media de la dispozitive de intrare gen camere web sau microfoane. Recepția și transmiterea de streamuri media.
Multiplexarea și demultiplexarea streamurilor. Salvarea în alt format.
Posibilitatea de extindere a funcționalității prin adăugarea de noi formate sau
plugin-uri.
Integrarea fără probleme cu API-urile deja existente
5.2 Tipuri media suportate de către JMF
JMF oferă suport pentru un număr foarte mare de date și formate multimedia. În
continuare două dintre cele mai importante formate care lipsesc din JMF sunt MPEG- 2 și
MPEG-4. Totuși este de așteptat să se introducă suport și pentru aceste două formate în
următoarea versiune de JMF. În aria protocoalelor JMF oferă sprijin pentru fișiere, http, ftp,
și rtp.
Există trei implementări ale JMF 2.1.1: cross platform versiunea Java pură (Cross),
varianta Solaris de performanță (Sol) și varianta Windows de performanță (Win). Diferă
foarte puțin în suportul de formate. Majoritatea formatelor suportate de către JMF pot fi atât
read (decoded) cât și write (encoded); totuși în anumite clase acest lucru nu este adevărat.
În tabelele următoare sunt trecute formatele audio și video suportate de către implementarea JMF 2.1.1.
Tipul Formatul
conținutului
AIFF (.aiff) 8-biți mono/stereo linear
16 biți mono/stereo linear
G.711 (U-law)
A-law
51
Decode/Read Encode/Write
Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win
IMA4 ADPCM Cross,Sol,Win Cross,Sol,Win
GSM (.gsm) GSM mono audio Cross,Sol,Win Cross,Sol,Win
MIDI (.mid) Tipul 1&2 midi Sol,Win
MPEG layer 2 MPEG layer 1&2 audio Cross,Sol,Win Sol,Win
audio (.mp2)
MPEG layer 3 MPEG layer 1&2&3 audio Cross,Sol,Win Sol,Win
audio (.mp3)
Sun Audio (.au) 8-biți mono/stereo linear Cross,Sol,Win Cross,Sol,Win
16 biți mono/stereo linear Cross,Sol,Win Cross,Sol,Win
G.711 (U-law) Cross,Sol,Win Cross,Sol,Win
A-law Cross,Sol,Win
Wave (.wav) 8 biți mono/stereo linear Cross,Sol,Win Cross,Sol,Win
16 biți mono/stereo linear Cross,Sol,Win Cross,Sol,Win
G.711 (U-law) Cross,Sol,Win Cross,Sol,Win
A-law Cross,Sol,Win
GSM mono Cross,Sol,Win Cross,Sol,Win
DVI ADPCM Cross,Sol,Win Cross,Sol,Win
MS ADPCM Cross,Sol,Win Cross,Sol,Win
ACM Win Win
Tabel cu formatele audio suportate de către JMF 2.1.1
Tipul Formatul Decode/Read Encode/Write
conținutului
AVI (.avi) Audio: 8biți mono/stereo linear Cross,Sol,Win Cross,Sol,Win
Audio: 16biți mono/stereo linear Cross,Sol,Win Cross,Sol,Win
Audio: DVI ADPCM compresat Cross,Sol,Win Cross,Sol,Win
Audio: G.711 (U-law) Cross,Sol,Win Cross,Sol,Win
Audio: A-law Cross,Sol,Win
Audio: GSM mono Cross,Sol,Win Cross,Sol,Win
Audio: ACM Win Win
Video: Cinepak Cross,Sol,Win Sol
Video: JPEG(411,422,111) Cross,Sol,Win Sol,Win
Video: RGB Cross,Sol,Win Cross,Sol,Win
Video: YUV Cross,Sol,Win Cross,Sol,Win
Video: VCM Win Win
Flash (.swf) Macromedia Flash 2 Cross,Sol,Win
HotMedia IBM HotMedia Cross,Sol,Win
(.mvr)
52
MPEG-1 Stream sistem multiplexat
video (.mpg)
Doar stream video
MPEG-4
video
QuickTime Audio: 8biți mono/stereo linear
(.mov)
Sol,Win
Sol,Win
Cross,Sol,Win Cross,Sol,Win
Cross,Sol,Win Cross,Sol,Win
Audio: 16biți mono/stereo linear Cross,Sol,Win Cross,Sol,Win
Audio: G.711 (U-law)
Audio: A-law
Audio: GSM mono
Audio: IMA4 ADCP
Video: Cinepak
Video: H.261
Video: H.263
Video: JPEG(411,422,111) Video: RGB
Cross,Sol,Win Cross,Sol,Win
Cross,Sol,Win
Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win Cross,Sol,Win Sol
Sol,Win
Cross,Sol,Win Sol,Win
Cross,Sol,Win Sol,Win
Cross,Sol,Win Cross,Sol,Win
Tabelul cu formatele video suportate de către JMF 2.1.1
Sunt disponibile un număr de interfețe pe care utilizatorii pot să le implementeze cu propriile clase. Suportul multiformat al JMF ar trebui să crească nu numai prin adăugările Sun cât și prin dezvoltările utilizatorilor individuali.
5.3 Structura API-ului
API-ul JMF este constituit din 209 clase, din care 85 sunt interfețe, divizate în 11 API-
uri.
În Java, API-urile servesc atât pentru clasele din același grup cât și pentru controlul vizibilității atributelor și metodelor din acele clase. Pentru a folosi o clasă membră a unui API specific, trebuie importată ea sau întreg API-ul.
Cele 11 API-uri care compun JMF, împreună cu domeniile lor sunt listate mai jos:
Javax.media – API-ul principal care conține majoritatea claselor printre care și
cele mai importante precum Time, Manager, Procesor și Player.
Javax.media.bean.playerbean – O colecție de șapte clase care oferă
încapsularea Java Bean pentru un player. Media Player este cea mai importantă clasă a acestui API.
Javax.media.control – Un API compus din 18 interfețe care definesc diferitele
tipuri de controale. Exemplele includ FrameRateControl și FormatControl.
Javax.media.datasink – Un API alcătuit din o interfață și 3 evenimente care
defineste un listener pentru evenimente datasink.
Javax.media.format – Un API important alcătuit din 10 clase (dintre care una
este o excepție) care definesc tipurile de formaturi pe care JMF le recunoaște. Exemple ale acestor clase includ AudioFormat și H263Format.
53
Javax.media.protocol – Un API important de 25 de clase (15 interfețe) oferind
suport pentru comunicarea cu sursele de date și dispozitivele de captare. Printre
clasele importante ale acestui API amintim Datasource și CaptureDevice.
Javax.media.renderer – Un API de două interfețe care definesc un renderer
(pentru conținutul video).
Javax.media.rtp – Nivelul de top al celor 3 API-uri care lucrează cu RTP.
Conține 26 de clase (majoritatea interfețe) care se ocupă cu conținutul
streamului.
Javax.media.rtp.event – Un API de 23 de evenimente care ar putea avea loc
când se lucrează cu RTP.
Javax.media.rtp.rtcp – Un API de 5 clase (dintre care 4 interfețe) care
definesc utilizarea RTCP în JMF.
Javax.media.util – Un API format din 2 clase de utilitate ridicată
BuffertoImage și ImagetoBuffer pentru convertirea între buffere JMF și imagini
AWT.
5.3.1 Clase cheie în JMF API
Deși fiecare clasă din API are un rol bine definit, unele sunt mai importante decât altele. Acestea sunt des întâlnite în programele Java și oferă suportul pentru dezvoltarea multimedia.
Printre cele mai importante dintre acestea trebuie amintite următoarele:
AudioFormat – Informații despre un format audio incluzând rată de eșantionare
și nivelul de cuantificare.
CaptureDevice – Interfață ce definește comportamentul pe care trebuie să-l aibă
toate dispozitivele de captare.
CaptureDeviceInfo – Informații despre un anumit dispozitiv de captare,
incluzând formatele suportate.
CaptureDeviceManager – Managerul care are informații de la toate
dispozitivele de captare de pe sistem și care este capabil să ofere informații
despre ele.
Clock – Interfață ce definește modelul de timp fundamental JMF. Clase cheie ca
Players și Procerors implementează această interfață.
Codec – Interfață ce suportă procesarea unor date media dintr-un format în altul.
Controller – Interfață construită pe Clock care definește cele cinci stări ale
timpului oprit
Controls – O interfață ce specifică modurile prin care se obține controlul unui
obiect.
Datasink – Interfață pentru acceptarea datelor și rendarea lor către anumite
surse cum ar fi un fișier.
DataSource – Clasă ce oferă un simplu protocol de control media venite de la o
anumită sursă.
Demultiplexer – Interfață ce definește o unitate de procesare care aceptă un
singur stream de intrare și returnează track-urile ce îl compun.
Effect – O interfață care definește o unitate de procesare ce acceptă un buffer de
date, îl procesează și îl returnează. Interfața Effect suportă multe tipuri de
procesare.
FileTypeDescriptor – Definește diferitele tipuri de conținut suportate.
Format – O abstractizare a formatului media fără detaliile de codare.
54
Manager – Manager central sau punct de acces pentru obținerea resurselor
precum Playere, Processore, DataSource-le, și DataSink-urile.
MediaEvent – O clasa parinte de evenimente pentru toate evenimentele media MediaLocator – Un mod de specificare a locației conținutului media. Este
folosit pentru crearea Playere-lor, DataSource-lor și a Datasink-urilor.
Multiplexer – O unitate de procesare care acceptă mai multe track-uri media și
le combină pentru a crea un stream.
Participant – Un participant la o sesiune RTP, emițător sau receptor.
Player – Un obiect pentru rularea sau controlul unui obiect media.
PlugIn – O interfață care definește un plug-in generic care procesează date
media într-o anumită factură.
Proccesor – O extensie la interfața Player, Proccesor definește un obiect capabil
de procesarea și controlul unui obiect media.
PullDataSource – O sursă media din care datele trebuie extrase (de exemplu un
fișier).
PushDataSource – O sursă media din care datele sunt transferate (de exemplu o
sesiune RTP).
Time – Un obiect care definește timpul cu o precizie de nanosecunde. TimeBase – O sursa de timp în continuă rulare.
5.4 Utilizarea JMF pentru streamuri RTP
Trei pachete din JMF se ocupă cu streamingul RTP. Acestea sunt:
Javax.media.rtp – Nivelul de top al celor trei pachete care se ocupă cu RTP.
Este compus din 26 de clase, majoritatea interfețe care se ocupă cu gestionarea
streamurilor RTP.
Javax.media.rtp.event – Un pachet de 23 de evenimente care pot rezulta în
timpul utilizării RTP.
Javax.media.rtp.rtcp – Un pachet de cinci clase (dintre care patru interfețe) ce
definesc utilizarea RTCP în cadru JMF.
Un aspect cheie în legătură cu clasele ce se ocupă de RTP îl constituie faptul că nu
afectează funcționalitatea de bază a JMF. Ele sunt privite ca o extensie a JMF-ului,
neintervenind în modul de lucru al claselor de bază gen Player, Processor, DataSource,
DataSink.
5.4.1 Formatele RTP din cadru JMF
Nu toate formatele oferite de către JMF sunt disponibile pe RTP. În acest caz opțiunile sunt mult mai limitate. JMF oferă patru standarde RTP specifice audio și trei standarde RTP specifice video.
Formatele audio:
ULAW_RTP
GSM_RTP
DVI_RTP
G723_RTP
Formatele video:
JPEG_RTP
H261_RTP
H263_RTP
55
După cu indică și numele, aceste formate folosesc aceleași standarde de compresie ca și variantele non-RTP.
5.4.2 Utilizarea claselor RTP din JMF
Există posibilitatea streamingului RTP fără a utiliza clasele specifice acestui standard însă această opțiune duce la o limitarea seriosă a funcționalității. Pe de altă parte utilizarea claselor specifice RTP oferă următoarele avantaje:
Control asupra sesiunilor, participanți și streamuri media. Monitorizarea (prin interfețe listener) a evenimentelor RTP. Strângerea și generarea de statistici.
În particular, primele două seturi de capabilități sunt foarte importante în contextul unei conferințe video în care participanți pot ajunge sau pleca la momente diferite de timp, pot aplica scheme diferite de codare, și pot avea conexiuni diferite din punct de vedere al lărgimii de bandă. Automatizarea controlului în aceste cazuri necesită un program care să se ocupe de toți acești parametri în timp real.
Clasa centrală într-o implementare pe protocolul RTP este RTPManager. Această clasă a fost introdusă în JMF 2.1.1 în locul SessionManager care a fost considerată depreciată. Această clasă este utilizată mai des în cazul în care avem două sau mai multe streamuri trimise pe același port.
RTPManager este o clasă abstractă. Inițializarea sa se face prin metoda statică newInstance(). Fiecare sesiune RTP are propriul obiect RTPManager.
Controlul unei sesiuni RTP în care transmisia se face utilizând RTPManager necesită
următorii pași:
1. Crearea unui obiect RTPManager
2. Inițializarea RTPManager cu adresa gazdei locale
3. Pentru toți utilizatorii la care se va trimite streamul
Crearea unei adrese destinatar de tipul SessionAddress
Adăugarea SessionAddress ca o destinație pentru RTPManager
4. Crearea unui SendStream prin intermediul RTPManager pentru DataSource-ul
ce trebuie trimis.
5. Setarea listenerelor
6. Pornirea SendStream
7. Când sesiunea se termină, se efectuează următorii pași
Ștergerea fiecărui destinatar din RTPManager
Dezactivarea RTPManager
Principalele metode din clasa
RTPManager sunt prezentate în figura
5.1.
Figura 5.1 Metodele din cadru clasei
RTPManager
56
Totuși RTPManager nu este singura clasă de relevantă pentru controlul sesiunilor RTP. Următoarea listă le sumarizează pe cele mai importante.
InetAddress – Reprezentarea JAVA a unei adrese de Internet. Parte a pachetului
java.net. Necesară pentru crearea adreselor de sesiune.
LocalParticipant – Participantul de pe calculatorul local.
Participant – O aplicație care recepționează sau trimite streamuri.
ReceiveStream – O interfață care reprezintă un stream de date recepționat în
interiorul unei sesiuni RTP.
Remote Listener – O interfață care poate fi implementată de către o clasă cu
scopul de a informa asupra evenimentelor generate de către participanți.
ReceiveStreamListener – O interfață care poate implementată de către o clasă cu
scopul de a informa asupra evenimentelor ce au legătură cu ReceiveStream.
RemoteParticipant – Un participant într-o sesiune RTP care nu este pe aceeași
gazdă cu RTPManager.
RTPControl – O interfață care permite controlul asupra unei DataSource RTP, în
sensul obținerii de date statistice despre sesiune.
RTPStream – Superclasă pentru SendStream și ReceiveStream.
5.5 Utilizarea JMF în conjuncție cu alte API-uri
JMF este un API puternic care suportă procesarea conținutului media dinamic la un nivel înalt. O calitate poate la fel de importantă este că face parte dintr-o platformă Java mult mai mare. Avantajul acestei calități este posibilitatea de combinare cu alte posibilități oferite de mediu de dezvoltare Java.
Un exemplu ar putea fi o aplicație a viitorului, un software pentru conferințe audio-
video în care participanții vorbesc limbi diferite. O asemenea aplicație ar folosi JMF în
conjuncție cu Java 3D, JAI și alte API-uri precum Java Speech. Pistele audio ar fi extrase din
stream și analizate de către bibliotecile de recunoaștere a limbajului, după procesare fiind
prezentate ca subtitrari sau prin reconstrucție cu ajutorul unui sintetizator de voce.
Aplicațiile care folosesc JMF în conjuncție cu alte API-uri se împart în două categorii de bază. Forma simplă, în care JMF este folosit ca un plugin auxiliar. Acest gen de aplicații, deși destul de mari sunt împărțite pe module și nu necesită o interfațare low-level cu celelalte API-uri. Aplicațiile mult mai complicate, genul conferinței AV într-un mod virtual care implică traducerea de limbaj nu sunt la fel de modulare în structura lor. Acestea tind să se bazeze pe fuzionarea API-urilor la un nivel mult mai de bază. Având în vedere implicarea mult mai profundă a celorlalte API-uri în procesarea informațiilor, trebuie cunoscute datele structurale a celorlalte API-uri.
Două clase, BufferToImage și ImageToBuffer furnizează legătura între componenta
video a JMF grafica 2D sau 3D. De exemplu, cu ajutorul acestor clase este posibilă
extragerea imaginilor individuale dintr-un video, inserarea de cadre într-un video sau chiar
extragerea, modificarea și reinserarea lor. BufferToImage este o clasă prin intermediul căreia
conținutul JMF poate fi interpretat în orice alt context. De exemplu, un conținut JMF poate fi
utilizat ca textură în Java 3D. În sens invers un video poate fi construit dintr-o succesiune de
imagini AWT.
ImageToBuffer și BufferToImage sunt membri componenți ai clasei javax.media.util .
Clasa BufferToImage are un singur constructor, acceptând un obiect de tip Format.
Acesta specifică formatul bufferului video care trebuie convertit. De aici înainte, obiectele
BufferToImage sunt specifice unui Format particular, dar poate converti orice buffer în acel
57
format în imaginea sa echivalentă. Clasa are o singură metodă createImage() care acceptă un
Buffer și returnează o imagine AWT. Dacă conversia nu se poate efectua se returnează null.
Obținerea unei Image dintr-o secvență video implică obținerea unui obiect Buffer care
să corespundă cadrului video în cauză. Obținerea unui Buffer de la un cadru video particular
poate fi îndeplinită prin interfața FrameGrabbingControl. Aceasta poate fi exportată de către
un player sau Renderer prin metoda getControl(). Interfața are decât o singură metodă
grabFrame() care returnează un obiect Buffer care corespunde cadrului curent din streamul
video.
În direcție inversă de trecere de la o imagine AWT la un buffer JMF este necesară clasa
ImageToBuffer. Clasa posedă o singură metodă statică care acceptă imagini AWT și rata
cadrelor dorită și returnează un buffer JMF cu un format RGB. Cu toate că această operație
este simplă, construcția unui stream din aceste buffere este cumva un pic mai dificilă.
5.6 Direcții de viitor ale JMF
JMF este un API puternic care se maturizează repede care oferă mijloace de manipulare
a conținuului media la nivel înalt. Toate structurile cheie și clasele pentru captarea, redarea,
procesarea, recepția și transmisia de conținut media există deja în API. În acest moment API-
ul trece printr-o fază de întărire – dezvoltatorii explorează și adoptă API-ul ca o soluție pentru
diverse aplicații. În același timp Sun continuă să ofere un suport solid pentru API prin
adăugarea unor noi opțiuni pe termen scurt cu un scop bine stabilit pe termen lung.
Următoarea versiune a JMF va include un modul dedicat sesiunilor RTP rescris împreună cu optimizări importante.
Echipa JMF din cadru Sun au făcut din suportul pentru MPEG-2 și MPEG-4 cea mai mare prioritate. Acest suport va fi înglobat în JMF 2.2 dar licență și drepturile de autor sunt lucrurile care decid momentul în care acest suporta va apărea.
Maturitatea, stabilitatea și mărimea JMF indică o eventuală înglobare a acestuia în nucleul Java destul de puțin probabilă. Totuși o integrarea lângă alte pachete opționale cum ar fi Java 3D poate fi posibilă. În acest sens, standarde gen MPEG-4 pot fi considerate ca drivere în această direcție. Sun și-a exprimat crdința că MPEG-4 va aduce o îmbunătățire vizibilă a funcționalității.
Sun colaborează cu Nokia și alte companii de telecomunicații internaționale la un API media pentru J2ME (Java 2 Micro Edition). J2ME este varianta redusă (cu cerințe de memorie și de putere de procesare mult mai reduse) a platformei Java.
5.7 Recepția și prezentarea streamurilor media RTP utilizând JMF
Playerele și procesoarele oferă prezentarea, captura și mecanismul de conversie de date pentru streamurile RTP.
Câte un player separat este folosit pentru fiecare stream recepționat de managerul sesiunii. Se poate construi un player din două tipuri de resurse:
MediaLocator care conține parametrii sesiunii RTP. Această clasă face parte
din javax.media.Medialocator
ReceiveStream prin extragerea DataSource-ului din stream. Prezența a unui
ReceiveStream este anunțată prin intermediul metodei newReceiveStream()
într-un RTPReceiveStreamListener.
Dacă se folosește un MediaLocator pentru a construi un Player, se poate recepționa primul stream din sesiunea RTP. Dacă se dorește redarea mai multor streamuri RTP este necesară utilizarea clasei RTPManager.
Schema generală a fluxului de date în cazul recepție RTP este prezentată în figura 5.2.
58
Figura 5.2 Diagrama de flux de date pentru recepția RTP
Pentru crearea unui player din fiecare stream recepționat trebuie urmați următorii pași:
Setarea sesiunii RTP
1. Crearea unui RTPManager.
// create the RTP Manager
RTPManager rtpManager = RTPManager.newInstance();
2. Executarea RTPSessionMgr addReceiveStreamListener pentru a
înregistra un listener.
// adding a ReceiveStreamListener
rtpManager.addReceiveStreamListener(this);
3. Inițializarea sesiunii RTP prin metoda initialize() unde localAddress
este o variabilă de tipul SessionAddress.
// initialize the RTPManager
rtpManager.initialize( localAddress);
4. Pornirea sesiunii RTP prin metoda addTarget() care primește ca
parametru o variabilă de tipul SessionAddress.
// open the connection
rtpManager.addTarget( remoteAddress);
În metoda update pentru ReceiveStreamListener, se urmărește evenimente de
tipul NewReceiveStreamEvent, care indică detectarea unui nou stream de date.
//detecting a NewReceiveStreamEvent
if ( event instanceof NewReceiveStreamEvent )
Când este detectat un nou eveniment de tipul NewReceiveStreamEvent se scoate
ReceiveStream-ul prin utilizarea metodei getReceiveStream.
// getting a ReceiveStream from a NewReceiveStreamEvent
stream =((NewReceiveStreamEvent)event).getReceiveStream ();
Extragerea DataSource-ului din streamul RTP prin metoda getDataSource.
Acesta este un PushBufferDataSource cu un format specific RTP. De exemplu
codarea unui stream audio în format DVI va fi DVI_RTP.
// getiing the DataSource from a ReceiveStream dataSource = stream.getDataSource ();
Trimiterea unei DataSource către o nouă instanță a aplicației.
//opening a datasource
frame=createNewPlayer();
frame.open(dataSource);
5.8 Transmiterea streamurilor RTP utilizând JMF
Pentru a transmite un stream RTP, se utilizează un Processor pentru a produce un
DataSource codat RTP și un RTPManager sau DataSink pentru controlul transmisiei.
Datele de intrare în Processor pot fi stocate sau captate în timp real. Pentru datele
stocate, se poate utiliza un MediaLocator pentru a identifica fișierul în momentul creării
Processorului.
Pentru trimiterea streamului RTP există două metode:
59
Prin utilizarea unui MediaLocator care conține parametrii sesiunii RTP.
Utilizând acești parametrii se poate crea un DataSink prin intermediul metodei
createDataSink() a clasei Manager.
Prin intermediul unei manager de sesiune pentru crearea de SendStream-uri
Dacă se utilizează un MediaLocator pentru crearea unui DataSink se poate transmite decât primul stream al DataSource-ului.
Indiferent de modul ales pentru trimiterea unui stream RTP, sunt necesari următorii
pași:
Crearea unui procesor cu DataSource-ul care trebuie transmis.
Configurarea Processor-ului pentru transmiterea de date în format RTP.
Extragerea datelor de ieșire de la Processor în formatul DataSource.
O diagramă generală de flux de date pentru transmiterea de date RTP este prezentată în figura 5.3.
Figura 5.3 Diagrama de flux de date pentru transmiterea RTP
5.9 Captura conținutului media utilizând JMF
Se poate utiliza JMF pentru captura datelor media de la un dispozitiv de genul microfon sau cameră video.
Pentru captarea de date media trebuie urmați următorii pași:
Localizarea dispozitivului de captare prin interogarea CaptureDeviceManager. Returnarea unui obiect CaptureDeviceInfo de la dispozitiv.
Determinarea unui MediaLocator din CaptureDeviceInfo, utilizat pentru crearea
unui DataSource .
Crearea unui Player utilizând DataSource-ul.
Pornirea Playerului sau Processorului pentru începerea procesului de captare.
Accesul la dispozitivele de captare se face prin intermediul CaptureDeviceManager. Această clasă este registrul central pentru toate dispozitivele de captare disponibile în JMF. Se poate returna o listă cu dispozitivele de captură disponibile cu ajutorul metodei getDeviceList. Fiecare dispozitiv este reprezentat de către un CaptureDeviceInfo. Acest obiect conține trei tipuri de informații despre dispozitiv: formats (formatele suportate de către dispozitiv), locator (MediaLocator-ul care stochează adresa la care se află dispozitivul), name (numele dispozitivului).
60
5.10 Procesarea media utilizând JMF
Un Processor poate fi folosit ca un Player programabil care îți oferă controlul asupra
procesului de decodare și rendare. Un Processor poate fi deasemenea folosit ca un procesor
de captare care permite multiplexarea streamurilor obținute de la dispozitivele de intrare.
Se pot controla acțiunile de procesare efectuate de Processor prin diferite metode:
Utilizarea unui ProcessorModel pentru a construi un Processor care are
anumite caracteristici de intrare sau de ieșire.
Utilizarea metodei setFormat din clasa TrackControl pentru a specifica tipul
de conversii ce se vor efectua pentru fiecare pistă în parte.
Utilizarea metodei setOutputContentDescriptor din clasa Processor pentru a
specifica pentru a specifica tipul multiplexat de date de la ieșirea procesorului.
Utilizarea setCodecChain din clasa TrackControl pentru a selecta puginul de
tip Effect sau Codec care sunt utilizare de către Processor.
5.10.1 Configurarea unui Processor
În plus față de Realizing și Prefetching prin care orice Player trebuie să treacă, un Proccesor are în plus o fază de Configuring. Se execută configure pentru a trece un Processor Unrealized în starea Configuring.
În timpul în care este în starea de configurare, Processor-ul adună informațiile necesare pentru construcția TrackControl în cazul fiecărei piste în parte. Când se termină trece în starea Configured și postează un eveniment ConfigureCompleteEvent. Odată ce un procesor este Configured se poate seta formatul de ieșire și opțiunile legate de TrackControl. Când se termină specificarea opțiunilor de procesare, se apelează realize pentru a muta Processor-ul în starea Realizing și se începe procesul de realizare.
Odată ce un Processor-ul este în starea Realized, viitoarele încercări de modificare a opțiunilor de procesare, nu sunt garantate. În majoritatea cazurilor se va arunca o excepție de tipul FormatChangeException
Pentru a selecta ce pluginuri se folosesc pentru procesarea fiecărei piste a streamului media se execută următorii pași:
Execuția PlugInManager.getPlugInList pentru a determina ce plugin-uri sunt
disponibile. PlugInManager-ul returnează pluginurile care se potrivesc tipurilor
de intrări și ieșiri specificate de tipul acestuia.
Execuția getTrackControls din clasa Processor pentru a returna TrackControl-
ul fiecărei piste din stream. Procesorul trebuie să fie în starea Configured
înainte de a apela getTrackControls.
Se apelează metodele setRenderer sau setCodecChain pentru a specifica
pluginurile care trebuie folosite pentru fiecare pistă în parte.
Când se folosește setCodecChain pentru a specifica codecurile sau efectele folosite pentru un Processor, ordinea în care acestea apar în lanțul de procesare este determinată de formatul de intrare și de ieșire pe care îl suportă fiecare plugin.
Pentru a controla procesul de transcoding efectuat de un anumit codec se apelează metoda getControls din clasa TrackControl.
Se poate selecta formatul unei anumite piste din stream cu ajutorul clasei TrackControl:
Se apelează getTrackControls pentru a obține TrackControlul fiecărei piste.
Se apelează setFormat din TrackControl pentru a specifica formatul în care se va
convertii pista selectată.
61
5.11 Implementarea tehnica a aplicației în JMF
În acest subcapitol este prezentat modul în care sunt utilizate clasele JMF pentru
implementarea celor trei mai procese ale aplicației: captura, transmiterea și recepția
5.11.1 Captura de pe dispozitivele de intarea
Codul funcției de captură din aplicație este listat după cum urmează:
private void captureMedia () {
CaptureDialog dialogCapture;
DataSource dataSource;
CaptureDeviceInfo cdi;
nameCaptureDeviceAudio = null;
nameCaptureDeviceVideo = null;
dialogCapture = new CaptureDialog ( this, cfgJMApps ); dialogCapture.show ();
if (dialogCapture.getAction() == CaptureDialog.ACTION_CANCEL)
return;
cdi = dialogCapture.getAudioDevice();
if ( cdi != null && dialogCapture.isAudioDeviceUsed() )
nameCaptureDeviceAudio = cdi.getName();
cdi = dialogCapture.getVideoDevice();
if ( cdi != null && dialogCapture.isVideoDeviceUsed() )
nameCaptureDeviceVideo = cdi.getName();
dataSource = JMFUtils.createCaptureDataSource ( nameCaptureDeviceAudio,
dialogCapture.getAudioFormat(),
nameCaptureDeviceVideo,
dialogCapture.getVideoFormat()
);
if ( dataSource != null ) {
if (dataSource instanceof CaptureDevice
&& dataSource instanceof PushBufferDataSource) {
DataSource cdswrapper = new
CDSWrapper((PushBufferDataSource)dataSource);
dataSource = cdswrapper;
try {
cdswrapper.connect();
}
catch (IOException ioe) {
dataSource = null;
nameCaptureDeviceAudio = null;
nameCaptureDeviceVideo = null;
MessageDialog.createErrorDialog ( this,
JMFI18N.getResource("jmstudio.error.captureds") );
}
}
open ( dataSource );
if ( dataSource != null ) {
dlgCaptureControls = new CaptureControlsDialog (
interfata.this, dataSource );
if ( dlgCaptureControls.isEmpty() ) {
dlgCaptureControls = null;
62
}
else {
// dlgCaptureControls.setVisible ( true );
}
}
}
else {
nameCaptureDeviceAudio = null;
nameCaptureDeviceVideo = null;
MessageDialog.createErrorDialog ( this,
JMFI18N.getResource("jmstudio.error.captureds") );
}
}
Se crează un obiect de tip CaptureDialog care va arăta ca în figura 6.3. Parametrii constructorului sunt Frame-ul curent și fișierul de configurație alaplicației cfgJMApps. În cazul în care se primeste un eveniment de tip ACTION_CANCEL se iese din funcție. După cum a fost prezentat în capitolele de mai sus pentru a identifica dispozitivele de intrare este necesar de un obiect de tipul CaptureDeviceInfo. Acest tip de obiect este returnat în caz general de către CaptureDeviceManager. Instant Audio Video Streamerul folosește metodele getAudioDevice() și getVideoDevice() din clasa CaptureDialog
cdi = dialogCapture.getAudioDevice();
cdi = dialogCapture.getVideoDevice();
În cazul în care variabila cdi este liberă iar device-urile sunt libere se trece la
inițializarea acestora. Pentru a efectua transmisia este necesară crearea unui DataSource care
să conțină cele două streamuri. Acest lucru este posibil prin intermediul metodei
JMFUtils.createCaptureDataSource din pachetul jmapps.util al framework-ului JMF.
În cazul în care DataSource-ul nu este null se verifică dacă este o instanță a interfeței
CaptureDevice și PushBufferDatasource. Se creează un obiect CDSWrapper pentru a avea un
mai bun control asupra streamurilor din DataSource. Prin metoda connect() se încearcă
inițializarea obiectului în cauză. În cazul în care această operație nu reușește se aruncă o
excepție IOException în care se resetează DataSource-ul și numele dispozitivelor de intrare.
Dacă inițializarea obiectului reușește se deschide în fereastra principală a aplicației sursa de captură prin intermediu-ul metodei open care are codul de mai jos:
public void open ( DataSource dataSource ) {
MediaPlayer mediaPlayer;
boolean boolResult;
mediaPlayer = jmapps.util.JMFUtils.createMediaPlayer (
dataSource, (Frame)this );
boolResult = open ( mediaPlayer ); if ( boolResult == true )
dataSourceCurrent = dataSource;
}
Se testează încă o dată dacă DataSource-ul nu este null, iar în cazul în care acest lucru se verifică se construiește un obiect de tipul CaptureControlsDialog în același Frame al aplicației și din DataSource-ul specificat. Fereastra cu controlurile capturii va arăta ca în figura 6.11.
Dacă DataSource-ul este null, se resetează numele dispozitivelor de intrare și se afișează un mesaj de eroare.
63
5.11.2 Transmisia streamurilor
Codul funcției de transmisie din cadrul aplicației este listat după cum urmează:
private void transmitMedia () {
TransmitWizard dlgTransmit;
String urlString = null;
String strAction;
MediaPlayer mediaPlayer;
Processor processorTransmit;
boolean boolResult;
DataSource dataSource = null;
if ( dataSourceCurrent != null && dataSourceCurrent instanceof CDSWrapper) {
dataSource = dataSourceCurrent; dataSourceCurrent = null;
killCurrentPlayer();
// setPlaceholder();
urlString = "Capture";
}
else if ( mediaPlayerCurrent != null ) {
urlString = mediaPlayerCurrent.getMediaLocation ();
}
dlgTransmit = new TransmitWizard ( this, urlString, dataSource, cfgJMApps );
dlgTransmit.show ();
strAction = dlgTransmit.getAction ();
if ( !strAction.equals(TransmitWizard.ACTION_FINISH) )
return;
processorTransmit = dlgTransmit.getProcessor (); if ( processorTransmit == null )
return;
strOptionalTitle = JMFI18N.getResource ( "jmstudio.playerwindow.transcoding" );
mediaPlayer = jmapps.util.JMFUtils.createMediaPlayer ( processorTransmit, (Frame)this );
boolResult = open ( mediaPlayer ); if ( boolResult == true ) {
vectorMngrSessions = dlgTransmit.getMngrSessions ();
vectorStreams = dlgTransmit.getStreams ();
vectorStreamLabels = dlgTransmit.getStreamLabels ();
dlgTransmissionStats = new TransmissionStatsDialog ( this, vectorMngrSessions, vectorStreamLabels );
this.updateMenu ();
}
}
Dacă aplicația este în modul capture și sursa de date curentă este setată se copiază în
variabila dataSource sursa de date curentă, se copiază în variabila urlString calea sursei de
date în acest caz șirul de caractere „Capture”. În cazul în care dataSource-ul este null se
verifică dacă MediaPlayerul este diferit de null și ne salvează MediaLocator-ul sursei. Se
încearcă deschiderea unui dialog de transmisie cu parametrii: Frame-ul curent, dataSource,
64
urlString, fișierul de configurare al aplicației. Până când nu se apasă pe butonul FINISH
pentru a primi un eveniment de această natură aplicația nu trece mai departe.
Se apelează metoda getProcessor() asociată obiectului TransmitWizard pentru a returna
datele de configurarea ale streamurilor ce urmează a fi transmise. Se crează un Player nou
prin executarea metodei jmapps.util.JMFUtils.createMediaPlayer cu parametrii
Processor-ul curent și Frame-ul curent. În clasa JMFUtils nu există funcția care să aibă ca
parametrii variabila Processor dar profitând de calitatea de Player a acestuia funcția este
aplicabilă și în acest caz. Se deschide un nou MediaPlayer cu ajutorul metodei open care are
codul listat mai jos
public boolean open ( MediaPlayer mediaPlayer ) {
if ( mediaPlayer == null )
return ( false );
killCurrentPlayer ();
this.setCursor ( cursorWait );
mediaPlayerCurrent = mediaPlayer;
mediaPlayer.setPopupActive ( false );
mediaPlayer.setControlPanelVisible ( false ); mediaPlayer.addControllerListener ( this ); mediaPlayer.realize();
updateMenu ();
return ( true );
}
Dacă în urma acestui apel al funcției se returnează o valoare true se inițializează un vector cu numărul sesiunilor RTP existente, numărul streamurilor transmise și un vector cu etichetele streamurilor.
Se creează un nou dialog de transmitere a statisticilor după cum este prezentat în
figurile 6.15 și 6.16.
De transmisia propriu-zisă se ocupă obiectul TransmitWizard.
5.11.3 Receptia si prezentarea streamurilor.
Codul funcției de recepție și prezentare a streamurilor este listat după cum urmează:
private void openRtp () {
OpenRtpDialog dlgOpenRtp;
String strAction;
String strAddress;
String strPort;
String strTtl;
int port,ttl,i;
PlayerFrame frame;
SessionAddress x = new SessionAddress();
dlgOpenRtp = new OpenRtpDialog ( this, cfgJMApps ); dlgOpenRtp.show ();
strAction = dlgOpenRtp.getAction ();
if ( !strAction.equals(JMDialog.ACTION_OPEN) )
return;
strAddress = dlgOpenRtp.getAddress();
65
strPort = dlgOpenRtp.getPort ();
strTtl = dlgOpenRtp.getTtl ();
InetAddress ipAaddress=null;
try {
ipAddress=InetAddress.getByName(strAddress); } catch (UnknownHostException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
port=Integer.valueOf(strPort).intValue();
ttl=Integer.valueOf(strTtl).intValue();
SessionAddress point = new SessionAddress(adresaip,port,ttl);
RTPManager reception=RTPManager.newInstance();
try {
reception.initialize(x);
} catch (InvalidSessionAddressException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
reception.addTarget(point);
} catch (InvalidSessionAddressException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Vector<ReceiveStream> vect = new Vector<ReceiveStream>
();
vect = reception.getReceiveStreams(); Enumeration elem=vect.elements();
ReceiveStream[] inStream = new ReceiveStream[2];
i=0;
while(elem.hasMoreElements())
{
inStream[i++]=(ReceiveStream)elem.nextElement();
}
mngrSessionRtp = null;
for (i=0;i<=inStream.length+1;i++)
{
if ( vectorRtpFrames != null && vectorMngrSessions !=null
&& vectorMngrSessions.size() > 0
&&
vectorMngrSessions.firstElement() == receptie ) { frame = new PlayerFrame ( this, strOptionalTitle ); vectorRtpFrames.addElement ( frame );
frame.open ( inStream[i].getDataSource() ); frame.setVisible(true);
}
else {
open ( inStream[i].getDataSource() );
vectorMngrSessions = new Vector<RTPSessionMgr> ();
66
vectorMngrSessions.addElement (
(RTPSessionMgr)reception );
dlgSessionControl = new SessionControlDialog
( this,(RTPSessionMgr) reception);
updateMenu ();
vectorRtpFrames = new Vector<PlayerFrame> ();
}
}
try {
reception.removeTarget(point, "Client disconnected");
} catch (InvalidSessionAddressException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
reception.dispose();
}
Se începe prin crearea unui ferestre de dialog Open RTP după cum este prezentată în
figura 6.2. Din acestă fereastră se memorează adresa de IP multicast, portul și TTL-ul
specifice sesiunii RTP care se dorește a fi recepționată. Aceste date sunnt salvate în format
String.
Având în vedere că dorim să recepționăm unul sau mai multe streamuri din DataSource, suntem obligați să folosim clasa RTPManager. Inițializarea acestei clase se face prin metoda newInstance(). Odată inițializat se adaugă adresa sursei la sesiune. Această adresă trebuie să fie de tipul SessionAddress. Se crează un obiect de tipul SessionAddress din adresa salvată în timpul dialogului, convertită în formatul InetAddress. Acest format este specific pachetului java.net. În cazul conversiei de la adresa în format String la adresa în format InetAddress se aruncă o excepție de tipul UnknownHostException. Deasemenea, la adăugarea adresei în format SessionAddress la RTPManager se aruncă o excepție de tipul InvalidSessionAddressException. După adăugarea adresei la sesiune se crează un Vector de elemente ReceiveStream. Se salvează în acest vector streamurile recepționate, pentru returnarea elementelor fiind nevoie de o variabilă de tip Enumeration. Se mai crează încă un vector de tip ReceiveStream pentru a clona elementele din Vector-ul inițial. Pentru fiecare element salvat în acest vector se testează dacă numărul de frame-uri RTP este diferit de null și dacă numărul de sesiuni active e mai mare ca zero.
Dacă primul element din vectorul de sesiuni RTP este reception și dacă vectorul de Frame-uri e diferit de null se crează un nou Frame, se adaugă în vectorul de Frame-uri corespunzatoare numărului de streamuri si se deschide DataSource-ul asociat.
În caz contrar se execută următorii pași:
Se deschide streamul asociat în fereastra principală a programului. Se crează un nou Vector de sesiuni RTP
Se adaugă sesiunea curentă în acest vector
Se crează un nou obiect de tipul SessionControlDialog pentru a monitoriza
transmisia de pachete RTCP pe rețea.
Pentru a activa această opțiune în meniu-ul aplicației se apelează metoda upgradeMenu().
După efectuarea recepției se șterge fiecare gazdă din managerul sesiunii și se închide sessiunea.
67
5.12 Soluțiile de server side pentru real time streaming existente pe Internet
Există la ora actuală un număr de soluții destul de fiabile pentru streaming în timp real. Printe acestea trebuie să amintim:
În materie de servere de streaming real-time:
1. Helix Streaming Server dezvoltat de compania Real Networks
2. Quick Time Streaming Server dezvoltat de compania Apple
3. Windows Media Streaming Server dezvoltat de compania Microsoft
4. Darwin Streaming Server, o variantă lite și open-source a Quick Time
Streaming Server
5. Flash Media Streaming Server dezvoltat de către compania Adobe
Majoritatea acestor soluții de streaming audio-video au plusuri și minusuri după cum urmează:
Helix Streaming Server:
Avantaje:
1. Suportul pentru o mare parte din formatele media deja existente:
RealAudio, RealVideo, Windows Media, QuickTime, MP3, MPEG-4,
3GPP(H.263, H.264).
2. Flexibilitate pentru adoptarea noilor formate în viitor.
3. Suportul pentru un număr foarte mare de utilizatori.
4. Protecția serviciilor de Streaming utilizand Helix Security Manager.
5. Posibilitatea streamingului atât pe unicast cât și pe multicast.
6. Posibilitatea de streaming pentru dispozitivele mobile.
7. Quality of Service.
8. Suportul pentru tehnologia multi-core pe 64 de biți.
9. Administrare Webbased.
Dezavantaje:
1. Este o soluție dedicată afacerilor cu streaming în timp real foarte mari.
2. Oferă suport numai pentru sistemele de operare pentru servere:
Windows 2003, Solaris 10, RedHat Enterprise Linux.
3. Prețul unei liicențe pentru acest produs este de zece mii de euro (poate
cel mai mare dezavantaj).
Quick Time Streaming Server:
Avantaje:
1. API-ul QuickTime poate fi accesat prin intermediul Java.
2. Posibilitatea de streaming unicast și multicast.
3. Posibilitatea de streaming media stocat pe suport fizic sau captat în
timp real de la un dispozitiv de intare.
4. Este integrat în Mac OSX Server.
5. Protecția broadcast-ului audio cu parolă. Dezavantaje:
1. Oferă suport numai pentru Mac OSX, Windows și POSIX.
2. Suportă decât formatele: QuickTime, MPEG-4 și 3GPP.
3. Este integrat în Mac OSX Server, eventualele instalări pe Mac OSX,
Windows sau POSIX necesitând compilarea surselor.
68
Windows Media Streaming Server
Avantaje:
1. Suportă tehnologia pe 64 de biți.
2. Sunt suportate atât comunicațiile unicast cât și multicast.
3. Este integrat în Windows Server 2003 și Windows Server 2008.
4. Oferă posibilitatea de streaming în timp real direct de pe dispozitivele
de intrare.
5. Posibilitatea de broadcast. Dezavantaje:
1. Suportul pentru formatele: Windows Media, JPEG și MP3.
2. Este integrat numai pe sistemele Microsoft.
3. Versatilitate redusă.
Darwin Streaming Server
Avantaje:
1. Este opensource permițând îmbunătățirea continuă a facilităților
oferite.
2. Are suport pentru majoritatea sistemelor de operare incluzând
Windows, Linux și Solaris.
3. Administrare Webbased
4. Toate funcționalitățile oferite QuickTime Streaming Server sunt
valabile și în cazul Darwin Streaming Server.
Dezavantaje:
1. Suportul pentru acest server este oferit doar de comunitatea
Opensource.
2. Nu oferă suport pentru formatele Windows Media.
3. Pentru instalarea pe sistemul Windows necesită Perl (instalarea și
configurarea destul de greoaie).
Flash Media Streaming Server
Avantaje:
1. Posibilitatea de streaming live.
2. Utilizează formatul FLV care oferă dimensiuni reduse și în raport cu
calitatea imaginii.
3. Sistem de control al statisticilor cu particularizare pe fiecare utilizator
în parte.
4. Posibilitatea de implementarea a serviciilor Internet TV.
5. Se poate instala pe Windows XP.
6. Quality of Service.
Dezavantaje:
1. Este disponibil pe Windows Server 2003, Windows Server 2008,
Linux RedHat 4, Linux RedHat 5.2
2. Necesită resurse pentru server destul de mari.
3. Liicența unui asemenea server este o mie de dolari.
Având în vedere raportul preț/calitatea al acestor produse și luând în considerarea că
singurul care este OpenSource și care oferă opțiunile unui adevărat server de real time
streaming este Darwin Streaming Server, acesta este prima opțiune pentru utilizarea într-o
afacere de mărimi mici sau medii. Nu este însă potrivit pentru streaminguri unicast sau
69
multicast la o mărime foarte mică având în vedere ca este necesară instalarea sa pe un server dedicat.
Pentru astfel de streaminguri este ideală utilizarea unui Instant Audio-Video Streamer care oferă următoarele avantaje și dezavantaje.
Avantaje:
1. Este implementat utilizând API-ul JMF. Poate rula pe orice platformă care are
Java instalat.
2. Librăria de codecuri poate fi îmbunătățită constant prin adăugarea de noi
formate sau efecte.
3. Este open source, deci poate fi dezvoltat prin adăugarea unor noi funcționalități.
4. Oferă funcționalități de bază pentru QoS de tip RTCP.
5. Poate fi folosit atât ca server cât și ca client.
6. Este foarte flexibil și bine țintit.
7. Poate fi integrat foarte ușor în alte API-uri Java.
8. Moștenește puterea limbajului Java pentru programarea pe rețea. Dezavantaje:
1. Poate fi folosit doar pentru streaming multicast
2. Suportă un număr de abonați destul de redus.
3. Este axat numai pe instant streaming și are o paletă de funcționalități destul de
redusă.
4. Lipsa suportului de control al congestiilor
70
CAPITOLUL 6 – MANUAL DE UTILIZARE
Se pornește aplicația. Fereastra principală a aplicației va arăta ca în figura 6.1:
Figura 6.1 Fereastra principală a aplicației
După cum se poate vedea există două meniu-uri principale: File și Player
6.1 Meniu-ul File
Meniu-ul file conține următoarele opțiuni
Open RTP Session – deschiderea unei sesiuni RTP.
Capture – Captură în timp real de pe dispozitive de intrare (webcam și
microfon).
Close – Închiderea aplicației.
Transmit – Transmiterea unei sesiuni RTP.
Preferences – Setarea dispozitivelor de intrare și ieșire. Exit – Închiderea tuturor ferestrelor deschise.
6.1.1 Open RTP Session
Fereastra de Open RTP Session va arăta după cum este prezentată în figura 6.2.
Figura 6.2 Fereastra pentru deschiderea unei noi sesiuni RTP
Având în vedere că Instant Audio Video Streamer suportă doar sesiuni multicast în
câmpul adresă se va introduce adresa multicast a serverului. În câmpul port se va introduce
71
portul de intrare a streamului. Dacă există situația în care streamurile media sunt trimise pe porturi diferite în acest caz se se va executa de două ori Open RTP Session..
Câmpul TTL conține numărul de routere prin care trebuie trecut semnalul până să
„expire” (TTL = Time To Live). Valorile acestui câmp pot fi de la 1 până la 255.
6.1.2 Capture
La executarea comenzii Capture va apărea o fereastră de configurarea a tipului capturii care poate fi atât audio cât și video. Aceasta va arăta ca în figura 6.3.
Figura 6.3 Fereastra de configurarea a capturii
În fereastra de configurarea a capturii video avem dispozitivul de captură video, după care schema de codare YUV sau RGB, rezoluția care poate fi de la 160×120 până la 640×480, numărul de cadre pe secundă care variază de la 1 până la 30 de cadre, tipul YUV.
În fereastra de configurare a dispozitivului audio avem două opțiuni Direct Sound Capture care utilizează driverul de sunt din DirectX și
Java Sound Audio Capture.
În cazul Direct Sound Capture avem:
Encoding – LINEAR
Sample Rate – de la 8 kHz până la 48 kHz Bits per Sample – 8 sau 16 biți
Canal – mono sau stereo
Dacă se confirmă setările selectate aplicația ca începe înregistrarea imaginii și a sunetului de pe dispozitivele de intrare.
Butoanele din dreapta jos au urmatoarele funcționalități:
anuleaza intrarea audio
intră în statisticile de captare și PlugIn
Viewer
Figura 6.4 Fereastra de captură
72
6.1.3 Transmit
La executarea comenzii Transmit va apărea o fereastă de selectare a sursei transmisiei după cum este prezentat în figura 6.5.
Figura 6.5 Fereastra de selectarea a sursei
În această fereastră există două opțiuni transmisie de File sau de Capture. Pentru transmiterea de fișiere aplicația nu este încă suficient optimizată, având o bibliotecă de codecuri destul de limitată. Prin urmare selectarea de transmisie a unui fișier în acest moment poate întâmpina probleme.
Scopul acestei aplicații este
streamingul în timp real de pe
dispozitivele de intrare. În acest caz vom
selecta Capture pentru configurarea
dispozitivelor de intrare după cum a fost
arătat în figura 6.3. Odată efectuate
setările se va apăsa butonul de Next și va
apărea o fereastră cu două tab-uri pentru o
configurare finală a parametrilor
dispozitivelor de intrare.
Interfața va arăta ca în figura 6.6.
Figura 6.6 Configurarea audio
73
Pentru transmisiile în timp real formatul este în ambele cazuri RAW/RTP. În cazul audio avem următoarele opțiuni:
Enable Track – Pentru a selecta sau nu sursa de intrare audio.
Encoding – Tipul de compresie care poate fi DVI/RTP, G723/RTP, ULAW/RTP
sau MPEGAUDIO/RTP.
Sample rate – Rata de eșantionare care în cazul DVI/RTP (codec suficient
pentru un streaming real time) poate fi între 8kHz și 22kHz.
Bits per sample – În acest caz este blocat la 16biți.
Canal – Pentru transmisiile de tip DVI/RTP este mono dar pentru
MPEGAUDIO/RTP se poate selecta și un canal stereo.
Pentru configurarea dispozitivului video avem interfața din figura 6.7.
Figura 6.7 Configurarea video
În cazul video avem următoarele opțiuni:
Enable Track – Pentru a selecta sau nu sursa video.
Encoding – Tipul compresie care care poate fi H263/RTP sau JPEG/RTP.
Video size – care este Custom și poate fi setat în câmpurile de sub acesta.
Frame Rate – Default (acesta fiind în prima etapă de setare a dispozitivelor de
intrare).
După ce s-a finalizat a doua fază de configurarea a dispozitivelor de intrare se va trece la pasul următor.
În acest pas se setează adresa și portul de ieșire al fiecărui stream în parte plus parametrul TTL. Adresa trebuie să fie în mod obligatoriu multicast după cum este descris în detaliu în subcapitolul 2.5.2 din lucrare.
Dacă portul de transmisie diferă se vor executa de două ori instrucțiunile de la subcapitolul 6.1.1 pentru fiecare stream în parte. Aplicația suportă atât transmisia streamurilor pe adrese și porturi diferite cât și pe adrese și porturi identice.
Fereastra de configurarea a acestui pas de configurare ca arăta ca în figura 6.8.
74
Figura 6.8 Fereastra de configurarea a adreselor de trimitere pentru fiecare
stream
Setarea de Video Monitor poate modifica numărul de fps numai în cazul în care se setează tipul de compresie video JPEG/RTP. Pentru H263/RTP această setare nu este valabilă. Cele două setări de monitor audio și monitor video permit alegerea streamului care este monitorizat în timp real după cum este arătat în figura 6.9.
Figura 6.9 Fereastra pricipală de captură
Concomitent cu fereastra principală de captură prezentată în figura 6.9 mai apar încă două ferestre prezentate după cum urmeză:
75
Figura 6.10 Monitorul principal de captură
Figura 6.11 Fereastra de vizualizarea a parametrilor capturii
În monitorul principal de captură se monitorizeză captura video în timp real indiferent dacă acest stream mai este monitorizat sau nu. În fereastra de vizualizare a parametrilor capturii nu se pot efectua modificări deoarece odată configurat un Processor acesta trebuie închis și repornit cu parametrii modificați. Prin urmare este foarte importantă setarea corectă a parametrilor de captură de la bun început.
76
6.1.4 Preferences
Preferences utilizează modulul JMFRegistry care este parte integrantă a Java Media Frameworks. Acest modul permite adăugarea de noi Plugin-uri, tipuri media suportate sau pachete auxiliare la aplicație.
În afară de acest avantaj JMFRegistry mai permite setarea anumitor opțiuni după cum este prezentat în figura 6.12.
Figura 6.12 Fereastra de setarea a opțiunilor pentru utilizator
Aceste opțiuni sunt valabile pentru întreg framework-ul JMF. Prima opțiunea permite applet-urilor care folosesc JMF scrierea de fișierul pe HDD-ul utilizatorului, cea de-a doua opțiune permite utilizarea capturilor de pe dispozitivele de intrare, cea de-a treia opțiune permite stocarea temporară pe HDD a unor informații adunate de la dispozitivele de intrare. Ultima opțiune permite stocarea tuturor datelor legate de transmisiile efectuate sau de condițiile de rulare a programului în log-uri separate.
Tot în acest modul sunt stocate și dispozitivele de intrarea care au fost identificate în momentul în care a fost instalat frameworkul JMF.
După cum este arătat în figura 6.13 în partea din stânga sunt listate dispozitivele de
intrare recunoscute iar în partea din dreapta sunt trecute specificațiile fiecărui dispozitiv
selectat.
Există posibilitatea adăugării sau eliminării anumitor dispozitive. Există chiar un buton de detecție a dispozitivelor de intrare existente care este folosit în cazul în care s-a instalat un dispozitiv nou și se dorește recunoașterea acestuia.
În cazul în care se apasă din greșeală butonul de Remove și se elimină unul dintre dispozitive se poate apăsa butonul Restore și modulul revine la configurația anterioară.
77
Figura 6.13 Fereastra de adăugare și recunoaștere a dispozitivelor de intrare
6.2 Meniu-ul Player
În momentul activării transmisiei anumite funcții din meniu-ul Player devin active.
6.2.1 Cazul aplicației ce efectuează transmisia
În cazul aplicației de transmitere se activează submeniu-urile PlugIn Viewer și Transmission Statistics.
Submeniu-ul PlugIn Viewer va afișa codecurile de procesare ale imaginii înaintea ca aceasta să fie transmisă în modul multicast după cum este prezentat și în figura 6.14.
Figura 6.14 Funcția PlugIn Viewer în cazul aplicației de transmitere
Aceste codecuri pot fi diferite în funcție de tipul transmisiei selectate atât audio cât și video. În cazul în care se selectează decât un dispozitiv de intrare în etapa de configurare prezentată în subcapitolul 6.1.2 în figura de mai sus ar fi apărut decât lanțul de codecuri asociat numai acelui dispozitiv de intrare.
Submeniu-ul Transmission Statistics prezintă statisticile de transmitere ale serverului pentru a superviza calitatea transmisiei. În funcție de aceste date primite se ca încerca o reconfigurarea a formatului folosit sau conservarea unui singur stream, de preferință audio datorită importanței sale și a lărgimii de bandă consumate.
78
În figurile de mai jos sunt prezentate fereastrele corespunzătoare statisticilor de transmisie pe streamurile audio și video.
Figura 6.15 Statistici audio Figura 6.16 Statistici video
6.2.2 Cazul aplicației care efectuează recepția
În cazul aplicației de recepție în primul și în primul rând apar ferestrele corespunzatoare streamurilor de intrare.
Figura 6.17 Fereastra de recepție video
Butonul din dreapta jos oferă detalii despre streamul recepționat după cum este prezentat și în figura 6.18.
Fereastra conține trei tab-uri după cum urmează: General, Video, PlugIn Settings. În tab-ul General sunt prezentate informațiile de baza ale streamului cum ar fi: rata de transfer, timpul scurs de la începerea sesiunii, numărul de cadre pe secundă. În Tab-ul Video este prezentat formatul streamului recepționat iar în tab-ul PlugIn Settings este prezent butonul care deschide PlugIn Viewer-ul pentru streamul video.
79
Figura 6.18 Fereastra de proprietăți pentru streamului video
La recepție PlugIn Viewer-ul pentru acest stream este disponibil numai prin intermediu acestui buton având în vedere că se deschide un nou Frame și nu o nouă instanță a aplicației.
Dacă se dorește vizionarea acestui lanț de codecuri care funcționează pentru conversia
și prezentarea conținutului media se apasă butonul în cauză rezultatul arătând asemănător cu cel din figura 6.19.
Figura 6.19 Funcția PlugIn View pentru streamul video recepționat
În cazul aplicației audio lucrurile stau asemănător cu diferența că acest stream este deschis în fereastra principală a playerului după cum se vede și în figura 6.19.
Figura 6.20 Fereastra de recepție audio
80
În fereastra de recepție audio butoanele din dreapta jos au următoarele funcționalități:
anulează volumul streamului recepționat
intră în proprietățile streamului
Descrierea funcționalității ferestrei de proprietăți pentru streamul audio este aproape
identică cu cea a streamului video cu mențiunea că pe tab-ul General avem în loc de Bit Rate,
Frame Rate și în tab-ul audio rata de eșantionare, numărul de biți pe eșantion și numărul de
canale.
Fereastra de proprietăți în cazul streamului audio va arăta ca în figura 6.21
Figura 6.21 Fereastra de proprietăți pentru streamul audio
Dacă se dorește vizionarea lanțului de codecuri utilizate pentru decompresia și redarea
streamului audio se va accesa PlugIn Viewer-ul ori din meniu-ul Player al ferestrei principale,
ori din tab-ul PlugIn Settings al ferestrei de proprietăți. Acesta va arăta ca în figura 6.22.
Figura 6.22 Funcția PlugIn Viewer pentru streamul audio recepționat
81
6.2.3 RTP Session Control
În cazul aplicației de recepție în meniu-ul Player se activează opțiunea RTPSession Control. Acesta se ocupă cu setările legate de sesiunea RTP din care sunt extrase mai departe streamurile audio și video.
Fereastra principală a acestei opțiuni arată ca în figura 6.23.
Figura 6.23 Fereastra principală a submeniu-ului RTP Session Control
În fereastra principală, în tab-ul Overall RTP Statistics, sunt prezentate datele cumulate pentru toată sesiunea. Comparând aceste date cu cele ale aplicației sursă putem trage concluzii privind buna funcționare a rețelei sau a transmisiei.
În tab-ul Participants sunt prezentați participanții la sesiune în partea din stânga iar în partea din dreapta utilizatorii diferențiați după anumite criterii. Aceste criterii au următoarea descriere:
Remote – Utilizatorul identificat drept gazdă. Pot exista mai mulți utilizatori
gazdă după cum se pot folosi mai multe surse și un multiplexor pentru a
recepționa mai multe track-uri audio sau video dintr-un singur stream.
Local – Utilizatorul unde oferă datele despre starea sesiunii. Întotdeauna există
un singur utilizator local corespunzător aplicației de recepție.
Active – Utilizatorul care participă activ la sesiune. După cum a fost explicat în
subcapitolul 2.5.4, pot fi create sesiuni de tipul multipoint/multipeer prin setarea
mai multor utilizatori activi care de cele mai multe ori sunt considerați și gazde.
Passive – Utilizatorul care recepționează streamurile din sesiune fără a participa
cu nimic la desfășurarea acesteia.
82
Opțiunile tab-ului Participants sunt prezentate în figura 6.24.
Figura 6.24 Tab-ul Participants din fereastra principală a submeniu-ului RTP
Session Control
Tab-ul Buffer Control al ferestrei este prezentat în figura 6.25.
Figura 6.25 Tab-ul Buffer Control al submeniu-ului RTP Session Control
83
CONCLUZII
Internetul oferă din ce în ce mai multe posibilități pentru dezvoltarea multimedia în
timp real.
Așa cum formatul text a fost înlocuit după o perioadă de timp de conținutul media
static, într-un viitor apropiat conținutul multimedia static va fi înlocuit, în totalitate, de
conținutul multimedia dinamic.
Tehnologia multimedia actuală se concentrează pe rețelele mobile cu un potențial
extraordinar de dezvoltare în viitor.
Integrarea serviciilor IPTV și Internet TV într-un viitor apropiat va conduce la o
explozie în domeniului accesului la informație.
Web 3.0 va avea ca nucleu de dezvoltare multimedia în timp real și inteligența
articifială, un succes cât se poate de garantat.
Transmisiile multicast reduc foarte mult consumul de lărgime de bandă de pe server
însă pun o extra-sarcină pe anumite routerele din rețea.
RTP este dezvoltat pe UDP pentru a evita mecanismul de retransmisie TCP care poate
îngreuna foarte mult real-time streamingul.
RTP este alcătuit din două subprotocoale RTP Data Protocol a cărui implementare
ține mai mult de layerul aplicației și RTCP care este protocolul de control care oferă
date despre starea transmisiei.
RTP face parte la rândul său parte dintr-un protocol mai general denumit RTSP care îl
folosește pentru transmisia de date și folosește SDP pentru stabilirea și negocierea
sesiunilor, SIP pentru configurarea și gestiunea acestora și SAP pentru a le anunța.
RTP poate fi implementat atât pe rețelele IP (Internet Protocol) cât și pe rețelele ce au
la bază ST-II (Streaming Protocol) cu diferența că pe acestea oferă Quality of Service
garantat.
În cazul în care RTP este utilizat pe rețele IP, pentru a asigura Quality of Service se
poate utiliza un protocol de control al congestiilor de tip DCCP sau se pot dezvolta
profiluri RTP care să ofere Quality of Service integrat. Un număr de astfel de profiluri
sunt în dezvoltarea la ora actuală.
Având în vedere suportul Java pentru majoritatea protocoalelor descrise în lucrarea de
față precum și numărul destul de mare de biblioteci de clase disponibile pentru
programarea pe rețea, se așteaptă în viitor o dezvoltarea mult mai mare a API-urilor
multimedia.
Software-urile de streaming multimedia pot profita de independența de platformă a
mediului Java.
Java Media Framworks a devenit mult prea mare pentru a putea fi înglobat în nucleul
limbajului Java
Integrarea API-ului JMF se poate face atât de sine stătătoare ca aplicație(.jar) cât și ca
applet web.
Dezvoltarea acestor software-uri este limitată de mărimea infrastructurii în care
funcționează servicul de real time streaming.
Pentru rețele de o anvergură foarte mare, alte soluții dedicate de tipul Helix Streaming
Server sau Quick Time Streaming Server devin mult mai rentabile.
Instant Audio-Video Streamer se adresează în special rețelelor de streaming mici și
foarte mici sau sistemelor de conferințe locale.
Necesarul de resurse în cazul Instant Audio-Video Streamer este extrem de redus.
84
Profitând de modulul de configurare JMRegistry suportul pentru noi codecuri,
formate media suportate și efecte poate fi îmbunătățit constant.
Instant Audio-Video Streamer are avantajul că poate fi folosit atât ca aplicație de
transmitere (server) cât și ca aplicație de recepție (player)
Cu ajutorul acestei aplicații se pot crea transmisii de tip multiport/multipeer prin
setarea anumitor utilizatori atât ca receptori cât și ca surse. Acest lucru nu este în
cazul soluțiilor dedicate de genul Helix Streaming Server sau celelalte servere de
streaming.
Momentan Instant Audio-Video Streamer oferă suport numai pentru transmisiile
multicast însă poate fi dezvoltat în viitor și către transmisiile de tip unicast sau
broadcast.
Sun lucrează împreună cu Nokia și alte companii de telefonie pentru dezvoltarea unui
API funcțional pe J2ME. Există un potențial uriaș pentru Java și real time multimedia
pe piața dispozitivelor mobile. La momentul scoaterii acestui API pe piața Instant
Audio-Video Streamer poate fi convertit foarte ușor pe J2ME.
85
BIBLIOGRAFIE
[1] Colin Perkins „RTP:Audio and Video for the Internet”, 2006, Addison-Wesley
[2] William Stallings „Data and computer comunications”, 2007, Prentice Hall
[3] Adrian Farrel „The Internet and its protocols”, 2004, Morgan Kaufman
[4] Syed Mahbubur Rahman „Multimedia Networking: technology, management and
applications”, 2002, Idea Grup Inc.
[5] A.C.M. Fong, S.C. Hui „Multimedia Engineering: A practical guide for Internet
implementation”, 2006, Wiley
[6] Edwin Wright, Deon Reynders „Practical Telecommunications and Wireless
Comunications”, 2004, Elsevier
[7] Sudhir Dixit, Tao Wu „Content networking in the mobile Internet”, 2004, Wiley
[8] Sanjoy Paul „Multicasting on the Internet and its aplications”, 1998, Springer
[9] Gerard O’Driscoll „Next generation IPTV services and technologies”, 2008, Wiley
[10] Syed Mahbubur Rahman „Multimedia Technologies: Concepts, Methodologies, Tools and Applications”, 2008, Information Science Reference
[11] Ralph Wittmann și Martina Zitterbart “Multicast Comunication: Protocols and
Aplications”,2001, Morgan Kaufmann
[12] Borko Furth și Syed Ahson „Handbook of Mobile broadcasting”, 2008, CRC Press
[13] Henry Sinnreich, Alan B. Johnston „Internet Comunications using SIP”, 2006, Wiley
[14] Larry L. Peterson și Bruce S. Davie “Computer Networks: a systems approach”, 2007, Morgan Kaufmann
[15] Wes Simpson și Howard Greenfield „IPTV and Internet Video”,2007 , Focal Press
[16] Ismail Khalil Ibrahim “Handbook of Research on Mobile Multimedia”, 2009,
Information Science Reference
[17] Alejandro Terrazas și John Ostuni și Michel Barlow “ Java Media API’s: Cross patform Imaging, Media and Visualization “, 2002, Sams Publishing
[18] Miikka Poikselka și Georg Mayer “The IMS: IP Multimedia Concepts and services”, 2009, Wiley
[19] Sun Microsystems “Java Media Framework API Guide”, 1999, Sun Microsystems [20] Tobias Künkel “Streaming Media”, 2003, Wiley
[21] H Schulzrinne și S. Casner și R. Frederick „RTP: A Transport Protocol for real-time
applications”, 1996, http://www.ietf.org/rfc/rfc1889.txt , IETF
86
[22] H. Schulzrinne și A. Rao și R. Lanphier “Real Time Streaming Protocol”,1998,
http://tools.ietf.org/html/rfc2326 , IETF
[23] Budi Kurniawan “Program multimedia with JMF”, 2001, javaworld.com
[24] Walt Howe “Brief history of the Internet”, 1998, walthowe.com
[25] Dany Cohen “RFC-741 Specification of the Network Voice Protocol”, 1976, NSG
[26] C. Perkins “RTP and Datagram Congestion Control Protocol (DCCP)”, 2006,
http://tools.ietf.org/id/draft-perkins-dccp-rtp-02.txt, NWG
[27] D. Thaler “Border Gataway Multicast Protocol”, 2003, http://www.javvin.com/
protocol/ietf-bgmp-spec05.pdf , IETF
[28] C. Topolcic “Experimental Internet Stream Protocol, Version 2 (ST-II),
http://tools.ietf.org/html/rfc1190 , IETF
87
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Instant Audio Video Streamer (ID: 161764)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.