A felhős videó megfigyelőrendszeren való munka első napjaitól kezdve egy olyan problémával szembesültünk, amelyre megoldás nélkül lemondhattunk az Ivideonról – ez volt a mi Everestünk, a megmászás sok energiát igényelt, de most végre sikerült jégcsákányt szúrt a keresztplatformos puzzle tetejébe.
A hang- és képátviteli rendszer az interneten keresztül nem függhet a berendezésektől, webkliensektől és az általuk támogatott szabványoktól, és megfelelően működik hálózati címfordítók és tűzfalak jelenlétében is. A felhőalapú videó megfigyelő felhasználó akkor is szeretne hozzáférni a szolgáltatáshoz, ha analóg kamerát használ, és inkább a legmodernebb eszközön nézi az élő videót.
Nagyon fontos, hogy a felhasználó minimális késéssel akarja megnézni a videókat. Szinte az egyetlen módja annak, hogy egy böngészőben alacsony késleltetésű videót jelenítsen meg, a WebRTC (webes valós idejű kommunikáció) használata. A WebRTC a video- és hang egyenrangú átvitelére szolgáló technológiák készlete a böngészőkben, amelyet eredetileg alacsony késleltetésű videofolyamok átvitelére és lejátszására terveztek. Erre a célra többek között az UDP protokollt használják.
Mielőtt elmondanánk, mit ad az új motor a felhasználónak, emlékeztetni fogjuk, miért és miért támogatjuk a HLS-technológiákat, és miért döntöttünk úgy, hogy továbblépünk.
HLS motor: előnyei és hátrányai
()
A HLS (HTTP Live Streaming) technológiát az Apple fejlesztette ki, így nem meglepő, hogy először Apple eszközökön támogatták. Manapság a HLS videót gyakorlatilag az összes set-top box és számos, az operációs rendszert futtató eszköz is támogatja. Android.
A HLS motor a jól ismert H264 videokodeket AAC vagy MP3 audio streamekkel kombinálva használja a videoadatok streameléséhez. A teljes audio és video adatfolyam egy MPEG-TS szállító tárolóba van csomagolva. A HTTP protokollon keresztüli továbbításhoz az adatfolyamban lévő információkat az m3u8 lejátszási listákban leírt töredékekre osztják. És csak ezután ezek a töredékek a lejátszási listákkal együtt HTTP-n keresztül kerülnek továbbításra. A darabolás automatikusan másodpercben késleltetést jelent. Ez az MPEG-TS tároló jellemzője.
A HLS motor támogatja a többbites adatfolyamokat, az élő/VOD-t is.
A HLS fő előnyei:
- beépített támogatás minden nagyobb böngészőben;
- könnyű implementáció (a WebRTC-hez képest);
- Nagyon kényelmes és hatékony mindenféle adás megszervezése nagy közönség számára, mivel a szegmensek egyszer feltölthetők egy CDN-re.
A motor egyszerűsége ellenére nem minden olyan sima, mint amilyennek látszik. A fő probléma az, hogy a külső lejátszófejlesztők eltávolodtak az Apple ajánlásaitól, például a támogatott hangformátumok tekintetében. Különösen sok fejlesztő elkezdte hozzáadni a népszerű hangfolyamokkal való együttműködés lehetőségét: mpeg2 videó, mpeg2 hang stb. Ennek eredményeként különböző lejátszási listaformátumokat kellett létrehozniuk a különböző lejátszókhoz.
De az egyik legnagyobb probléma a HLS motorral az adatátvitel magas késleltetése.
A „fékek” eredete
A HLS magas késleltetésének fő oka abban rejlik, hogy a programozók létrehozták a motort, hogy a legjobb minőségű képeket kapják. Ezért a használt képkocka-intervallum paraméterei és a lejátszási puffer mérete egyszerűen nem alkalmas élő videó közvetítésre. Emiatt a videofelvételek továbbításában meglehetősen nagy késés tapasztalható, ami 5-7 másodperc is lehet.
Ez egyrészt nem sok például annak, aki videó tárhely szerverről néz filmet. A videó megfigyelő rendszerek esetében azonban a videofelvételek továbbításának késése nagyon fontos lehet.
Ha olyan irodát néz, ahol az alkalmazottak óránként egyszer felnéznek a monitorjukra, akkor az 5 másodperces késleltetés egyáltalán nem számít. De az emberek elkezdtek panaszkodni, hogy például egy focimeccs közvetítésekor már GOOOOL-t írtak a chaten, de ez még nincs a videón :). Számos olyan felhasználói esetünk van már, amikor az Ivideonnak gyakorlatilag le kellene váltania a Skype-ot.
Meg lehet győzni a késleltetést a HLS-ben? A kérdésre adott válasz úgy hangzik, mint egy tapasztalt patkányirtó beszéde a kezdő kártevőirtó szakembereknek tartott előadáson: „A patkányokat nem lehet kiirtani, de számuk ésszerű minimumra csökkenthető.” Ugyanez a HLS késleltetésével sem lesz lehetséges nullára csökkenteni, de vannak olyan megoldások a piacon, amelyek jelentősen csökkenthetik a késést.
Finom vágások
A motor másik hátránya, hogy kis méretű fájlokat használ az adatátvitelhez. Úgy tűnik, mi a baj ezzel?
Bárki, aki nagyszámú kis fájlt próbált átmásolni egyik médiáról a másikra, valószínűleg észrevette, hogy egy ilyen készlet írási sebessége sokkal kisebb, mint egy azonos méretű nagy fájlé. És a merevlemezhez való hozzáférés intenzitása jelentősen megnő, ami általában negatívan befolyásolja az egész számítógép teljesítményét. Ezért a videoadatok kis 10 másodperces részletekben történő továbbítása szintén hozzájárul a motor késleltetésének növekedéséhez.
Foglaljuk össze röviden a HLS technológia előnyeit és hátrányait.
A HLS előnyei:
- Képesség bármilyen eszközzel dolgozni. Bármilyen modern eszközön megtekintheti a videókat, legyen az okostelefon, táblagép, laptop vagy asztali számítógép. A lényeg az, hogy a webböngésző naprakész és kompatibilis a HTML5-tel és a Media Source Extensions-el.
- Kiváló képminőség. Az alkalmazott adaptív adatátviteli funkció lehetővé teszi a továbbított videó minőségének dinamikus megváltoztatását az internetkapcsolat sávszélességétől függően, miközben az algoritmus a maximális minőség fenntartására törekszik.
- Nincs szükség a felhasználó berendezésének összetett konfigurálására.
Hátrányok:
- Egyes eszközökön korlátozott támogatás a motorral való munkavégzéshez.
- Nagy késések a képátvitelben.
- Jelentősen megnövekszik a rezsi és az optimalizálás bonyolultsága a kis fájlok használata miatt. A tároló jellegéből adódóan soha nem fogunk tudni a szegmens méreténél alacsonyabb késleltetést elérni.
A HLS hátrányai meghaladták az előnyeit számunkra, és arra kényszerítettek bennünket, hogy alternatív lehetőségeket keressünk.
Mi az a WebRTC
()
A WebRTC platformot a Google fejlesztette ki 2011-ben, hogy minimális késleltetéssel továbbítsa a streaming video- és audioadatokat a böngészők és a mobilalkalmazások között. Ehhez a szabványos UDP protokollt és a speciális áramlásvezérlő algoritmusokat használják. Ma ez egy nyílt forráskódú projekt, a Google aktívan karbantartja és fejlesztés alatt áll.
A WebRTC a peer-to-peer video- és audioátviteli technológiák halmaza. Azaz például a WebRTC-t használó felhasználói böngészők közvetlenül tudnak adatokat továbbítani egymásnak, anélkül, hogy távoli szervereket használnának 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 is feldolgoznak.
A technológia kényelmét és kiterjedt képességeit minden népszerű böngésző fejlesztője nagyra értékelte. A WebRTC támogatás jelenleg a Mozilla Firefoxban, az Operában, a Google Chrome-ban (és az összes Chromium alapú böngészőben), valamint a mobilalkalmazásokban érhető el. Android és iOS-en.
Minden kétségtelen előnye ellenére a WebRTC-nek számos jelentős hátránya van.
A választás nehézségei
A WebRTC technológia sokkal összetettebb a hálózati interakciók szempontjából, mivel P2P-ről van szó. Nehéz hibakeresni, tesztelni, és kiszámíthatatlanul viselkedhet. Ugyanakkor le kell győznünk a NAT-ot és a tűzfalat, biztosítanunk kell a működést olyan hálózatokban, ahol az UDP blokkolva van.
A Google WebRTC megvalósítását nagyon nehéz használni. Még egy teljes cég is nyújt SDK összeszerelési szolgáltatásokat. Ráadásul a Google implementációját nagyon nehéz volt integrálni a rendszerünkkel a teljes videó újrakódolása nélkül.
Azonban régóta szeretnénk lehetőséget adni a felhasználóknak, hogy teljes értékű „élő” videóval dolgozhassanak, és minimálisra csökkentsük a képernyőn megjelenő kép és maguk az események közötti késést. Emellett az volt a vágyunk, hogy kényelmesebbé tegyük a PTZ kamerák használatát, ahol a késések kritikusak.
Tekintettel arra, hogy más késésgátló megvalósítások még mindig korlátozottan működnek, és észrevehetően rosszabbul működnek, a WebRTC használata mellett döntöttünk.
Mit tettünk
A WebRTC platform megfelelő megvalósítása nem könnyű feladat. Bármilyen téves számítás vagy pontatlanság ahhoz vezethet, hogy a videó átvitel késése nemhogy nem csökken más platformokhoz képest, hanem még nő is.
A WebRTC megfelelő működéséhez mindenekelőtt el kell végezni a verem technológiai frissítését a webes videóval való munkavégzéshez. Mi ezt tettük.
Először egy WebRTC jelzőprotokoll-szervert implementáltunk a Websocket-en keresztül, és egy WebRTC peer szervert is telepítettünk a felhőben a webrtc.org SDK alapján. Feladata a video streamek elosztása a kliens WebRTC társaknak H.264 + Opus/G.711 formátumban videó átkódolás nélkül.
A Websocket-et választottuk jelzőprotokollnak, mert már minden népszerű webböngészőben kiváló minőségű támogatással rendelkezik. Ennek köszönhetően nemcsak a fejlesztési többletköltséget csökkentheti jelentősen, hanem elkerülheti az idő- és erőforrás-pazarlást az ismételt TCP és TLS kézfogással az AJAX-hoz képest.
A tény az, hogy alapértelmezés szerint a WebRTC nem biztosítja a jelzési protokollt, amely a forrás- és az ügyfélalkalmazások közötti valós idejű videokommunikáció megfelelő konfigurálásához, karbantartásához és leállításához szükséges.
A jelzéstechnológia önálló megvalósításához pedig saját jelzőszerverünket kellett kifejlesztenünk, amely több webprotokollt (Websocet, WebRTC) is támogat. És a munkamenetek és értesítések valós idejű biztonságos kezelésének képességével, videókezeléssel és még sok mással.
Leküzdöttük a P2P korlátait azzal, hogy nem a P2P-n keresztül csökkentjük a késleltetést, hanem az UDP-n és az áramlásvezérlésen keresztül a késleltetés csökkentése érdekében. Ez a WebRTC-be is be van építve, mivel a fő használati eset a böngészőn keresztüli p2p beszélgetés.
A mobil kliensben a webrtc.org SDK segítségével implementáltuk a lejátszót, mivel csak ez valósítja meg helyesen az áramlásvezérlést, rendelkezik az összes ismert továbbítási hibajavítási (FEC) sémával, és minden böngészőben megfelelően implementálja a csomagok újraküldésének mechanizmusát. Az is fontos, hogy a webrtc.org SDK-t a Google aktívan fejleszti.
Mi az eredménye a WebRTC bevezetésének?
A kamerák élő videójának megtekintéséhez új, WebRTC-n alapuló optimalizált lejátszót adtunk hozzá személyes fiókjához. Gyors videóbetöltési sebességet biztosít, és teljesen kiküszöböli a megtekintési idő növekedésével felhalmozódó késleltetés problémáját.
Miután bevezettük a WebRTC támogatást az Ivideon felhőszolgáltatásba, teljes bizalommal kijelenthetjük, hogy ügyfeleink immár teljes értékű élő videót nézhetnek. Most a videoszekvenciák sugárzásának késleltetése nem haladja meg az egy másodpercet! Összehasonlításképpen, az előző HLS motor 5-7 másodperces késéssel biztosította a videóleadást. A videóbemutató sebességének különbsége igen jelentős, és ezt a felhasználó azonnal észreveszi, miután elkezdett dolgozni videószolgáltatásunkkal.
Ahogy azt vártuk, az új lejátszó bevezetése javította a PTZ válaszkészségét és a kamerával történő hangkommunikációt.
Csak egy finom pontra szeretnénk felhívni a figyelmet. Az új WebRTC lejátszó jelenleg teszt üzemmódban működik. És ezért alapértelmezés szerint nem engedélyezzük minden ügyfelünk számára. De saját maga is aktiválhatja, ha engedélyezi a megfelelő elemet a kamera beállításaiban (ehhez menjen a ).
A WebRTC megvalósításának jellemzői az Ivideon szolgáltatásban
A WebRTC jelenleg még kísérleti technológia. Támogatása még nincs megfelelően implementálva minden böngészőben és felhasználói eszközben, és nem is minden kamerában.
Pontosan ez az oka annak, hogy még nem tettük a WebRTC lejátszót alapértelmezetté minden felhasználó számára.
Egyelőre azt javasoljuk, hogy a WebRTC használatát csak a Google Chrome böngészőkben használja. A Firefox és a Safari legújabb verziói is támogatják ezt a technológiát, de sajnos még mindig instabil.
Még nem vezettük be a WebRTC támogatást a mobileszközök böngészőihez. Jelenleg, ha mobileszközről jelentkezik be, és aktiválja a WebRTC-t, ez a mód nem működik. A WebRTC azonban elérhető a mobilalkalmazásainkban и .
És befejezve a szolgáltatásunkban a WebRTC implementáció jellemzőiről szóló történetet, jegyezzünk meg még két finom pontot.
Először is, a technológia az élő videó valós idejű sugárzására összpontosít. Ezért, ha a csatornád nem rendelkezik elegendő sávszélességgel a videó továbbításához, képkocka-csökkenést fogsz észlelni (HLS esetén a videó fakulását és megnövekedett késleltetést észlelsz, de nem lesz képkocka csökkenés), de a videó továbbra is valós adásban lesz látható. idő.
Másodszor, mivel a technológiát kifejezetten arra tervezték, hogy valós idejű élő videóval működjön, nem használjuk archivált videoadatokkal való munkavégzésre.
Egyéb változások a szolgáltatásban
Jelenleg a Flash már nem vesz részt az automatikus motorválasztási mechanizmusban. Továbbra is használhat ilyen lejátszót, de ehhez manuálisan kell kiválasztania a fiók vagy a kamera beállításaiban. Ez nem tisztelgés a divat előtt, mindössze annyi, hogy szolgáltatásunk statisztikái szerint gyakorlatilag nem maradt Flash-el dolgozó felhasználó. És megpróbálva megállapítani, hogy a felhasználó böngészője támogatja-e, körülbelül 2 másodpercnyi értékes időt veszítünk.
Íme egy rövid áttekintés azokról a változásokról, amelyek felhőalapú videó megfigyelő rendszerünkben és személyes fiókunkban várnak Önre. Tarts velünk és kövesd a híreket!
Forrás: will.com
