Einbindung (IP) Kamera über "Motion"

[Superdad]

Ich hänge mich mal mit an.

Finde den Ansatz auch sehr spannend.

Habe meine Kameras mit CuxD eingehangen. Ist mir aber zu unausgegoren.

Alle Kameras werden auch nicht unterstützt und müssen händisch eingetragen werden.

Ist zwar nicht das Problem, aber wenn man eine Kamera besitzt die nicht Foscam oder Instar heisst, wird es schon umständlich.

[ruhigundrelaxed]

Ok. Super. Fangen wir mal an.

Grundvoraussetzung um den iobroker Motion Adapter zu nutzen ist natürlich ein funktionierender motion daemon. Dieser Dienst muss nicht zwangsweise auf dem gleichen System laufen wie iobroker, da der Adapter mit diesem via Netzwerk spricht.

Da Motion rtsp nativ erst in einer neueren Version unterstützt (ich benutze 4.0.1) ergeben sich zwei unterschiedliche Möglichkeiten. Beide haben vor und Nachteile.

1.) Man nutzt eine aktuelle Version von Motion.

2.) Man benutzt eine ältere Version von Motion und macht rtsp und decodierung des h264 streams extern.

Die Vorteile von Variante 1 liegen auf der Hand. Weniger Komplexität und daher vermeintlich höhere Stabilität.

Die Nachteile von Variante 1: H264 decodierung in Software (daher höhere cpu last)

Die Vorteile von Variante 2: Höhere Flexibilität bei Quelle und Decodierung. Alles was gstreamer kann, kann auch mit motion verwendet werden. (inkl. omxdecode auf der rpi gpu)

Die Nachteile von Variante 2: Höhere Komplexität. Vor dem Motion dameon muss noch ein loopback modul geladen werden und eine gstreamer pipeline muss eingerichtet werden. Das sind alles Dinge die abspacken können.

Vorschlag:

Wenn motion auf einer Kiste läuft, die wenig CPU aber die Möglichkeit von GPU Decoding hat (vaapi, omx usw.) wie z.b. der rpi dann empfehle ich Variante 2.

Wenn man keine Möglichkeit des GPU Decodings hat, oder genug cpu power dann empfehle ich Variante 1.

Wenn das alles läuft, können wir uns um den Adapter kümmern.

[fu_zhou]

Meine Kamera kann nur H.264 streamen, obwohl man im Konfigurationsdialog auf MJPEG umstellen kann. Die momentane motion Version kann das nicht (V3.12), ich habe aber eine Anleitung gefunden, die eine aktuellere Version ("Mr. Dave") installiert und ffmpeg ergänzt, so dass in motion auch ein H.264 Stream gezeigt wird. Wird daurch nun die CPU Last reduziert und die GPU verwendet, also Variante 2? Kann ich die CPU Last durch motion irgendwie prüfen?

https://raspberry-pi.ninja/2017/02/05/m … auch-rtsp/ - ist sogar einigermaßen aktuell, git muss vorher allerdings noch installiert sein/ werden.

Dann werde ich mich mal mit deinem Motion Adapter beschäftigen. Installiert ist er aus github, unter "Objekte" finde ich ihn allerdings (noch) nicht in ioBroker.

Als erstes wäre mal ein Objekt wie "MotionDetected" =false/true interessant, so dass ich telegram triggern und Licht schalten kann

[ruhigundrelaxed]

Meines Wissens nach nein. Soweit ich weiß ist Mr. Daves Patch in der aktuelle Version eingepflegt. (4.0.1) Also würde das Variante 1 entsprechen. Auf nem RPI würde dass dann ein einstelllige fps bei 100% cpu bedeuten.

Wenn du den Adapter installieren konntest, und unter Objekte nix davon zu sehen ist, so ist das ungewöhnlich. Ist der Adapter unter "Instanzen" zu sehen und grün?

Wichtig, und von mit immer wieder vergessen, ist die Notwendigkeit, den output des http control interfaces von motion auf "raw" zu setzen. Das macht man, indem man in der motion.conf die option webcontrol_html_output auf "off" setzt. http://www.lavrsen.dk/foswiki/bin/view/ … HtmlOutput

Es kann allerdings durchaus sein, dass die aktuell in git eingepflegte Variante des Adapters noch Probleme hat, wenn nur eine cam läuft. Das habe ich schon gefixed, bin mir aber nicht sicher ob das schon "eingecheckt" ist.

Gruß

[fu_zhou]

Ja, der Adapter ist in den Instanzen und grün.

Wie hast du die V4.0.1 von motion installiert? Über sudo apt-get motion kriegt man ja nur die 3.12.

Gibt es für Variante 2 eine Anleitung - motion 4.0.1, gstreamer, loopback, pipeline etc.? Mir ist die Latenzzeit des Videos im Browser zu hoch, was wohl auch auf Variante 1 deutet.

[ruhigundrelaxed]

Die hab ich aus git gezogen und kompiliert. Etwa so:

sudo apt-get install autoconf automake build-essential pkgconf libtool libzip-dev libjpeg62 libjpeg62-dev git libavformat-dev libavcodec-dev libavutil-dev libswscale-dev
cd ~ 
git clone https://github.com/Motion-Project/motion.git 
cd motion 
autoreconf -fiv 
./configure 
make 
make install

Variante 2:

1.) Gstreaner 1.0 + plugins installieren.

2.)v4l2loopback (dkms) installieren

3.)v4l2loopback laden (modprobe…)

4.)gstreamer pipeline starten (````
usr/bin/gst-launch-1.0 rtspsrc location=rtsp://192.168..**:8001/ch01.264 ! rtph264depay ! h264parse ! omxh264dec ! videoconvert ! tee ! v4l2sink device=/dev/video0

5.)Motion configurieren das /dev/video0 verwendet wird.

Autostart dann via systemd.

Ps.: du hast geschrieben, dass deine cam mjpeg können sollte, aber trotzdem h264 ausgibt. Das problem haben meine powerview cams auch. (Zumindest bei dem aux. Stream) Wohl gleiche plattform….

[fu_zhou]

Okay, zum Thema motion 4.0.1 sind wir schon einmal gleich vorgegangen…

Jetzt muss ich mich noch mal an den Rest machen. Verstehe ich das richtig, dass die Pipeline den Stream von der Kamera auf /dev/video0 umleitet, ich den netcam_url also wieder auskommentiere?

[ruhigundrelaxed]

> Verstehe ich das richtig, dass die Pipeline den Stream von der Kamera auf /dev/video0 umleitet, ich den netcam_url also wieder auskommentiere

Ja, genau. Für motion (und alle anderen programme die v4l nutzen) sieht das dann wie ein lokales device aus.

[fu_zhou]

Was bisher geschah:

Installation von motion:

sudo bash
apt-get install autoconf automake build-essential git libtool libjpeg8-dev libzip-dev libavformat-dev libavcodec-dev libavutil-dev libav-tools libswscale-dev libavdevice-dev
cd /
git clone https://github.com/Motion-Project/motion.git
cd motion
autoreconf -fiv
./configure
make
make install && ldconfig

dann noch die Konfiguration kopieren und bearbeiten:

sudo bash
cp /usr/local/etc/motion/motion-dist.conf /usr/local/etc/motion/motion.conf
nano /usr/local/etc/motion/motion.conf

/dev/video0 verwenden

Ports so einstellen, dass es keine Kollision mit ioBroker gibt

webcontrol_html_output auf "off"

…

motion muss auch noch gestartet werden:

sudo motion

` > 1.) Gstreaner 1.0 + plugins installieren.

2.)v4l2loopback (dkms) installieren

3.)v4l2loopback laden (modprobe…)

4.)gstreamer pipeline starten

5.)Motion configurieren das /dev/video0 verwendet wird `

zu 1.)

sudo bash
apt-get install gstreamer1.0-tools
apt-get install gstreamer1.0-plugins
apt-get install gstreamer1.0-omx

zu 2.)

Über apt-get install … bekommt man die Version 0.8, die mit der aktuellen Version von Jessie/ Firmware nicht kompatibel ist, daher:

sudo bash
apt-get install raspberrypi-kernel-headers
cd /
git clone https://github.com/umlaeute/v4l2loopback
cd v4l2loopback
make && sudo make install

zu 3.)

modprobe v4l2loopback

zu 4.)

/usr/bin/gst-launch-1.0 rtspsrc location=rtsp://192.168.0.9 ! rtph264depay ! h264parse ! omxh264dec ! videoconvert ! tee ! v4l2sink device=/dev/video0

Und siehe da, es geht. Motion belastet die CPU jetzt mit ca 44% aber wenn Bewegung erkannt wird geht die Belastung hoch auf 99%. Die Verzögerungszeit ist ca. 5 Sek. Hast du eine Idee, wo man noch tunen kann? Die Kamera liefert schnelle Bilder, das sehe ich am PC mit iSpy.

zu 5.)

siehe "Installation von motion" oben

Denn Autostart via systemd musst du noch beisteuern. Passt sonst alles?

[ruhigundrelaxed]

Hey, du bist ja richtig schnell…

Prima, dass es funktioniert.

Hier die Service Files:

cat /etc/systemd/system/gstreamer.service

[Unit]
Description=Launch and monitor Gstreamer Pipeline

[Service]
ExecStart=/usr/bin/gst-launch-1.0 rtspsrc location=rtsp://192.168..:8001/ch01.264 !  rtph264depay ! h264parse ! omxh264dec ! videoconvert ! tee ! v4l2sink device=/dev/video0
Restart=always
[Install]
WantedBy=multi-user.target

und

cat /etc/systemd/system/motion.service 
[Unit]
Description=Motion Daemon

[Service]
Type=forking
PIDFile=/var/run/motion/motion.pid
ExecStart=/usr/bin/motion -c /etc/motion/motion.conf
Restart=on-failure
Requires=gstreamer.service
[Install]
RequiredBy=gstreamer.service

Ich kümmere mich grade um den "nur eine cam bug".

Gruß

Martin

ps.:

Die erste Zeile mit dem "cat" gehört natürlich nicht in die Files. Habs nur stehe gelassen, damit du weist wohin du die Files packen musst. Die Pipeline im gstreamer.service file musst du natürlich auch anpassen.

[fu_zhou]

Habe das ganze jetzt einmal auf einem Pi2 installiert - nur motion und v4l, sonst nichts (die Anleitung oben funktioniert also…). Da ist die Videowiedergabe noch langsamer, als beim Pi3, auf dem noch parallel SQL und ioBroker läuft. Ist sichergestellt, dass die GPU verwendet wird oder macht hier alles die CPU? Kann man das irgendwie prüfen?

[ruhigundrelaxed]

Naja, es wird halt nur das h264 decoding auf der gpu gemacht. Die eigentliche Bewegungserkennung ist cpu. Du könntest ja mal testweise in der gstreamer pipeline einen anderen h264 decoder verwenden. Z.B.: x264dec Da x264dec auf der cpu decodiert. Leider kommt man nicht so ohne weiteres an die Auslastung des entsprechenden gpu subsystems. (There are no tools I am aware of to monitor H264 block utilisation.) Was ist den langsam? Der mjpeg stream? Hast du dir den mal mit vlc angesehen? Leider steht mein pi ca. 70km von meiner aktuellen positon entfernt. Daher kann ich keine zuverlässige tests durchführen. Die Bandbreite (upstream) würde da reinpfuschen. Ich meine aber, dass ich bei 720p ca. 15-20 frames bei ca. 2-5 Sekunden Latenz hatte. (Pi2) Es sah erstaunlich flüssig aus…

[fu_zhou]

Beim rtsp Stream auf dem PC (VLC) habe ich eine Latenz-Zeit deutlich kleiner als eine Sekunde, im Browser, wenn ich auf den Pi schaue, von ca. 4-5 Sekunden. Framerate im VLC ist auch deutlich höher.

Ich habe mir jetzt mal noch nen Pi 3 bestellt, mal schaun, wie's da dann aussieht, wenn er nur mit der Kamera beschäftigt ist. Wie sieht's mit dem Adapter aus? Kann ich im Moment irgendetwas zur Unterstützung tun?

[ruhigundrelaxed]

Hmmm. Ich meinte nicht die Latenz cam->vlc, sondern die Latenz motion-mjpeg-stream->vlc. Also die Url des motion http streams in vlc. (Um den browser-player als Ursache auszuschließen.) falls du x11 auf dem pi hast, könntest du auch direkt mal mit vlc /dev/video0 testen. (Um gstreamer h264 decoding als Ursache auszuschließen.) Ich denke cam -> vlc (also direkt rtsp über vlc) markiert die minimale Latenz. (Weniger geht nicht.)

[ruhigundrelaxed]

Ok, ich habe mal was gegen den "one cam bug" getan. Bitte mal den file "motion.js" aus dem git ziehen und damit die bestehende ersetzen.

[fu_zhou]

Bald gibt's hier ein Update mit Tutorial, wie jede Billig-IP-Kamera in ioBroker eingebunden werden kann - rtsp ist Voraussetzung, das kann aber so ziemlich jede Kamera, wie es scheint.

Damit ist es auch möglich, Bilder auf's Handy geschickt zu bekommen, obwohl die Kamera keinen URL für Snapshots "versteht".

Stay tuned…

[0018]

@fu_zhou:

Bald gibt's hier ein Update mit Tutorial, wie jede Billig-IP-Kamera in ioBroker eingebunden werden kann - rtsp ist Voraussetzung, das kann aber so ziemlich jede Kamera, wie es scheint.

Damit ist es auch möglich, Bilder auf's Handy geschickt zu bekommen, obwohl die Kamera keinen URL für Snapshots "versteht".

Stay tuned… `

Hi,

bin auf der Suche nach einer ähnlichen Anbindung.

Kannst du schon sagen wann das Tutorial ungefähr fertig sein wird?

Mfg

[fu_zhou]

Über's verlängerte Wochenende jetzt sollte ich fertig werden.

[andyb]

@fu_zhou:

Über's verlängerte Wochenende jetzt sollte ich fertig werden. `
Ohne irgendeine Art von Druck erzeugen zu wollen, einfach weil ich ne Lösung suche…. Gibt es da ne Zeitschiene? :oops:

[fu_zhou]

Gibt's seit Ende Mai:

http://forum.iobroker.net/viewtopic.php … 900#p68900

Kannst dich gleich mal zum Thema v4l2loopback einbringen…