vrlo je ugodno i u\u010dinkovito organizirati razli\u010dite prijenose za veliku publiku zahvaljuju\u0107i tome \u0161to se segmenti mogu u\u010ditati na CDN samo jednom.<\/li>\n<\/ul>\n\nUnato\u010d jednostavnosti enginea, situacija s njim nije tako glatka kao \u0161to izgleda. Glavni problem je u tome \u0161to su se programeri tre\u0107ih strana odmaknuli od preporuka Applea, na primjer u pogledu podr\u017eanih audioformata. Konkretno, mnogi programeri su po\u010deli dodavati mogu\u0107nost rada s popularnim audio streamovima: mpeg2 video, mpeg2 audio i sl. Kao rezultat toga, morali su se stvoriti razli\u010diti formati playlista za razli\u010dite player-e.<\/p>\n
Jedan od najve\u0107ih problema HLS enginea je visoka latencija prijenosa podataka.<\/p>\n
Izvori \"zakasnelosti\"<\/h2>\n \nGlavni uzrok visoke latencije kod HLS le\u017ei u tome \u0161to su programeri stvorili engine za postizanje maksimalne kvalitete slike. Stoga parametri kori\u0161tenog intervala sli\u010dica i veli\u010dina reprodukcijskog predmemoriranja jednostavno nisu prikladni za vo\u0111enje izravnih video prijenosa. Kao rezultat toga, javlja se prili\u010dno visoka latencija u prijenosu videa, koja mo\u017ee iznositi 5-7 sekundi.<\/p>\n
S jedne strane, to nije mnogo, primjerice, za one koji gledaju film s poslu\u017eitelja video hostinga. No, za sustave video nadzora, latencija u prijenosu videa mo\u017ee imati vrlo veliku va\u017enost.<\/p>\n
Ako promatrate ured gdje se zaposlenici svako toliko udaljavaju s monitora, tada latencija od 5 sekundi nema nikakvog zna\u010daja. No, ljudi su po\u010deli prigovarati da, primjerice, prilikom prijenosa nogometne utakmice, u chatu su ve\u0107 napisali GOOOOL, a na videu toga jo\u0161 nema :). Ve\u0107 imamo niz korisni\u010dkih slu\u010dajeva gdje Ivideon prakti\u010dki treba zamijeniti Skype.<\/p>\n
Mo\u017ee li se prevladati latencija u HLS? Odgovor na ovo pitanje zvu\u010di kao izlaganje iskusnog deratizatora pred po\u010detnicima: \"Glodavce je nemogu\u0107e iskorijeniti, ali njihovu populaciju se mo\u017ee svesti na razuman minimum\". Tako je i s latencijom u HLS, ne mo\u017eemo je potpuno eliminirati, ali na tr\u017ei\u0161tu postoje rje\u0161enja koja omogu\u0107uju zna\u010dajno smanjenje latencije.<\/p>\n
Sitno rezanje<\/h2>\n \nJo\u0161 jedan minus enginea je kori\u0161tenje malih datoteka za prijenos podataka. \u010cinilo bi se da tu nema ni\u0161ta lo\u0161e?<\/p>\n
Svaka osoba koja je poku\u0161ala kopirati veliki broj malih datoteka s jednog medija na drugi, sigurno je primijetila da je brzina pisanja takvog skupa znatno ni\u017ea nego kod jedne velike datoteke iste veli\u010dine. Osim toga, intenzitet pristupa tvrdom disku znatno se pove\u0107ava, \u0161to sveukupno negativno utje\u010de na performanse cijelog ra\u010dunala. Stoga prijenos video podataka u obliku malih 10-sekundnih segmenata tako\u0111er pridonosi pove\u0107anoj latenciji motora.<\/p>\n
Ukratko sa\u017eeto sve prednosti i nedostatke HLS tehnologije.<\/p>\n
Prednosti HLS:<\/b><\/p>\n\nMogu\u0107nost rada sa svim ure\u0111ajima. Mo\u017eete gledati video na bilo kojem suvremenom ure\u0111aju, bio to pametni telefon, tablet, laptop ili stolno ra\u010dunalo. Najva\u017enije je da web preglednik bude suvremene verzije i kompatibilan s HTML5 i Media Source Extensions.<\/li>\n Odli\u010dna kvaliteta slike. Funkcija adaptivnog prijenosa podataka omogu\u0107uje dinami\u010dnu promjenu kvalitete prenesenog videa ovisno o propusnosti internetske veze, pri \u010demu algoritam nastoji zadr\u017eati kvalitetu maksimalnom.<\/li>\n Nema potrebe za slo\u017eenim pode\u0161avanjem korisni\u010dke opreme.<\/li>\n<\/ol>\n\nNedostaci:<\/b><\/p>\n\nOgrani\u010dena podr\u0161ka za rad s motorom na nekim ure\u0111ajima.<\/li>\n Visoke latencije u prijenosu slike.<\/li>\n Veliko pove\u0107anje tro\u0161kova i slo\u017eenost optimizacije zbog kori\u0161tenja datoteka malih veli\u010dina. Zbog posebnosti kontejnera nikada ne\u0107emo mo\u0107i posti\u0107i latenciju manju od veli\u010dine segmenta.<\/li>\n<\/ol>\n\nNedostaci HLS-a nadma\u0161ili su njegove prednosti i natjerali nas da tra\u017eimo alternativne opcije.<\/p>\n
\u0160to je WebRTC<\/h2>\n \nc<\/noindex>)<\/p>\nPlatforma WebRTC razvijena je od strane Googlea 2011. godine za prijenos streamanih video i audio podataka izme\u0111u pregleda\u010da i mobilnih aplikacija s minimalnom latencijom. Za to se koristi standardni protokol UDP i posebni algoritmi za upravljanje protokom. Danas je to projekt otvorenog koda koji aktivno podr\u017eava Google i razvija se.<\/p>\n
WebRTC je skup tehnologija za peer-to-peer prijenos videa i zvuka. Drugim rije\u010dima, preglednici korisnika mogu putem WebRTC-a izravno razmjenjivati podatke jedni s drugima, bez kori\u0161tenja udaljenih poslu\u017eitelja za pohranu i obradu podataka. Sve informacije tako\u0111er se obra\u0111uju u preglednicima i mobilnim aplikacijama krajnjih korisnika.<\/p>\n
Zgodnost i velike mogu\u0107nosti ove tehnologije cijenili su programeri svih popularnih preglednika. Danas je podr\u0161ka za WebRTC implementirana u Mozilla Firefox, Operi, Google Chrome (i svim preglednicima temeljenim na Chromiumu), kao i u mobilnim aplikacijama za Android i iOS.<\/p>\n
Unato\u010d svojim neosporivim prednostima, WebRTC ima nekoliko zna\u010dajnih nedostataka. <\/p>\n
Te\u0161ko\u0107e u izboru<\/h2>\n \nTehnologija WebRTC mnogo je slo\u017eenija s obzirom na mre\u017ene interakcije zbog P2P arhitekture. Te\u0161ko ju je debagirati i testirati, a mo\u017ee se pona\u0161ati nepredvidivo. Osim toga, moramo prevladati NAT i firewall, te osigurati rad u mre\u017eama gdje je UDP blokiran.<\/p>\n
Implementaciju WebRTC-a od Googlea vrlo je te\u0161ko koristiti. \u010cak postoji cijela tvrtka koja pru\u017ea usluge izrade SDK-a. Osim toga, implementaciju od Googlea bilo je vrlo te\u0161ko integrirati s na\u0161im sustavom bez ponovne kodiranja cijelog videa.<\/p>\n
Me\u0111utim, dugo smo \u017eeljeli omogu\u0107iti korisnicima rad s pravim \u201e\u017eivim\u201d videom i minimizirati ka\u0161njenje slike na ekranu u odnosu na stvarne doga\u0111aje. Tako\u0111er, imali smo \u017eelju olak\u0161ati kori\u0161tenje PTZ kamera, gdje su ka\u0161njenja kriti\u010dna.<\/p>\n
Uzimaju\u0107i u obzir da druge implementacije borbe protiv ka\u0161njenja trenutno imaju ograni\u010denu funkcionalnost i rade znatno lo\u0161ije, odlu\u010dili smo koristiti WebRTC. <\/p>\n
\u0160to smo u\u010dinili<\/h2>\n \n
Za ispravan rad WebRTC-a, prije svega, potrebno je provesti tehnolo\u0161ku modernizaciju stoga za rad s web videom. To smo i u\u010dinili.<\/p>\n
Prvo smo implementirali signalnu protokol WebRTC preko Websocket-a, kao i postavili WebRTC peer-server u oblaku koriste\u0107i SDK webrtc.org. Njegova uloga je distribucija video streamova klijentima WebRTC peer-ovima u H.264 + Opus\/G.711 formatu bez recodiranja videa.<\/p>\n
Odabrali smo Websocket kao signalni protokol zbog njegove dobre podr\u0161ke u svim popularnim web preglednicima. Na taj na\u010din mo\u017eemo zna\u010dajno smanjiti ne samo tro\u0161kove razvoja, ve\u0107 i u\u0161tedjeti vrijeme i resurse na ponovnom TCP i TLS handshake-u u usporedbi s AJAX-om.<\/p>\n
Naime, WebRTC po defaultu ne pru\u017ea signalni protokol potreban za pravilno postavljanje, odr\u017eavanje i prekid video veze u stvarnom vremenu izme\u0111u izvornih i klijentskih aplikacija.<\/p>\n
Kako bismo sami implementirali signalizacijsku tehnologiju, bilo je potrebno razviti vlastiti signalni server s podr\u0161kom za nekoliko web protokola (WebSocket, WebRTC). Tako\u0111er, omogu\u0107ili smo sigurno upravljanje sesijama i notifikacijama u stvarnom vremenu, upravljanje videom i mnogim drugim parametrima.<\/p>\n
Ograni\u010denja P2P prevladali smo smanjenjem latencije ne oslanjaju\u0107i se na P2P, ve\u0107 na UDP i upravljanje protokom usmjereno na smanjenje latencije. To je tako\u0111er ugra\u0111eno u WebRTC, jer je glavni use-case P2P razgovor kroz preglednik.<\/p>\n
U mobilnom klijentu implementirali smo plejer koriste\u0107i SDK webrtc.org, jer samo on ispravno upravlja protokom, ima sve poznate sheme Forward Error Correction (FEC), i pravilno implementira mehanizam ponovne slanja paketa za sve preglednike. Tako\u0111er je va\u017eno napomenuti da Google aktivno razvija SDK webrtc.org.<\/p>\n
Koji su rezultati implementacije WebRTC-a?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")