Rtsp protokoll ip kamerákhoz. Videofolyam sugárzása IP-kameráról a WebRTC használatával

Ha nehézségei vannak a termék beállítása vagy használata során, kérjük, tekintse meg a GYIK-et és a GYIK-et.

Hogyan szerezhetek REVISOR VMS ajándéklicencet?

Kövesse az utasításokat a Revisor VMS ajándéklicenc beszerzéséhez. Töltse le az utasításokat.

Van egy 1,3 MP RedLine IP kamerám. Megpróbálom telepíteni az ActiveX-et, de „HTTP 404 – Nem található” hibaüzenet jelenik meg. Mit tegyek?

Az 1,3 megapixeles videokamerákba nincs beépítve az ActiveX modul, azt a készlethez mellékelt lemezről kell telepíteni, vagy letölteni a linkről

4 MP-es kamerákhoz:

rtsp://admin:123456@IP-cím:554/ch01/0 - főszál

rtsp://admin:123456@IP-cím:554/ch01/1 - további adatfolyam

rtsp://admin:123456@IP-cím:554/streaming/mjpeg - mjpeg adatfolyam

1,3 MP és 2 MP kamerákhoz

rtsp://admin:123456@IP-cím:554/streaming/video0 - fő stream

rtsp://admin:123456@IP-cím:554/streaming/video1 - további adatfolyam

Milyen szoftver alkalmas mobil eszközökhöz?

Milyen portok szükségesek a hálózaton keresztüli működéshez?

80 - webes felület

554-rtsp (video) adatfolyam

4900 - mob. kikötő

9988 - 4 MP-es IP-kamerákkal való kliens csatlakozásokhoz

Mi a teendő, ha a hang nem működik a felvevőn vagy harmadik féltől származó szoftverben?

A hang továbbításához aktiválnia kell a hangátvitelt a HÁLÓZAT lap - RTSP adatfolyam beállításaiban.

Az elfoglalt hely mennyisége a kiválasztott felvételi minőségtől és a mozgás gyakoriságától függ (érzékeléssel történő rögzítés esetén). Az archívum kiszámításához használhatja a Lemezszámoló szoftvert.

Hogyan találhatok IP-kamerát a helyi hálózaton?

Telepítse a szoftvert, és futtassa rendszergazdaként. A megjelenő ablakban megjelenik a helyi hálózathoz csatlakoztatott berendezések listája.

A hálózati beállítások megváltoztatásához a felső mezőben válassza ki a berendezést, az alsó mezőben adja meg a hálózati beállításokat (IP-cím, maszk, átjáró), adja meg a felhasználónevet, jelszót, majd kattintson a Módosítás gombra. A jövőben a megadott IP-címet kell használnia a csatlakozáshoz.

1,3 MP és 2 MP IP kamerákhoz használata javasolt

Hogyan adhatunk hozzá 1,3 MP-es IP kamerát a CVMS-hez?

Ha a kamera a helyi hálózaton van, akkor nézet módban az Eszközök menüben (balra) kattintson a jobb gombbal, és válassza a "Gyorskeresés" lehetőséget, majd válassza ki a kívánt kamerát és adja meg a jelszót.

Ha az interneten keresztül jön létre a kapcsolat, akkor nézet módban az Eszközök menüben (balra) kattintson a jobb gombbal, és válassza az "Eszköz hozzáadása" lehetőséget, és adja meg a csatlakozáshoz szükséges adatokat, A TCP PORTOT MEG KELL MEGADNI (alapértelmezett 1115)

Előfordulhat, hogy a CCTV kamerához mellékelt kézikönyv nem mindig tartalmaz információkat az RTSP protokollról, amely szerint az eszköz működik. Azonban nagyon sok olyan eset van, amikor szükséges ezt a protokollt használni, ezért szükségessé válik a címének megismerése.

A videó megfigyelőrendszer tulajdonosának különféle helyzetekben szüksége lehet az RTSP adatfolyam ismeretére:

a kamera csatlakoztatása a felhőkiszolgálóhoz;
videoinformációk továbbításának beállítása a weboldalra;
videók lejátszásához a lejátszó adatfolyamában különböző eszközökön - mobiltelefonon, laptopon vagy táblagépen.

Mire való az RTSP protokoll?

Az RTSP protokoll neve online vezérlést jelent. Így a Real Time Streaming Protocol segít az online videó streamelés kezelésében. Ezt a protokollt nagyon gyakran használják az IP-videó megfigyelésben, mivel tartalmazza a szükséges parancsok leírását.

Az RTSP protokoll segítségével a biztonsági kamera tulajdonosa több fontos funkciót is megoldhat:

adatok sugárzása VLC használatával;
sugározzon videót erőforrásaira és platformjaira;
konfigurálja az NVR-videorögzítőket;
csatlakoztasson egy videó megfigyelő kamerát virtuális tárolóval;
videokamerát adjon hozzá Android vagy iOS alapú mobilalkalmazásokhoz.

Ugyanakkor a videó megfigyelő rendszerek sok felhasználója számára nem túl könnyű, és meglehetősen nehéz megnyitni egy RTSP adatfolyamot.

Tudja meg egy térfigyelő kamera RTSP-címét

Számos lehetőség van, amelyek lehetővé teszik a videokamera RTSP adatfolyamának megtudását, ha az nincs megadva a megfelelő utasításokban.

Az Oroszországban értékesített IP-kamerák nagy része kínai XMEye elemeket tartalmaz. Ezek az alkatrészek még a hazai fényképezőgép-gyártóknál is láthatók, mint például a Vesta, HiQ, SVplus és hasonlók. Az ilyen modellek kamerája a következő RTSP adatfolyam formátummal rendelkezik:

rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi

Ez a cím olyan összetevőket tartalmaz, mint:

192.168.132.32 – közvetlen eszköz IP-címe;
554 – protokoll port (alapértelmezés szerint 554-es a száma, de ez a paraméter módosítható az eszközbeállításokban);
admin - bejelentkezés a térfigyelő kamerába;
12355 – felhasználói bejelentkezési jelszó.

Abban az esetben, ha más összetevők is jelen vannak az IP-videokamerában, akkor az alábbiakban felsorolt két lehetőség valamelyikét kell használnia.

Az első lehetőség a legegyszerűbb. Ahhoz, hogy megtudja az RTSP adatfolyamot egy térfigyelő kamerából, kapcsolatba kell lépnie az eszköz gyártójával vagy szállítójával. Kérésre képesek lesznek biztosítani a kívánt adatfolyam formátumát, és még a kínai eladók is biztosíthatják ezt a szolgáltatást - kínai gyárakból vagy az AliExpress webhelyéről.

A második lehetőség speciális szoftver használata. Ez a módszer akkor segíthet, ha egy, a videó megfigyelő rendszer nem tulajdonosa nem tudja vagy nem akarja kérni az RTSP adatfolyam címét a szolgáltatótól. Ezután szoftver segítségével saját kezűleg is megteheti.

Először le kell töltenie a One Device Manager nevű programot. A telepítés után ez a szoftver segít megtalálni az RTSP-címet.

Általános szabály, hogy a legtöbb videokamera támogatja az onvif protokollt, így a szoftver használata során nem lehetnek nehézségek. Fontos árnyalat - a megfelelő működéshez csatlakoztatnia kell egy laptopot vagy számítógépet, ahol a program telepítve lesz, valamint magát az IP-eszközt ugyanahhoz a helyi hálózathoz.

Az interneten teljes listákat találhat, amelyek az RTSP-folyamok címeit tartalmazzák, mivel ezek az adatok attól függnek, hogy melyik márka gyártja a videó megfigyelő kamerát.

Hogyan lehet megnyitni egy RTSP adatfolyamot egy kamerában?

Amikor az RTSP adatfolyam címe ismertté válik a nyomkövető rendszer tulajdonosa előtt, videó információkat kaphat az IP kamerától. A streaming videó adás megnyitásához a következő lépések listáját kell végrehajtania:

állítson be állandó IP-címet a kamerához, és rendelje meg egy internetszolgáltatótól;
a videokamerától érkező helyi kérések átvitele az RTSP portra;
teljesítőképességi tesztet teljesíteni.

Statikus cím konfigurálható az IP Hunter programmal, vagy felveheti a kapcsolatot internetszolgáltatójával, és megkérheti, hogy adjon meg állandó IP-címet kiegészítő lehetőségként. Ezt követően be kell állítania a továbbítási és továbbítási portokat az RTSP portra a videokamera helyi portjairól. Ezután továbbléphet az áramlás ellenőrzésére.

Annak megértéséhez, hogy az RTSP-hivatkozás működik-e, nyissa meg a VLC-lejátszót, és ellenőrizze ott. Ehhez a lejátszó főmenüjében a "Média" kategóriára kell kattintani, és az "URL megnyitása" elemet kell kiválasztani. Ezután lépjen a "Forrás" ablak "Hálózat" lapjára, és adja meg a hivatkozást.

Az IP-kameráról történő online közvetítés problémájának megoldása általában nem igényli a WebRTC használatát. A kamera maga egy szerver, IP-címmel rendelkezik, és közvetlenül csatlakoztatható egy routerhez, hogy videotartalmat terjeszthessen. Tehát miért használjuk a WebRTC technológiát?

Ennek legalább két oka van:

1. Az Ethernet adás nézőinek számának növekedésével először a csatornavastagság, majd maga a kamera erőforrásai hiányoznak majd.

2. Mint fentebb említettük, az IP kamera egy szerver. De milyen protokollokkal tudja majd átadni a videót az asztali böngészőnek? Mobil eszköz? Valószínűleg HTTP streamelésről van szó, ahol a videokockákat vagy a JPEG képeket HTTP-n keresztül továbbítják. A HTTP streamelés köztudottan nem alkalmas valós idejű videó streamingre, bár jól működik az igény szerinti videóknál, ahol az adatfolyam interaktivitása és késleltetése nem különösebben fontos. Valójában, ha filmet néz, a videó néhány másodperces késleltetése nem rontja a helyzetet, kivéve, ha valaki mással egy időben nézi a filmet. "Óh ne! Jack megölte! - Alice spoilert ír a chatben Bobnak 10 másodperccel a tragikus végkifejlet előtt.

Vagy RTSP/RTP és H.264 lesz, ebben az esetben a böngészőbe telepíteni kell egy videólejátszó plugint, mint például a VLC vagy a QuickTime. Egy ilyen beépülő modul felveszi és lejátssza a videót, akárcsak magát a lejátszót. De valóban szükségünk van egy valódi böngésző alapú streamingre, további mankók / bővítmények telepítése nélkül.

Először is szagoljuk meg az IP-kamerát, hogy megtudjuk, pontosan mit küld ez az eszköz a böngésző felé. Tesztalanyaként egy D-Link DCS 7010L kamera lesz:

A kamera telepítéséről és konfigurálásáról alább olvashat bővebben, de itt csak azt nézzük meg, hogy mit használ a videó streaminghez. Amikor a webes felületen keresztül belép a kamera adminisztrációs paneljébe, valami ilyesmit látunk (elnézést a tájképért):

A kép minden böngészőben megnyílik, és egyenletesen podlagivaet, körülbelül másodpercenként egyszer. Figyelembe véve, hogy a kamera és a laptop, amelyen a streamet nézzük, ugyanahhoz a routerhez csatlakozik, mindennek simának és gyönyörűnek kell lennie, de nem az. Hasonló a HTTP-hez. Futtassa a Wiresharkot, hogy megerősítse sejtéseinket:

Itt egy 1514 bájt hosszúságú TCP-fragmensek sorozatát látjuk

És egy utolsó HTTP 200 OK a kapott JPEG hosszával:

Nincs szükségünk erre a közvetítésre. Nem zökkenőmentes, HTTP kéréseket von le. Hány ilyen kérést tud elviselni a kamera másodpercenként? Van okunk azt hinni, hogy 10 nézőnél és korábban a kamera biztonságosan elhajlik, vagy rettenetesen hibázni kezd és csúszik.

Ha belenézünk a kamera adminisztrációs oldalának HTML-kódjába, a következő érdekes kódot fogjuk látni:

If(browser_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; if (g_isIPv6) //mert az ipv6 nem támogatja a rtsp.var host = g_netip;else var host = g_host;o+=""; //figyelmeztetés(o); DW(o); )

Az RTSP/RTP pont az, amire szüksége van a megfelelő videólejátszáshoz. De működni fog böngészőben? - Nem. De ha telepíti a QuickTime bővítményt - minden működni fog. De mi tisztán böngésző alapú streamelést végzünk.

Itt megemlíthető még a Flash Player, amely RTSP-ről, RTP-ről, H.264-ről konvertált RTMP streamet tud fogadni egy megfelelő szerveren keresztül, mint például a Wowza. De a Flash Player, mint ismeretes, egy böngészőbővítmény is, bár összehasonlíthatatlanul népszerűbb, mint a VLC vagy a QuickTime.

Ebben az esetben ugyanazt az RTSP/RTP re-streaminget fogjuk tesztelni, de egy WebRTC-kompatibilis böngészőt fogunk használni lejátszóeszközként, további böngészőbővítmények és egyéb mankók nélkül. Felállítunk egy közvetítő szervert, amely átveszi az IP-kamerából a streamet és elküldi az internetre tetszőleges számú felhasználónak WebRTC-képes böngészők használatával.

IP kamera csatlakoztatása

Mint fentebb említettük, egy egyszerű D-Link DCS-7010L IP kamerát választottak tesztelésre. A legfontosabb kiválasztási szempont itt az RTSP protokoll támogatása volt, hiszen ezen keresztül veszi a szerverünk a videó streamet a kamerából.

A mellékelt patch kábellel csatlakoztatjuk a kamerát a routerhez. A tápfeszültség bekapcsolása és a routerhez való csatlakozás után a kamera DHCP-n keresztül vett egy IP-címet, esetünkben ez 192.168.1.34 (Ha a router beállításainál lépsz, látni fogod, hogy a DCS 7010L eszköz csatlakoztatva van - ez a azt). Ideje tesztelni a kamerát.

Nyissa meg a megadott IP-címet a böngészőben 192.168.1.34, hogy elérje a kamera adminisztrátori webes felületét. Alapértelmezés szerint nincs jelszó.

Amint látja, a kamera videója megfelelően sugárzik az adminisztrációs panelen. Ugyanakkor megfigyelhető az időszakos elakadás. Ezt a WebRTC segítségével javítjuk.

Kamera beállítása

Először is a kamera beállításainál letiltjuk a hitelesítést – a tesztelés részeként mindenkinek megadjuk a streamet, aki kéri. Ehhez a kamera webes felületén lépjen a beállításokhoz Setup-Networkés állítsa be az opció értékét Hitelesítés a Letiltásban.

Ugyanitt ellenőrizzük az RTSP protokoll port értékét, alapértelmezés szerint 554. A továbbított videó formátumát a használt profil határozza meg. Ebből maximum hármat állíthatunk be a kamerában, mi az elsőt, a live1.sdp-t fogjuk használni – alapértelmezés szerint a videóhoz H.264, a hanghoz pedig a G.711-re van beállítva. A beállításokat szükség esetén módosíthatja a részben Beállítás - Audio és videó.

Most az RTSP-n keresztül ellenőrizheti a kamera működését. Nyissa meg a VLC Playert (bármely másikat használhat, amely támogatja az RTSP-t - QuickTime, Windows Media Player, RealPlayer stb.), és az URL megnyitása párbeszédpanelen állítsa be a kamera RTSP-címét: rtsp://192.168.1.34/live1.sdp

Nos, minden úgy működik, ahogy kell. A kamera az RTSP protokollon keresztül megfelelően lejátssza a lejátszóban lévő videofolyamot.

Mellesleg, az adatfolyamot meglehetősen simán és műtermékek nélkül reprodukálják. Ugyanezt várjuk el a WebRTC-től is.

Szerver telepítés

Tehát a kamera telepítve van, asztali lejátszókkal tesztelve, és készen áll a szerveren keresztüli sugárzásra. A whatismyip.com segítségével meghatározzuk a kamera külső IP-címét. Esetünkben 178.51.142.223 volt. Továbbra is közölni kell az útválasztóval, hogy amikor az 554-es porton RTSP-n keresztül ér el, a bejövő kérések az IP-kamerához kerülnek.

A megfelelő beállításokat beleütjük a routerbe...

...és ellenőrizze a külső IP-címet és az RTSP-portot a Telnet segítségével:

Telnet 178.51.142.223 554

Miután megbizonyosodtunk arról, hogy van válasz ezen a porton, folytatjuk a WebRTC szerver telepítését.

Az Amazon EC2-n futó Centos 64 bites virtuális szervere lesz felelős a tárhelyszolgáltatásért.
A teljesítményproblémák elkerülése érdekében az m3.medium példányt választottuk egy VCPU-val:

Igen, igen, van még Linode és DigitalOcean, de ebben az esetben az Amazon-ot akartam.
A jövőre nézve leírom, hogy az Amazon EC2 vezérlőpulthoz több szabályt kell hozzáadnia (további portok), amelyek nélkül a példa nem fog működni. Ezek a WebRTC (SRTP, RTCP, ICE) forgalom portjai és az RTSP/RTP forgalom portjai. Ha megpróbálja, az Amazon szabályaiban valami hasonlónak kell lennie a bejövő forgalomra:

A DigitalOcean-nel egyébként minden egyszerűbb lesz, csak nyisd ki ezeket a portokat a tűzfalon, vagy tompítsd az utóbbit. A DO-példányok üzemeltetésének legfrissebb tapasztalatai szerint továbbra is statikus IP-címet adnak ki, és nem foglalkoznak a NAT-okkal, ami azt jelenti, hogy nincs szükség a port-továbbításra, mint az Amazon esetében.

A Flashphoner WebRTC Media & Broadcasting Serverét használjuk szerverszoftverként, amely RTSP/RTP adatfolyamot továbbít a WebRTC felé. A streaming szerver nagyon hasonlít a Wowzához, amely képes RTSP/RTP-t streamelni a Flash-re. Az egyetlen különbség az, hogy ezt a streamet a WebRTC kapja, nem a Flash. Azok. egy őszinte DTLS fog áthaladni a böngésző és a szerver között, létrejön egy SRTP munkamenet, és a VP8-ban kódolt adatfolyam eljut a nézőhöz.

A telepítéshez SSH hozzáférésre van szükségünk.

A spoiler alatt - a végrehajtott parancsok részletes leírása

1. Töltse le a szerver telepítési archívumát:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Telepített:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Telepítve:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
A telepítés során a szerver külső IP-címe 54.186.112.111 és belső 172.31.20.65 (az a privát IP-cím) lett megadva.
4. A szerver elindítása:
$service webcallserver start
5. Ellenőrizte a naplókat:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Megbizonyosodtunk arról, hogy a szerver elindult, és készen áll a működésre:
$ps aux | grep Flashphoner
7. Telepített és elindított apache:
$yum telepítés httpd
$szolgáltatás httpd start
8. Töltse le a webfájlokat, és helyezze el a szabványos Apache /var/www/html mappába
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Adja meg a szerver IP-címét a flashphoner.xml konfigurációban:
10. Leállította a tűzfalat.
$service iptables leáll

Elméletileg a 10. pont helyett helyes lenne az összes szükséges portot és tűzfalszabályt beállítani, de tesztelés céljából úgy döntöttünk, hogy egyszerűen letiltjuk a tűzfalat.

Szerver hangolás

Emlékezzünk vissza, hogy WebRTC adásunk felépítése a következő:

Ennek a diagramnak a fő elemeit már telepítettük, hátra van az interakciók "nyilai" meghatározása.

A böngésző és a WebRTC szerver közötti kapcsolatot egy webkliens biztosítja, amely elérhető a github :-on. A JS-, CSS- és HTML-fájlok egy készletét egyszerűen be kell dobni /var/www/html a telepítési szakaszban (lásd a fenti 9. bekezdést a légterelő alatt).

A böngésző és a szerver közötti interakciót a flashphoner.xml konfigurációs XML-fájl konfigurálja. Ott meg kell adni a szerver IP-címét, hogy a webkliens HTML5 Websocketeken keresztül csatlakozhasson a WebRTC szerverhez (fenti 9. pont).

A szerver beállítása itt ér véget, ellenőrizheti a működését:

Megnyitjuk a böngészőben az index.html webkliens oldalt (ehhez az Apache ugyanarra az Amazon szerverre lett telepítve a paranccsal yum -y telepítse a httpd):

54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp

Itt webrtc-ipcam.ddns.net a noip.com dinamikus DNS-kiszolgálón keresztül beszerzett ingyenes domain, amely külső IP-címünkre utal. Azt mondtuk az útválasztónak, hogy a NAT-szabályoknak megfelelően irányítsa át az RTSP-kéréseket a 192.168.1.34-re (lásd még fent).
Paraméter id=rtsp://webrtc-ipcam.ddns.net/live1.sdp megadja a lejátszandó adatfolyam URL-jét. A WebRTC szerver adatfolyamokat kér a kamerától, feldolgozza és elküldi a böngészőnek a WebRTC-n keresztüli lejátszáshoz. Lehet, hogy a routered támogatja a DDNS-t. Ha nem, akkor maga az IP-kamera rendelkezik ilyen támogatással:

És így néz ki a DDNS támogatás magában az útválasztóban:

Most elkezdheti a tesztelést és értékelheti az eredményeket.

Tesztelés

A hivatkozás böngészőben való megnyitása után létrejön a kapcsolat a WebRTC szerverrel, amely kérést küld az IP kamerának, hogy fogadja a videó streamet. Az egész folyamat néhány másodpercet vesz igénybe.

Ekkor a böngésző websocketeken keresztül csatlakozik a szerverhez, majd a szerver RTSP-n keresztül kéri az IP-kamerát, RTP-n keresztül fogadja a H.264 streamet és átkódolja azt VP8/SRTP-be – amit végül a WebRTC böngésző játszik le.

A videó alján megjelenik a videofolyam URL-je, amely másolható és megnyitható megtekintésre egy másik böngészőből vagy lapról.

Meggyőződésünk, hogy ez valóban WebRTC.

Hirtelen becsaptak minket, és az IP-kamerából a videó ismét HTTP-n keresztül érkezik? Ne nézzük tétlenül a képet, hanem nézzük meg, hogy valójában milyen forgalmat kapunk. Természetesen újra elindítjuk a Wiresharkot és a hibakereső konzolt a Chrome-ban. A böngésző Chrome konzoljában a következőket figyelhetjük meg:

Ezúttal nem villog, és nem látszanak HTTP-képek. Ezúttal csak Websocket kereteket látunk, és ezek többsége ping/pong típusú a Websocket munkamenet fenntartására. Érdekes keretek: connect, readyRtspSession és onReadyToPlay – ebben a sorrendben jön létre a kapcsolat a szerverrel: először egy Websocket kapcsolat, majd egy stream kérés a lejátszáshoz.

És itt van, amit mutat chrome://webrtc-internals

A grafikonok szerint az IP kamera bitrátája 1 Mbps. Van kimenő forgalom is, valószínűleg ezek RTCP és ICE csomagok. Az RTT az Amazon szerver felé körülbelül 300 ezredmásodperc.

Most nézzük a Wiresharkot, ott jól látszik a szerver IP címéről érkező UDP forgalom. Az alábbi képen 1468 bájtos csomagok. Ez a WebRTC. Pontosabban, az SRTP csomagok VP8-as videókockákat hordoznak, amit a böngésző képernyőjén figyelhetünk meg. Ráadásul a STUN kérések kihagyásra kerülnek (a legalacsonyabb csomag a képen) – ez a WebRTC ICE gondosan ellenőrzi a kapcsolatot.

Érdemes megjegyezni a videólejátszás viszonylag alacsony késleltetését (az adatközpontba küldött ping körülbelül 250 ms volt). A WebRTC az SRTP/UDP-n keresztül működik, amely a leggyorsabb módja a csomagok kézbesítésének, ellentétben a HTTP-vel, RTMP-vel és más TCP-szerű streamelési módszerekkel. Azok. A szem által látható késleltetésnek RTT + böngésző pufferelés, dekódolás és lejátszási időnek kell lennie. Vizuálisan ebben az esetben ez - a szem szinte nem látja a késleltetést, ez kevesebb, mint 500 ezredmásodperc.

A következő teszt a többi néző összekapcsolása. 10 Chrome ablakot tudtam kinyitni, és mindegyik egy-egy képet mutatott. Ugyanakkor maga a Chrome is kezdett egy kicsit tompa lenni. A 11. ablak megnyitásakor egy másik számítógépen a lejátszás zökkenőmentes maradt.

A WebRTC-ről a mobileszközökön

Mint tudják, a WebRTC-t a Chrome és a Firefox böngészők támogatják Android platformon.
Nézzük meg, hogy az adásunk megjelenik-e ott:

A képen a HTC telefon, a kamera videója megjelenik a Firefox böngészőben. Nincs különbség az asztalról történő lejátszás simaságában.

Következtetés

Ennek eredményeként minimális ráfordítással sikerült elindítanunk a WebRTC élő adást IP kameráról több böngészőre. Nem volt szükség tamburára vagy rakétatudományra – csak a Linux és az SSH konzol alapismeretei.

Az adás minősége elfogadható szinten volt, a lejátszási késleltetés pedig láthatatlan volt.

Összegezve elmondhatjuk, hogy a böngésző alapú WebRTC adásoknak létjogosultsága van, mert. esetünkben a WebRTC már nem mankó vagy beépülő modul, hanem valódi platform a böngészőben történő videólejátszáshoz.

Miért nem látjuk a WebRTC széles körű elterjedését?

A fő fék talán a kodekek hiánya. A WebRTC közösségnek és a szállítóknak erőfeszítéseket kell tenniük a H.264 kodek bevezetésére a WebRTC-be. A VP8 ellen nincs mit mondani, de miért adnánk fel milliónyi kompatibilis eszközt és szoftvert, amelyek H.264-gyel működnek? Szabadalmak, ilyen szabadalmak...

A második helyen a böngészők nem teljes körű támogatása. Az IE és a Safari esetében például a kérdés nyitott marad, és ott át kell váltanod egy másik típusú streamingre, vagy olyan beépülő modult kell használni, mint a webrtc4all.

Így a jövőben reméljük, hogy találunk még érdekesebb megoldásokat, amelyek nem igényelnek átkódolást és stream-konverziót, és a legtöbb böngésző képes lesz közvetlenül lejátszani a különféle eszközökről érkező streameket.