Bitek mindenhol, avagy okos tárgyak

Ha az embernek olyan gondolata támadna, miszerint kíváncsi lenne mi történik távollétében a lakása környékén, és szeretné ezeket az eseményeket rögzíteni is adott esetben, akkor pár IP kamerára lesz szüksége (természetesen a rögzítéshez kell még egy eszköz: maga a rögzítő, de az már egy másik történet), ha pedig minimálisan sem szeretne kábelezni, akkor WiFi képesre ráadásul. Ilyet az e-bayen 8-9 ezer forint körüli összegért lehet szerezni, és ha a vámon megfogják, hozzáadódik a +27% áfa is... kis hazánkon belül vásárolva pedig alaphangon 13-20ezer Ft körül kezdődnek a nem túl nagy tudású modellek. Keressünk hát alternatív megoldást! (Kivéve persze, ha a fentiek megfelelnek az igényeinknek és nem mozog bennünk semmi barkácsösztön)

Azt már a Raspberry kameránál próbáltam, hogyan lehet egy kamera felvételét rögzíteni a gazdaeszköz saját tárhelyére, most arról lesz szó, hogyan lehet ebből IP kamerát varázsolni, és egy hálózati rögzítő felé továbbítani a képet.

Lássunk néhány alapfogalmat:

• IP - Internet Protocol: szabvány, mely meghatározza, hogy hálózatba kötött csomópontok milyen módon tudnak egymással kommunikálni
• IP cím: a fenti protokollban meghatározza egy eszköz címét, cím nélkül ugyanis nincs kommunikáció
• IP kamera: egy olyan, önállóan is működőképes kamera, mely képes az IP rendszerű hálózatban kommunikálni, a hálózat másik tagja felé képeket továbbítani
• ONVIF - Open Network Video Interface Forum: egy olyan, gyártófüggetlen szabvány, mely leírja, hogyan lehet beállítani a kamera tulajdonságait, a kép felbontását, minőségét, riasztási és mozgásdetektálási információkat, stb. Amelyik IP kamera támogatja ezt a szabványt - elméletben - bármely ONVIF kompatibilis rögzítővel tud együttműködni. Azt természetesen tudni kell, hogy minden gyártó hozzáad valami pluszt a saját kamerájához, így a legjobban az azonos gyártótól származó eszközök tudnak egymással együttműködni, de az alapvető funkciókban az ONVIF egy jó "közös nyelv", a képet pedig RTSP szabvány szerint továbbítják
• RTSP - Real Time Streaming Protocol: video és/vagy audió adatfolyam (stream) továbbításának módját leíró szabvány
• USB - Universal Serial Bus: számítógépes rendszerek csatlakozója, perifériák, részegységek számára
• USB (web)kamera: önállóan nem működő részegység, mely az USB gazdaeszköz számára képeket továbbít. Megtévesztő a neve, amiben szerepel a "web", de ez inkább utal a jellemző felhasználási területére, nem arra, hogy önmagától netre tudna csatlakozni.

Mi következik mindebből? USB webkamerával - illetve egyéb helyi csatlakozású kamerával - csak akkor lehet megvalósítani a fenti feladatot, ha beiktatunk egy feldolgozóegységet, ami lehet PC, notebook vagy egyéb miniszámítógép, mely képes csatlakozni IP hálózatra. (amire önmagában az USB kamera képtelen) Érdemi felhasználás során ennek az gazdaeszköznek állandóan bekapcsolva kell lennie, így egy nagyfogyasztó PC nem a legoptimálisabb választás, ellenben egy 1-5W fogyasztású mikroszámítógép, mint pl a Raspberry Pi Zero W vagy egy Orange Pi megfelelő választás lehet. (Vagy egy OpenWRT/LEDE futtatására képes routert is fel lehet okosítani az mjpeg-streamer-rel, melyet az USB kamerával teszteltem) Extraként a Raspberry saját kameráját is próbára tettem, természetesen ez csak Raspberry-vel működik.

A korábbi tesztjeim után nyilvánvalóvá vált, hogy mivel a tesztegyed USB kamera nem ad tömörített MJPEG streamet sem, nemhogy H264-et, szükség lesz egy tömörítési fázisra, utána pedig egy programra, amely RTSP formában szolgáltatja a képet.

A tömörítési fázishoz az ffmpeg nevű alkalmazásra esett a választásom, ezzel lehet használni a Raspberry integrált GPU-jának OMX gyorsítási módját. Sajnálatos módon viszont forrásból kell fordítani, ami egymagos Zero esetében több órás folyamat.

x264 függvénykönyvtár telepítése:

ffmpeg fordítása és telepítése: (sajnos kihagytam az "--enable-filter=drawtext" kapcsolót, így nem tudtam időbélyeget varázsolni a későbbiekben a képre, és külön ezért nem igazán szándékozom újrafordítani)

Az RTSP stream szórásához a legegyszerűbb megoldásnak a vlc alkalmazást találtam, ami a vlc-nox csomag telepítésével használható grafikus felület nélkül is, "cvlc" a konzolos indítóprogram neve.

A sok előkészület után tehát a következőt tesszük:

1. Miután /dev/video0 eszközként felismerte a rendszer az USB kamerát, az ffmpeg segítségével direktben tömörítjük a YUYV színterű nyers 640x480 képanyagot a h264_omx plugin segítségével "superfast" - vagyis a leggyorsabb és leggyengébb - minőségben, és ezt kiküldjük a standard kimentre
2. cvlc segítségével a standard bemenetről érkező h264 formátumú streamet mindenféle további feldolgozás nélkül kiajánljuk a 8554-es porton unicast elérési úton

Ezt a két dolgot összerakjuk és extraként a kamerából jövő 30fps sebességű képet 25fps-re alakítjuk vissza, mivel a vlc valamilyen megfontolásból csak 25fps sebességgel tud szinkronban RTSP jelet továbbítani. A kamera viszont nem tud 25fps-t szolgáltatni direktben, csak 30-at vagy 15-öt.

Az egysoros parancs a következő:

Ellenőrzésképpen egy másik gépről megnyithatjuk a streamet, hogy működik-e, ha teszem azt az USB kamerával rendelkező gép címe 192.168.1.101, akkor:

A kép ilyen módon való tömörítése és szórása közben az 1Ghz-es egy magos RPI Zero W-n nagyjából 39%-os (37% ffmpeg+2% cvlc) CPU terheltséget mértem, ami azért sokkal jobb, mint a korábbi tesztben az mjpeg-streamer nevű alkalmazás által demonstrált teljesítmény. Nyilván az OMX gyorsítás használata segített sokat. A WiFi-re pedig jótékony hatással van a H264 tömörítés miatti kisebb sávszélesség-igény, egész egyszerűen azért, mert kisebb adatmennyiséget kell továbbítania a hálózaton a jobb tömörítési hatásfok miatt.

Hogy teszteljem a stream kompatibilitását, beállítottam felvételre egy Hikvision DS-7616NI-E2/16P/A rögzítő segítségével, amely támogatja az ONVIF szabványt. A "miért pont ezen" kérdést ne firtassuk, egyszerűen ez volt kéznél. :) A fent írt RTSP elérési utat a következőképpen lehet beállítani a Hikvision rögzítőben:

Ezután a rögzítő zokszó nélkül elfogadta az USB kamera képét a hálózaton keresztül, a kért 640x480-as felbontásban, a mellékelt képet az iVMS-4200 segítségével mentettem le a Hikvision rögzítőről.

Nem állítanám, hogy őrült jó a minőség, az előző teszthez hasonlóan rendkívül pixeles képet kapunk, és akkor még a fakó színekről nem is beszéltünk.

Összehasonlításképpen ugyanebből a beállításból, és a sportszerűség kedvéért először ugyanebben a felbontásban ugyanezt a tesztet elvégeztem a Raspberry saját kamerájával is. A teszt idejére az USB kamerát kihúztam, és betöltöttem a Raspberry kamera driverét, majd igyekeztem a lehetőségekhez képest legjobban követni az előző tesztet:

Látható, hogy itt is a tömörítetlen képet adtam át az ffmpeg-nek, viszont itt már alapvetően 25fps volt a kiinduló adatfolyam sebessége, mivel ez a kamera tudja ezt (is). A Hikvision rögzítő nem sokkal ezután már vígan mutatta az új képet:

Az optika nem azonos a két kameránál, így sajnos az összehasonlítás nehéz, viszont a színek szerintem eléggé mások ez esetben. A CPU terhelés nagyon hasonló 35% körüli. (33% ffmpeg + 2% cvlc)

Akkor most sutba dobva a sportszerűséget, térjünk át a Raspberry kamera tömörített streamjének használatára, és felejtsük el az USB webkamerát, valamint az ffmpeg-et is, ideje a raspivid-re koncentrálni.

Ez még mindig 640x480-as felbontás, de már a raspivid szolgáltatja a h264 streamet direktben, további feldolgozás nélkül:

A kettő között látszatra nem sok különbség van, eltekintve az időbélyegtől, amit a raspividdel ágyaztam a képbe, illetve attól az apró ténytől, hogy a CPU terhelés 6,3% volt a művelet közben. (5% cvlc + 1,3% raspivid)

Majd továbblépve még egy szinttel, nézzük az 1MP felbontást (HD/720p):

Mintha kicsit kevesebbet látnánk az asztalból, ugye? Nem csalás, de ámítás, a kamera szenzora, mint már írtam fix 5MP felbontású, ezen semmilyen szoftveres matatás sem változtat, csak ebből mindig kinyeri számunkra az általunk kért méretű képet, a megfelelő méretarányokkal. CPU terhelés 12,3%. (11% cvlc + 1,3% raspivid)

És akkor jöhet a finálé, 2MP felbontás (FullHD/1080p):

Az alján hozzáadott 8 pixel magas fekete csíkot magam sem értem, az iVMS-4200 program örök titka marad, miért tette ezt hozzá a mentett képhez... CPU terhelés 24,3%. (23% cvlc + 1,3% raspivid)

Talán van, akiben felmerül a kérdés: Mi ez a nagy felhajtás a Megapixelek körül? Bátorkodtam a fenti képekből kivágni ugyanazokat a részeket, amiket előre megfontolt szándékkal helyeztem oda.
Alább látható bal oldalon a 640x480-as felvételből, középen a HD felvételből, jobb oldalon a FullHD felvételből kimentett kép látszik, azonos méretre vágva:

Gondolom mindenki sejti mi lenne a bal oldali szövegből, ha elhangzana az amerikai akciófilmekben divatos "Nagyítást kérek! Most tisztítsa ki!" felkiáltás. Egy nagy paca. És ugyanez igaz az arcvonásokra, ha az elkövetőről készült képekről van szó, így érdemes okosan megválasztani, hogy a megfigyelt területhez megfelelő felbontású kamerát válasszunk.

Sikerült IP kamerát készítenünk? Valamilyen szinten, talán. Bár egy IP kamera ennél sokkal többre képes. Igazából egy hálózati RTSP videofolyam-szóró eszközt készítettünk, amiről egy megfelelő hálózati rögzítővel folyamatosan tudjuk menteni a felvételeket. Az RTSP csak egy része annak, amit tudnia kellene, a teljes ONVIF támogatás esetén a rögzítőről lehetne állítani a video felbontását, valamint a kamera jelezhetné, ha mozgás van, és így csak azokban az esetekben foglalná a helyet a felvétel a rögzítőn, ha tényleg történik valami. Továbbá az okosabb kamerák képesek egyéb analitikai funkciókra, arcdetektálásra, vonalátlépés, tárgyeltűnés stb jelzésére a rögzítő felé, ha pedig hangot is vesznek, pl az extrém hangerőváltozásról is tudnak jelezni.

Azt jó tudni egyébként, hogy nem minden ebay-en "ONVIF" jelzővel ellátott olcsó IP kamera tudja a mozgásérzékelést továbbítani a rögzítő felé, némelyik semmivel sem tud többet, mint az itt összeállított kamera.. viszont ez nem beszél kínaiul bekapcsoláskor és nem jelentkezik be a hazai kínai szerverre. ;)
Persze hardveresen is akad pár hiányosság a projektben, pl egy megfelelő kameraház, illetve egy infravető, hogy sötétben is lásson valamit a kamera.

Azért az ONVIF támogatásra is található nyílt forrású alkalmazás, de nem igazán győzőtt meg, valamint az RPI Zero teljesítménye is elég kevésnek tűnik hozzá.

Hálózati rögzítőből érdemes hardveres, dedikált változatot beszerezni, de ha akad egy elfekvő Linuxos gép vagy erősebb, többmagos Raspberry, külső HDD-vel, akkor van pár szoftveres alternatíva:

• ARM eszközökhöz (pl Raspberry) ingyenes: Orchid Core VMS
• RapidVMS
• Shinobi
• ZoneMinder (ez speciel támogatja a sima helyi USB kamerát is)
• kerberos.io

Kapcsolódó cikkek:

• Shinobi videorögzítő teszt
• IP kamerák