A rendszer fejlesztésének első napjaitól kezdve a felhőalapú videómegjelenítéssel kapcsolatban egy problémával szembesültünk, amelynek megoldása nélkül búcsút mondhattunk volna az Ivideonnak – ez volt a mi Everestünk, amelynek megmászása rengeteg energiát felemésztett, de most végre sikerült a jégcsákányunkat beverni a keresztplatformos rejtély csúcsába.
A hang és video interneten keresztüli továbbításának nem szabad függenie a hardverektől, a webes kliensektől és az általuk támogatott szabványoktól, valamint zökkenőmentesen működnie kell a hálózati címfordítók (NAT) és tűzfalak jelenlétében is. A felhőalapú videómegjelenítés felhasználója hozzá kíván férni a szolgáltatáshoz, még akkor is, ha analóg kamerákat használ, míg a valós idejű videoközvetítést a legmodernebb eszközökön szeretné nézni.
Különösen fontos, hogy a felhasználó minimális késleltetéssel kívánja nézni a videót. Gyakorlatilag az egyetlen lehetőség a böngészőben alacsony késleltetésű videó megjelenítésére a WebRTC (web valós idejű kommunikáció) használata. A WebRTC egy olyan technológiai készlet, amely lehetővé teszi a videó és hang peer-to-peer továbbítását böngészők között, és eredetileg alacsony késleltetésű videófolyamok továbbítására és lejátszására tervezték. Ehhez többek között UDP protokollt használ.
Mielőtt részleteznénk, mit nyújt a felhasználónak az új motor, emlékeztetjük arra, miért és miért támogatjuk az HLS-technológiákat, és miért döntöttünk úgy, hogy tovább lépünk.
HLS motor: előnyök és hátrányok
()
Az HLS (HTTP Live Streaming) technológiát az Apple fejlesztette ki, így nem meglepő, hogy először a cég eszközein jelent meg a támogatás. Jelenleg a HLS formátumú videók lejátszása szinte minden TV boxban és sok Android operációs rendszeren futó eszközön megvalósítható.
A HLS motor a jól ismert H264 videokódot használja videoadatok folyamatok továbbításához, kombinálva AAC vagy MP3 audiosávokkal. Az összes audio- és videoadat egy MPEG-TS szállítókonténerben kerül csomagolásra. Az HTTP protokollon történő továbbításhoz az adatfolyam információját darabokra osztják, amelyek a m3u8 lejátszási listákban vannak leírva. Csak ezután ezeket a fragmentumokat a lejátszási listákkal együtt továbbítják HTTP-n. A darabokra osztás automatikusan azt jelenti, hogy másodpercekben kifejezett késleltetést eredményez. Ez a MPEG-TS konténer egyik sajátossága.
A HLS motor támogatja a többszörös bitrátás folyamatokat, valamint a Live/VOD-t.
A HLS fő előnyei:
- Beépített támogatás minden főbb böngészőben;
- Könnyű megvalósítás (a WebRTC-hez képest);
- Nagyon kényelmes és hatékony nagy közönségnek szóló adások szervezése, mivel a szegmenseket egyszer kell csak betölteni a CDN-re.
A motor egyszerűsége ellenére nem minden olyan sima, mint amilyennek tűnik. A fő probléma az, hogy a külső lejátszók fejlesztői eltértek az Apple ajánlásaitól, például a támogatott audioformátumok tekintetében. Különösen sok fejlesztő kezdte el beépíteni a népszerű audiofolyamok kezelését: mpeg2 video, mpeg2 audio stb. Ennek következményeként különböző lejátszási lista formátumokat kellett létrehozni a különböző lejátszókhoz.
De az HLS motornak az egyik legnagyobb problémája a magas adatátviteli késleltetés.
A "megakasztások" gyökerei
A HLS magas késleltetésének fő oka az, hogy a programozók a lehető legjobb képminőség elérésére tervezték a motort. Ezért a használt képközi idő és a lejátszási puffer mérete egyszerűen nem alkalmas élő videó közvetítések lebonyolítására. Ennek következtében viszonylag magas késleltetés lép fel a videójelek átvitelében, ami 5-7 másodperc is lehet.
Egyrészt ez elfogadható, például azok számára, akik filmet néznek egy videómegosztó szerverről. De a videómegfigyelő rendszerek esetében a videó jeleinek késleltetése nagyon nagy jelentőséggel bírhat.
Ha egy irodát figyelsz, ahol a munkatársak óránként egyszer néznek el a monitorról, akkor az 5 másodperces késleltetés nem jelent semmit. De az emberek elkezdtek panaszkodni, hogy például egy focimeccs közvetítésekor a csevegésben már írták, hogy GÓÓÓL, de még nincs a videón :). Már van néhány felhasználói esetünk, ahol az Ivideonnak gyakorlatilag helyettesítenie kell a Skype-ot.
Lehet-e csökkenteni az HLS késleltetését? A kérdésre a válasz úgy hangzik, mint egy tapasztalt patkányírtó előadása kezdő kártevőirtók előtt: "A patkányokat nem lehet eltüntetni, de a számukat ésszerű minimumra csökkenthetjük." Így van ez az HLS késleltetésével is, nulla értékre csökkenteni nem lehet, de a piacon vannak olyan megoldások, amelyek jelentősen csökkentik a késleltetést.
Finom szeletelés
A motor egy másik hátránya, hogy kis méretű fájlokat használ az adatok átvitelére. Sokan azt gondolhatják, hogy ez miért problémás?
Bárki, aki megpróbálta nagy mennyiségű kis fájl átmásolását egyik adathordozóról a másikra, biztosan észrevette, hogy az ilyen készlet írási sebessége sokkal alacsonyabb, mint egy nagy fájlé ugyanakkora mennyiségben. Ráadásul a merevlemezhez való hozzáférés intenzitása is jelentősen nő, ami összességében negatívan hat a számítógép teljesítményére. Ezért a videoadatok átvitele kis, 10 másodperces darabokban szintén hozzájárul a motor késleltetésének növekedéséhez.
Röviden összefoglalva a HLS-technológia előnyeit és hátrányait.
A HLS előnyei:
- Bármilyen eszközzel való működés lehetősége. Bármilyen modern eszközön nézheti a videót, legyen az okostelefon, táblagép, laptop vagy asztali PC. A lényeg, hogy a webszerver modern verzióval rendelkezzen, és kompatibilis legyen az HTML5-tel és a Media Source Extensions-tel.
- Kiváló képminőség. Az alkalmazott adaptív adatátviteli funkció lehetővé teszi a továbbított videóminőség dinamikus megváltoztatását az internetkapcsolat sávszélessége alapján, miközben az algoritmus törekszik a maximális minőség megőrzésére.
- Nincs szükség a felhasználói berendezés bonyolult beállítására.
Hátrányok:
- Korlátozott támogatás a motornak egyes eszközökön való működéséhez.
- Magas késleltetés a képátvitel során.
- Jelentős növekedés a költségekben és a finomhangolás bonyolultságában a kis méretű fájlok használata miatt. A konténer sajátosságai miatt soha nem tudunk kevesebb késleltetést elérni, mint a szegmens mérete.
A HLS hátrányai felülmúlják az előnyeit, és alternatív megoldásokat kezdtünk keresni.
Mi az a WebRTC
()
A WebRTC platformot a Google fejlesztette ki 2011-ben videó- és audiostream-ek átvitelére böngészők és mobilalkalmazások között minimális késleltetéssel. Ehhez az UDP szabványos protokollt és speciális adatáramlás-szabályozási algoritmusokat használ. Ma ez egy nyílt forráskódú projekt, amelyet a Google aktívan támogat és fejleszt.
A WebRTC egy olyan technológiák összessége, amely lehetővé teszi a peer-to-peer videó- és hangátvitelt. Ez azt jelenti, hogy például a felhasználók böngészői a WebRTC segítségével közvetlenül adatokat cserélhetnek egymással, anélkül, hogy távoli szervereket kellene használniuk az adatok tárolására és feldolgozására. Minden információt a végfelhasználók böngészői és mobilalkalmazásai dolgoznak fel.
A technológia kényelmét és széles lehetőségeit a népszerű böngészők fejlesztői is értékelték. Ma a WebRTC támogatása megvalósult a Mozilla Firefox, az Opera, a Google Chrome (és minden Chromium-alapú böngésző), valamint az Android és iOS mobilalkalmazásaiban.
Bár a WebRTC-nek kétségtelenül sok előnye van, van néhány jelentős hátránya is.
A választás nehézségei
A WebRTC technológia sokkal bonyolultabb a hálózati interakciók szempontjából, mivel P2P alapon működik. Nehéz hibakeresni, tesztelni, és kiszámíthatatlanul viselkedhet. Emellett át kell hidalnunk a NAT-ot és a tűzfalakat, valamint biztosítani kell a működést olyan hálózatokban, ahol a UDP le van tiltva.
A Google WebRTC megvalósítása nagyon nehezen használható. Van egy egész vállalat, amely az SDK összeállítását kínálja. Ráadásul a Google megvalósítását nagyon nehéz volt integrálni a rendszerünkkel úgy, hogy közben ne kelljen újrakódolni az összes videót.
Ugyanakkor régen meg akartuk adni a felhasználóknak a lehetőséget, hogy teljes értékű, 'élő' videótartalommal dolgozhassanak, és minimalizálják a képen megjelenő kép késését az eseményekhez képest. Továbbá, szerettük volna kényelmesebbé tenni a PTZ kamerák használatát, ahol a késések kritikus jelentőséggel bírnak.
Figyelembe véve, hogy más megoldások az akadás csökkentésére jelenleg korlátozott funkcionalitással bírnak és nyilvánvalóan gyengébben teljesítenek, úgy döntöttünk, hogy a WebRTC-t választjuk.
Mit tettünk
A WebRTC platform szakszerű bevezetése nem könnyű feladat. Bármilyen hiba vagy pontatlanság arra vezethet, hogy a videóátvitel késései nemcsak hogy nem csökkennek más platformokhoz képest, hanem nőnek is.
A WebRTC megfelelő működéséhez először is technológiai modernizálást kell végezni a webes videó kezelésére szolgáló stacken. Ezt már megtettük.
Először megvalósítottuk a WebRTC jelzőprotokollt a Websocket felett, valamint felállítottunk egy WebRTC peer szervert a felhőben a webrtc.org SDK alapján. Feladata az, hogy videófolyamokat biztosítson a kliens WebRTC peer-eknek H.264 + Opus/G.711 formátumban átkódolás nélkül.
A Websocket-et választottuk jelzőprotokollnak, mert már kiváló támogatással bír minden népszerű böngészőben. Ezáltal jelentősen csökkenthetők a fejlesztési költségek, és nem kell időt és forrást pazarolni a TCP és TLS kézfogások ismétlésére az AJAX-hoz képest.
A lényeg az, hogy alapértelmezetten a WebRTC nem biztosítja a jelzőprotokollt, amely szükséges a videofelvételek valós idejű beállításához, támogatásához és megszakításához a forrás- és kliensalkalmazások között.
Ahhoz, hogy saját jelzőtechnológiát valósítsunk meg, szükségünk volt egy saját jelzőszerver fejlesztésére, amely több web protocolot támogat (Websocket, WebRTC). Ezen kívül biztosítania kellett a szekciók és értesítések biztonságos kezelését valós időben, a videó kezelését és sok más paramétert.
A P2P korlátokat úgy tudtuk áthidalni, hogy a késleltetést nem a P2P, hanem az UDP és a késleltetést csökkentő áramláskezelés révén csökkentettük. Ez is be van építve a WebRTC-be, mivel a fő felhasználási eset a böngészőn keresztüli P2P beszélgetések.
A mobil kliensben egy lejátszót valósítottunk meg a webrtc.org SDK használatával, mivel csak ebben van megfelelően implementálva az áramlás kezelése, minden ismert Forward Error Correction (FEC) séma megtalálható, és helyesen lett végrehajtva a csomagok újraküldési mechanizmusa minden böngészőhöz. Nem elhanyagolható az sem, hogy a webrtc.org SDK-t a Google aktívan fejleszti.
Milyen eredmény származik a WebRTC bevezetéséből?
A kamerák élő videójának megtekintéséhez új, WebRTC alapú optimalizált lejátszót adtunk hozzá a felhasználói fiókhoz. Ez biztosítja a videófolyama magas sebességű betöltését, és teljesen megszünteti a töltési késleltetés felhalmozódásának problémáját a megtekintési idő növekedésével.
A WebRTC támogatásának bevezetése óta az Ivideon felhőszolgáltatásában teljes magabiztossággal mondhatjuk, hogy mostantól ügyfeleink számára elérhető a teljes értékű élő videók megtekintése. Jelenleg a videóadatok közvetítési késedelme nem haladja meg az egy másodpercet! Összehasonlításképpen, a korábbi HLS-motor 5-7 másodperces késedelmet biztosított a videó továbbításában. A videó bemutatásának sebességbeli különbsége nagyon jelentős, és a felhasználó ezt azonnal észreveszi a videószolgáltatásunk használata során.
Ahogyan azt vártuk, az új lejátszó megvalósítása növelte a PTZ és a kamera közötti hangkommunikáció reakciókészségét.
Van egy apró, de fontos dolog, amire szeretnénk felhívni a figyelmet. Az új WebRTC lejátszó egyelőre teszt üzemmódban működik. Éppen ezért nem kapcsoljuk be alapértelmezettként minden ügyfelünk számára. De önállóan aktiválhatja, ha bekapcsolja a megfelelő opciót a kamera beállításaiban (ehhez be kell lépnie a ).
A WebRTC megvalósításának jellemzői az Ivideon szolgáltatásban
A WebRTC jelenleg még mindig kísérleti technológia. A támogatása nem minden böngészőben és felhasználói eszközön működik megfelelően, és nem minden kameránál található meg.
Ez magyarázza, hogy eddig miért nem tettük alapértelmezetté a WebRTC lejátszót minden felhasználó számára.
Jelenleg azt javasoljuk, hogy a WebRTC-t csak a Google Chrome böngészőben használják. A legújabb Firefox és Safari verziók is támogatják ezt a technológiát, de sajnos még mindig instabil.
Jelenleg nem vezettük be a WebRTC támogatását a mobil böngészőkben. Ha most mobil eszközről lép be és aktiválja a WebRTC-t, ez a mód nem fog működni. Azonban a WebRTC elérhető a mobilalkalmazásainkban és .
És zárásként, a WebRTC megvalósításának jellemzőiről még két apró részletet szeretnénk megemlíteni.
Először is, a technológia kifejezetten élő videók valós idejű közvetítésére lett tervezve. Ezért, ha az Ön sávszélessége nem elegendő a videó átviteléhez, észreveheti a képkockák elvesztését (HLS esetén észlelheti a videó megfagyását és a késlekedés növekedését, ekkor a képkockák nem fognak eltűnni), de a videó valós időben továbbra is közvetítve lesz.
Másrészt, mivel a technológia kifejezetten élő, valós idejű videók kezelésére készült, nem használjuk archív videoadatok feldolgozására.
Egyéb változások a szolgáltatásban
Jelenleg a Flash már nem része az automatikus motorválasztási mechanizmusnak. A lejátszót továbbra is használhatja, de ehhez kézzel kell kiválasztania a fiók vagy a kamera beállításaiban. Ez nem divat kérdése, csupán a statisztikáink szerint a Flash-t használó felhasználóknak szinte nyoma sincs. Az a próbálkozás, hogy meghatározzuk, a felhasználó böngészője támogatja-e, körülbelül 2 másodperc drága időt veszít.
Itt egy rövid összefoglaló azokról a változtatásokról, amelyekre számíthat az felhőalapú videómegfigyelő rendszerünkben és a személyes fiókjában. Maradjon velünk, és kövesse a híreket!
Forrás: habr.com
