Ich habe im vorhergehenden Artikel davon berichtet, wie ich versuchte, meinen Raspis eine neue Betriebssystemversion zu verpassen.

Das habe ich nicht nur deswegen getan, weil ich mit Cybersecurity mein Geld verdiene und nicht den Spruch "Der Schuster hat die schlechtesten Schuhe" oder "Der Schmied hat das schlechteste Werkzeug" leben wollte. Ich habe mir überlegt, eine preisgünstige Überwachungskamera selbst zu bauen. Dabei sollte der Preis nicht nur die Anschaffung, sondern vor allem den Betrieb meinen. Das Ganze sollte aklso so sparsam wie möglich funktionieren.

Dafür benötigte ich entsprechende Hardwarevoraussetzungen. Die Idee, einen meiner diversen für Bastelprojekte angeschafften ARM-basierten Bastelrechner dafür zu benutzen lag nahe - allerdings mussten zunächst erst einmal moderne Betriebssysteme auf dem Stand der Technik die schon etwas angestaubten Installationen ersetzen. Bei meinen Rock64 - von eingeweihten auch gerne als Trump-Board bezeichnet - funktionierte das einwandfrei.

Ich schaffte es sogar das Rätsel des Raspi zu lösen, der sich standhaft weigerte, übers Netzwerk zu booten.

Selbst meinen Pi Zero W konnte ich auf die Höhe der Zeit bringen.

Nachdem ich nun einige Experimentierplattformen zur Verfügung hatte, konnte ich daran gehen, zunächst die Software zu definieren. Mir kam da natürlich sofort der Gedanke an FFMpeg. Ich fand einige weitere Ressourcen, die es mir erlaubten, die Kommandozeilen für Streaming per UDP zu entwickeln:

#Kamera:
v4l2-ctl --list-devices #list video devices
v4l2-ctl -d /dev/video0 --list-formats
#Server:
ffmpeg -re -f v4l2 -thread_queue_size 64 -framerate 25 -video_size 800x600 -i /dev/video0 -r 10 -f mpegts udp://${CLIENT_IP}:${SERVER_PORT}?pkt_size=1316
#Text im Bild:
ffmpeg -re -f v4l2 -thread_queue_size 64 -framerate 25 -video_size 800x600 -i /dev/video0 -vf "drawtext=fontfile=/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf: text='%{localtime\:%T}': fontsize=24: fontcolor=white@0.8: x=7: y=460" -r 10 -f mpegts udp://${CLIENT_IP}:${SERVER_PORT}?pkt_size=1316
#Client:
ffplay -fflags nobuffer -probesize 32 -sync ext -vf setpts=0 udp://{SERVER_IP}:${SERVER_PORT}

Was ich leider noch nicht geschafft habe ist, die Hardwarebeschleunigung der verbauten Mali450 GPU zu nutzen: Ich denke, dass das an der Version des Kernels liegt - allerdings musste ich die KErnelversion beim Betriebssystemupgrade der Rock64 einfrieren - bevor ich Versuche mit der Ersetzung des Kernels durchführe warte ich auf die Ankunft der schnelleren Massenspeicher, damit das nicht so schmerzhaft wird, immer wieder das Backup zurückzuspielen: Davon hatte ich genug, bis ich bemerkte, dass nicht das neue Betriebssystem verhinderte, dass die Teilchen booten, sondern eben der zu neue Kernel. Inzwischen habe ich herausgefunden, dass der Kernel nicht zu neu sein darf: einer der Version 6.6.63 funktioniert - neuer geht nicht!

Übersetzt und installiert ist eine entsprechende Version von FFMPeg bereits. Dabei stellte sich übrigens heraus, dass das die Grenze der kleinen Dingerchen ist: Beim Übersetzen stieg die Auslastung des Arbeitsspeichers maximal auf knapp 600 MB - aber beim Linken war der Ram und der Swap beinahe vollständig ausgereizt (insgesamt 1.5 G), so dass ich befürchtete, dass der Vorgang ganz am Ende abbrechen würde - aber ich hatte Glück...

Ich wendete mich daher dem Projekt µstreamer zu - und siehe da - nach extrem kurzer Bauzeit hatte ich einen MJPEG-Streamer, der - richtig konfiguriert - das System absolut nicht belastete - also Hardware-Encoding betrieb - und dessen Stream ich mir im Browser ansehen konnte die Kommandozeile dazu lautet:

 #kompilieren
apt install libevent-dev libbsd-dev libgpiod-dev libsystemd-dev libasound2-dev libspeex-dev libspeexdsp-dev libopus-dev libjpeg62-turbo-dev
git clone --depth=1 https://github.com/pikvm/ustreamer
cd ustreamer
make -j 4
 #benutzen
./ustreamer -r 800x600 --encoder=m2m-image --drop-same-frames=30 --device=/dev/video0 --host=0.0.0.0 --port=8882

Auf dem Rock64 funktioniert das leider nur ohne Hardware-Beschleunigung - hier ist also nochmal eine genaue Messung des Strombedarfs nötig. Die Lösung beansprucht einen Kern des Rock64 zu 30%...

Nachdem ich noch einige infrastrukturelle Modifikationen am Heimlabor vorgenommen hatte, habe ich es nun auch geschafft, meinen USB-OZG-Adapter wiederzufinden - damit war es möglich, die Kamera auch an den Pi Zero W anzuschließen. Natürlich geht dort alles viel gemächlicher - von der Installation der Dependencies bis hin zum Kompilieren. Aber nachdem das alles abgeschlossen war konnte ich mit Freuden feststellen, dass das System - auch mit Hardwarebeschleunigung - ebenfalls auf diesem System funktionierte. Mein Leistungsmesser zum Stecken zwischen Steckdose und Verbraucher zeigte mit diesem Setup 0W an - ein sicheres Zeichen dafür, dass der Verbrauch zu gering war, um mit diesem doch eher kruden Baumarktteil eine Messung durchführen zu können. Daher kam das gute alte Labornetzteil wieder mal zum Einsatz.

Hier konnte ich nun bei 5V Eingangsspannung eine Stromaufnahme im Standby ohne Last von etwas über 200mA messen - startete ich µstreamer und verband einen Konsumenten, so steigerte sich dieser Wert auf bis zu knapp 500mA - jedoch nie darüber! Das bedeutet, dass das Gesamtsystem mit der eingesetzten Kamera derzeit maximal 2.5W verbraucht. Nicht schlecht sollte man meinen - für Krempel, der bei mir im Regal rumliegt...