IP kamerák megtekintése az rtsp-n keresztül. RTSP videó megfigyelés

Egyes adatok szerint a mai napig a világ telepítette százmilliókat IP kamerák videó megfigyeléshez. Azonban messze nem mindegyik, a videólejátszás késése kritikus. A videó megfigyelés általában "statikusan" történik - az adatfolyamot a tárolóban rögzítik, és elemezhető mozgás szempontjából. A videó megfigyeléshez számos szoftveres és hardveres megoldást fejlesztettek ki, amelyek jól végzik a dolgukat.

Ebben a cikkben egy kicsit más alkalmazást fogunk megvizsgálni. IP kamerák, nevezetesen az online adásokban való felhasználás, ahol szükséges alacsony kommunikációs késleltetés.

Mindenekelőtt tisztázunk egy esetleges félreértést a webkamerákkal és IP-kamerákkal kapcsolatos terminológiában.

Webkamera egy videorögzítő eszköz, amely nem rendelkezik saját processzorral és hálózati interfésszel. A webkamerához csatlakozni kell számítógéphez, okostelefonhoz vagy más olyan eszközhöz, amely hálózati kártyával és processzorral rendelkezik.

IP kamera egy önálló eszköz, amely saját hálózati kártyával és processzorral rendelkezik a rögzített videó tömörítésére és a hálózatra küldésére. Így az IP-kamera egy önálló mini-számítógép, amely teljes mértékben csatlakozik a hálózathoz, és nem kell más eszközhöz csatlakoztatnia, és közvetlenül képes sugározni a hálózatra.

Alacsony késleltetés(alacsony késleltetés) meglehetősen ritka követelmény az IP-kamerák és az online adások esetében. Az alacsony késleltetésű munka szükségessége például akkor jelenik meg, ha a videofolyam forrása aktívan együttműködik a stream nézőivel.

Leggyakrabban alacsony késleltetésre van szükség játékhasználati esetekben. Példák: valós idejű videoaukció, élő kereskedő videokaszinó, interaktív online TV-műsor házigazdával, kvadrokopter távirányítója stb.

Egy élő online kaszinókereskedő a munkahelyén.

Egy közönséges RTSP IP kamera általában benyomja a videót H.264 kodek és kétféle adatátviteli módban működhet: átlapoltÉs nem átlapolt.

Mód átlapolt a legnépszerűbb és legkényelmesebb, mert ebben az üzemmódban a videoadatok TCP protokollon keresztül kerülnek továbbításra a hálózati kapcsolaton belül a kamerához. Az IP-kameráról az interleavedre történő terjesztéshez csak meg kell nyitnia / továbbítania kell a kamera egyik RTSP portját (például 554-et) kifelé. A lejátszónak csak TCP-n keresztül kell csatlakoznia a kamerához, és fel kell vennie a már ezen a kapcsolaton belüli adatfolyamot.

A kamera második üzemmódja az nem átlapolt. Ebben az esetben a kapcsolat a protokoll használatával jön létre RTSP/TCP, és a forgalom már külön megy a protokoll szerint RTP/UDP a létrehozott TCP-csatornán kívül.

Mód nem átlapolt kedvezőbb a videó sugárzására minimális késleltetéssel, mivel a protokollt használja RTP/UDP, de ugyanakkor problémásabb, ha a játékos mögött van NAT.

Amikor a lejátszó NAT mögött található IP-kamerájához csatlakozik, a lejátszónak tudnia kell, hogy mely külső IP-címeket és portokat használhatja hang- és videoforgalom fogadására. Ezeket a portokat az RTSP-kapcsolat létrejöttekor a kamerának küldött SDP-konfiguráció szövegben határozzák meg. Ha a NAT megfelelően lett megnyitva, és a megfelelő IP-címek és portok vannak megadva, akkor minden működni fog.

Tehát ahhoz, hogy minimális késleltetéssel videót készítsen a kameráról, használnia kell nem interleave módban, és fogadja a videoforgalmat UDP-n keresztül.

A böngészők nem támogatják közvetlenül az RTSP/UDP protokollvermet, de támogatják a beágyazott technológiai protokollvermet WebRTC.

Főleg a böngésző- és kameratechnológiák nagyon hasonlóak SRTP titkosítva van RTP. De a böngészőkhöz való helyes terjesztéshez az IP-kamerának részlegesen támogatnia kell a WebRTC veremét.

Ennek az inkompatibilitásnak a kiküszöbölésére egy köztes közvetítő szerverre van szükség, amely hidat képez az IP kamera protokolljai és a böngésző protokolljai között.

A szerver a streamet az IP kamerától magához veszi RTP/UDPés WebRTC-n keresztül adja a csatlakoztatott böngészőknek.

A WebRTC technológia a protokoll szerint működik UDPés így alacsony késleltetést biztosít az irányba Szerver > Böngésző. Az IP kamera is a protokollon működik RTP/UDPés alacsony késleltetést biztosít az irányba Kamera > Szerver.

A kamera korlátozott számú adatfolyamot tud adni a korlátozott erőforrások és sávszélesség miatt. Egy köztes szerver használata lehetővé teszi, hogy az adást egy IP-kameráról nagyszámú nézőhöz skálázza.

Másrészt a szerver használatakor két kommunikációs láb engedélyezve van:
1) A nézők és a szerver között
2) A szerver és a kamera között
Egy ilyen topológiának számos "tulajdonsága" vagy "csapdája" van. Az alábbiakban felsoroljuk őket.

1. buktató – kodekek

A használt kodekek akadályozhatják az alacsony késleltetést, és a rendszer általános teljesítményének romlását okozhatják.

Például, ha a kamera 720p-s videofolyamot ad H.264-ben, és egy Chrome böngésző csatlakozik egy Android okostelefonhoz, amely csak a VP8-at támogatja.

Ha az átkódolás engedélyezve van, minden csatlakoztatott IP-kamerához létre kell hozni egy átkódolási munkamenetet, amely dekódolja H.264és bekódol VP8. Ebben az esetben egy 16 magos, kétprocesszoros szerver csak 10-15 IP-kamerát lesz képes kiszolgálni, hozzávetőlegesen 1 kamera fizikai magonként.

Ezért ha a szerver kapacitása nem teszi lehetővé a tervezett számú kamerák átkódolását, akkor az átkódolást kerülni kell. Például csak a H.264-támogatással rendelkező böngészőket szolgálja ki, a többieknek pedig natív mobilalkalmazás használatát ajánlja fel iOS-re vagy Androidra, ahol a H.264 kodek is támogatott.

A mobilböngészőben az átkódolás megkerülésére szolgáló lehetőségként használhatja HLS. De a HTTP streamelés egyáltalán nem alacsony késleltetésű, és jelenleg nem használható interaktív adatfolyamhoz.

2. buktató – A kamera bitsebessége és vesztesége

Az UDP protokoll segít megbirkózni a késleltetéssel, de lehetővé teszi a videocsomag elvesztését. Ezért az alacsony késleltetés ellenére a kamera és a szerver közötti nagy hálózati veszteségek miatt a kép megsérülhet.

A veszteségek kiküszöbölése érdekében meg kell győződni arról, hogy a kamera által generált videofolyam bitsebessége belefér a kamera és a szerver között lefoglalt sávszélességbe.

3. buktató – Nézői bitráta és veszteség

Minden adás-néző, aki csatlakozik a szerverhez, szintén rendelkezik egy bizonyos letöltési sávszélességgel.

Ha az IP kamera olyan adatfolyamot küld, amely meghaladja a néző csatorna képességeit (például a kamera 1 Mbps, és a néző csak elfogadhatja 500 kbps), akkor nagy veszteségek lesznek ezen a csatornán, és ennek eredményeként videófrízek vagy erős műtermékek jelennek meg.

Ebben az esetben három lehetőség van:

1. A videofolyamot minden egyes néző számára külön kódolja át a kívánt bitsebességgel.
2. Az adatfolyamok átkódolása nem minden egyes csatlakoztatott, hanem egy nézőcsoport egy csoportja számára.
3. Előzetesen készítsen adatfolyamot a kameráról többféle felbontásban és bitsebességgel.

Első lehetőség Az egyes nézők átkódolása nem megfelelő, mivel már 10-15 csatlakoztatott néző esetén is elhasználja a CPU erőforrásokat. Bár meg kell jegyezni, hogy ez az opció maximális rugalmasságot biztosít maximális CPU-terhelés mellett. Azok. ez ideális, ha például csak 10 földrajzilag elosztott személynek streamel, mindegyikük dinamikus bitsebességet kap, és mindegyiküknek minimális késleltetésre van szüksége.

Második lehetőség célja, hogy csökkentse a szerver CPU terhelését átkódoló csoportok segítségével. A szerver több csoportot hoz létre bitsebesség szerint, például kettőt:

• 200 Kbps
• 1 Mbps

Ha a nézőnek nincs elég sávszélessége, akkor átvált arra a csoportra, amelyben kényelmesen tudja fogadni a videofolyamot. Így az átkódolási munkamenetek száma nem egyenlő a nézők számával, mint az első esetben, hanem egy fix szám, például 2, ha csoportokat kódol át. kettő.

Harmadik lehetőség magában foglalja a szerveroldali átkódolás teljes elutasítását és a már előkészített videofolyamok használatát különböző felbontásokban és bitsebességekben. Ebben az esetben a kamera úgy van beállítva, hogy két vagy három különböző felbontású és bitsebességű adatfolyamot adjon ki, és a nézők a sávszélességüktől függően váltanak ezek között az adatfolyamok között.

Ebben az esetben a szerver átkódolási terhelése megszűnik, és magára a kamerára tolódik át, mert a kamera most két vagy több adatfolyamot kénytelen kódolni egy helyett.

Ennek eredményeként három lehetőséget mérlegeltünk a nézők sávszélességéhez való alkalmazkodásra. Ha feltételezzük, hogy egy átkódolási munkamenet 1 szervermagot vesz igénybe, akkor a következő CPU-terhelési táblázatot kapjuk:

A táblázat azt mutatja, hogy az átkódolási terhelést áthelyezhetjük a kamerára, vagy átvihetjük az átkódolást a szerverre. A 2. és 3. lehetőség tűnik a legoptimálisabbnak.

Az RTSP tesztelése WebRTC-ként

Ideje lefuttatni néhány tesztet, hogy felfedje a valós képet arról, hogy mi történik. Vegyünk egy valódi IP-kamerát, és teszteljük a sugárzási késleltetés mérésére.

Vegyünk egy ősi IP kamerát tesztelésre D-link DCS-2103 a támogatással RTSPés kodekek H.264 és G.711.

Mivel a kamera sokáig egy szekrényben hevert egyéb hasznos eszközökkel, vezetékekkel, el kellett küldenem Visszaállítás a kamera hátulján található gomb 10 másodpercig tartó nyomva tartásával.

A hálózathoz való csatlakozás után a kamera zöld lámpája kigyulladt, és a router egy másik eszközt látott a helyi hálózaton, amelynek IP-címe 192.168.1.37.

A kamera webes felületére lépünk, és beállítjuk a kodekeket és a felbontást teszteléshez:

Ezután lépjen a hálózati beállításokhoz, és keresse meg a kamera RTSP-címét. Ebben az esetben az RTSP-cím live1.sdp, azaz A kamera a következő címen érhető el rtsp://192.168.1.37/live1.sdp

A kamera hozzáférhetősége egyszerűen ellenőrizhető VLC lejátszó. Média – Nyissa meg a hálózati adatfolyamot.

Megbizonyosodtunk arról, hogy a kamera működik, és RTSP-n keresztül ad videót.

A teszteléshez a Web Call Server 5-öt használjuk szerverként. Ez egy streaming szerver támogatással RTSP és WebRTC protokollok. Ezzel csatlakozik az IP kamerához RTSPés vegye át a videofolyamot. Az adatfolyam további terjesztése a következővel: WebRTC.

A telepítés után a szervert RTSP módba kell kapcsolni nem átlapolt amelyet fentebb tárgyaltunk. Ezt a beállítás hozzáadásával lehet megtenni

rtsp_interleaved_mode=false
Ez a beállítás hozzáadódik a flashphoner.properties konfigurációhoz, és a szerver újraindítását igényli:

Service webcallserver újraindítása
Így van egy olyan szerverünk, amely a non-interleaved séma szerint működik, UDP-n keresztül fogadja a csomagokat az IP-kamerától, majd WebRTC-n (UDP) keresztül terjeszti.

A tesztszerver a frankfurti adatközpontban található VPS-szerveren található, 2 maggal és 2 gigabájt RAM-mal rendelkezik.

A kamera a helyi hálózaton található a 192.168.1.37 címen.

Ezért az első dolgunk, hogy az 554-es portot a 192.168.1.37-re továbbítsuk a bejövő portokhoz. TCP/RTSP kapcsolatokat, hogy a szerver csatlakozhasson az IP kameránkhoz. Ehhez csak egy szabályt adjon hozzá az útválasztó beállításaihoz:

A szabály azt mondja az útválasztónak, hogy az 554-es porton keresztül irányítsa át az összes bejövő forgalmat a 37-es IP-címre.

Ha van egy barátságos NAT-ja, és ismeri a külső IP-címet, akkor elkezdheti a tesztelést a szerverrel.

A Google Chrome böngésző szabványos demólejátszója így néz ki:

Az RTSP stream lejátszásának megkezdéséhez csak be kell írnia a címét a mezőbe Folyam.
Ebben az esetben az adatfolyam címe: rtsp://ip-cam/live1.sdp
Itt ip cam ez a kamera külső IP-címe. A szerver megpróbál kapcsolatot létesíteni ezzel a címmel.

VLC vs WebRTC késleltetési teszt

Miután konfiguráltuk az IP kamerát és teszteltük VLC, beállítottuk a szervert és teszteltük RTSPátfolyik a szerveren a terjesztéssel WebRTC, végre összehasonlíthatjuk a késéseket.

Ehhez egy időzítőt fogunk használni, amely a másodperc töredékeit mutatja a monitor képernyőjén. Kapcsolja be az időzítőt és egyidejűleg játssza le a videofolyamot VLC helybenés a Firefox böngészőben távoli szerveren keresztül.

Ping a szerverre 100 ms.
Ping helyben 1 ms.

Az első időzítő teszt így néz ki:
Fekete alapon az eredeti időzítő látható, amely nulla késleltetést mutat. Bal VLC, jobb oldalon Firefox fogadása WebRTC stream egy távoli szerverről.

	Nulla	VLC	Firefox, WCS
Idő	50.559	49.791	50.238
késleltetés ms	0	768	321

Ezen a teszten késést látunk VLC kétszer olyan hosszú, mint a késés Firefox + Web Call Server, annak ellenére, hogy a VLC-ben lévő videót a helyi hálózaton játsszák le, és a Firefoxban megjelenített videó áthalad egy németországi adatközpont szerverén, és visszatér. Ez az eltérés annak a ténynek tudható be, hogy a VLC TCP-n (interleaved mode) keresztül működik, és tartalmaz néhány további puffert a zökkenőmentes videólejátszás érdekében.

Készítettünk néhány felvételt a késleltetési értékek rögzítéséhez.

RTSP (Real Time Streaming Protocol) egy valós idejű streaming protokoll, amely egyszerű alapvető parancsokat tartalmaz a videofolyam vezérléséhez.

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

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. Ezenkívül a felhasználó csatlakozhat ilyen kamerákhoz, hogy képeket sugározzon egy videokonferencia során.

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á, figyelemmel kísérheti cége gyártási folyamatát.
• A távoli objektumok éjjel-nappal megfigyelését végezheti. Például, ha nyaralni megy, és nem akarja őrizetlenül hagyni a lakását, csak telepítsen oda 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 TrueConf kliens alkalmazások Windowsra, Linuxra és macOS-re minden felhasználó számára lehetőséget biztosítanak videokonferenciák rögzítésére, aminek köszönhetően bármilyen eseményt rögzíthet a videó megfigyelés során, és dokumentált bizonyítékot kaphat azokról.

Kényelmes videoadások megtekintése, vagy konfigurálható a számítógépén található szoftveres multimédia lejátszókkal. Ma megvizsgáljuk, hogyan állíthatunk be RTSP adatfolyamot a Dahua Technology hálózati berendezésekhez az egyik legnépszerűbb VLC Media Playerben.

Az RTSP (Real Time Streaming Protocol – valós idejű streaming protokoll) egy olyan protokoll, amely lehetővé teszi a felhasználó számára, hogy távolról lejátszhassa a multimédiás adatfolyamot (hang és videó) egy hiperhivatkozás és egy multimédia lejátszó (esetünkben VLC Media Player) segítségével.

Ha videofolyamot kell beállítania, kövesse az alábbi lépéseket:

1. Először is le kell töltenie és telepítenie kell a VLC Media Playert, amely ingyenesen elérhető a hivatalos webhelyen.
2. Kattintson a Média (Média) - Hálózati adatfolyam megnyitása (URL megnyitása) menüpontra.
3. Írja be az RTSP hálózati címét a prompt sorba.
4. Nyomja meg a lejátszás gombot, amikor a videokép megjelenik a képernyőn.

Link visszafejtése RTSP

Példa:

rtsp:// :@:/cam/realmonitor?channel= &altípus=

Ahol :

: Felhasználónév (bejelentkezés).

: Jelszó.

: a hálózati kamera IP-címe.

: Alapértelmezés szerint az 554-es port van beállítva, ez az érték figyelmen kívül hagyható.

: csatorna száma. A számozás 1-től kezdődik.

: folyam típus. Jelentése A főszál 0, az 1. másodlagos szál 1, a 2. másodlagos szál értéke 2. Például az 1. másodlagos szál hivatkozása a következő lenne:

rtsp://admin: [e-mail védett]:554/cam/realmonitor?channel=1&subtype=1

A Dahua Technology IP videokamerák támogatják a TCP és UDP adatátviteli protokollokat. Ha az 554-es port megváltozott, módosítsa azt a kamerabeállítások megfelelő mezőjében (webes felület).

Ha bármilyen problémába ütközik az RTSP adatfolyam beállítása során, olvassa el a megfelelő részt.