SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA ZAVRŠNI RAD br. 5794 Objektivna i subjektivna mjerenja iskustvene kvalitete mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRTC Magdalena Lisica Zagreb, lipanj 2018.
2
3
Sadržaj Pojmovnik...5 1. Uvod...6 2. WebRTC...8 2.1. Početci i razvoj...9 2.1.1. Prepreke...11 2.2. Arhitektura...12 2.2.1. Web arhitektura...16 2.2.2. Protokoli...17 2.3. Odvijanje komunikacije...17 2.3.1. Sigurnost...19 2.4. Standardizacija...20 3. Iskustvena kvaliteta tehnologije WebRTC...21 3.1. QoE mjerenja...23 4. Objektivne metrike kvalitete videa...25 4.1. VQMT- Video Quality Measurement Tool...25 4.1.1. Računanje pojave efekta zamućenja...26 4.1.2. Računanje efekta pojave blokova...28 5. Ispitivanje iskustvene kvalitete i objektivne kvalitete videa...31 5.1. Metodologija provedbe ispitivanja...31 5.1.1. WebRTC Internals...35 5.1.2. Wireshark...35 6. Analiza rezultata...36 6.1. Analiza subjektivnih MOS ocjena ispitanika...36 6.2. Analiza degradacija video poziva...37 6.3. Perspektiva slike...38 6.4. Ocjene za svaki testni scenarij...38 6.5. Objektivne metrike...40 7. Zaključak...44 8. Literatura...45 9. Sažetak...48 10. Summary...49 11. Popis slika...50 PRILOG: Primjerak upitnika sa izjavom o suglasnosti...52 4
Pojmovnik JavaScript - skriptni programski jezik koji omogućava korisnicima dinamički interakciju s Web aplikacijom. Flash - autorski softver razvijen od strane Macromedia, omogućuje web programerima da uključe animacije i interaktivni sadržaj na svoje web stranice. HTML (eng. HyperText Markup Language) - prezentacijski jezik za izradu Web stranica. HTML5 - peta i aktualna glavna inačica HTML standarda; unaprjeđuje jezik s podrškom za najnovije višemedijske komponente. HTTP - request/response protokol za komunikaciju između poslužitelja i klijenta. HTTP klijent, kao što je web preglednik najčešće inicira prijenos podataka nakon što uspostavi TCP vezu s udaljenim web poslužiteljem na određenim vratima. Web Socket - protokol za komunikaciju s računalom, drugačiji TCP protokol od HTTP-a. Oba protokola nalaze se u sloju 7 u OSI modelu i kao takvi ovise o TCP-u u sloju 4. 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. MOS (eng. Mean opinion score) - mjera koja predstavlja ukupnu kvalitetu sustava. To je aritmetička sredina prema svim pojedinačnim "vrijednostima na unaprijed definiranoj skali koju subjekt dodjeljuje njegovom mišljenju o izvedbi kakvoće sustava". 5
1. Uvod Živimo u vremenu sve zastupljenije komunikacije u stvarnom vremenu, kada očekujemo da će nam sve potrebne informacije biti odmah dostavljene. Društvene mreže, video konferencije, jednostavne komunikacije i različite suradnje su moguće upravo zbog razvijenosti komunikacije u stvarnom vremenu. Takva komunikacija pruža razmjenu informacija i interakciju s ljudima putem Interneta kao da komuniciraju licem u lice, u stvarnom vremenu. Koristi se ne samo u profesionalnom okruženju, već i u privatnom, npr. za druženje s prijateljima i članovima obitelji [1]. Najveći izazov je pružiti korisnicima izvrsnu kvalitetu usluge (eng. Quality of Service, QoS), odnosno iskustvenu kvalitetu (eng. Quality of Experience, QoE) u različitim uvjetima. WebRTC (eng. Web Real-Time Communication) je HTML5 specifikacija koja pruža mogućnost korištenja takve vrste komunikacije. Potpuno besplatna tehnologija omogućuje Web preglednicima i mobilnim aplikacijama komunikaciju u stvarnom vremenu putem jednostavnog sučelja za programiranje aplikacija (eng. Application Programming Interface, API). Jednostavnom i brzom konekcijom između ravnopravnih čvorova, tzv. peer-to-peer kominikacijom (P2P), ostvaruje se audio i video komunikacija između više Web preglednika bez potrebe za postavljanjem ikakvih dodataka u pregledniku [2]. Neki od Web preglednika koji podržavaju WebRTC su Google Chrome, Mozilla Firefox, Safari i Opera. WebRTC je široko popularan za video pozive, ali je sposoban za puno više. Tehnologija dolazi kao projekt otvorenog izvornog koda (eng. open source) koji je ugrađen u Web preglednike, ali ga možete preuzeti i usvojiti za vlastite potrebe. Korištenje prilično jednostavnog JavaScript kôda može rezultirati novim mogućnostima višemedijskih komunikacija ugrađenih u aplikacije na nove i zanimljive načine. To zauzvrat stvara živahni i dinamičan ekosustav različitih projekata otvorenog koda i okvira oko WebRTC-a, kao i komercijalne ponude tvrtki koje pomažu pri izgradnji proizvoda. WebRTC je objavljen 2011. i od tada se stalno razvija i poboljšava, stoga je i njegova popularnost sve veća [3]. Cilj ovog rada je upoznati se sa tehnologijom WebRTC, predstaviti i raspraviti subjektivne ocjene kvalitete mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRTC, kao i objektivne metrike kvalitete videa. Za ispitivanje iskustvene kvalitete provesti će se ispitivanje kojim će se prikupiti subjektivne ocjene pojedinih testnih 6
slučajeva, u kojima su mijenjane vrijednosti video parametara mobilnog višekorisničkog poziva. Istraživanja provedena u okviru ovog rada vezana su uz istraživanje u sklopu projekta Q-MANIC 1 koji se provodi na Zavodu za telekomunikacije (FER) i koji financira Hrvatska zaklada za znanost. Rad je podijeljen u 6 poglavlja. U idućem poglavlju upoznajemo se sa tehnologijom WebRTC. Uz povijesni razvoj tehnologije raspraviti će se i o arhitekturi, sigurnosti, te o načinu rada i korištenja WebRTC-a. U trećem poglavlju objašnjen je pojam iskustvene kvalitete. Opisani su načini mjerenja kvalitete, te opisani pojmovi izražavanja mjere kvalitete koji su vezani uz mjerenje kvalitete video poziva. Nakon toga opisan je način mjerenja objektivnih metrika kvalitete videa i alat koji je korišten za računanje metrika. U petom poglavlju objašnjeno je samo provođenje i ispitivanje iskustvene kvalitete mobilnog višekorisničkog video poziva ostvarenog putem tehnologije WebRTC. Opisani su korišteni uređaji, programi, kao i korišteni testni scenarija za svaku promjenu parametara video poziva. U zadnjem poglavlju provodi se analiza i prikaz podataka prikupljenih ispitivanjem. Nakon toga slijedi zaključak, popis korištene literature, sažetci na hrvatskom i engleskom jeziku te dodatak sa popisom slika iz rada. 1 https://www.fer.unizg.hr/qmanic 7
2. WebRTC WebRTC (eng. Web Real-Time Communication) je besplatan, otvoren projekt koji omogućava Web preglednicima i mobilnim aplikacijama jednostavnu komunikaciju u stvarnom vremenu korištenjem jednostavnih API-ja. WebRTC aplikacije trebaju učiniti nekoliko stvari [4]: Preuzeti audio, video ili druge podatke od klijenta, Nabaviti informacije o mreži kao što su IP adrese i priključci te ih razmijeniti s drugim klijentima WebRTC-a kako bi omogućili vezu, čak i putem NAT-ova (eng. Network Address Translation) i vatrozida, Koordinirati signalizacijsku komunikaciju za prijavljivanje pogrešaka i pokretanje ili zatvaranje sjednica, Razmjena informacija o mogućnostima medija i klijenta, poput razlučivosti i kodeka, Slanje audio, video ili druge podatke. Osnovni zahtjevi su pristup Internetu, video i audio komponente kojima se omogućuje pristup korištenja JavaScript API-ja. Glavni cilj takve tehnologije je omogućiti razvijanje bogatih i kvalitetnih RTC (eng. Real-Time Communications) aplikacija te omogućiti komunikaciju putem zajedničkog skupa protokola. WebRTC nije zasebna tehnologija već kolekcija standarda i protokola. Standardizacija za WebRTC je podijeljena između W3C 2 i IETF 3 grupa. WebRTC ne nalaže specifičan signalizacijski protokol, već provoditelji mogu birati između već postojećih protokola (SIP, Jingle, itd.) ili napisati svoje. Na taj način, WebRTC pruža fleksibilnost u postavljanju komunikacijskih usluga u raznim topologijama (point-to-point, multi-to-many ili Multipoint-Conferencing Unit MCU). Po prvi put, preglednici stupaju u interakciju izravno s drugim preglednicima. Razvoj WebRTC sustava potaknut će široko usvajanje video konferencija na Internetu. 2 https://www.w3.org/ 3 https://www.ietf.org/ 8
2.1. Početci i razvoj Krajem 2009. godine javila se ideja za razvoj WebRTC-a, više od godinu dana nakon pokretanja Web preglednika Google Chrome-a [5]. Chromeov tim potražio je funkcionalnost "rupa" između radne površine i weba. Iako je većina odstupanja već bila riješena tekućim projektima, nije bilo rješenja za komunikaciju u stvarnom vremenu (RTC). U to vrijeme samo su tehnologija Flash i poneki dodatci (eng. plugins) omogućavali RTC. Flash je ponudio nešto nižu kvalitetu i zahtijevao licencu poslužitelja. Instaliranje nekih dodataka predstavljalo je zahtjevan posao za korisnike. Takvu tehnologiju koristili su Skype, Facebook (koji koristi Skype) i Google Hangouts (koji koriste dodatak za Google Talk). Početkom 2010. godine Google je završio kupnju tvrtke On2, koja je razvila niz video kodeka (Video Partition structured video codecs, VP 4 ). On2 je uvijek postavio svoje kodeke kao zamjena za H.26x seriju kodeka, koji su bili standardizirani, patentirani i široko korišteni. Google je nastavio s kupnjom, i u svibnju 2010. godine kada je kupio Global IP Solutions (GIPS). Zatim su On2 tehnologije bila dostupna svima kao i VP8 pod nazivom WebM. Ideja je bila zamijeniti H.264 za web videozapise i tako smanjiti troškove patenta za sve, osobito za sam Google. uklanjanje jeke. U to vrijeme komponente su licencirali nekoliko velikih kupaca i bile su prisutne u proizvodima tvrtke Google, Skype, AOL, Yahoo!, Cisco i drugi. Kao i kod On2, Google je GIPSovu tehnologiju omogućio da bude javno dostupna i angažirao relevantna tijela za standarde u IETF-u i W3C-u kako bi osigurao konsenzus industrije. Izbacili su sve glasovne i video kodeke koji su imali vlasnike patenata i dodao je dodatni sloj JavaScript API kao integracijski sloj za web preglednike. Kombiniranjem tih audio i video komponenata s JavaSript sučeljem, riješila se velika rupa u web ponudi i potaknula inicijative na tržištu RTC-a. U svibnju 2011. izgrađena je prva implementaciju WebRTC-a. WebRTC je sada implementirao otvorene standarde za video, audio i podatkovnu komunikaciju u realnom vremenu bez dodataka [6]. WebRTC je stekao veliku popularnost. Postao je dostupan u preglednicima poput Chrome, Firefox, Safari i drugih. Po mnogim mjerenjima 2016. godina zabilježena je kao godina iznimnog rasta popularnosti (Slika 1). 4 https://www.webmproject.org/vp9/mp4/ 9
Google je te godine prikupio nekoliko ključnih podataka [7]: dvije milijarde Chrome preglednika s WebRTC tehnologijom, milijardu WebRTC audio/video minuta tjedno na Chrome-u, 1200 tvrtki i projekata temeljenih na WebRTC-u, 0,1 posto svih web prometa, pet milijardi preuzimanja mobilnih aplikacija koje uključuju WebRTC. Slika 1. Popularnost VoIP tehnologije 2016.godine [7] Ovime je vidljivo da WebRTC radi bolje nego bilo koja prethodna VoIP tehnologija. Uspjeh WebRTC-a proteže se i izvan Google-a. Još važnije, većina njegovog uspjeha bila je u izvornim mobilnim aplikacijama. Na primjer, Snapchat, koji je u trenutku pisanja ovog rada prošao 60 milijuna dnevno aktivnih korisnika, koristi WebRTC. Najuspješniji razvojni programer aplikacija WebRTC zapravo nije Google, već je to Facebook. Facebook-ov Messenger koristi WebRTC od početka 2015 (Slika 2). U manje od dvije godine ima više od 300 milijuna aktivnih korisnika mjesečno koji koriste svoje glasovne i video značajke. Nastavlja se dodavanje novih značajki i povećanje korisničke baze. Dodana je i mogućnost grupnog video poziva. Facebook je također objavio, da je svaki mjesec više od 245 milijuna ljudi koristilo samo video pozive. 10
Slika 2. Facebook Messenger aplikacija [7] Dodavanje WebRTC aplikacije postaje sve lakše, pa ćemo vjerojatno imati mogućnost vidjeti sve više novih, inovativnih aplikacija. Šira podrška za WebRTC pomoći će da se WebRTC probije među glavne aplikacije. Zahvaljujući velikoj mjeri društvenim mrežama, kao i sve većem broju mobilnih uređaja koji dolaze na Internet novo izvješće navodi kako će tržište WebRTC-a samo postati veće i bolje. Izvješće pod nazivom "Tržište rješenja za web komunikaciju u stvarnom vremenu (RTC): Globalna analiza industrije i procjena mogućnosti, 2015-2025" [24], navodi kako će se tržište WebRTC rješenja proširiti na CAGR od 45,2 posto do kraja 2025 [25]. Izvješće vjeruje da će tržište u Sjedinjenim Američkim Državama u narednom desetljeću rasti čak 35 posto, a slijedi zapadna Europa s rastom tržišnog udjela od 22,7 posto. Očekuje se da će tehnologija i dalje rasti u zemljama u razvoju, iako ne u istom ritmu. 2.1.1. Prepreke Uz sve ove dobre strane WebRTC-a, potrebno je i napomenuti da WebRTC ne radi svugdje [7]. Slika 3 prikazuje zastupljenost u Web preglednicima. Boje označavaju u kojoj su mjeri pojedini elementi zastupljeni: zelena - u potpunosti; žuta - djelomično; crvena - nije podržano. WebRTC ima neke velike nedostatke u Apple i Microsoftovim ekosustavima. Apple ne dopušta razvoj nijednom web pregledniku bez korištenja vlastite web-platforme, a takav preglednik ne podržava WebRTC. To znači da Safari nema podršku za WebRTC, pa ni Googleov Chrome ne može ponuditi mogućnosti za WebRTC na iphoneu i tabletu. To znači da programeri WebRTC-a trebaju izraditi izvorne mobilne aplikacije za podršku za ios, često na veći trošak i poteškoće u izgradnji web-aplikacije. Velike implementacije su i same mobilne aplikacije (koje ne upotrebljavaju preglednik), pa se čini da nije previše prepreka. Ipak, Apple je napredovao dodavanjem WebRTC-a pomoću WebKit-a koji omogućava korištenje Safari i ios preglednika. 11
Microsoftov novi Windows 10 preglednik podržava WebRTC. Skype korisnici mogu upućivati pozive s Edgea bez instaliranja dodatnog softvera. Microsoft je čak počeo koristiti WebRTC za podršku Skypeu na Linuxu i Chromebooku. Microsoft ne dopušta WebRTC u Internet Explorer (IE), preferirajući umjesto toga preseliti korisnike na Edge i Windows 10. 2.2. Arhitektura Slika 3. Sustavi i preglednici koji koriste/ne koriste WebRTC [16] WebRTC nudi programerima aplikacija mogućnost pisanja bogatih višemedijskih aplikacija koje nude komunikaciju u stvarnom vremenu bez potrebe za dodatcima, preuzimanjima ili instalacijama. Uglavnom se koristi za video, ali pruže i niz drugih mogućnosti. Svrha je izgraditi snažnu RTC platformu koja radi na više web preglednika, na više platformi. WebRTC proširuje semantiku klijent-poslužitelja uvođenjem peer-to-peer komunikacijske paradigme između preglednika. Najopćenitiji arhitektonski model WebRTC temelji se na tzv. SIP (eng. Session Initiation Protocol) trapezodi modelu (Slika 4). U tom modelu oba preglednika izvode web aplikaciju koja se preuzima sa različitih web poslužitelja. Dva web poslužitelja mogu komunicirati koristeći standardni signalizacijski protokol kao što su SIP ili Jingle. Mogu koristiti i vlastiti signalizacijski protokol. Protokol HTTP ili WebSocket prenose signalizacijske poruke putem web poslužitelja koji ih mogu mijenjati, prevoditi ili njima upravljati po potrebi. Važno je napomenuti da signalizacija između preglednika i poslužitelja nije standardizirana u WebRTC-u, jer se smatra dijelom aplikacije. Što se tiče puta podataka, PeerConnection omogućuje medijima da izravno protječu između preglednika bez ikakvih poslužitelja. Najčešći scenarij WebRTC-a najvjerojatnije će biti onaj 12
u kojem oba preglednika imaju istu web-aplikaciju preuzetu s iste web stranice. U tom slučaju trapezoid postaje trokut (Slika 5), te se ne koriste signalizacijski protokoli [8]. Slika 4. WebRTC trapezoid [8] Slika 5. WebRTC trokut [8] 13
Signalizacija se koristi za razmjenu tri vrste podataka [4]: Poruke kontrole sijednice: za inicijalizaciju ili zatvaranje pogrešaka komunikacije i izvješća. Konfiguracija mreže: u vanjskom svijetu, koja je IP adresa i priključak računala? Medijske mogućnosti: koje kodeke i rezolucije mogu upravljati moj preglednik i preglednik s kojim želi komunicirati? Razmjena informacija putem signalizacije mora se uspješno dovršiti prije početka peer-topeer (P2P) konekcije. U slučaju višekorisničkog video poziva, korištenje P2P komunikacije može doći do preopterećenje kapaciteta. U takvom slučaju se koristi MCU arhitektura (Slika 6). Kod MCU arhitekture povećanjem broja korisnika povećava se samo izlazni mrežni tokovi, a ne i ulazni kao kod P2P komunikacije. MCU uspješno prosljeđuje tokove podataka, pospješuje komunikaciju na mobilnim uređajima koji imaju ograničeni CPU i propusnost. Slika 6. MCU arhitektura [4] Kako bi preuzeli i poslali podatake, WebRTC tehnologija oslanja se na sljedeće API-je: MediaStream, RTCPeerConnection, RTCDataChannel. MediaStream omogućuje Web pregledniku pristup korisničkoj kameri i mikrofonu te ostvaruje strujanje medija s tih uređaja. RTCPeerConnection ostvaruje izravnu P2P komunikaciju između web preglednika i koristi UDP/IP protokol kojim se ne garantira isporuka paketa na odredište. RTCDataChannel predstavlja glavni komunikacijski kanal za 14
prijenos podataka od jednog do drugog krajnjeg čvora. Slika 7 prikazuje elemente arhitekture WebRTC-a koji prikazuju ulogu RTCPeerConnection [17]: Web API sučelje za razvoj Web aplikacije (koristi treća strana), WebRTC C++ API mehanizam koji koriste Web aplikacije za izbjegavanje korištenja dodataka u stvarno-vremenskoj komunikaciji, 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. Video mehanizam okvir za video medij, od kamere do mreže i od mreže do zaslona, 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). Slika 7. Model WebRTC API-ja [17] 15
2.2.1. Web arhitektura Klasična semantika web arhitekture temelji se na paradigmi klijent-poslužitelj, gdje preglednici šalju HTTP (eng. Hypertext Transfer Protocol) zahtjev za sadržajem web poslužitelju koji odgovara s odgovorom koji sadrži tražene informacije. Resursi koje pruža poslužitelj usko su povezani s entitetom poznatim po URI (eng. Uniform Resource Identifier) ili URL (eng. Uniform Resource Locator). U scenariju web aplikacije poslužitelj može ugraditi neki JavaScript kôd na HTML stranicu koju šalje natrag klijentu. Takav kôd može komunicirati s preglednicima putem standardnih JavaScript API-ja i s korisnicima putem korisničkog sučelja. WebRTC web aplikacija (obično napisana kao mješavina HTML-a i JavaScript-a) komunicira s web preglednicima putem standardiziranog WebRTC API-ja (Slika 8). WebRTC web aplikacija također komunicira s preglednikom, koristeći i WebRTC i ostale standardizirane API-jeve, kako proaktivno (npr. za pretraživanje sposobnosti preglednika) tako i reaktivno (npr. za primanje obavijesti koje generira preglednik). WebRTC API mora stoga pružiti široki skup funkcija, poput upravljanja vezama (u peer-to-peer načinu), pregovaranja, odabira i kontrole mogućnosti kodiranja / dekodiranja, kontrole medija, vatrozida i NAT elemenata. Slika 8. RTC komunikacija putem Web preglednika [8] 16
2.2.2. Protokoli RTP (eng. Real-Time Transport Protocol) je mrežni protokol za isporuku audia i videa preko IP mreža. Obično se pokreće preko protokola UDP (eng. User Datagram Protocol). RTP u stvarnom vremenu multipleksira različite tokove i kodira ih u jedinstven tok UDP paketa. Koristi se zajedno sa RTCP (RTP Control Protocol) protokolom. Dok RTP prenosi medijske tokove (npr. audio i video), RTCP se koristi za praćenje statističkih podataka o prijenosu i kvaliteti usluge (QoS) te pomaže sinkronizaciji višestrukih struja. U WebRTC-u, podatkovni paketi (u RTP) i paket povratnih informacija (u RTCP) su multipleksirani na istom priključku kako bi se smanjio broj 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. RTP je jedan od tehničkih osnova usluge VoIP i u tom se kontekstu često koristi zajedno sa signalizacijskim protokolima kao što su SIP, Jingle, ISUP ili drugi [26]. Za razmjenu softverskih i hardverskih podataka koji uključuju listu medijskih uređaja dostupnih korisniku, listu audio i video kodeka koje korisnici podržavaju, načine kriptiranja komunikacije i dr. koristi se protokol SDP (eng. Session Description Protocol). Protokolom SDP podaci se razmjenjuju tekstualnim porukama u formatu <ključ>=<vrijednost>, a razmjena prve poruke ne znači nužno postavljanje parametara na vrijednosti koje obje strane podržavaju. Razmjena poruka trajat će dok sudionici komunikacije ne predlože parametre koje svi podržavaju, ako je to moguće [9]. 2.3. Odvijanje komunikacije Sigurnosne postavke mnogih podmreža znatno su otežale uspostavljanje P2P veze između korisnika jer nije potrebno samo pronaći put iz vlastite podmreže nego i put u podmreže drugih sudionika komunikacije. Primjerice, u privatnim je mrežama moguće uspostaviti privatni adresni prostor u kojem dodjelom IP adresa upravlja vlasnik mreže. U takvim je slučajevima potrebno na rubu privatne mreže provesti prevođenje privatne u javnu adresu pri izlazu na Internet, odnosno javne u privatnu adresu pri ulazu s Interneta. To obavlja pretvarač mrežnih adresa NAT. Ove prepreke WebRTC zaobilazi uporabom protokola STUN (eng. Session Traversal Utilities for NAT) i protokola TURN (eng. Traversal Using Relays around NAT). 17
Protokol STUN omogućuje klijentskoj aplikaciji otkrivanje prisutnosti NAT-a u mreži i dobavljanje javne IP adrese i vrata (eng. port) koji joj pripadaju. Ovu uslugu uspostavlja nezavisni STUN poslužitelj koji se nalazi u javnoj mreži. Neki internetski preglednici poput Google Chrome-a ili Mozille Firefox imaju ugrađenu adresu svojih STUN poslužitelja. U drugim je slučajevima programer obvezan u web-aplikaciji definirati adresu STUN poslužitelja. Postoje slučajevi kada, uslijed velikih sigurnosnih ograničenja privatne mreže, nije moguće uspostaviti vezu sa STUN poslužiteljem. Tada je potrebno konfigurirati novi prosljeđivački poslužitelj (eng. relay server) u javnoj mreži koji će se ponašati kao P2P sudionik komunikacije. Taj će poslužitelj proslijediti promet kojeg je dobio od jednog korisnika do drugog. Protokol TURN omogućuje aplikaciji domaćinu koja se nalazi iza NAT-a dobavljanje javne IP adrese i vrata prosljeđivačkog poslužitelja koji se nalazi u javnoj mreži. Nakon dobavljanja adrese TURN poslužitelja, sudionici komunikacije mogu preko njega uspostaviti komunikaciju. Ipak, komunikacija preko TURN poslužitelja nije česta jer se u većini slučajeva komunikacija uspije uspostaviti i bez njega. Kako bi se pojednostavnio proces pronalaska puta u mreži, protokole STUN i TURN ujedinjuje protokol ICE (eng. Interactive Connectivity Establishment). Proces protokola ICE odvija se na ICE poslužitelju inkrementalnim prolaskom kroz niz koraka u kojima se utvrđuje kako je konfigurirana mreža u kojoj se nalazi pojedini sudionik komunikacije. Međutim, sudionici se najprije moraju razmjenom poruka dogovoriti koji će ICE poslužitelj koristiti. Takve poruke nazivamo ICE kandidatima, a prenose se preko poslužitelja web-aplikacije. Svaki sudionik predlaže svoj preferirani ICE poslužitelj, a razmjena ICE kandidata trajat će dok se, ako je to moguće, svi sudionici ne dogovore o istom preferiranom ICE poslužitelju. U slučaju uspješnog usuglašavanja, sudionici se spajaju na ICE poslužitelj i pokušavaju uspostaviti P2P vezu protokolom STUN. Odnosno, svaki će sudionik komunikacije pitati STUN poslužitelj koja je njihova javna adresa u internetskoj mreži. Ukoliko je korištenje protokola STUN kod jednog od sudionika komunikacije onemogućeno, ICE poslužitelj će komunikaciju omogućiti prelaskom u TURN način rada [4]. 18
2.3.1. Sigurnost Slika 9. Protokoli koje koristi tehnologija WebRTC [8] Postoji nekoliko načina na koji komunikacijski program ili dodatak za komunikaciju u stvarnom vremenu mogu ugroziti sigurnost. Ne kriptirani medij ili podaci mogu se presresti na putu između preglednika ili između preglednika i poslužitelja. Na zajedničkoj računalnoj platformi kao što je preglednik, korisnici koji imaju pristup toj platformi (tj. web aplikaciji) mogli bi pristupiti informacijama koje bi ugrozile povjerljivost komunikacije. Aplikacija može snimati i distribuirati video ili audio zapise bez da korisnik zna. Zlonamjerni softver ili virusi mogu biti instalirani zajedno s očito neškodljivim dodatkom ili aplikacijom. WebRTC ima nekoliko značajki kako bi izbjegao ove probleme. WebRTC implementacije koriste sigurne protokole kao što su DTLS i SRTP. Šifriranje je obavezno za sve komponente WebRTC-a, uključujući signalizacijske mehanizme. Sigurnosni sustav prijenosa podataka (DTLS) koristi se kako bi osigurao sve P2P komunikacije. Prepoznavanje korištenog WebRTC protokola putem protokola aplikacijskog sloja (ALPN) omogućuje uspješno prepoznavanje krajnjeg korisnika i razlikovanje od drugih DTLS korisnika. Konkretno, to omogućuje identifikaciju sjednica koja zahtijevaju zaštitu povjerljivosti od aplikacije koja upravlja signalizacijom sjednice. DTLS sjednica koristi se za pružanje ključeva za SRTP sjednicu u kombinaciji s WebRTC podatkovnim kanalom. SRTP ili podatkovni kanali mogu biti odsutni. Podatkovni kanali šalju protokol kontrole prijenosa SCTP (eng. Stream Control Transmission Protocol) preko DTLS sloja, koji se može multipleksirati sa SRTP preko istog UDP toka. WebRTC zahtijeva upotrebu ICE-a za uspostavljanje UDP-a, ali to nije obuhvaćeno identifikatorom. Zaštita 19
povjerljivosti osigurava zaštitu medija od drugih aplikacija, ali se zaštita povjerljivosti ne odnosi na poruke na podacima kanala [10]. 2.4. Standardizacija Glasovna i video komunikacija u stvarnom vremenu unutar Web preglednika su među temama koje dobivaju zamah među dvama glavnih internetska standardizacijska tijela, Internet Engineering Task Force (IETF) i World Wide Web Consortium (W3C). Vizija tih dvaju tijela je standardizacija otvorenih okvira koji omogućuju komunikaciju između preglednika. IETF i W3C zainteresirani su za različite, ali komplementarne aspekte komunikacije u stvarnom vremenu na webu. IETF zajednica razmatra probleme poput identifikacije i definicije aspekata povezanih s mrežom, uključujući kontrolne protokole, povezivanje, osnivanje i upravljanje, te odabir najprikladnijih kodera i dekodera. S druge strane, W3C uglavnom se odnosi na definiciju pravilnog JavaScript mehanizma usmjerenog na dopuštanje i osiguranje pristupa ulaznim uređajima, kao i mrežnih protokola odabranih za komunikaciju. Dvije grupe su neovisne, ali se usko surađuju i imaju mnogo zajedničkih sudionika, uključujući i autore. Cilj standardizacije je definiranje WebRTC API-ja koji omogućava web aplikaciju koja se pokreće na bilo kojem uređaju putem sigurnog pristupa ulaznim periferijama (kao što su web kamere i mikrofoni), za razmjenu medija i podataka u stvarnom vremenu s udaljenom strankom u P2P konekciji [11] [12]. 20
3. Iskustvena kvaliteta tehnologije WebRTC Komunikacija u stvarnom vremenu, ostvarena korištenjem preglednika, jako je bitna značajka za buduće web aplikacije. Koristeći komunikaciju u stvarnom vremenu, krajnjim korisnicima potrebno je omogućiti visoku razinu kvalitete audio i video usluga. Stoga, poboljšanje takve vrste komunikacije je veliki izazov za mrežnog pružatelja usluga. Višemedijske aplikacije u stvarnom vremenu ne toleriraju velike varijacije u pogledu kašnjenja i propusnog opsega. Kvaliteta usluge (eng. Quality of Service, QoS) i iskustvena kvaliteta usluge (eng. Quality of Experience, QoE) su glavne mjere koje koristimo za ispitivanje kvalitete ovakve vrste komunikacija. Stalni porast broja višemedijskih aplikacija zahtijevao je modifikaciju postojećih mrežnih protokola da bi se osigurali kvantitativni QoS parametri. Kao rezultat, započeto je nekoliko projekata koji su imali za cilj poboljšanje postojećih mrežnih protokola s mogućnošću QoS upravljanja, tj. verifikacije i održavanja željene razine kvalitete koje zahtjeva svaka pojedina aplikacija. Pojam QoS ima više definicija, a prema preporuci X.902 [15] QoS je definiran kao skup zahtjeva u pogledu kvalitete kolektivnog ponašanja jednog ili vise objekata. QoS predstavlja mogućnost dodjeljivanja različitih prioriteta različitim aplikacijama, korisnicima i tokovima podataka ili osiguranja određenog nivoa usluge za neki tok podataka. Kompleksnost QoS problema promatra se u postojanju razlika između aplikacijskih i mrežnih QoS parametara (Slika 10) [13]. Važan element u analizi predstavlja translacija korisničkih/aplikacijskih QoS parametara kao što su kvaliteta video signala koja se opisuje brzinom prijenosa okvira (30 okvira/s), veličinom okvira-a (visina širina izraženo u pikselima), bojom (bita/pikselu) itd., u mrežne QoS parametre vezane uz propusnost (npr. veličina paketa, propusni opseg), karakteristike prometa (npr. gubitak paketa, kolebanje kašnjenja, kašnjenje od kraja do kraja ) i karakteristike performansi (korekcija grešaka, fragmentacija i dr.), koja je podosta kompleksna s obzirom na nepotpuna saznanja o percepcijskim karakteristikama korisnika aplikacije, a za cilj ima translaciju aplikacijskih QoS parametara u one parametre koji opisuju protokole, sustav i mrežu. 21
Slika 10. QoS podjela [13] Rješavanje problema upravljanja QoS-om u višemedijskim telekomunikacijama zasniva se na pronalaženju efikasne raspodjele mrežnih resursa, uz ostvarenje QoS zahtjeva i visoke razine iskorištavanja resursa. QoE, (rjeđe QoX ili QX) je mjera koja pruža procjenu ljudskih očekivanja, osjećaja, percepcije, spoznaje i zadovoljstva u odnosu na određeni proizvod, uslugu ili primjenu (npr. pregledavanje weba, telefonski poziv, TV emisija) [14]. Temeljena je na društvenoj psihologiji, kognitivnoj znanosti, ekonomiji i inženjerskoj znanosti i usmjerena na razumijevanje cjelokupnih zahtjeva ljudske kvalitete. Tom mjerom želi se shvatiti korisnička percepcija kvalitete usluge i time poboljšati i samu uslugu. Glavni faktori utjecaja su: Čimbenici ljudskog utjecaja o Niska razina obrade (vizualna i auditivna oštrina, spol, dob, raspoloženje,...) o Višu razinu obrade (kognitivni procesi, socio-kulturna i ekonomska pozadina, očekivanja, potrebe i ciljevi, druge osobine ličnosti...) Čimbenici utjecaja sustava o Vrsta sadržaja o Medijski (kodiranje, razlučivanje, brzina uzorkovanja...) o Mrežne karakteristike (širina pojasa, kašnjenje,...) o Usluga povezana s uređajem (razlučivost zaslona, veličina prikaza...) Kontekstno utjecajni čimbenici o Fizički kontekst (lokacija i prostor) o Vremenski kontekst (doba dana, učestalost korištenja...) 22
o Društveni kontekst (osobni odnosi tijekom iskustva) o Ekonomski kontekst o Kontekst zadatka (više zadataka, prekidi, vrsta zadatka) o Tehnički i informacijski kontekst (odnos između sustava) Ocjenjivanje iskustvene kvalitete mora biti temeljeno na utjecajnim faktorima koji mogu biti kontrolirani i koji su mjerljivi. Kao mjerilo krajnjeg učinka na razini usluge iz perspektive korisnika, QoE je važan mjerni podatak za dizajn sustava i inženjerskih procesa. To je osobito važno za video usluge, jer zbog visokih zahtjeva za prometom, loše performanse mreže mogu vrlo utjecati na korisničko iskustvo. Pri projektiranju sustava, najčešće se uzima srednja ocjena mišljena (eng. Mean Opinion Score, MOS) kao cilj optimizacije. Zbog inherentnih ograničenja u mjerenju QoE u jednoj skalarnoj vrijednosti, često se raspravlja o korisnosti MOS-a [14]. 3.1. QoE mjerenja Prilikom vrednovanja korisnikove kvalitete razlikujemo subjektivne i objektivne metode za mjerenje iskustvene kvalitete. Procesi subjektivnog vrednovanja koriste korisnikovo mišljenje o kvaliteti usluge, a objektivni procesi vrednovanja koriste matematičke modele koji približavaju rezultate od subjektivne procjene kvalitete. Mišljenja korisnika najčešće se opisuju prosječnom ocjenom mišljenja (MOS). U tu svrhu, oznake kategorijskih skala mogu se prevesti u brojeve. Na primjer, odgovori "loši" do "izvrsni" mogu se rangirati na vrijednosti od 1 do 5, a zatim prosječno. MOS vrijednosti uvijek treba biti prijavljeno s njihovim statističkim intervalima pouzdanosti kako bi se mogao procijeniti opći sporazum između promatrača. Često se poduzimaju dodatne mjere prije procjene rezultata. Potrebno je analizirati dobivene rezultate kako bi se odbacile ocjene koje se smatraju nevaljanim ili nepouzdanim. Nevažeće ocjene teško je otkriti, jer su subjekti mogli ocijeniti bez gledanja videozapisa ili varati tijekom testiranja [19]. Postoji mnogo načina odabira pravilnih sekvenci, postavki sustava i metodologija testiranja. Nekoliko njih je standardizirano. Oni su temeljito opisani u nekoliko ITU-T preporuka (eng. International Telecommunication Union Telecommunication Standardization Sector). Standardizirana metoda testiranja obično opisuje sljedeće aspekte: koliko dugo traje eksperimentna sjednica, gdje se eksperiment odvija, koliko puta i u kojem redoslijedu svaki 23
testni scenarij treba biti pregledan, da li se ocjene uzimaju jednom po stimulusu (npr. nakon prezentacije) ili kontinuirano, jesu li ocjene apsolutne, tj. odnose se na samo jedan stimulans ili relativni (uspoređujući dva ili više podražaja) te koje su ocjene na skali korištene. Prema ITU preporuci P.920 [18], 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. Za provedbu testa potrebno je barem 16 sudionika, a svaki test podijeljen je na više scenarija. 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. 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. 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: 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/m2, omjer kontrasta ekrana bez pozadinske osvjetljenosti od 30 do 50, omjer pozadinske luminacije i maksimalne luminacije ekrana približno 0,25. 24
4. Objektivne metrike kvalitete videa Objektivne metode ocjenjivanja baziraju se na različitim metrikama koje automatski mogu procijeniti kvalitetu videa, odnosno percipiranu kvalitetu razmatranog videa. Objektivne metode ocjene kvalitete videa dijele se u tri skupine: metode ocjene kvalitete videa s potpuno dostupnim referentnim videom (eng. full reference methods FR methods), metode ocjene kvalitete videa s djelomično dostupnim informacijama o referentnom videu (eng. reduced reference methods, RR methods) i metode ocjene kvalitete videa bez dostupnih informacija o referentnom videu (eng. no-reference, NR methods). Najčešći je slučaj da referentni video nije dostupan pa je ocjena kvalitete moguća samo NR. Pristup bez referentnog testiranja svodi se na pronalazak poznatih svojstva artefakata koji se mogu pojaviti u video sadržaju kao rezultat različitih distorzija tijekom produkcije i prijenosa videa [28]. 4.1. VQMT- Video Quality Measurement Tool Najčešći artefakti koji se koriste prilikom izračun objektivnih NR video metrika su efekt pojave blokova (eng. blockiness) i zamućenja (eng. blurriness) videa [22]. Blok efekt je vjerojatno najčešća proučavana degradacija. MSU Blocking i MSU Blurring su metrike dostupne unutar MSU alata za ocjenu kvalitete video signala [23]. MSU alat za mjerenje kvalitete videa (eng. MSU Video Quality Measurement Tool-VQMT) je program za objektivnu procjenu kvalitete videa. Pruža funkcionalnost za FR, RR i NR metode. Ocjena kvalitete video zapisa je obilježje video zapisa koji prolazi kroz sustave za prijenos i obradu video zapisa, formalna i neformalna mjera opaženog pogoršanja video zapisa. Sustavi za obradu video zapisa mogu uvesti neke količine izobličenja ili artefakata u video signal pa je ocjena kvalitete video zapisa vrlo važna. Osnovna shema alata ilustrirana je na slici 11. Program pruža odgovore na sljedeća pitanja: Jedan kodek ima više zamućenja od drugog. Na kojim okvirima? Prosječna ocjena? Jedan kodek ima više blokade nego drugi. Na kojim okvirima? Prosječna ocjena? Jedan kodek ima nižu kvalitetu od drugog. Na kojim okvirima? Prosječna ocjena u PSNR (eng. Though the Peak Signal to Noise), VQM (eng. Video Quality Metric), SSIM (eng. Structural Similarity Index)? 25
Jedan od načina pohrane rezultata mjernih podataka i prosječne vrijednosti je u obliku CSV datoteke (vrijednosti odvojene zarezima). Svaki CSV sadrži vrijednosti mjernog podatka za svaki okvir, originalnog videa i referentnih, te prosječnu vrijednost mjernih podataka za svaki video. 4.1.1. Računanje pojave efekta zamućenja Slika 11. VQMT [23] Efekt zamućenja jedan je od artefakata kompresije videozapisa [27]. Glavni izvor ovog artefakta je kvantizacija transformacijskih koeficijenata tijekom kodiranja. Visokofrekventna komponenta informacija prvenstveno pati tijekom ovog procesa. Unatoč niskoj percepciji HVS-a (eng. Human Visual System) do visokofrekventnog pojasa, takvi su artefakti često vidljivi gledateljima videozapisa. Ovaj mjerni podatak omogućuje usporedbu snage zamućivanja dviju slika. Ako je vrijednost mjerne vrijednosti za prvu sliku veća, nego za drugu, to znači da je druga slika zamućenija od prve. Metoda procjene glatke slike je izračun promjene svjetline u susjedstvu trenutačnog piksela. S obzirom na video okvir kao kontinuiranu funkciju l(x, y), može se izračunati gradijent funkcije (Jednadžba 1). l = ( l x, l x ) Jednadžba 1: Gradijent funkcije Magnituda promjene svjetline može se procijeniti kao veličina gradijenta: 26
V = l = ( l x ) 2 + ( l y ) 2 Jednadžba 2: Veličina gradijenta Umjesto točnog rješenja u slučaju diskretne slike treba se koristiti razlika. Koristili smo središnju izvedbu razlike. Jednadžba 3 prikazuje aproksimaciju djelomičnog X derivata. l x l(x 1, y) + l(x + 1, y) 2 Jednadžba 3: Aproksimacija djelomičnog X derivata Dodatno, sljedeća formula korištena je za približavanje veličine gradijenta: l = l x + l x Jednadžba 4. Veličina gradijenta Slika 12. Piksel korišten za metriku zamućenja [27] Takva aproksimacija omogućuje izbjegavanje izračuna složenog kvadratnog korijena i ne smanjuje značajno preciznost. Kao rezultat toga, za izračunavanje mjernih vrijednosti za svaki piksel (Jednadžba 5) koriste se samo pikseli, tri dodavanja i dva modusna operacija (vidi Slika 12): V blurring = abs(a 1 A 2 ) + abs(b 1 B 2 ) Jednadžba 5. Izračunavanje vrijednosti zamućenja za jedan piksel 27
4.1.2. Računanje efekta pojave blokova Većina suvremenih algoritama kompresije videozapisa, uključujući MPEG-2, MPEG-4 ASP, H.263, MPEG-4 AVC / H.264 i neki drugi dijele svaki okvir u blokove unaprijed određene veličine. Tehnika kompenzacije pokreta primjenjuje se na svaki blok nakon transformacije procijenjenog ostatka. Svrha transformacije jest smanjiti zavisnost između piksela bloka. Rezultirajući koeficijenti su kvantiziranje i kodiranje pomoću kompresije bez gubitaka. Gubitak informacija tijekom kvantizacije stvara broj artefakata u komprimiranom videozapisu kao što je blokirajući efekt, efekt zamućenja, Gibbsov efekt, itd. Učinak blokiranja pojavljuje se zbog odvojenih blokova transformacije. Susjedni blokovi izobličeni su samostalno, što rezultira velikom razlikom svjetline na granicama blokova u dekodiranim sekvencama. Taj učinak postaje jači istodobno s povećanim koeficijentom kvantiza (smanjenje podataka nakon kvantizacije). Vidljivost blokiranja je dodatno povezana s značajkama HVS-a. Poznato je da su visokofrekventni artefakti (uključujući blokiranje) vidljivi u glatkim područjima nego u detaljnim područjima. Ova značajka HVS uzeta je u obzir u metričkim algoritmom uz pomoć procjene kontrasta područja. Ovaj mjerni podatak također sadrži heurističku metodu za otkrivanje rubova objekata, koji su postavljeni na rub bloka. U tom se slučaju vrijednost metričke vrijednosti spušta, točnije mjeri precizno blokiranje. Koristimo podatke iz prethodnih okvira kako bismo postigli bolju točnost. Slika 13. Piksel korišten za metriku pojave blokova [27] Metrika se izračunava za piksele na granicama od 8x8 blokova. Vrijednost metričke vrijednosti jednaka je svakoj od dviju susjednih blokova graničnih piksela (tamnosivi pikseli na slici 13). Ta vrijednost ovisi o dva faktora: veličini razlike u bojama ruba bloka i kontrast slike u blizini granica (Jednadža 6). 28
A = V 0 V 1 B = V 1 V 2 C = V 2 V 3 D = C (A + B)/2 Jednadžba 6. Izračunavanje veličina razlike u boji na granici bloka M = abs(d[1] + D[2] + D[3]) Jednadžba 7. Izračunavanje vrijednosti loma boje Svaka komponenta vektora D je razlika između produženja linija, proizvedenih vrijednostima od dva piksela sa svake strane bloka, do blokiranja granica (Slika 14). Dakle, geometrijski smisao vektora D je veličina razlike u boji na granici bloka. Slika 14. Geometrijski smisao vektora D za MSU blokiranje Kontrast blizu granice bloka izračunava se pomoću sljedećih formula: W 1 = W(abs(A[0]) + abs(b[0])) W 2 = W(abs(A[1]) + abs(b[1])) W 3 = W(abs(A[2]) + abs(b[2])) W R = (W 1 + W 3 ) W 2 Jednadžba 8. Izračunavanje vrijednosti koeficijenta kontrasta 29
Veća vrijednost kontrasta manja je koeficijent kontrasta W R. Ponašanje takvog koeficijenta postignuto pomoću oblika funkcije W (x). Važna značajka ove funkcije je sporo smanjenje brzine pri niskim vrijednostima argument. Koeficijent kontrasta je blizu jednog u glatkim područjima i ne utječe na vrijednost dobivenu metrički. S druge strane, koeficijent kontrasta je niska za kontrastne površine, što smanjuje vrijednost rezultata mjerenja. Rezultat metričke vrijednosti V R (Jednadžba 8) se može dobiti množenjem vrijednosti loma boje M i koeficijenta kontrasta W R. V block = M W R Jednadžba 9. Izračunavanje vrijednosti pojave bloka za jedan piksel 30
5. Ispitivanje iskustvene kvalitete i objektivne kvalitete videa Korištenje usluga koje se temelje na tehnologiji WebRTC pod utjecajem je brojnih različiti čimbenika. Cilj je identificirati najvažnije i najmanje utjecajne čimbenike koji utječu na mišljenja korisnika i istražiti njihov utjecaj u ovom kontekstu. To daje doprinos u procesu stvaranja preduvjeta za uspješno korištenje tehnologije WebRTC. Video kvaliteta ovisi o mrežnim pokazateljima, kao što su kašnjenje, gubitak ili širina pojasa. Kako bi se osigurala visoka razina QoE, potrebno je voditi brigu o drugim čimbenicima sustava koji nisu orijentirana na mrežu. Ovdje se može govoriti o značajkama uređaja, poput brzine jedinice središnjeg procesora (CPU), razlučivost / veličina zaslona, memorija, vrsta operativnog sustava (OS) / preglednik itd. Moramo uzeti u obzir i ostale parametre uvjeta kao što su osvjetljenje prostora, udaljenost gledanja, dob i obrazovna razina gledatelja. U ovom ispitivanju promatrali smo utjecaj različitih rezolucija, različit broj okvira u sekundi (eng. frames per second, fps), uz različite brzine prijenosa podataka (eng. bitrate). 5.1. Metodologija provedbe ispitivanja Ispitivanje iskustvene kvalitete mobilnog višekorisničkog pozive ostvarenog putem tehnologije WebRTC proveli smo testiranjem 7 različitih scenarija (Tablica 1). Svi ispitanici podijeljeni su u grupe po 3 člana, te ispitivali svaki od 7 scenarija u istim okruženjima. Svaki član grupe podijeljen je u svoju prostoriju i omogućeno mu je korištenje mobilnog uređaja Samsung Galaxy S7 (Tablica 3), preko kojeg se spaja na bežičnu WiFi mrežu. Komunikacija se odvijala u lokalnoj mreži gdje je svaki pametan telefon imao definiranu statičku IP adresu (192.168.1.70, 192.168.1.80, 192.168.1.90). Koristio se bežični usmjeritelj: Asus RTAC51U. Prije početka svakog scenarija u svakoj prostoriji mjerili su se: temperatura, relativna vlažnost, svjetlina i snaga signala (Tablica 2). Video poziv je omogućen pomoću Licode-a [20], WebRTC komunikacijske platforme, koja uspostavlja i konfigurira komunikaciju. Licode se pokretao na prijenosnom računalu Asus s Intel Core i5, procesorom brzine 2,6 GHz i 8 GB RAM-a. Korišten je operacijski sustav Ubuntu 14.04 LTS. 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 pokrenula Web aplikacija koja kreira videokonferencijsku sobu potrebnu za razmjenu medija između 31
korisnika. Za snimanje zaslona korištena je Android aplikacija DU Recorder 5, verzija 1.6.4. Arhitektura cjelokupnog sustava prikazana je na slici 15. Strelice na slici označuju strujanja između Web preglednika na svakom uređaju. Na prikazu uređaja prikazan je i razmještaj prozora u kojima su se prikazivali video tokovi govornika. Slika 15. Laboratorijsko okruženje u kojem su se provodila mjerenja Svaki od ispitanika za svaki scenarija bio je dužan učiniti sljedeće: 1. Pokrenuti Chrome preglednik, 2. Otvoriti chrome://webrtc-internals, 3. Otvoriti novu karticu u pregledniku i učitati adresu: https://192.168.1.1.129:3004, 4. Pokrenuti snimanje zaslona pomoću DU Recorder-a, 5. Sudjelovati u višekorisničkom audiovizualnom pozivu u trajanju od 2 min, 6. Nakon isteka dvije minute preći na karticu sa adresom chrome://webrtc-internals i preuzeti log datoteke (CREATE DUMP), 7. Prekinuti komunikaciju i zatvoriti preglednik, 8. Zaustaviti snimanje na DU Recorderu, 9. Ispuniti upitnik za određeni scenarij. 5 https://du-recorder.en.uptodown.com/android 32
Za vrijeme trajanja višekorisničkog poziva na prijenosnom računalu koji pokreće Licode pokrenut je i alat Wireshark koji omogćuje snimanje i analizu mrežnog prometa. Nakon dvije minute gasi se Licode naredbom sudo killal node i postavlja se konfiguracija za sljedeći scenarij. Upitnik se sastojao od pitanja o kvaliteti audia, videa, audio-video sinkronizacije te cjelokupne kvalitete na koje su ispitanici mogli odgovoriti s ocjenama: 1 Bad, 2 Poor, 3 Fair, 4 Good i 5 Excellent (Slika 16). Ispitanici su trebali označiti ukoliko se pojavila neka vrsta pogoršanja kvalitete videa: zamućenje- Blurriness, pojava blokova - Blockiness ili navesti ako su primijetili drugu vrstu pogoršanja. Bilo je potrebno označiti i koliko puta se aplikacija zamrznula tijekom trajanja video poziva: nijednom- Not once, jednom- Once, dva puta- Two times, više puta- Several times. Slika 16. Upitnik koji sudionik ispunjava nakon svakog testnog scenarija Moguće vrijednosti rezolucije bile su: 120x180, 180x240, 240x360 i 360x480 piksela. Vrijednosti FPS-a su mogle biti 15 ili 20 te je brzina prijenosa mogla biti 100, 150, 200 ili 300 kbps. Tablica 1: Naziv i karakteristike ispitivanih testnih scenarija Ime testnog scenarija: TC1 TC2 TC3 TC4 TC5 TC6 TC7 Karakteristike(rezolucija/frekvencija slike/brzina prijenosa) 360x480 15fps 300kbps 120x180 15fps 100kbps 120x180 20fps 200kbps 180x240 15fps 200kbps 240x360 15fps 150kpbs 240x360 15fps 200kpbs 240x360 20fps 300kbps 33
U ispitivanju je sudjelovalo 27 osoba (20 žena i 7 muškaraca), svaki scenarij zahtijevao je 2 minute višekorisničkog poziva. Svi ispitanici su studenti, koji u prosijeku imaju 22 godine (najmlađi ispitanik 20, najstariji 23 godine), a aplikacije kojima su se ranije koristili za video komunikaciju su najčešće Skype, Viber i WhatsApp. Prije provođenja ispitivanja, svakoj grupi ispitanika dane su upute o proceduri testiranja, objašnjeni su im upitnici, te su potpisali suglasnost da pristaju sudjelovati u ispitivanju i da se snima video tijekom njihovog razgovora. U prilogu ovog rada nalazi se primjer suglasnosti kao i primjerak upitnika. Kao kompenzacija za sudjelovanje u ispitivanju ispitanicima su podijeljene USB memorije. Tablica 2. Vrijednosti mjerenih parametara za svaku korištenu prostoriju Grupa Prostorija Temperatura ( C) Relativna vlažnost (%) Buka (db) Svjetlina (lx) 1 1 27,1 36 45,8 0,48 2 27,7 35,6 34,5 0,52 3 28 34,8 33,4 0,37 2 1 27 34,2 35,6 0,44 2 27,1 34,5 36,7 0,45 3 27,8 34,5 33,6 0,48 3 1 27,2 35,7 34,5 0,52 2 27 35,4 33,4 0,54 3 26,9 34,8 33,4 0,51 4 1 26,7 35,4 33,3 0,52 2 26,7 35,1 42,6 0,44 3 26,8 35,2 33,4 0,35 5 1 23,7 36,2 33,5 0,57 2 24 39,9 34,7 0,67 3 23,8 33,1 33,9 0,39 6 1 25,5 33,5 37,5 0,42 2 25,6 33,5 39 0,42 3 25,7 33,5 37,8 0,64 7 1 25,7 33,7 37,8 0,64 2 25,7 34,7 37,4 0,58 3 25,6 33,5 37,5 0,42 8 1 26 36,3 53,6 0,45 2 25,3 37,5 34,5 0,64 3 26,1 36,4 34,1 0,52 9 1 24,8 36 39 0,43 2 24 35,2 33,5 0,59 3 25 35,6 39,8 0,47 34
Tablica 3. Karakteristike korištenih mobilnih uređaja CPU 4x Mongoose 2,3 GHz + 4x Cortex A53 1,6 GHz ZASLON 5,1 Super AMOLED, 577 ppi, Gorilla Glass 4 REZOLUCIJA ZASLONA 2560 x 1440 PREDNJA KAMERA BATERIJA 5 MP/QHD, f/1.7, 22 mm 3000 mah 5.1.1. WebRTC Internals Chrome: // webrtc-internals je unutarnja kartica Chrome koja sadrži statistike o aktivnim WebRTC sjednicama (Slika 17). Može se koristiti za praćenje toka WebRTC sjednica kako bi se utvrdilo probleme tijekom razvoja ili implementacije. Webrtc-internals omogućuje skidanje datoteke koja koristi JSON format za zapis podataka [21]. Slika 17. WebRTC internals [21] 5.1.2. Wireshark Wireshark 6 je besplatan analizator prometa, otvorenog koda. Koristi se za rješavanje problema s mrežom, analizu, razvoj softvera i komunikacijskih protokola i obrazovanje. Snimanjem prometa na whiresharku tijekom ispitivanja uočeni su sljedeći protokoli: RTP, RTCP, ARP,UDP, TCP, STUN, SSDP, MDNS i DTLSv. 6 https://www.wireshark.org/ 35
MOS ocjena 6. Analiza rezultata 6.1. Analiza subjektivnih MOS ocjena ispitanika Slika 18 prikazuje srednje subjektivne ocjene za kvalitetu audia, videa, AV sinkronizacije i za ukupnu kvalitetu višekorisničkog video poziva svakog testnog scenarija. Vidimo da najvišu srednju vrijednost ocjene za audio kvalitetu ima TC6. TC1 ima najvišu ocjenu za kvalitetu videa, AV sinkronizacije, te ukupnu kvalitetu. Možemo vidjeti kako upravo TC1 za ostvarenje video poziva koristi najviše korištene vrijednosti brzine prijenosa i rezolucije, a vrijednost FPS-a je 15. Nakon TC1, najviše ocjene ima TC7 koji koristi istu brzinu prijenosa kao i TC1, 300 kbps, ali koristi viši FPS, te manju rezoluciju. Prema tim podatcima vidimo da je upravo veća brzina prijenosa osigurala veću kvalitetu usluge za korisnika. Utjecaj brzine prijenosa možemo vidjeti i usporedbom TC5 i TC6 koji koriste različitu brzinu prijenosa, ali iste ostale parametre. TC6 koji ima koji koristi brzinu od 200kbps ima veće ocjene za sve komponente, od TC5 koji koristi brzinu od 150kbps. Najniže ocjene za sve komponente ima TC2, koji ujedno koristi najniže vrijednosti brzine, FPS-a i rezolucije. Audio Video AV sync Overall 4,5 4 3,5 3 2,5 2 1,5 1 0,5 0 TC1: 360x480 15fps 300kbps TC2: 120x180 15fps 100kbps TC3: 120x180 20fps 200kbps TC4: 180x240 15fps 200kbps TC5: 240x360 15fps 150kbps TC6: 240x360 15fps 200kbps TC7: 240x360 20fps 300kbps Audio 3,63 3,296 3,481 3,555 3,333 3,704 3,63 Video 3,741 2,407 3,222 3,355 3,26 3,593 3,63 AV sync 3,63 2,777 3,333 3,37 3,222 3,481 3,555 Overall 3,741 2,888 3,407 3,555 3,26 3,555 3,593 Slika 18. Grafički i tablični prikaz MOS ocjena za pojedine testne scenarije 36
% 6.2. Analiza degradacija video poziva Slika 19 prikazuje postotak slučajeva u kojima su sudionici primijetili da je došlo do zamućenja, pojave blokiranja ili zamrzavanja video poziva u odnosu na ukupan broj prikaza testnog scenarija. Svaki je testni scenarij bio prikazan jednom za svakog ispitanika. Vidimo da su se ove degradacije primijetile barem jednom u svim scenarijima. Zamućenje tijekom video poziva primijećeno je u 59,26% slučajeva za TC2, TC3 i TC4. Za razliku od ostalih scenarija u tim testovima koristi se najniža rezolucija. Za TC7 taj postotak je najniži i iznosi 37,04%, vidimo da taj scenarij ne koristi najvišu rezoluciju, ali koristi najvišu vrijednost FPSa uz visoku rezoluciju. Blokiranje slike prilikom video poziva u najvišem postotku je primijećeno kod TC2, a najniži postotak od 7,41 % kod TC1 i TC4. Kod TC1 i TC4 vrijednosti FPS-a su 15, dok TC1 za rezoluciju od 360x460ps koristi brzinu prijenosa od 300kbps, TC4 za rezoluciju od 180x240ps koristi brzinu od 200kbps. Možemo vidjeti da te karakteristike nisu dovele do blokiranja. Najveći postotak primijećenog zamrzavanja videa pojavio se kod TC5 jer za rezoluciju od 240x360ps, uz FPS 15, koristi brzinu prijenosa od 150kbps. Možemo zaključiti da je do toga dovelo korištenje niže brzine prijenosa za visoku rezoluciju. Najniži postotak od 3,7% se javio kod TC4 i TC1, koji koriste dobre omjere brzine prijenosa i rezolucije. Blurriness Blockiness Frozen 70 60 50 40 30 20 10 0-10 59,26 59,26 59,26 48,15 48,15 48,15 44,44 40,74 37,04 37,04 37,04 29,63 25,93 22,22 25,93 14,81 11,11 7,41 7,41 3,7 3,7 TC1 TC2 TC3 TC4 TC5 TC6 TC7 Testni scenarij Slika 19. Postotak testnih scenarija kod kojih je primijećeno zamućenje, blokiranje i zamrzavanja videa za svaki testni scenarij 37
6.3. Perspektiva slike U nekim testnim scenarijima prikaz korisnika bio je krupniji, korisnik nam je djelovao bliže, suprotno tome korisnici su bili udaljeniji i samim time imali smo više prikazanih komponenti. Ispitanici su označili Closer ako im se sviđa bliži prikaz korisnika ili Further ako preferiraju udaljeniji prikaz. Rezultati su prikazani na slici 20. 4; 15% Closer Further 23; 85% 6.4. Ocjene za svaki testni scenarij Slika 20. Rezultati ispitivanja perspektive Sljedeće slike (Slika 21 Slika 26) prikazuju distribucije subjektivnih ocjena za audio, video, sinkronizaciju audia i videa, te za cjelokupnu kvalitetu pojedinih testnih scenarija (karakteristike prikazane u Tablici 1). Za TC1 (Slika 21) vidimo da je najveći broj korisnika za audio, video i za cjelokupnu kvalitetu dao ocjenu 4, dok ocjenom 1 nije ocjenjena nijedan parametar kvalitete. Na slici 22 za TC2 vidimo raznolike vrijednosti ocjena. Za audio kvalitetu je najviše puta dodijeljena ocjena 4, za video 2, a za sinkronizaciju i ukupnu kvalitetu ocjena 3. Testnom scenariju TC3 (slika 23) je za audio kvalitetu najveći broj ispitanika dodijelio ocjenu 3, a za ostale parametre ocjenu 4. Dodijeljena je jedna jedinica za audio kvalitetu. Na slici 24 prikazana je distribucija ocjena za TC4. Za sve parametre kvalitete je najveći broj korisnika dao ocjenu 4, ocjena 1 nije dana za nijedan parametar. TC5 (slika 25) za audio i video parametre ima najviše dodijeljenih ocjena 4, a za ostale parametre ocjena 3, a TC6 (slika 26) za sve parametre ima najviše dodijeljenih ocjena 4, te nema dodijeljenih ocjena 1. 38
Ukupan broj ocjena Ukupan broj ocjena Ukupan broj ocjena Ukupan broj ocjena Vrlo raznoliki prikaz vidimo na slici 27 za TC7. Tom testnom scenariju za sve parametre kvalitete najveći broj korisnika dao je ocjenu 4, ali ujedno je scenarij sa najvećim brojem dodijeljenih ocjena 5 za sve parametre kvalitete, kao i ocjena 1. Po ovakvoj distribuciji ocjena, možemo zaključiti da su najveće vrijednosti ocjena dodijeljene za testni slučaj TC1, koji ima najviše dodijeljenih ocjena 4 od ostalih testnih slučaja za sve parametre kvalitete, te najmanje dodijeljenih ocjena 1 i 2. TC1 TC2 18 14 8 15 7 8 1 5 14 3 7 0 10 5 1 2 3 4 5 ocjena 8 12 8 11 5 14 6 2 9 2 1 11 7 5 1 3 01 1 2 3 4 5 Ocjena AUDIO VIDEO AV sync OVERALL AUDIO VIDEO AV sync OVERALL Slika 21. Prikaz subjektivnih ocjena za TC1 Slika 22. Prikaz subjektivnih ocjena za TC2 TC3 TC4 13 11 14 8 8 11 2 3 6 13 9 2 1 1 0 2 2 1 2 3 4 5 Ocjena 15 12 12 10 13 10 4 0 2 9 12 21 0 0 3 3 1 2 3 4 5 Ocjena AUDIO VIDEO AV sync OVERALL AUDIO VIDEO AV sync OVERALL Slika 23. Prikaz subjektivnih ocjena za TC3 Slika 24. Prikaz subjektivnih ocjena za TC4 39
Ukupan broj ocjena Ukupan broj ocjena Ukupan broj ocjena TC5 TC6 13 11 12 9 13 10 12 2 5 11 3 12 5 7 1 20 1 2 3 4 5 Ocjena 9 5 13 3 8 3 6 15 3 7 3 0 2 1 2 3 4 5 Ocjena AUDIO VIDEO AV sync OVERALL AUDIO VIDEO AV sync OVERALL Slika 25. Prikaz subjektivnih ocjena za TC5 Slika 26. Prikaz subjektivnih ocjena za TC6 TC7 13 10 5 4 14 6 6 3 3 5 2 2 3 7 9 7 2 1 2 3 4 5 Ocjena AUDIO VIDEO AV sync OVERALL Slika 27. Prikaz subjektivnih ocjena za TC7 6.5. Objektivne metrike Za dobivanje objektivnih metrika izrezali smo dijelove videa za svaki testni scenarij u svakoj grupi. Izrezani video prikazuje dvije minute višekorisničkog poziva, te smo svaki od tih videa izrezali na 3 dijela za svaku prikazanu osobu (Slika 28). Za jednu grupu i jedan testni scenarij imamo ukupno 9 isječaka. U našem primjeru mobilne uređaje i osobe razlikovati ćemo po bojama. Tako imamo crni, crveni i smeđi uređaj. Crni na crnome označuje originalni prikaz 40
osobe na crnom mobitelu, crni na crvenome označuje osobu sa crnim mobitelom prikazanu na crvenome itd. VIDEO 1:Crni na crni VIDEO 2:Smedi na crni VIDEO 3:Crveni na crni Slika 28. Prikaz rezanja dvominutnog višekorisničkog poziva Svaki izrezani video korišten je za izračun efekta pojave blokova i zamućenja videa, pomoću VQMT alata. Za originalni video korišten je video isječak koji prikazuje osobu koja koristi uređaj sa kojeg je video snimljen. U našem primjeru to bi bio crni na crnome (crveni na crvenome ili smeđi na smeđem). Kao ostala 2 referentna videa koristi se crni na crvenome uređaju i crni na smeđem uređaju. Nakon provlačenja videa svih grupa, svih testnih scenarija, rezultati mjernih podataka i prosječne vrijednosti pohranjuju se u skupu CSV datoteka. Za svakog ispitanika dobili smo dvije CSV datoteke, jedna sadrži vrijednosti za mjerenje efekta blokova, a druga pojavu zamućenja, iz kojih su očitane prosječne vrijednosti. Na sljedećim slikama (Slika 29-34) prikazane su dobivene prosječne vrijednosti mjerenih metrika za pojedine testne scenarije, pojedenih grupa. Korišten je dani primjer te su prikazane vrijednosti za svaki korišten uređaj, te osobu prikazanu na tom uređaju. Slika 29 prikazuje vrijednosti metrike zamućenja dobivene prilikom ispitivanja grupe 6 za TC7. U tom mjerenju dobivene su najniže vrijednosti zamućenja. Za tu grupu pojava blokova je bila najizraženija na smeđem uređaju (Slika 30). Najveće vrijednosti pojave blokova pojavile su se prilikom ispitivanja grupe 3, za vrijeme testnog slučaja TC4. U tom slučaju smeđa osoba imala je vrijednosti pojave blokova iznad 100 (Slika 32). Vrijednosti zamućenja za tu grupu i TC4 bile su od 11 do 17 (Slika 31). Na slici 33 i 34 prikazani su rezultati za testni slučaj TC6, prilikom ispitivanja grupe 7. Prikazane vrijednosti su približne prosječnim vrijednostima 41