SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA ZAVRŠNI RAD br. 5154 Utjecaj parametara video kodiranja na iskustvenu kvalitetu mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRTC Tima Redžović Zagreb, lipanj 2017.
Sadržaj 1. Uvod... 1 2. WebRTC... 3 2.1. Početci i razvoj WebRTC-a... 3 2.2. Sustav WebRTC... 7 2.3. WebRTC arhitektura... 8 2.3.1. Elementi WebRTC tehnologije... 11 2.4. Uspostava komunikacije putem tehnologije WebRTC... 13 2.5. WebRTC na mobilnim uređajima... 16 3. Iskustvena kvaliteta... 17 4. Ispitivanje utjecaja parametara video kodiranja na iskustvenu kvalitetu mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRTC. 21 4.1. Metodologija ispitivanja... 21 4.2. Arhitektura sustava i način prikupljanja podataka... 26 5. Analiza rezultata... 29 5.1. Analiza subjektivnih ocjena ispitanika... 29 5.2. Analiza video parametara usluge... 39 5.3. Rasprava... 49 6. Zaključak... 51 7. Literatura... 52 8. Sažetak... 56 9. Summary... 57 10. Dodatak : Popis slika... 58
Pojmovnik JavaScript - skriptni programski jezik koji omogućava korisnicima dinamički interakciju s Web aplikacijom. HTML (eng. HyperText Markup Language) - prezentacijski jezik za izradu Web stranica. SIP (eng. Session Initiation Protocol) - signalizacijski protokol za pokretanje, modificiranje i raskid sjednice. Jingle - proširenje protokola XMPP koji se koristi za upravljanje VoIP sjednicama i videokonferencijama preko IP mreža. NAT (eng. Network Address Translation) - proces pretvaranja IP adrese koja se koristi u jednoj mreži u IP adresu koja se koristi u drugoj mreži. ISUP (eng. ISDN User Part ) - signalizacijski protokol koji se koristi za uspostavu i raskid telefonskih poziva u javnoj telefonskoj mreži. STUN (eng. Simple Transversal Utilities for NAT) - mrežni protokol koji omogućava klijentima koji se nalaze iza jednog ili više NAT uređaja, pronalazak njegove javne IP adrese, vrstu NAT-a iza kojeg se nalazi i vanjski port dodijeljen od strane NAT uređaja kao i originalni port unutarnjeg računala. TURN (eng. Traversal Using Relays around NAT) - protokol koji omogućava uređajima iza NAT usmjerivača da primaju podatke preko TCP ili UDP veza. ICE (eng. Interactive Connectivity Establishment) - protokol zasnovan na algoritmu koji je iterativni proces u kojem dva uređaja, oba smještena iza NAT-a, razmjenjuju adrese u pokušaju međusobne komunikacije. JSON (eng. JavaScript Object Notation) - format za razmjenu podataka, služi za reprezentaciju JavaScript objekata u obliku string.
1. Uvod Početci komunikacije u stvarnom vremenu sežu do 2006. godine kada je kompanija Google dodala komunikacijski sustav GoogleTalk u svoju uslugu elektroničke pošte Gmail. Od tada nadalje počeli su se razvijati brojni drugi dodaci (eng. plugin) s ciljem uspostave audio i video komunikacije putem Web preglednika. Međutim, tehnologija Web Real-Time Communication (WebRTC) razvijala se u suprotnom smjeru. Ona eliminira potrebu za korištenjem plugin-ova Web stranice ili aplikacije jer se video i audio komunikacija između korisnika odvija izravno u Web pregledniku [1]. WebRTC omogućuje da se između više Web preglednika brzo i jednostavno uspostavi konekcija i to bez obzira na vrstu uređaja. Ovo otvara vrata brojnim komunikacijskim uslugama između ravnopravnih čvorova (eng. peer-to-peer, P2P) kao što su: video pozivi, audio pozivi, dijeljenje datoteka, slanje tekstualnih poruka i sl. Zahvaljujući ostvarenoj direktnoj i brzoj konekciji, WebRTC ima široku primjenu i utječe na cjelokupan Web [2]. Iako je glavna svrha omogućiti komunikaciju u stvarnom vremenu putem Web preglednika, tehnologija WebRTC može također biti integrirana u ostale komunikacijske sustave primjerice: Voice over Internet Protocol (VoIP), SIP komunikacija i javna telefonska mreža. Ovo pokazuje da cilj WebRTC tehnologije nije samo ostvariti komunikaciju putem Web preglednika nego i integrirati sve mogućnosti Web-a u telekomunikacijski svijet industriju za koju se predviđa da će do 2018. godine vrijediti oko 6,5 trilijuna dolara [3] [4]. Cilj ovog rada je proučiti tehnologiju WebRTC i način na koji pojedini video parametri utječu na iskustvenu kvalitetu mobilnog višekorisničkog video poziva ostvarenog putem ove tehnologije. Naime, iako je prvi koncept WebRTC-a nastao 2011. godine, podrška za mobilne uređaje počela se razvijati 2013. godine te se do danas istražuju sve njene mogućnosti. Ovaj rad se sastoji od 6 poglavlja. U drugom poglavlju opisana je tehnologija WebRTC, razvoj tehnologije i dostignuća do danas. Također, ovdje je opisana i temeljna arhitektura WebRTC-a te svi elementi tehnologije koji su potrebni za uspostavu komunikacije. Poglavlje sadrži i opis potrebnih aplikacijsko programskih 1
sučelja (engl. Application Programming Interface, API) te opis protokolnog stoga kojeg obuhvaća WebRTC. Dodatno, u drugom se poglavlju ukratko opisuje tehnologija WebRTC na mobilnim uređajima. U trećem poglavlju objašnjen je pojam iskustvene kvalitete te je prikazan način mjerenja iste. Četvrto poglavlje opisuje način ispitivanja utjecaja parametara video kodiranja na iskustvenu kvalitetu mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRT te prikazuje arhitekturu sustava koja je bila korištena pri testiranju. U sljedećem poglavlju prikazani su rezultati ispitivanja s pripadajućim grafovima te su izvedeni zaključci o ovisnosti iskustvene kvalitete o parametrima video kodiranja. Na kraju rada slijedi zaključak, popis korištene literature, sažetci na hrvatskom i engleskom jeziku te dodatak sa popisom slika iz rada. 2
2. WebRTC Web Real-Time Communication ili WebRTC, je projekt otvorenog koda koji dodaje nove funkcionalnosti Web pregledniku. Pojavom WebRTC-a po prvi put je omogućena izravna slikovna i zvučna komunikacija u stvarnom vremenu između Web preglednika. Zahvaljujući ovoj tehnologiji Web stranica je postala kontrola, izvor i odredište komunikacije s interno ugrađenim multimedijskim stogom. Bitno je naglasiti da WebRTC nije zasebna (single) tehnologija već da je to kolekcija standarda i protokola koja se svakodnevno razvija. WebRTC pruža fleksibilnost implementacije interaktivnih komunikacijskih usluga u raznim topologijama (pointto-point, multi-to-many ili Multipoint-Conferencing Unit MCU), pri čemu nije striktno definiran određeni protokol za komunikaciju već je moguće izabrati neki od postojećih ili pisati vlastiti protokol [5]. The World Wide Web Consortium (W3C) i Internet Engineering Task Force (IETF) su 2 grupacije koje su zaslužne za definiranje: JavaScript API-ja (Application Programming Interfaces), oznaka HTML5 te osnovnih komunikacijskih protokola za uspostavu i upravljanje komunikacijskim kanalom između bilo kojeg para Web preglednika. U W3C-u grupa WebRTC definira Javascript API-je web preglednika, a u IETF-u je RTCWeb grupa zaslužna za definiranje protokola, formata podataka, sigurnosti i svih ostalih aspekata koji tu potrebni da bi se ostvarila peer-to-peer komunikacija između Web preglednika [6] [7]. One zajedno provode standardizaciju s ciljem da se definira WebRTC API koji će omogućiti korištenje Web aplikacije na bilo kojem uređaju putem sigurnog pristupa ulaznim jedinicama hardvera (web kamera, mikrofon i sl.), razmjenu medija i podataka [8]. 2.1. Početci i razvoj WebRTC-a Ideja za razvoj WebRTC-a javila se krajem 2009. godine, godinu dana nakon što je izdana inačica Web preglednika Google Chrome [9]. Tada je Chromeov tim odlučio pronaći funkcionalne razlike između Web i nativnog stolnog 3
računala te ubrzo shvatio da ne postoji zadovoljavajuće rješenje za komunikaciju u stvarnom vremenu. U to vrijeme komunikacija na Web-u odvijala se koristeći isključivo Flash ili pluginove te je podrazumijevala nisku kvalitetu i veliki napor prilikom instaliranja podrške na razne verzije Web preglednika i verzije operacijskih sustava. Razvoj tehnologije WebRTC započeo je kada je 2010. godine kompanija Google kupila tvrtke [9]: 1. On2 tvorci video kodeka VP8, 2. Global IP Solutions (GIPS) prva tvrtka koja je započela razvoj WebRTC-a, zaslužna za licenciranje komponenti potrebnih za WebRTC. Uz pomoć standardizacijskih tijela W3C i IETF, Google je nakon toga razvijao i unapređivao svoju tehnologiju, a W3C je u svibnju 2011. godine po prvi puta objavio tehnologiju WebRTC. Prvi javni nacrt prezentiran je u listopadu 2011. godine [2]. Do 2012. godine Chrome Canary (preglednik za razvojne programere) bio je vodeći po pitanju podržanosti tehnologije WebRTC, a kasnije je postao dostupan i u ostalim Web preglednicima poput Chrome, Firefox, Safari i sl. Pet godina nakon prve implementacije WebRTC-a, ova je tehnologija dosegla veliki uspjeh. Naime, 2015. godine Google je objavio sljedeće ključne točke [10]: do 2015.godine postojalo je: 2 milijarde Chrome preglednika s WebRTC-om, 1 milijarda WebRTC audio/video minuta po tjednu na pregledniku Chrome, 950 WebRTC baziranih kompanija i projekata (danas to prerasta 1200 kompanija i projekata), 5 milijardi mobilnih aplikacija koje su uključivale WebRTC. 4
Kao što je prikazano na slici 2.1.1, nakon 5 godina jedna od najzastupljenijih VoIP tehnologija postala je WebRTC. Slika 2.1.1 VoIP tehnologije [11] Za razliku od klasične VoIP tehnologije, WebRTC je nova metoda za prijenos podataka te može biti nastavak VoIP-a. Ova tehnologija, kao i VoIP, također pruža mogućnost slanja audia i videa preko IP mreže no ne može je u potpunosti zamijeniti. Usporedba ove dvije tehnologije prikazana je u nastavku [12]. Klasični VoIP WebRTC Signalizacijski protokol SIP ili H.323 nije definiran Prijenos medija RTP/RTCP RTP/RTCP Sigurnost SRTP za SIP, H.235 za H.323 SRTP NAT STUN/TURN/ICE za SIP, H.450.x za H.323 STUN/TURN/ICE Video kodek H.263, H.264 VP8 Audio kodek G.7xx verzije kodeka G.711, ilbc, isac 5
Zahvaljujući svojoj popularnosti, tehnologija WebRTC se sve više razvijala te je postala dostupna na većem broju Web preglednika. Koji su elementi podržani u kojem pregledniku pokazuje Slika 2.1.2 Zastupljenost u Web preglednicima. Boje označavaju u kojoj su mjeri pojedini elementi zastupljeni: zelena - u potpunosti; žuta - djelomično; crvena - nije podržano. Slika 2.1.2 Zastupljenost u Web preglednicima [13] Rastuću popularnost WebRTC tehnologije dokazuju brojne aplikacije koje je primjenjuju, npr. frisb - usluga koji omogućuje jeftinije razgovore (skoro) svugdje po svijetu, Plushcare - sustav koji pruža udaljenu komunikaciju s liječnikom, CubeSlam - primjer igre koja koristi WebRTC te Facebook Messenger i Snapchat koji odnedavno također koriste WebRTC prilikom video komunikacije [14]. 6
2.2. Sustav WebRTC Sustav WebRTC (Slika 2.2.1) omogućuje komunikaciju Web preglednika na različitim operacijskim sustavima i različitim uređajima (računalo, tablet, mobilni uređaj), ali i komunikaciju s prilazima (engl. gateway), SIP telefonima te Jingle klijentima. Trenutno postoji podrška za operacijske sustave Windows, Mac OS, Linux, Android i ios. Istraživanja pokazuju da će broj računala i tableta koji koriste WebRTC porasti u sljedećih nekoliko godina, a najveći porast predviđa se kod pametnih telefona [15]. Slika 2.2.1 Elementi WebRTC sustava [16] 7
2.3. WebRTC arhitektura Web aplikacije su dominantno temeljene na klijent - poslužitelj arhitekturi, gdje komunikaciju između klijenta i poslužitelja možemo podijeliti na 3 faze. Prva faza obuhvaća period u kojem klijent šalje zahtjev poslužitelju za obavljanjem određene usluge. U drugoj fazi poslužitelj obrađuje zahtjev te se rezultati obrade u fazi slanja rezultata šalju klijentu. WebRTC proširuje navedenu arhitekturu na način da između Web preglednika uvodi peer-to-peer (P2P) komunikaciju - komunikaciju između ravnopravnih čvorova. Također, za prijenos podataka može se koristiti i Multipoint Control Unit (MCU) arhitektura. Karakterističan model arhitekture temelji se na tzv. modelu SIP (engl. Session Initiation Protocol) trapezoid te se naziva WebRTC trapezoid (Slika 2.3.1). Slika 2.3.1 WebRTC trapezoid [8] Radi se o modelu gdje Web poslužitelji komuniciraju uz pomoći signalizacijskih protokola kao što su SIP, Jingle ili jedan od nestandardnih (vlasničkih) signalizacijskih protokola. 8
S različitih Web poslužitelja se preuzimaju Web aplikacije te se pokreću na Web preglednicima, a putem HTTP ili WebSocket protokola prenose se signalizacijske poruke za uspostavu/prekid komunikacije. Tok podataka odvija se direktno između Web preglednika. Jedan od češće korištenih modela je WebRTC trokut. Taj model karakterizira činjenica da oba web preglednika pokreću istu Web aplikaciju s iste Web stranice te se ne koriste nikakvi signalizacijski protokoli (Slika 2.3.2). Slika 2.3.2 WebRTC trokut [8] WebRTC tehnologija oslanja se na 3 API-ja. Svaki od njih obavlja određenu funkciju kako bi omogućio nesmetanu komunikaciju s Web aplikacijom. Jedan od API-ja je MediaStream. On omogućuje Web pregledniku da pristupa korisnikovoj kameri i mikrofonu te ostvaruje strujanje medija s tih uređaja. RTCPeerConnection drugi je API WebRTC-a. Ovo sučelje predstavlja stvarnu WebRTC konekciju i zaslužno je za upravljanje strujanjem podataka između 2 krajnja čvora (eng. peer). 9
PeerConnection API ima 2 specifična svojstva: 1. ostvaruje izravnu peer-to-peer komunikacija između web preglednika, 2. koristi UDP/IP protokol kojim se ne garantira isporuka paketa na odredište. Treći API na koji se oslanja WebRTC je DataChannel. On predstavlja glavni komunikacijski kanal kroz koji se koristi za izravan prijenos podataka od jednog do drugog krajnjeg čvora. Sve navedene arhitekture temelje se na P2P komunikaciji što u slučaju velikog broja sudionika nije uvijek najbolji odabir. Naime, ukoliko veliki broj korisnika sudjeluje u videokonferencijskom pozivu, može doći do preopterećenja lokalne širine pojasa i kapaciteta. U tim slučajevima koristi se MCU arhitektura. Za razliku od P2P komunikacije gdje se ulazni i izlazni mrežni tokovi povećavaju s porastom broja korisnika, kod MCU-a rastu samo izlazni mrežni tokovi. Smanjenje potrebnih mrežnih tokova omogućuje da više sudionika sudjeluje u komunikaciji, što je posebno izraženo na mobilnim uređajima s ograničenim CPU-om i ograničenom propusnošću. Bez obzira na različite rezolucije, kodeke i FPS-ove (engl. Frames Per Second), MCU uspješno prosljeđuje tokove podataka i provodi transkodiranje [17]. Primjer MCU arhitekture za 3 sudionika prikazan je na slici 2.3.3. Slika 2.3.3 Primjer MCU arhitekture 10
2.3.1. Elementi WebRTC tehnologije Za ispravan rad navedenih API-ja, WebRTC koristi brojne tehnologije i protokole. Cjelokupna arhitektura se dijeli na 2 sloja: sloj vezan za Web, Web aplikacije i Web API koji koriste Web programeri te sloj koji je upravlja C++ APIjem i P2P konekcijom. Elementi tehnologije su (Slika 2.3.1.1.) : 1. Web API sučelje za razvoj Web aplikacije (koristi treća strana), 2. WebRTC C++ API mehanizam koji koriste Web aplikacije za izbjegavanje korištenja dodataka u stvarno-vremenskoj komunikaciji, 3. Glasovni mehanizmi komponenta vezana za audio medij i uspostavu konekcije od zvučne kartice do mreže i između korisnika, a) mogući audio kodeci: isac,ilbc,opus, b) NetEQ dinamički jitter spremnik i algoritam za prikrivanje pogrešaka koji se koristi za prikrivanje negativnih učinaka varijacije kašnjenja i gubitka paketa te na taj način osigurava da kašnjenje bude što je moguće niže, zadržavajući pri tome najvišu kvalitetu zvuka. 4. Video mehanizam okvir za video medij, od kamere do mreže i od mreže do zaslona, 5. Transport/sjednica sadrži komponente potrebne za sjednicu (međuspremnik za kolebanje kašnjenja, P2P komunikacijske komponente, STUN/TURN, RTP i mehanizmi za prikrivanje grešaka i smanjenje kašnjenja ) [18]. 11
Slika 2.3.1.1 Model WebRTC API-ja [18] Što se tiče protokola, WebRTC se na transportnom sloju oslanja na protokol UDP kojim je omogućen prijenos audia, videa i aplikacijskih UDP paketa. Ovdje se zapravo koristi protokol RTP koji u realnom vremenu multipleksira različite tokove i kodira ih u jedinstven tok UDP paketa. S obzirom da prijenos podataka nije jedina stvar o kojoj se WebRTC mora brinuti, potrebni su i drugi mehanizmi za primjerice zaobilazak NAT-a i vatrozida, pregovaranje o parametrima za svaki tok podataka, šifriranje korisničkih podataka i sl. Primjeri takvih mehanizama su protokoli ICE, STUN, i TURN koji su potrebni za uspostavu i održavanje P2P konekcije putem UDP-a. DTLS protokol ima zadaću da pomoću šifriranja zaštiti sve podatke koji se prenose između peer-ova, a za kontrolu toka, multipleksiranje različitih tokova informacija te osiguravanje pouzdane isporuke putem UDP-a brinu se aplikacijski protokoli SCTP i SRTP. Također, WebRTC omogućuje interoperabilnost između različitih signalizacijskih protokola te eksplicitno ne definira koji se od njih mora nužno koristiti. 12
Za signalizaciju se može koristiti protokol Session Initiation Protocol (SIP), Jingle, ISDN User Part (ISUP) protokol ili brojni drugi. WebRTC također koristi i Session Description Protocol (SDP) protokol. On služi za opis parametara P2P konekcije. Važno je napomenuti da SDP ne prenosi sam medij već on opisuje parametre uspostavljene sjednice kao što su vrsta medija koja se prenosi, koji se kodeci koriste, širina pojasa i ostali metapodaci [19]. Slika 2.3.1.2 WebRTC protokolni stog [19] 2.4. Uspostava komunikacije putem tehnologije WebRTC WebRTC nudi tri načina uspostave komunikacije: izravna P2P veza, korištenje STUN poslužitelja, korištenje TURN poslužitelja. Protokoli ICE, STUN, i TURN (Slika 2.4.1) rješavaju problem oko uspostave komunikacije u stvarnom vremenu koje mogu uzrokovati NAT-ovi i vatrozidi. 13
Slika 2.4.1 Primjena STUN,TURN i ICE protokola [20] Naime, za ostvarenje peer-to-peer komunikacije obje strane moraju poznavati IP adrese i dodijeljena UDP vrata, a upravo ove informacije se ne mogu uvijek direktno razmijeniti između sudionika. Ovaj problem rješava ICE sučelje čiji je zadatak pronaći najbolji put do povezivanja 2 peer-a te ono pomaže WebRTC-u odlučiti koji je najbolji način da se zaobiđu NAT i vatrozid. U slučaju asimetričnog NAT-a, ICE će koristiti STUN poslužitelj (Slika 2.4.2 Uspostava konekcije uz pomoć STUN-a2). Njemu uređaj iza NAT-a šalje upit o svojoj IP-adresi te mu on vraća adresu s koje je upit došao. Na taj način STUN pribavlja javnu IP adresu i vrata koja pripadaju određenoj konekciji. Za signalizaciju metapodataka koristi se posrednički poslužitelj. U većini slučajeva STUN poslužitelj se koristi jedino prilikom uspostave konekcije, a nakon što je uspostavljena sjednica podaci se direktno šalju između sudionika. 14
Posrednički poslužitelj Slika 2.4.2 Uspostava konekcije uz pomoć STUN-a [6] Ukoliko se putem STUN poslužitelja ne može uspostaviti konekcija, ICE može koristiti TURN (Slika 2.4.3). To je ekstenzija STUN-a te se često koristi u slučaju simetričnog NAT-a. On kao i STUN također pribavlja javnu IP adresu, ali i vrata od poslužitelja u javnom Internetu. Zahvaljujući ovome, sudionik može primati medij od svih koji imaju mogućnost poslati paket putem Interneta. Kao i kod STUN poslužitelja, TURN za signalizaciju metapodataka koristi posrednički poslužitelj. U slučaju kada se koristi TURN podaci se prenose kroz poslužitelja, a ne direktno između sudionika [17]. Posrednički poslužitelj Slika 2.4.3 Uspostava konekcije uz pomoć STUN-a [6] 15
2.5. WebRTC na mobilnim uređajima Aplikacije koje se nalaze na mobilnim uređajima ili u obliku JavaScript-a unutar Web preglednika komuniciraju s Web aplikacijskim poslužiteljima i na taj način omogućuju komunikaciju između različitih uređaja. Nakon uspostave konekcije, medij između uređaja se prenosi izravno putem peer-to-peer veze. Prilikom prijenosa putem Interneta, ova P2P komunikacija je jednostavna, besplatna i ne zahtjeva nikakvu dodatnu infrastrukturu. No, kvaliteta usluge nije osigurana i ona ovisi o uvjetima u mreži i karakteristikama krajnje-korisničkog uređaja (npr. procesor, memorija, veličina ekrana). U idealnom WebRTC scenariju krajnji korisnici koriste računala dobrih performansi, žičnu ili bežičnu vezu i relativno stabilnu mrežu te se o ovim uvjetima komunikacija odvija bez velikih smetnji. Problem nastaje kod mobilnih uređaja koji koriste 3G, 4G ili bežičnu mrežu, često izmjenjuju iste te time ostvaruju promjenjivu propusnost. Ovo uvelike utječe na iskustvenu kvalitetu korisnika, a WebRTC tehnologija za sada ne uspijeva u potpunosti riješiti ovaj nedostatak. Tablica 2.5-1 prikazuje usporedbu preporučenog maksimalnog broja korisnika koji sudjeluju u jednoj sesiji za računala i mobilne uređaje te pokazuje ograničenje korištenja tehnologije WebRTC na mobilnim uređajima [21]. Tablica 2.5-2 Preporučeni maksimalni broj sudionika za pojedine uređaje i arhitekture [22] Desktop (računalo) Mobilni uređaj Maksimalno sudionika* P2P MCU P2P MCU Audio 12 22 8 14 Audio i video 6 10 4 6 * Preporučeni maksimalni broj sudionika u sesiji, ovisi o dostupnoj širini frekvencijskog pojasa te o različitim audio/video kodecima 16
3. Iskustvena kvaliteta Razvojem višemedijskih i stvarno-vremenskih usluga fokus se pomaknuo s tehnologije na korisnike i njihove zahtjeve. Ugrađeni mehanizmi usluga mogu uvelike utjecati na način slanja podataka i na parametre poput kašnjenja, brzine prijenosa i gubitaka paketa. Upravo ovi parametri utječu na iskustvenu kvalitetu krajnjeg korisnika. Za komunikacijske usluge definirana su 2 pristupa kvaliteti: 1. Kvaliteta usluge (eng. Quality of Service, QoS), 2. Iskustvena kvaliteta usluge (eng. Quality of Experience, QoE). Jedna od definicija QoS-a koja se može pronaći u literaturi je sljedeća [23]: QoS predstavlja skup takvih kvalitativnih i kvantitativnih karakteristika distribuiranog multimedijskog sustava koji je potreban za realiziranje željene funkcionalnosti aplikacije. Kvaliteta usluge može se promatrati na više razina, od korisnika i aplikacije, do mreže. Bitan element u analizi predstavlja mapiranje korisničkih/aplikacijskih QoS parametara kao što su kvaliteta video signala koja se opisuje brzinom prijenosa okvira, veličinom okvira, bojom itd., u mrežne QoS parametre poput protoka (npr. veličina paketa, propusni opseg), karakteristike prometa (npr. gubitak paketa, jitter, kašnjenje) i karakteristike performansi (korekcija grešaka, fragmentacija i dr.) [24]. Dok kvaliteta usluge obuhvaća sve karakteristike vezane za određeni sustav te je primarno tehnički orijentirana, iskustvena kvaliteta je korisnički usmjeren koncept koji pokušava ustanoviti i shvatiti korisničku percepciju kvalitete usluge kako bi se poboljšala sama usluga i povećalo zadovoljstvo korisnika uslugom. Koncept iskustvene kvalitete razvijen je kao nadopuna kvalitete usluge QoS, a standardizacijsko tijelo ITU-T (eng. International Telecommunication Union Telecommunication Standardization Sector) u preporuci E.800 [25] definira iskustvenu kvalitetu usluge kao "kolektivni utjecaj performansi usluge koji određuju stupanj zadovoljstva krajnjeg korisnika uslugom". 17
Model za mjerenje iskustvene kvalitete koji bi vrijedio za sve (telekomunikacijske) usluge nemoguće je definirati zbog subjektivne prirode iskustvene kvalitete, ali je moguće odrediti pojedine modele za procjenu iskustvene kvalitete za različite tipove usluga. Ocjenjivanje iskustvene kvalitete mora biti temeljeno na utjecajnim faktorima koji mogu biti kontrolirani i koji su mjerljivi. Metode koje se koriste za ocjenjivanje se dijele na subjektivne i objektivne. Subjektivna mjerenja se oslanjanju na mišljenje korisnika dok se objektivna temelje na objektivnim mjerama (npr. točnost izvršavanja zadatka izražena u broju pogrešaka). Kod subjektivnih ispitivanja se najčešće koristi ljestvica kvantificiranja korisničkog iskustva - MOS (eng. Mean Opinion Score). Ova ljestvica nije najbolje rješenje za ocjenu kvalitete usluge jer u većini slučajeva korisnici imaju različite interpretacije ocjena te ponekad oba korisnika isto ocijene različita iskustva. Ukoliko se uzorak s promijenjenim uvjetom od interesa uspoređuje s izvornim uzorkom, tada se MOS vrijednost često naziva DMOS (eng. Degradation MOS). Za određivanje MOS-vrijednosti najčešće se koristi ACR (eng. Absolute Category Rating) skala, a za određivanje DMOS-vrijednosti DCR (eng. Degradation Category Rating) skala. Obje skale su diskretne, a korisnikov odgovor je ograničen na jednu od 5 vrijednosti prikazanih u Tablici 3-1. [26]. Tablica 3-1. MOS i DMOS vrijednosti [27] Ocjena MOS DMOS Procjena napora razumijevanja 5 izvrsno nečujno pogoršanje bez napora 4 dobro 3 prihvatljivo čujno pogoršanje, ali ne smeta primjetno pogoršanje, malo smeta bez posebnog napora osrednji napor 2 loše podnošljivo, ali smeta priličan napor 1 vrlo loše izraženo pogoršanje, jako smeta neprepoznatljivo bez izrazitog napora 18
Na slici 3.1. prikazani su faktori koji utječu na iskustvenu kvalitetu podijeljeni u tri skupine: faktori sustava - sve karakteristike sustava koje utječu na iskustvenu kvalitetu korisnika, korisnički faktori - sve karakteristike korisnika koje utječu na njegovu subjektivnu ocjenu kvalitete usluge) i kontekstni faktori - trenutni faktori iz okoline i sustava prisutni za vrijeme korištenja usluge [28]. Slika 3.1 Faktori koji utječu na iskustvenu kvalitetu korisnika [sl8] Kod mjerenja iskustvene kvalitete u višemedijskoj komunikaciji, svaka aplikacija koja omogućava takvu vrstu komunikacije zahtijeva različite mrežne parametre i ima određene zahtjeve za kvalitetom usluge kako bi usluga bila što pogodnija za korisnika. Neki od zahtjeva mogu biti: velika propusnost mreže, mali postotak gubitaka paketa, malo kašnjenje i sl. Također, pojedine aplikacije su osjetljivije na neke parametre, dok druge mogu na njih imati veću toleranciju. Prema ITU preporuci [29], u audiovizualnoj komunikaciji se utjecaj parametra na QoE mjeri tako što se sudionici komunikacije stavljaju u što prirodnije okruženje i međusobno vode aktivan razgovor. Parametri čiji se utjecaji najčešće promatraju u QoE testu su kašnjenja u prijenosu, gubitci paketa, brzina prijenosa te frekvencije osvježavanja okvira. U nastavku (Tablica 3.1-1) prikazani su zahtjevi pojedinih aplikacija za kvalitetu usluge. 19
Tablica 2.5-2 Zahtjevi za kvalitetom usluge [30] Vrsta prometa Maksimalni broj izgubljenih paketa Maksimalno jednosmjerno kašnjenje Maksimalne varijacije kašnjenja Zajamčena propusnost po sjednici VOIP 1% 200ms 30ms 12 do 106 kbps Videokonferencija 1% 200ms 30ms Veličina sesije plus 20% Prijenos videa strujanjem 2% 5s N/A Ovisi o kodiranom formatu i o video protoku Podaci promjenjivo promjenjivo promjenjivo promjenjivo Svaki test sastoji se od više scenarija te bi prema ITU preporuci [29] trebao imati barem 16 sudionika. Točan broj ovisi o željenoj preciznosti rezultata. Testno okruženje također ima utjecaj na cjelokupnu iskustvenu kvalitetu te se zato za što bolje i preciznije rezultate preporuča osigurati sljedeće uvjete [31] [29]: razina buke u pozadini trebala bi biti manje od 30 dba, osvijetljenost oko 500 lx, akustična izolacija između dvije prostorije u kojima su ispitanici treba biti bolja od 60dB, vršna luminacija od 70 do 200 cd/m 2, omjer kontrasta ekrana bez pozadinske osvjetljenosti od 30 do 50, omjer pozadinske luminacije i maksimalne luminacije ekrana približno 0,25. Po završetku određenog scenarija svaki sudionik ispunjava upitnik s pitanjima, najčešće s diskretnim odgovorima: skale s 5 razina ili da/ne odgovori. 20
4. Ispitivanje utjecaja parametara video kodiranja na iskustvenu kvalitetu mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRTC Dosadašnja istraživanja su pokazala da veliki broj faktora može utjecati na iskustvenu kvalitetu korisnika u mobilnom višekorisničkom video pozivu gdje se koristi tehnologija WebRTC [5] [32]. S obzirom na to da se svaka poruka između primatelja i pošiljatelja mora najprije pripremiti za obradu, potom kodirati zbog prijenosa te u konačnici dekodirati na strani primatelja, postoje brojna mjesta gdje može doći do kašnjenja ili ostalih pojava koje mogu utjecati na ukupnu kvalitetu usluge. Primjerice, do sada se došlo do zaključaka da, iako veće video rezolucije doprinose boljoj kvaliteti videa, one također nameću veće opterećenje sustava i dovode do zagušenja kod pojedinih širina frekvencijskog pojasa. U jednom radu, korisničko ispitivanje pokazalo je da je najbolja rezolucija 640x480 u slučaju kada je širina dostupnog frekvencijskog pojasa približno 300 kbps [32]. Ovo su samo neki od parametra koji imaju značajnu ulogu kod višekorisničkog video poziva. 4.1. Metodologija ispitivanja Prilikom ispitivanja utjecaja parametra video kodiranja na iskustvenu kvalitetu mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRTC, svi sudionici ispitivanja sudjelovali su u istim višekorisničkim video pozivima te su imali jednako testno okruženje. Ispitivanje je bilo ostvareno između troje sudionika koji su koristili pametne telefone te se poziv odvijao putem središnje komunikacijske točke u bežičnoj mreži. Za uspostavu i konfiguraciju komunikacije koristio se Licode - open source WebRTC komunikacijska platforma [33]. To je projekt otvorenog koda koji omogućuje da se u Web aplikaciju uključi komunikacija u stvarnom vremenu (npr. videokonferencija) na brz i jednostavan način. Licode se sastoji od klijentskog i poslužiteljskog API-ja. Klijentski API Erzo 21
upravlja spajanjem korisnika u virtualne sobe i tokom podataka u Web aplikacijima, a Nurve - poslužiteljski API upravlja i konfigurira same virtualne sobe. Licode je bio instaliran na prijenosom računalu Asus s Intel Core i5 procesorom brzine 2,6 GHz i 8 GB RAM-a. Na prijenosno računalu instaliran je operacijski sustav Ubuntu 14.04 LTS. Sudionici su koristili Samsung Galaxy S6 pametne telefone čije su specifikacije: operacijski sustav Android 7.0.0 Nougat zaslon Quad HD Super AMOLED zaslon od 5.1 rezolucija zaslona 2560 x 1440 prednja kamera baterija 5 MP/1080p snima video u 1440p rezoluciji pri 30 fps 2550 mah U ovom se testiranju ispitivao utjecaj 3 parametra video kodiranja na iskustvenu kvalitetu: rezolucija, FPS i brzina prijenosa (eng. bitrate). Moguće vrijednosti rezolucije bile su: 480x320 i 640x480, vrijednosti FPS-a su mogle biti 15 ili 20 te je brzina prijenosa mogla biti 300 ili 600 kbps. Ovi su se parametri konfigurirali u Licode API-ju, tj. u datoteci licode_config.js. Primjer definiranja konfiguracije prikazan je na slici 4.1.1. Cilj testiranja bio je saznati koliko se ocjene iskustvene kvalitete korisnika razlikuju za određene parametre kodiranja i na taj način odrediti minimalne zahtjeve sustava i granicu prihvatljivosti za korisnike. Slika 4.1.1 Konfiguriranje parametra video kodiranja u Licode API-u 22
Svaka osoba bila je u zasebnoj prostoriji te je sudjelovala u 8 različitih testnih scenarija, svaki u trajanju od 3 minute. Svaki scenarij sastojao se od toga da 3 ispitanika sudjeluju u višekorisničkom video pozivu te nakon toga ocjenjuju iskustvenu kvalitetu za pojedini scenarij. Predviđeno trajanje jednog scenarija bilo je 6 minuta te je uključivalo 3 minute višekorisničkog video poziva te 3 minute za ispunjavanje upitnika. Ukupno trajanje testiranja za pojedinu grupu bio je u rasponu od 70-90 min. Za ostvarenje višekorisničkog video poziva putem tehnologije WebRTC koristio se Web preglednik Chrome verzije 57.0.2987.132. Također, u svakoj su se prostoriji mjerili dodatni parametri: temperatura, relativna vlažnost, svjetlina i snaga signala čije su prosječne vrijednosti prikazane u tablici 4.1-1, a sve vrijednosti u tablici 4.1-2. Tablica 4.1-1 Prosječne vrijednosti mjerenih parametra prostorija temperatura(ºc) relativna vlažnost (%) buka (db) svjetlina (lx) snaga signala (Mbps) Room 1 23,22 45,93 50,87 169,11 108,44 Room 2 22,79 46,74 34,72 162,22 104,11 Room 3 23,08 45,68 33,64 122,56 109,89 23
Grupa Prostorija 1 2 3 4 5 6 7 8 9 Tablica 4.1-2 Vrijednosti mjerenih parametra temperatura (ºC) relativna vlažnost(%) buka (db) svjetlina (lx) snaga signala (Mbps) room1 22,5 43,5 48,8 194 130 room2 22,9 43,2 34,5 161 104 room3 22,1 43,8 33,2 140 130 room1 23,9 41,6 47,3 201 130 room2 23,7 42,1 35,9 136 104 room3 24,1 41,7 33,8 120 72 room1 21,9 59,1 49,1 179 130 room2 21,4 58,8 33,8 106 72 room3 22,2 55,7 32,3 125 130 room1 23,6 46,7 51,3 140 104 room2 23,2 46,5 36,2 119 104 room3 23,1 46,2 33,7 134 130 room1 23,1 41,9 54,5 165 104 room2 22,5 43,7 36,4 194 104 room3 23,5 41,2 33,6 110 72 room1 23,3 45,5 48,5 163 130 room2 23,1 45,6 33,7 171 117 room3 24,2 43,4 33,6 121 130 room1 21,7 50,1 51,1 161 104 room2 21,4 50,8 33,9 182 130 room3 21,1 51,7 33,8 109 117 room1 25,8 39,8 53,9 164 72 room2 24,8 41,5 34,3 201 72 room3 25,6 39,6 34,9 104 104 room1 23,2 45,2 53,3 155 72 room2 22,1 48,5 33,8 190 130 room3 21,8 47,8 33,9 140 104 24
Sveukupno je u testiranju sudjelovalo 27 osoba (21 muškarac i 6 žena) koje su bile podijeljene u 9 grupa, svaka po 3 člana. Prosječna dob sudionika je bila 21 godina, najmlađi sudionik imao je 20 godina, a najstariji 29 godina. Sudionici su najčešće bili studenti koji su koristili razne aplikacije za video komunikaciju (npr. Skype, Viber, WhatsApp i sl.) te nisu imali dodatna znanja o audio i video tehnologijama. Oni su na kraju svakoj testnog slučaja ispunjavali kratki upitnik o iskustvenoj kvaliteti. Upitnik se sastojao od pitanja o kvaliteti audia, videa, audiovideo sinkronizacije te cjelokupne kvalitete na koje su ispitanici mogli odgovoriti s ocjenama: 1 Bad, 2 Poor, 3 Fair, 4 Good i 5 Excellent. Primjer upitnika prikazan je na slici 4.1.2. Slika 4.1.2 Upitnik koji sudionik ispunjava nakon svakog testnog scenarija Testni slučajevi prikazani su u tablici 4.1-3 te su se uvijek provodili u istom redoslijedu: Tablica 4.1-3 Testni scenariji Testni scenarij (TS) FPS Bitrate Rezolucija 1 15 300 480x320 2 15 600 480x320 3 20 300 480x320 4 20 600 480x320 5 15 300 640x480 6 15 600 640x480 7 20 300 640x480 8 20 600 640x480 25
4.2. Arhitektura sustava i način prikupljanja podataka Mobilni višekorisnički video poziv između troje sudionika ostvaren je korištenjem WebRTC aplikacije koja je bila pokrenuta na Licode MCU. Komunikacija se odvijala u lokalnoj mreži gdje je svaki pametan telefon imao definiranu statičku IP adresu (192.168.1.75, 192.168.1.90, 192.168.1.150). Arhitektura cjelokupnog sustava prikazana je na slici 4.2.1. Slika 4.2.1 Arhitektura sustava prilikom testiranja Korisnici su bili smješteni u 3 različite prostorije i mogli su komunicirati zahvaljujući bežičnoj WiFi mreži (standard 802.11b). Koristio se bežični router : Asus RT- AC51U. Na prijenosnom računalu bila je instalirana platforma Licode, ono je imalo ulogu Licode poslužitelja te je predstavljalo Licode MCU. Poslužitelj se uključivao pokretanjem skripte./scripts/initlicode.sh te se na taj način pokrenule sve Licode komponente. Nakon toga se uz pomoći skripte./scripts/initbasicexample.sh 26
pokrenula Web aplikacija koja kreira videokonferencijsku sobu potrebnu za razmjenu medija između korisnika. Detaljniji postupak testiranja bio je sljedeći: 1. pokretanje Licode poslužitelj i Web aplikacije, 2. svaki korisnik na svom pametnom telefonu u Chrome-u otvara 2 taba: a) jedan u kojem se odvija višekorisnički video poziv, URL: https://192.168.1.129:3004, b) drugi u kojem se otvara URL: chrome://webrtc-internals/ (ovaj dio služi za prikupljanje podataka), 3. na prijenosnom računalu se pokreće snimanje mrežnog prometa s alatom Wireshark te se mjeri vrijeme od 3 minute, 4. nakon isteka vremena, uz pomoć webrtc-internals-a stvara se datoteka koja sadrži statistike o aktivnim WebRTC sjednicama, 5. komunikacija se prekida, zatvaraju se oba taba te korisnici ispunjavaju upitnik. Generirana datoteka sadrži statistike o aktivnim WebRTC sjednicama, a sami podaci zapisani su u JSON formatu. Primjer datoteke prikazan je na slici 4.2.2. Slika 4.2.2 JSON zapis generirane datoteke Radi lakše analize dobivenih podataka, za obradu i vizualizaciju podataka koristila se usluga testrtc dostupna na https://testrtc.com/. Osim samih podataka dobivenih iz generirane datoteke, u pozadini se snimao i mrežni promet (alatom Wireshark) kako bi se moglo nadgledati stanje u mreži i 27
saznati informacije o korištenim protokolima (Slika 4.2.4). Protokoli koji su se koristili bili su ARP,UDP, TCP, STUN, SSDP, MDNS i DTLSv1.0. Slika 4.2.3 Generirani promet iz alata Wireshark 28
5. Analiza rezultata 5.1. Analiza subjektivnih ocjena ispitanika Analiza rezultata podijeljena je na 2 dijela s obzirom na brzinu prijenosa. Prvi dio obuhvaća rezultate pri brzini 300 kbps, a drugi pri 600 kbps. Za svaki dio analizirale su se subjektivne ocjene ispitanika za audio, video te za cjelokupnu kvalitetu. Za prijenosnu brzinu 300 kbps koja se javila u testnom scenariju 1, 3, 5 i 7 na slici 5.1.1 prikazane su srednje vrijednosti ocjena za kvalitetu audia, videa i cjelokupnu kvalitetu. Iz grafa se vidi da prvi testni scenarij ima najviše srednje vrijednosti za kvalitetu audia, videa i cjelokupnu kvalitetu. Slika 5.1.1 Srednja vrijednost ocjena za testne scenarije pri prijenosnoj brzini 300 kbps s intervalima pouzdanosti razine 95% 29
Prvi testni scenarij imao je FPS 15, a rezoluciju 480x320. Distribucije subjektivnih ocjena za audio, video i za cjelokupnu kvalitetu prikazane su na slikama 5.1.2, 5.1.3, 5.1.4. Slika 5.1.2 Subjektivne ocjene za audio (TS1) Slika 5.1.3 Subjektivne ocjene za video (TS1) Slika 5.1.4 Subjektivne ocjene za cjelokupnu kvalitetu (TS1) Iz slika se može vidjeti da je najveći broj ispitanika za audio, video i cjelokupnu kvalitetu dao ocjene 3 i 4, a tek nekoliko osoba je dalo najbolju moguću ocjenu (5). Ispitanici su najgore ocijenili audio. Slika 5.1.5 prikazuje postotak korisnika koji su cjelokupnu kvalitetu video poziva ocijenili s ocjenom većom ili jednakom 3 za prvi testni scenarij. Iz grafa je vidljivo da je 96,29% korisnika dalo ocjenu veći ili jednaku 3, a najveći postotak sudionika (44,44%) ocijenio cjelokupnu kvalitetu video poziva s najvišom ocjenom (5). 30
Slika 5.1.5 Postotak korisnika s ocjenom 3 za cjelokupnu kvalitetu za TS1 Sudionici su se u upitniku također izjasnili koliko puta se aplikacija zamrznula tijekom jednog video poziva. Na slici 5.1.6 vidljivi su njihovi odgovori za prvi testni slučaj. Iz grafa je vidljivo da se najveći broj korisnika (23) izjasnio da se aplikacija nije nikada zamrznula tijekom video poziva. Slika 5.1.6 Broj puta kada se aplikacija zamrznula (TS1) Za prijenosnu brzinu 300 kbps pokazalo se da je za video i audio komponentu najgore rezultate dao peti testni scenarij, a za ukupnu kvalitetu najgore ocjene je dobio sedmi testni scenarij (Slika 5.1.7, 5.1.8, 5.1.9). 31
Slika 5.1.7 Subjektivne ocjene za audio (TS5) Slika 5.1.8 Subjektivne ocjene za video (TS5) Slika 5.1.9 Subjektivne ocjene za cjelokupnu kvalitetu (TS7) Iz slike 5.1.10 se vidi postotak ispitanika koji su dali ocjenu veću ili jednaku 3 (81,48%). Vidljivo je i da nitko od sudionika nije dao ocjenu 5 za cjelokupnu kvalitetu (0%). Također, u ovom je slučaju veći broj korisnika (4) tvrdio da se aplikacija zamrznula nekoliko puta tijekom jednog video poziva (slika 5.1.11). 32
Slika 5.1.10 Postotak korisnika s ocjenom 3 za cjelokupnu kvalitetu za TS7 Slika 5.1.11 Broj puta kada se aplikacija zamrznula (TS7) 33
U testnim scenarijima 2, 4, 6, 8 prijenosna brzina bila je 600 kbps te su za ove scenarije na slici 5.1.12 prikazane srednje vrijednosti ocjena za kvalitetu audia, videa i cjelokupnu kvalitetu. Iz grafa se vidi da osmi testni scenarij ima najviše srednje vrijednosti za kvalitetu audia, videa i cjelokupnu kvalitetu. Slika 5.1.12 Srednja vrijednost ocjena za testne scenarije pri prijenosnoj brzini 600 kbps s intervalima pouzdanosti razine 95% Pri ovoj prijenosnoj brzini rezultati su se razlikovali za pojedine komponente višekorisničkog video poziva. Za audio su najbolje ocjene korisnika postignute u osmom testnom scenariju, a za video kvalitetu i cjelokupan doživljaj kvalitete najbolji se pokazao drugi testni scenarij. Razdioba subjektivnih ocjena za audio, video i za cjelokupnu kvalitetu prikazani su na slikama 5.1.13, 5.1.14, 5.1.15. Iz slika se može vidjeti da je najveći broj korisnika za audio, video i za cjelokupnu kvalitetu dao ocjenu 4. Kao i u slučaju prijenosne brzine od 300 kbps, audio je najgore ocijenjen. 34
22 Slika 5.1.13 Subjektivne ocjene za audio (TS8) Slika 5.1.14 Subjektivne ocjene za video (TS2) Slika 5.1.15 Subjektivne ocjene za cjelokupnu kvalitetu (TS2) Na slici 5.1.16 prikazan je postotak korisnika koji su cjelokupnu kvalitetu video poziva ocijenili s ocjenom većom ili jednakom 3 za drugi testni scenarij. Vidljivo je da je da su svi korisnici dali ocjenu veću ili jednaku 3 (100%),a najveći broj korisnika (55,55%) dao ocjenu 4. 35
Slika 5.1.16 Postotak korisnika s ocjenom 3 za TS2 Što se tiče broja puta kada se aplikacija zamrznula tijekom video poziva, slika 5.1.17 pokazuje da je najveći broj korisnika (20) za drugi testni slučaj rekao da se aplikacija nije ni u jednom trenutku zamrznula. Slika 5.1.17 Broj puta kada se aplikacija zamrznula (TS2) 36
Pri istoj prijenosnoj brzini (600 kbps) pokazalo se da je za kvalitetu audia najgore bio ocjenjen četvrti testni scenarij (slika 5.1.18), a za video i cjelokupnu kvalitetu šesti testni scenarij (slika 5.1.19, 5.1.20). Slika 5.1.18 Subjektivne ocjene za audio (TS4) Slika 5.1.19 Subjektivne ocjene za video (TS6) Slika 5.1.20 Subjektivne ocjene (najgore) za cjelokupnu kvalitetu (TS6) Na slici 5.1.21 prikazan je postotak korisnika koji su cjelokupnu kvalitetu video poziva ocijenili s ocjenom većom ili jednakom 3 za šesti testni scenarij (85,19%). Iz grafa se može vidjeti je da veći broj korisnika (18,52%) dao ocjenu 3. 37
Slika 5.1.21 Postotak korisnika s ocjenom 3 Ukoliko promatramo broja puta kada se aplikacija zamrznula tijekom video poziva, slika 5.1.22 pokazuje da se za šesti testni slučaj aplikacija malo puta zamrznula te da je veći broj korisnika (24) rekao da se nije ni jednom zamrznula. Slika 5.1.22 Broj puta kada se aplikacija zamrznula (TS6) 38
5.2. Analiza video parametara usluge Iz datoteke koja se generirala nakon svakog testnog scenarija mogli su se iščitati razni statistički podaci poput: varijacija kašnjenja, gubitak paketa, prijenosne brzine za audio i video. U nastavku (Tablica 5.2-1) su prikazane prosječne vrijednosti za sve sudionike po pojedinim testnim scenarijima. Tablica 5.2-1 Vrijednosti podataka dobivene iz generiranih datoteka min. max. min. max. prosječan Bitrate (kbps) Rezolucija FPS varijacija kašnjenja za audio varijacija kašnjenja za audio varijacija kašnjenja za video varijacija kašnjenja za video gubitak paketa(%)* (ms) (ms) (ms) (ms) 300 480x320 640x480 15 65,50 145,90 55,10 133,40 20 79,15 238,45 44,40 69,70 15 90,20 255,40 51,05 95,55 20 93,45 229,70 43,15 81,00 in*:0,0275 out*:0,0095 in:0,8247 out:0,7741 in:0,5331 out:0,4398 in:0,3996 out:0,3089 600 480x320 640x480 15 84,15 237,25 56,15 144,20 20 96,75 273,00 45,35 79,7 15 100,35 226,15 62,60 106,40 20 97,10 301,25 47,40 64,25 in:0,4687 out:0,4113 in:0,0226 out:0,0134 in:0,0174 out:0,0131 in:2,7383 out:2,4187 *in dolazni tok podataka; *out odlazni tok podataka 39
Iz priloženog se može vidjeti da je prvi testni slučaj imao najmanju, a osmi najveću minimalnu varijaciju kašnjenja za audio. Najmanju minimalnu varijaciju kašnjenja za video imao je četvrti testni scenarij, a najveću drugi. Što se tiče gubitka paketa, najmanji prosječan gubitak paketa u dolaznom smjeru imao je šesti testni scenarij, a najveći osmi. Najmanji prosječan gubitak paketa u odlaznom smjeru imao je prvi testni scenarij, a najveći osmi. Gledajući sa stajališta prijenosnih brzina rezultati su sljedeći (Tablica 5.2-2) : Tablica 5.2-2 Testni slučajevi s obzirom na varijaciju kašnjenja i postotak gubitka paketa Bitrate (kbps) min. varijacija kašnjenja za audio (ms) max. varijacija kašnjenja za audio (ms) min. varijacija kašnjenja za video (ms) max. varijacija kašnjenja za video (ms) min. prosječan gubitak paketa (%) max. prosječan gubitak paketa (%) 300 TS1 TS5 TS7 TS1 TS1 TS2 600 TS8 i TS2 TS4 i TS6 TS4 TS2 TS6 TS8 S obzirom na subjektivne ocjene ispitanika i na odabrane najbolje testne scenarije, u nastavku su prikazani grafovi s promjenom brzine prijenosa, varijacijom kašnjenja za audio i video te s postotkom gubitka paketa tijekom razgovora. Na slikama 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, 5.2.6 su prikazani grafovi za prvi testni slučaj koji se pokazao najboljim za prijenosnu brzinu 300 kbps za jednog sudionika. Na svim navedenim grafovima na x-osi nalazi se vrijeme u sekundama. Za prijenosnu brzinu 300 kbps iz slike 5.2.1 može se vidjeti da je prijenosna brzina za audio tijekom razgovora bila oko 70 kbps, a iz slike 5.2.2 da je za video ona varirala oko 300 kbps te je u nekim trenucima bila i veća od zadane vrijednosti (300 kbps). 40
Slika 5.2.1 Prijenosna brzina audia za TS1 Slika 5.2.2 Prijenosna brzina videa za TS1 Iz slika 5.2.3 i 5.1.4 vidi se da je u većini slučajeva varijacija kašnjenja za audio i video bila mala te da se u prosjeku prenosilo 100 paketa. Slika 5.2.3 Varijacija kašnjenja audia za TS1 41
Slika 5.2.4 Varijacija kašnjenja videa za TS1 Što se tiče postotka gubitka paketa, on je za audio (slika 5.2.5) bio manji no za video (slika 5.2.6) još uvijek nije prelazio vrijednost od 3,5% gubitka paketa. Slika 5.2.5 Postotak gubitka paketa za audio za TS1 Slika 5.2.6 Postotak gubitka paketa za video za TS1 Što se tiče najgorih slučajeva, slikama 5.2.7, 5.2.8, 5.2.9, 5.2.10, 5.2.11, 5.2.12 su prikazani grafovi za sedmi testni slučaj koji se pokazao najgorim za prijenosnu brzinu 300 kbps. Grafovi su prikazani za jednog korisnika, a na svim navedenim grafovima na x-osi nalazi se vrijeme u sekundama. Iz slike 5.2.7 može se vidjeti da je prijenosna brzina za audio tijekom razgovora bila oko 70 kbps, ali je 42
imala veće varijacije u odnosu na najbolji testni slučaj (TS1). Slika 5.2.8 prikazuje prijenosnu brzinu za video koja također ima veće varijacije u odnosu na najbolji testni slučaj te u nekim trenucima postiže vrijednosti od 200 kbps. Slika 5.2.7 Prijenosna brzina audia za TS7 Slika 5.2.8 Prijenosna brzina videa za TS7 Slike 5.2.9 i 5.2.10 pokazuju varijacije kašnjenja za audio i video. Vidljivo je da je ona u oba slučaja veća u odnosu na najbolji slučaj (TS1). Slika 5.2.9 Varijacija kašnjenja audia za TS7 43
Slika 5.2.10 Varijacija kašnjenja videa za TS7 Na slikama 5.2.11 i 5.2.12 prikazan je postotak gubitka paketa za audio i video. Može se uočiti da su za audio (slika 5.2.11) gubici veći od 3%, za razliku od najboljeg slučaja gdje su oni bili do 3%. Za video (slika 5.2.12) su gubici također veći i iznose do 5%. Slika 5.2.11 Postotak gubitka paketa za audio za TS7 Slika 5.2.12 Postotak gubitka paketa za video za TS7 (negativni gubici paketa se zanemaruju te se oni rezultati pogreške u usluzi testrtc) 44
Na slikama 5.2.13, 5.2.14, 5.2.15, 5.2.16, 5.2.17, 5.2.18 su grafovi za drugi testni scenarij koji se pokazao kao jedan od najboljih za brzinu 600 kbps također za jednog sudionika. Na svim navedenim grafovima na x-osi nalazi se vrijeme u sekundama. Za prijenosnu brzinu 600 kbps vrijednost prijenosne brzine audia (slika 5.2.13) bila je oko 70 kbps, a za video (slika 5.2.14) je ona varirala oko 600 kpbs te je u nekim slučajevima bila potrebna veća brzina prijenosa (800 kbps), a u nekim manja (400 kpbs). Slika 5.2.13 Prijenosna brzina audia za TS2 Slika 5.2.14 Prijenosna brzina videa za TS2 Varijacija kašnjenja bila je mala i za audio (slika 5.2.15) i za video (slika 5.2.16) te se za audio prenosilo između 100 i 200 paketa, a za video između 50 i 80 paketa. 45
Slika 5.2.15 Varijacija kašnjenja audia za TS2 Slika 5.2.16 Varijacija kašnjenja videa za TS2 Postotak gubitka paketa za prijenosnu brzinu 600 kbps bio je i za audio (slika 5.2.17) i za video (slika 5.2.18) manji od 2%. Jedino u slučaju kada se prekinuo razgovor (180-a sekunda) je bio veći. Slika 5.2.17 Postotak gubitka paketa za audio za TS2 46
Slika 5.2.18 Postotak gubitka paketa za video za TS2 Za najgori slučaj (TS6) pri prijenosnoj brzini 600 kbps, na slikama 5.2.29, 5.2.20, 5.2.21, 5.2.22, 5.2.23, 5.2.24 su prikazani grafovi za prijenosnu brzinu, varijaciju kašnjenja i postotak gubitka paketa za jednog sudionika. Na svim navedenim grafovima na x-osi nalazi se vrijeme u sekundama. Slično kao i slučaju za prijenosnu brzinu 300 kbps, u najgorem ocjenjenom slučaju vidljive su razlike u odnosu na najbolji. Na slikama 5.2.39 i 5.2.20 prikazane su prijenosne brzine za audio i video. U oba slučaja vidljive su veće oscilacije prijenosnih brzina u odnosu na najbolje ocijenjeni testni slučaj (TS2). Slika 5.2.19 Prijenosna brzina audia za TS6 Iz slike 5.2.20 se može vidjeti da je prijenosna brzina u nekim slučajevima bila dosta manja od zadane (600 kbps). 47
Slika 5.2.20 Prijenosna brzina videa za TS6 Slike 5.2.21 i 5.2.22 prikazuju varijacije kašnjenja za audio i video. Slično kao kod prijenosne brzine 300 kbps, varijacije kašnjenja su više u odnosu na najbolje ocjenjeni slučaj (TS2). Slika 5.2.21 Varijacija kašnjenja audia za TS6 Slika 5.2.22 Varijacija kašnjenja videa za TS6 Postotak gubitka paketa za audio i video prikazan je na slikama 5.2.23 i 5.2.24. Može se vidjeti da za audio postotak izgubljenih paketa prelazi 6%, što je više nego što je bilo u najbolje ocijenjenom slučaju (oko 2%). 48
Slika 5.2.23 Postotak gubitka paketa za audio za TS6 Na slici 5.2.24 prikazan je gubitak paketa za video te je on također veći no što je bio u najboljem slučaju (TS2). Ovdje doseže vrijednosti do 4% izgubljenih paketa. Slika 5.2.24 Postotak gubitka paketa za video za TS6 5.3. Rasprava Iz prethodnih rezultata može se uočiti da se ocjene iskustvene kvalitete mijenjaju shodno promjeni parametara video kodiranja. Pri prijenosnoj brzini od 300 kbps najbolje ocjene imao je prvi testni scenarij koji je imao najmanju moguću ponuđenu rezoluciju (480x320) i najmanji FPS (15). Povećanje FPS-a u ovom slučaju nije značajno utjecao na ocjene ispitanika. No, povećanje rezolucije dovelo je do većih promjena te su ti testni scenariji najgore ocijenjeni. Također, za ovaj testni scenarij ispitanici su se izjasnili da se, u odnosu na ostale scenarije, u ovom najmanji broj puta zamrznula aplikacija. Sukladno ovom, najgore ocijenjeni scenariji imali su najveći broj puta kada se aplikacija zamrznula tijekom video poziva. 49