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, rendelkezik IP-címmel, és közvetlenül csatlakoztatható a routerhez a videótartalom terjesztéséhez. Tehát miért használjuk a WebRTC technológiát?

Ennek legalább két oka van:

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

2. Mint fentebb említettük, az IP kamera egy szerver. De milyen protokollokkal küldhet videót az asztali böngészőbe? Mobil eszköz? Valószínűleg ez HTTP streaming lesz, ahol a videokockákat vagy a JPEG képeket HTTP-n keresztül továbbítják. A HTTP streaming, mint ismeretes, nem teljesen alkalmas valós idejű videó streamingre, bár jól bevált az on-Demand videóknál, ahol a stream interaktivitása és késleltetése nem különösebben fontos. Valójában, ha filmet néz, néhány másodperces késleltetés 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ége 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 bővítmény ugyanúgy rögzíti és lejátssza a videót, mint maga a lejátszó. De valódi böngésző alapú adatfolyamra van szükségünk további mankók/bővítmények telepítése nélkül.

Először is készítsünk egy pillanatképet az IP-kameráról, hogy megtudjuk, pontosan mit küld ez az eszköz a böngészőnek. A tesztalany a 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ünk 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, körülbelül másodpercenként egyszer lefagy. 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 ez nem így van. Úgy néz ki, mint a HTTP. Indítsuk el a Wiresharkot, hogy megerősítsük 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 ilyen streamingre. Nem sima, rángatja a HTTP kéréseket. Hány ilyen kérést képes kezelni a kamera másodpercenként? Okkal feltételezhetjük, hogy 10 nézőnél vagy korábban a kamera biztonságosan meghajlik, vagy szörnyen meghibásodni kezd, és csúszik.

Ha megnézi a kamera adminisztrációs paneljének HTML oldalát, ezt az érdekes kódot fogja 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 az rtsp-t. var host = g_netip; else var host = g_host; o+=""; //figyelmeztetés(o); DW(o); )

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

Itt említhetjük meg a Flash Playert is, amely egy megfelelő szerveren, például a Wowza-n keresztül RTSP, RTP, H.264-ből konvertált RTMP adatfolyamot tud fogadni. De a Flash Player, mint tudod, 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 vagy 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 tetszőleges számú felhasználónak küldi el az internetre a WebRTC-t támogató 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 kapja meg szerverünk a kamerától érkező videofolyamot.

A mellékelt patch kábel segítségével csatlakoztatjuk a kamerát a routerhez. A tápfeszültség bekapcsolása és a routerhez való csatlakozás után a kamera felvett egy IP-címet DHCP-n keresztül, esetünkben ez 192.168.1.34 (ha a router beállításaiba lép, látni fogja, hogy a DCS 7010L eszköz csatlakoztatva van - ennyi ). 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átor webes felületét. Alapértelmezés szerint nincs jelszó.

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

Kamera beállítása

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

Itt ellenőrizzük az RTSP protokoll port értékét is, ez alapértelmezés szerint 554. A továbbított videó formátumát a használt profil határozza meg. Legfeljebb hármat beállíthatunk a kamerában, mi az elsőt, a live1.sdp-t fogjuk használni – alapértelmezés szerint a H.264-et használja a videóhoz és a G.711-et a hanghoz. A beállításokat szükség esetén módosíthatja a részben Beállítás – Hang é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ás RTSP-t támogató lejátszót használhat – 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 rendszeresen reprodukálja a videofolyamot a lejátszóban az RTSP protokollon keresztül.

Mellesleg a streamet meglehetősen simán és műtermékek nélkül játssza le. 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. Csak annyit kell tennie, hogy közölje az útválasztóval, hogy az RTSP-n keresztül az 554-es porton keresztül a bejövő kérések az IP-kamerához kerülnek.

Adja meg a megfelelő beállításokat a routerben...

...é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 egy m3.medium példányt választottunk egy VCPU-val:

Igen, igen, van Linode és DigitalOcean is, de ebben az esetben ki akartam próbálni az Amazont.
A jövőre nézve megí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) és az RTSP/RTP forgalom portjai. Ha megpróbálja, az Amazon szabályaiban valami hasonlónak kell lennie a bejövő forgalomra:

A DigitalOceannal egyébként minden egyszerűbb lesz, csak nyissa meg ezeket a portokat a tűzfalon, vagy kapcsolja ki az utóbbit. A DO példányok üzemeltetésével kapcsolatos legfrissebb tapasztalatok 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 porttovábbításra, mint az Amazon esetében.

A Flashphoner WebRTC Media & Broadcasting Server-ét használjuk szerverszoftverként, amely az RTSP/RTP adatfolyamot továbbítja a WebRTC-hez. A streaming szerver nagyon hasonlít a Wowzához, amely képes RTSP/RTP adatfolyamot streamelni a Flash-re. Az egyetlen különbség az, hogy ez az adatfolyam a WebRTC-nek lesz elküldve, nem a Flash-nek. Azok. Az őszinte DTLS átmegy 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 megjelenítőhöz.

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

A spoiler alatt a végrehajtott parancsok részletes leírása található

1. Letöltötte 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. Kibontva:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Telepítve:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
A telepítés során megadtuk a szerver külső IP-címét: 54.186.112.111 és belső 172.31.20.65 (ugyanaz, mint a Private IP).
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. Győződjön meg 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. Írja be a szerver IP-címét a flashphoner.xml konfigurációba:
10. Leállította a tűzfalat.
$service iptables leáll

Elméletileg a 10. pont helyett helyes lenne beállítani az összes szükséges portot és tűzfalszabályt, 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, már csak az interakciók „nyilait” kell megállapítani.

A böngésző és a WebRTC szerver közötti kapcsolatot a 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 beépítési szakaszban (lásd a fenti 9. pontot a légterelő alatt).

A böngésző és a szerver közötti interakciót a flashphoner.xml XML konfigurációs fájl konfigurálja. Itt meg kell adnia 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, működését ellenőrizheti:

Nyissa meg a webkliens index.html oldalát a böngészőben (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 egy ingyenes domain a noip.com dinamikus DNS-kiszolgálón keresztül, amely külső IP-címünkre utal. Azt mondtuk az útválasztónak, hogy irányítsa át az RTSP kéréseket a 192.168.1.34-re a NAT hálózati címfordítási szabályoknak megfelelően (lásd fent is).
Paraméter id=rtsp://webrtc-ipcam.ddns.net/live1.sdp megadja a lejátszandó adatfolyam URL-jét. A WebRTC szerver streameket kér a kamerától, feldolgozza és elküldi a böngészőbe lejátszásra a WebRTC-n keresztül. 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 a videó stream fogadására. Az egész folyamat néhány másodpercet vesz igénybe.

Ekkor websocketeken keresztül jön létre a kapcsolat a böngésző és a szerver között, 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 VP8/SRTP-be – ami végül lejátssza a WebRTC böngészőt.

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.

Biztosítjuk, hogy ez valóban WebRTC.

Mi van, ha megtévesztenek minket, és az IP-kamera videója ismét HTTP-n keresztül kerül továbbításra? 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 Chrome böngésző konzoljában a következőket láthatjuk:

Ezúttal semmi sem villog, és HTTP-n keresztül továbbított képek sem láthatók. 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.

Íme, mit 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 Amazon szerver RTT-je körülbelül 300 ezredmásodperc.

Most nézzük meg a Wiresharkot, tisztán láthatja az UDP-forgalmat a szerver IP-címéről. Az alábbi képen a csomagok 1468 bájtosak. Ez a WebRTC. Pontosabban VP8-as videókockákat hordozó SRTP csomagok, amelyeket a böngésző képernyőjén figyelhetünk meg. Ezenkívül a STUN kérések átcsúsznak (a legalacsonyabb csomag a képen) - ez a WebRTC ICE, amely gondosan ellenőrzi a kapcsolatot.

Érdemes megjegyezni a viszonylag alacsony késleltetést is (az adatközpontba küldött ping körülbelül 250 ms volt) a videólejátszásnál. A WebRTC SRTP/UDP-n keresztül működik, és végül is ez 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 szemmel látható késleltetésnek RTT-nek kell lennie + a pufferelés, a dekódolás és a böngésző általi lejátszás ideje. Vizuálisan ez a helyzet ebben az esetben - 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. Sikerült kinyitnom 10 Chrome ablakot, és mindegyikben volt egy kép. Ugyanakkor maga a Chrome kezdett kissé unalmassá válni. 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 egy HTC telefon látható, a Firefox böngésző videót jelenít meg a kamerából. A lejátszás simasága terén nincs különbség az asztali számítógéphez képest.

Következtetés

Ennek eredményeként minimális erőfeszítéssel tudtunk WebRTC online adást indítani IP-kameráról több böngészőre. Nem volt szükség tamburával táncolni 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.

Összefoglalva azt mondhatjuk, hogy a böngésző alapú WebRTC adásoknak létjogosultsága van, mert esetünkben a WebRTC már nem egy mankó vagy egy plugin, hanem egy valódi platform a videó lejátszásához a böngészőben.

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

A fő akadály 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, és be kell vezetniük a H.264 kodeket a WebRTC-be. A VP8 ellen nincs mit mondani, de miért adnánk fel milliónyi kompatibilis eszközt és szoftvert, amelyek együttműködnek a H.264-gyel? Szabadalmak, ilyen szabadalmak...

A második helyen a böngészők nem teljes körű támogatása áll. 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, amelyekben nem lesz szükség a streamek átkódolására és konvertálására, és a legtöbb böngésző képes lesz közvetlenül lejátszani a különböző eszközökről érkező streameket.

RTSP (Real Time Streaming Protocol)– Valós idejű streaming protokoll, amely egyszerű alapvető parancskészletet tartalmaz a videofolyam vezérléséhez.

RTSP-források és IP-kamerák csatlakoztatása videokonferenciákhoz

Az RTSP-protokoll lehetővé teszi bármely TrueConf-felhasználó számára, hogy csatlakozzon IP-videokamerákhoz és más médiatartalom-forrásokhoz, amelyek ezzel a protokollal sugároznak távoli objektumok megfigyelésére. A felhasználó az ilyen kamerákhoz is csatlakozhat, hogy képeket sugározzon videokonferencia közben.

Az RTSP protokoll támogatásának köszönhetően a TrueConf Server felhasználók nem csak IP kamerákhoz csatlakozhatnak, hanem videokonferenciákat is sugározhatnak RTSP lejátszókra és médiaszerverekre. További információ az RTSP adásokról.

Az IP-kamerák TrueConf szoftvermegoldásokkal való használatának előnyei

• Ha IP-kamerát telepít egy irodai vagy ipari műhelybe, és bármikor csatlakozik hozzá, irányítani tudja cége gyártási folyamatát.
• A távoli objektumokat éjjel-nappal figyelheti. Például, ha nyaralni megy, és nem akarja felügyelet nélkül hagyni a lakását, egyszerűen szereljen fel egy vagy több IP-kamerát. Ha felhívja valamelyik kamerát számítógépéről, amelyen a TrueConf kliens alkalmazás telepítve van, bármikor csatlakozhat lakásához, és valós időben láthatja, mi történik ott.
• A Windows, Linux és macOS rendszerekhez készült TrueConf kliens alkalmazásokban minden felhasználó hozzáfér a videokonferenciák rögzítésének lehetőségéhez, aminek köszönhetően a videó megfigyelés során bármilyen eseményt rögzíthet, és azokról okirati bizonyítékokat kaphat.

Hogyan ellenőrizhető az RTSP adatfolyam IP-kameráról történő sugárzása különböző webböngészőkben

Ellenőrizzük az RTSP videofolyam megjelenítését Chrome, Firefox, Safari böngészőkben Windows, Mac OS X, Linux rendszerű asztali számítógépeken, valamint Android és iOS rendszerű mobileszközökön

Az RTSP adatfolyam ellenőrzése VLC-ben

Ha gyorsan meg szeretné győződni arról, hogy az RTSP adatfolyam elérhető, és streameli a videót, nyissa meg a VLC lejátszóban. Ha a stream megfelelően működik, akkor továbblépünk a webes felület tesztelésére. Az RTSP URL-t lekérheti az IP kamera vezérlőpultján, vagy használhat valamilyen nyilvánosan elérhető RTSP videofolyamot, például ezt: rtsp://b1.dnsdojo.com:1935/live/sys3.stream

Az RTSP-WebRTC adatfolyam tesztelése Google Chrome és Mozilla Firefox böngészőkben

Gondoskodunk arról, hogy ugyanazt az RTSP-folyamot lejátssza egy normál HTML-oldalon a Chrome és a Firefox böngészőkben.

1. Töltse be a bemutató felületet a 'Demo / Streaming Min' menüből. Ez egy minimális HTML5 webes felület, amely WebRTC technológiát használ az RTSP videofolyam megjelenítésére a Chrome és a Firefox böngészőkben.

2. Hozzon létre kapcsolatot a webhívás szerverrel

3. Adja meg a kamera RTSP-címét, és kezdje el lejátszani a streamet:

Ennek eredményeként sikeresen teszteltük az RTSP adatfolyam lejátszását a Google Chrome böngészőben. Hasonló teszt végezhető el a Firefox és az Opera böngészőkkel azokon az asztali és mobil platformokon, amelyek a böngészőkben támogatják a WebRTC technológiát.

RTSP-Websocket adatfolyam tesztelése a Safari böngészőben iOS és Mac OS X alatt

Az iOS eszközökön lévő böngészők nem támogatják a WebRTC technológiát. Emiatt egy különálló „WS Player Min” lejátszót használnak, amely a Websocket protokollon keresztül veszi a streamet, és a böngésző HTML5-Canvas elemében játssza le.

1. Csakúgy, mint a Chrome esetében, meg kell nyitnia a bemutató felület oldalát, de válasszon egy másik menüpontot:

2. Ezt követően hozzon létre kapcsolatot a webhívás szerverrel

3. Adja meg a korábban ismert RTSP sugárzási címet, és játssza le a videofolyamot:

Így a fentiek bemutatják a Web Call Server segítségével konvertált RTSP-forgalom megtekintésének képességét a leggyakoribb webböngészőkön, beleértve a legnépszerűbb mobilplatformokat is.

A következő lépés egy HTML5 RTSP lejátszó hozzáadása a saját webhelyéhez. A hozzáadási folyamat részletes leírása a szomszédos Megvalósítás részben található.

Az RTSP-WebRTC és az RTSP-Websocket lejátszó tesztelési folyamatát leíró videók

RTSP-WebRTC lejátszó Chrome-hoz és Firefoxhoz

RTSP-Websocket lejátszó iOS Safarihoz

Töltse le a Web Call Server 5-öt

Rendszerkövetelmények: Linux x86_64, 1 magos CPU, 2 Gb RAM, Java

Telepítés:

1. wget https://site/download-wcs5.2-server.tar.gz
2. Csomagolja ki és telepítse az "install.sh" szkript segítségével
3. Indítsa el a szervert a "service webcallserver start" paranccsal
4. Nyissa meg a https://host:8444 webes felületet, és aktiválja licencét

Ha Amazon EC2 szervereket használ, nem kell letöltenie semmit.

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 videokamera 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 protokollnév átadja a vezérlést online módba. Í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 a virtuális tárolóhoz;
• videokamerát adjon hozzá Android vagy iOS alapú mobilalkalmazásokhoz.

Ugyanakkor az RTSP adatfolyam megnyitása a videó megfigyelőrendszerek sok felhasználója számára nem túl egyszerű és meglehetősen nehéz.

Tudja meg a CCTV kamera RTSP címét

Számos lehetőség van, amelyek lehetővé teszik a videokamera RTSP adatfolyamának megtudását, ha azt a megfelelő utasítások nem jelzik.

Az Oroszországban értékesített nagyszámú IP-videokamera 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. A hasonló 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 a következő összetevőket tartalmazza:

• 192.168.132.32 – az eszköz közvetlen IP-címe;
• 554 – protokoll port (alapértelmezés szerint 554-es számmal van ellátva, de ez a paraméter módosítható az eszközbeállításokban);
• admin – CCTV kamera bejelentkezés;
• 12355 – jelszó a felhasználói bejelentkezéshez.

Abban az esetben, ha az IP-videokamera egyéb összetevőket is tartalmaz, az alábbiakban felsorolt ​​két lehetőség valamelyikét kell használnia.

Az első lehetőség a legegyszerűbb. A CCTV kamerából származó RTSP adatfolyam megtudásához vegye fel a kapcsolatot az eszköz gyártójával vagy szállítójával. Kérésre biztosítani tudják a szükséges 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 olyan esetekben segíthet, amikor a videó megfigyelő rendszer tulajdonosának nincs lehetősége vagy nem akar RTSP stream címet kérni a szállítótól. Ezután saját maga is megteheti szoftver segítségével.

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 lehet nehézség. Fontos árnyalat - a megfelelő működéshez csatlakoztatnia kell a laptopot vagy számítógépet, amelyre a programot telepíteni fogja, valamint magát az IP-eszközt ugyanahhoz a helyi hálózathoz.

Az interneten teljes listákat találhat, amelyek tartalmazzák az RTSP-folyamok címét, mivel ezek az adatok attól függenek, hogy melyik videomegfigyelő kamera márkáját gyártják.

Hogyan lehet megnyitni egy RTSP adatfolyamot egy videokamerá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. 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 videokamerának, és rendelje meg internetszolgáltatójától;
• a videokamerától érkező helyi kérések továbbítása az RTSP portra;
• teljesítőképességi tesztet teljesíteni.

Statikus cím konfigurálható az IP Hunter programmal, vagy felveheti a kapcsolatot a szolgá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 port továbbítást és a videokamera helyi portjairól az RTSP portra továbbító portokat. Ezután folytathatja az áramlás ellenőrzését.

Annak megértéséhez, hogy az RTSP-hivatkozás működőképes-e, nyissa meg a VLC-lejátszót, és ellenőrizze ott. Ehhez a lejátszó főmenüjében kattintson a „Média” kategóriára, és válassza az „URL megnyitása” lehetőséget. Ezután a „Forrás” ablak „Hálózat” lapjára kell lépnie, és meg kell adnia a hivatkozást.

Gyakran felmerül a kérdés: Hogyan lehet IP-kamerát NVR-hez csatlakoztatni, ha nem szerepel a kompatibilitási listán?

Két lehetőség van ONVIF és RTSP

Kezdjük az ONVIF protokollal (Open Network Video Interface Forum)

Az ONVIF egy általánosan elfogadott protokoll IP-kamerák, NVR-ek, szoftverek közös üzemeltetésére, abban az esetben, ha minden eszköz más gyártótól származik. Az ONVIF az emberek nemzetközi kommunikációjában az angol nyelvhez hasonlítható.

Győződjön meg arról, hogy a csatlakoztatott eszközök támogatják az ONVIF-et; egyes eszközökön az ONVIF alapértelmezés szerint le van tiltva.
Vagy előfordulhat, hogy az ONVIF-engedélyezés le van tiltva, ami azt jelenti, hogy a bejelentkezési név/jelszó alapértelmezés szerint mindig az lesz
függetlenül a WEB bejelentkezési nevétől/jelszavától

Azt is érdemes megjegyezni, hogy egyes eszközök használnakkülön port az ONVIF protokollon keresztüli működéshez

Egyes esetekben az ONVIF jelszó eltérhet a WEB hozzáférési jelszótól.

Mi érhető el, ha ONVIF-en keresztül csatlakozik?

Eszköz felfedezés

Videó átvitel

Hangadatok fogadása és továbbítása

PTZ kamera vezérlés

Videóelemzés (például mozgásérzékelés)

Ezek a paraméterek az ONVIF protokollverziók kompatibilitásától függenek. Egyes esetekben bizonyos paraméterek nem állnak rendelkezésre, vagy nem működnek megfelelően.

K és ONVIF használatával

Az SNR és Dahua felvevőkben az ONVIF protokoll a Távoli eszköz lap Gyártó sorában található.

Válassza ki azt a csatornát, amelyhez az eszköz csatlakozik

A Gyártó lapon válassza ki a lehetőséget ONVIF

Adja meg IP-cím eszközöket

RTSP a port alapértelmezett marad

Kamerák használata ONVIF 8080-as port
(2017 óta az új ONVIF modelleken a port 80-ra módosult az Alpha és Mira sorozat esetében)
OMNY kamerák Bázis használat ONVIF 80-as port, a regisztrátorban HTTP portként van feltüntetve

Név

Jelszó a készülék paraméterei szerint

Távoli csatorna az alapértelmezett érték 1. Ha az eszköz többcsatornás, a csatorna száma megjelenik.

Dekóder puffer— a videofolyam pufferelése, amely jelzi az időértéket

Szerver típusaitt választhat a TCP,UDP ütemezés közül

TCP- kapcsolatot létesít a küldő és a címzett között, gondoskodik arról, hogy minden adat változtatás nélkül és a kívánt sorrendben eljusson a címzetthez, valamint szabályozza az átviteli sebességet is.

A TCP-vel ellentétben UDP nem hoz létre előzetes kapcsolatot, hanem egyszerűen elkezdi az adatátvitelt. Az UDP nem figyeli az adatok fogadását, és nem másolja le azokat elvesztés vagy hiba esetén.

Az UDP kevésbé megbízható, mint a TCP. Másrészről azonban gyorsabb adatfolyamot biztosít az elveszett csomagok újraküldésének hiánya miatt

Menetrend— automatikus típusérzékelés.

Így néznek ki a csatlakoztatott eszközök Dahuában

A zöld állapot azt jelenti, hogy a felvevő és a kamera sikeresen csatlakoztatva van

A piros állapot azt jelenti, hogy kapcsolódási problémák vannak. Például a csatlakozási port nem megfelelő.

A második csatlakozási mód az RTSP(Valós idejű streamelési protokoll)

RTSPegy valós idejű streaming protokoll, amely leírja a videofolyam vezérlésére szolgáló parancsokat.

Ezekkel a parancsokkal a videó adatfolyamot a forrástól a címzettig sugározzák

például IP-kameráról DVR-re vagy szerverre.

Mi érhető el RTSP-n keresztüli csatlakozáskor?

Videó átvitel

Hangadatok fogadása és továbbítása

ElőnyEz az átviteli protokoll az, hogy nem igényel verzió-kompatibilitást.

Ma az RTSP-t szinte minden IP-kamera és NVR támogatja

Hibák A protokoll az, hogy a video- és hangadatok átvitelén kívül semmi más nem érhető el.

Nézzünk egy példát a kamera csatlakoztatására hogy és RTSP használatával

RTSP a Távoli eszköz lap Gyártó sorában található, az SNR és a Dahua felvevőben így jelenik megTábornok

Válassza ki azt a csatornát, amelyhez az eszköz csatlakozik

URL cím- ide írjuk be azt a lekérdezési karakterláncot, amelyre a kamera küld alapvető RTSP stream with magas felbontás.

Extra URL - Itt írja be a lekérdezési karakterláncot, amelyre a kamera küld további RTSP stream with alacsony felbontás.

Példa kérés:

rtsp://172.16.31.61/1 fő stream

rtsp://172.16.31.61/2 további adatfolyam

Miért van szükség további szálra?

A többképes rögzítőhöz csatlakoztatott helyi monitoron a felvevő egy további szálat használ az erőforrások megtakarítására. Például a 16 ablakos kis képeken egyáltalán nem kell Full HD felbontást dekódolni, elég a D1. Nos, ha 1/4/8 ablakot nyitott meg, ebben az esetben a fő stream nagy felbontással dekódolásra kerül.

Néva készülék paraméterei szerint

Jelszó a készülék paraméterei szerint

Dekóder puffera videó folyam pufferelése, amely jelzi az időértéket

Szerver típusa- TCP, UDP, ütemezés (hasonlóan az ONVIF protokollhoz)

Ez a cikk választ ad a leggyakoribb kérdésekre, például:

Az IP kamera kompatibilis az NVR-rel?

És ha kompatibilis, hogyan kell csatlakoztatni!?