Posted on

TL-MR 3020 as a webcam server

Took me a while, but I’m now rather confident that the issues I was having with the MR3020 as a mjpg-streamer powered streaming webcam server are related to the camera(s) used, not (only) to the tiny box. As you can see below, “only” in daylight the images gets distorted:

As of now I assume that the framerate reported by the camera is responsible for this, as that cam is reporting only 30 fps for all resolutions. It’s working nicely on a SheevaPlug with full-blown Debian, but Sheeva is a different hardware to the MR3020 (and 3 to 5 times as expensive per box); I might try a Dockstar as the host for this cam, but time will tell.

Just FTR, with a quickly ordered Logitech C270 HD, the MR320 is serving just nicely as a streaming webcam server (cam reports 5 and 10 fps for 1280×720, I choose 5, which is sufficient for now):

Posted on

Webcam server with TL-MR 3020?

Hmm. Previously, I build two nice webcam-servers out of Fonera 2.0g boxes (German posts: 1 & 2). cpuinfo of the Foneras is as follows:

root@cam-serv3:~# cat /proc/cpuinfo 
system type             : Atheros AR2315
processor               : 0
cpu model               : MIPS 4KEc V6.4
BogoMIPS                : 183.50
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : no
ASEs implemented        :
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

There I run two jobs, for /dev/video0 and /dev/video1, of mjpg_streamer -i input_uvc.so -f 10 -r 960x720 ..., which results in this top output:

Mem: 19836K used, 10080K free, 0K shrd, 1140K buff, 6096K cached
CPU:  19% usr  11% sys   0% nice   1% idle   0% io  31% irq  34% softirq
Load average: 2.57 2.51 2.45
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
 1518  1064 root     R     8732  29%  33% mjpg_streamer -i input_uvc.so -d /dev
 1517  1060 root     R     8572  29%  26% mjpg_streamer -i input_uvc.so -f 10 -
 1065  1064 root     R     8732  29%  20% mjpg_streamer -i input_uvc.so -d /dev
 1061  1060 root     S     8572  29%   7% mjpg_streamer -i input_uvc.so -f 10 -
 1577  1520 root     R     1960   7%   6% top -d 2 
 1519   933 root     S     1996   7%   1% /usr/sbin/dropbear -p 22 
 1064  1058 root     S     8732  29%   0% mjpg_streamer -i input_uvc.so -d /dev
 1058     1 root     S     8732  29%   0% mjpg_streamer -i input_uvc.so -d /dev
 1067  1064 root     S     8732  29%   0% mjpg_streamer -i input_uvc.so -d /dev
 1060  1056 root     S     8572  29%   0% mjpg_streamer -i input_uvc.so -f 10 -
 1056     1 root     S     8572  29%   0% mjpg_streamer -i input_uvc.so -f 10 -
 1066  1060 root     S     8572  29%   0% mjpg_streamer -i input_uvc.so -f 10 -
 1055     1 root     S     1976   7%   0% udhcpc -t 0 -i ath0 -b -p /var/run/at
  520     1 root     S     1972   7%   0% udhcpc -t 0 -i eth0.1 -b -p /var/run/
[...]

Recently I joined the MR3020 hype, them being quite similar to the Fonera 2.0g systems, i. e. Atheros-based, supported by OpenWR, rather cheap (<30 EUR) and with USB; only drawback is the ridiculously small on-board Flash:

root@cam-serv5:~# cat /proc/cpuinfo 
system type             : Atheros AR9330 rev 1
machine                 : TP-LINK TL-MR3020
processor               : 0
cpu model               : MIPS 24Kc V7.4
BogoMIPS                : 265.42
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0000, 0x0280, 0x05d0, 0x0630]
ASEs implemented        : mips16
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

But to my big disappointment, running even only one process of mjpg_streamer, /usr/bin/mjpg_streamer --input input_uvc.so --device /dev/video0 --fps 1 --resolution 1280x720 ..., seems to max the system out, and anything above 1 fps, I tested 2, 5, 10, gives quite chopy images, distorted in odd ways. top says:

Mem: 25868K used, 3308K free, 0K shrd, 1412K buff, 5392K cached
CPU:   0% usr   0% sys   0% nic  97% idle   0% io   0% irq   0% sirq
Load average: 0.06 0.11 0.11 1/41 1542
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 1514     1 root     S    24424  84%   0% /usr/bin/mjpg_streamer --input input_
 1541  1431 root     R     1496   5%   0% top -d 2
 1430  1362 root     S     1216   4%   0% /usr/sbin/dropbear -P /var/run/dropbe
 1431  1430 root     S     1504   5%   0% -ash
  592     1 root     S     1504   5%   0% /sbin/syslogd -C16
 1140     1 root     S     1504   5%   0% /sbin/udhcpc -t 0 -i wlan0 -b -p /var
...

So, it does not seem to be a CPU limitation; the CPU should be even more powerful than the Fonera’s, and the minor increase in resolution, 1280×720 instead of 960×720, should be compensated by far by the two USB cams served by the Fonera. Any opinions or tips?

Posted on

Schnee-Timelapse, die nächste ;)

Eigentlich war ich im Begriff, die lustigen Skripte, die mir aus vielen Teilen der Welt Webcam-Bilder archivieren, zu deaktivieren und die paar hundert GB zu recyclen, als doch noch mal was Sehenswertes über Deutschland passierte: Schnee im (meterologischen) Frühling — ansich nichts ungewöhnliches, denn, wie ich seit Jahren eine alte Weißheit wiederhole: »zur CeBIT schneit’s nochmal«.
Naja, wie dem auch sei, viel Spaß mit dem Zeitraffer zum neuerlichen Wintereinbruch über Ostwestfalen ;)

Posted on

Wie Miss #Daisy uns hängen lies …

Tja.
All den guten Ratschlägen zum Trotz: weder hundert heiße Ladenhüterdecken konnte man gestern an den Mann oder die Frau bringen noch stellte sich der herbeigeredete Stillstand Deutschlands durch Schnee im, Obacht!, Winter ein. Ja, es war frisch; nicht kalt, die Kälte war nur gefühlt. Durch den Wind. Der, zumindest in Mediatown City, eher mehr so spürbar war denn auffällig. Und groß anders war es offensichtlich nicht in Bielefeld (oben links), Detmold (oben rechts) oder Lemgo (unten links); vielen Dank an dieser Stelle an die Stadtverwaltungen und sonstigen Betreiber der öffentlichen Webcams für die Bereitstellung minütlicher Updates (über Mobotix-Standardzugänge)! Trotzdem waren im zu Fuß – auch während einer Eiszeit – erreichbaren LIDL in Steinwurfnähe unter anderem Toastbrot und andere Dinge des täglichen Bedarfs schon seit Freitag ausverkauft — go figure.

Und wer noch immer nicht die Lust an derlei Filmchen verloren hat: die Nacht von Daisy in Gütersloh, mit dem Tag davor und danach, aus anderer Perspektive nochmals im Zeitraffer:

Posted on

Daisy in OWL im Zeitraffer

Kurzer Zeitraffer von heute Mitternacht bis Mittag von öffentlichen Webcams in Bielefeld, Detmold, Lemgo und meiner Parkplatz-Cam in Gütersloh – Schnee ja, Chaos nein würde ich sagen:

(Derzeit meckert YouTube bei mir beim Abspielversuch noch »an error has occured«; hoffe, das fängt sich noch …)
Posted on

Wireless-Web-Cam, die 2.

Angespornt vom super Wetter (Schnee!), habe ich nun meinen zweiten Fonera 2.0g in einen drahtlosen Kameraserver verwandelt. Zwar leider nicht für ältere Webcams, aber bei den UVC-kompatiblen Kameras gibt es ja auch einige schmucke Geräte. Diesmal habe ich mir das OpenWRT-Image selbst zusammengebaut, im Endeffekt ist es reichtlich simpel, auf dieser Basis eine wireless Webcam zusammenzubauen, die, wie man sehen kann, auch bei unter -10 Grad Celsius noch funktioniert. Eine Creative Optia AF hatte ich schon im Sommer in ein entsprechendes Gehäuse (Baumarkt-Druckguß-300W-Halogenstrahler) gepackt und auf der Terrasse moniert (parallel zu einem ungeschützt aufgehängten alten Philips-pwc-Ei), nur leider klappte es seinerzeit nie, jene Cam weder mit blanken USB-Verlängerungskabeln noch mit aktiven USB2-Verlängerungskabeln noch mit letzteren plus eines außen dazwischengeschalteten netzgespeisten USB-2.0-Hubs irgendwie an den »cam-serv« und das darauf laufende »motion« anzuschließen. Lustige USB-Fehlermeldungen oder nur einen Start nach dem Reset überlebende Konstellationen waren die Folge; schade eigentlich, da jene Cam eine der wenigen ist, die unter Linux einen funktionierenden Autofocus mitbringen. Allerdings zeigt sich grade jetzt im Nachteinsatz, daß dieser Autofocus bei schlechten Lichtverhältnissen arg zum ziellosen pumpen neigt :(
Ich habe also heute abend, nachdem mein dedizierte Cam (s. o.) schneehöhenbedingt nur noch ein Schwarzbild zu liefern vermochte, auch meine zweiten Fonera 2.0g der kalten Unwirtlichkeit übereignet – und besagte Optia AF angeschlossen. Deren Bild liefert jetzt – leider liefert sie nur 800×600 als MJPEG-Stream – als kleines Einblendimage zusätzliches Bildmaterial, da mein Hauptimage ja schneehöhenbedingt uninteressant geworden ist.
Kurzer Abriß der eingesetzten Technik: Die »Himmelscam« als auch die »Parkplatzcam« sind Notebook-Pro-USB-Cams von Logitech, die an einem SheevaPlug (Parkplatz) bzw. einer Fonera-2.0g mit OpenWRT (Himmel); die Wetterdaten werden empfangen über FHEM in Verbindung mit CUL und CUN sowie S300TH/S555TH als Sensor. Ferner tut eine WS3600 Dienst, welche minütlich seriell über FHEM ausgelesen wird; deren Werte wandern allerdings, anders als jene der S300-Sensoren, noch nicht in die rrd-Datenhaltung, weshalb nur zwei Werte, die des Sensors in der Gartenhütte und die des Sensors oberhalb des Parkplatzes, in den Plot auftauchen. Bedingt durch die Funkübertragung gibt es gelegentlich Aussetzer, die im Graphen sich als fehlende Fortschreibung der entsprechenden Linie manifestieren; in der Folge fehlen dann entsprechend auch einen Tag später die als Fläche aufgetragenen Werte des Vortags. Warum es diese Aussetzer, insbesondere Nachts, gibt, ist eines der Themen, an denen ich derzeit kaue … Anyway, der Film der letzten zwei Tage:

Posted on

Rolling my own wireless webcam

Ich erwähnte es ja schon, zum Jahresende 2009 steht in der heimischen IT der Kehraus an, Entsorgung von Altlasten und Konsolidierung, insbesondere unter dem Aspekt der Energieeinsparung — GreenIT@Home, wenn man es verschlagworten wollte ;)
Ein Schritt wird es sein, die im Haus verteilten Pizzaschachtel-PCs, die lokal 1-3 USB-Kameras angeschlossen haben und mittels motion ihre Daten auf ein zentrales NFS-Share schieben, durch »etwas besseres« zu ersetzen.
Habe ich durchaus Erfolgt mit motion auf dem SheevaPlug gehabt (2-3 Bilder/Sekunde wurden bei erkannter Bewegung aufgezeichnet), so bin ich nun über mjpeg-streamer gestolpert – und begeistert. Denn statt bis zu 100% (motion) verbrät mjpeg-streamer auf dem SheevaPlug keine nennenswerte CPU-Leistung, und das bei 12 Bildern/Sekunde in einer Auflösung vom 960×720 Pixeln (die Kamera würde auch 1280×960 machen, aber dies liefert sie leider nur per YUV ab, nicht als MJPEG-Datenstrom; und grade dieses Feature moderner, UVC-kompatibler, Webcams macht sich ja, wie der Name schon andeutet, mjpg-streamer zu nutze: ein aufwendigen Kodieren, die Frames werden einfach von der Cam entgegengenommen und Netzanfragern als MJPEG-Datenstrom gegeben). Ein besonderes Feature aus meiner Sicht: während auf Rechner X motion sich den MJPEG-Stream zwecks Überwachung und Aufzeichnung reinzieht, kann ich auf Rechner Y (in meinem LAN) mit besagten 12 Bildern/Sekunde »aus dem Fenster schauen«. R0xx0r!
Na, und wenn das so super auf ‘nem 1,2 GHz-full-blown-Ubuntu läuft, dann gucken wir doch mal bei OpenWRT nach, ob uvcvideo und mjpg-streamer nicht auch schon zum Repertoire gehören, liegt hier doch noch ein Asus WL-500g Deluxe V mit 2x USB 2.0 rum …
Tja, Denkfehler eins: jene Plattform leidet noch immer unter den Binary-only-Treibern von Broadcom für die entsprechenden Broadcom-Devices; no meat bei 2.6. Und grade die »Portierungen« auf MIPS & Co. sind für 2.6er Geräte viel weiter, umfassender. Kurz: kein mjpg-streamer, kein uvcvideo im brcm-2.4-Repository. Also 2.6 nehmen und auf WLAN verzichten? Aber da, wo der hinsoll, wäre WLAN (als Client) ganz praktisch …
Ach, ich habe ja noch ‘n Fonera 2.0g da, Atheros-basiert und voll unterstützt, dann flashe ich den doch mal eben auf OpenWRT Kamikaze 8.09.2-2RC2, sprich, das aktuelleste, drauf …
Genau: Denkfehler Nummer zwei. Neu heißt nicht unbedingt gut, ich habe mich über das Web-GUI 3x ausgesperrt, sodaß ich neu flaschen mußte – Halleluja!
Naja, wie auch immer: ein auf Kamikaze geflashter Fonera 2.0g kann ebenfalls eine (identische) Webcam mit 960×720 Pixeln per mjpg-streamer bedienen – allerdings liegt die Systemlast hier deutlich höher (ok, hier werkelt auch »nur« ein Atheros AR2315 (MIPS 4KEc V6.4) mit, IIRC, 180 MHz; kein Vergleich zum SheevaPlug): 

Mem: 17348K used, 12568K free, 0K shrd, 1220K buff, 6308K cached
CPU: 6% usr 12% sys 0% nice 31% idle 0% io 9% irq 39% softirq
Load average: 0.89 0.88 0.67
PID PPID USER STAT VSZ %MEM %CPU COMMAND
1065 1059 root R 8492 28% 56% mjpg_streamer -i input_uvc.so -f 12 -
1060 1059 root S 8492 28% 3% mjpg_streamer -i input_uvc.so -f 12 -
1064 1023 root R 1960 7% 2% top
980 1 root S 1388 5% 1% /usr/sbin/ntpclient -i 60 -s -l -D -p
1022 860 root S 1996 7% 0% /usr/sbin/dropbear -p 22
1058 1 root S 8492 28% 0% mjpg_streamer -i input_uvc.so -f 12 -
1063 1059 root S 8492 28% 0% mjpg_streamer -i input_uvc.so -f 12 -
1059 1058 root S 8492 28% 0% mjpg_streamer -i input_uvc.so -f 12 -
[...]

Ich weiß jetzt nicht, woran dies leigt, evtl. ist das USB-Subsystem nicht wirklich für USB2-Datenraten ausgelegt, keine Ahnung. Siehe Fritz!Box 7170, da scheint ja durchaus das eine oder andere Mal gepfuscht zu werden; grade im Embedded-Bereich bedeutet eine USB-2.0-Schnittstelle nicht zwingend, daß diese auch performant ist :(
Jedenfalls habe ich mir mit der Fonera 2.0g und OpenWRT einen »WLAN-Webcam-Adapter« gebaut; die Fonera verbindet sich drahtlos mit meinem – im Garten nur noch schwachen – WLAN, mjpg-streamer wird von einem auf einem zentralen Mehrkern-Rechner laufenden motion abgefragt und ich brauche außer Strom für die Fonera und einem Platz für die Webcam – schwierig, wenn man so wie ich gerne »das Wetter« filmen möchte, es sind ja Persönlichkeitsrechte der Nachbarn zu beachten usw. – genau nix mehr. Und ich kann mir die Videoqualität – durch die Wahl der USB-Webcam – quasi aussuchen. Und wenn man das Ganze auf die Spitze treiben wollte, evtl. klappte es sogar mit einem 3G-USB-Stick parallel zur Webcam, die Bilder per UMTS/3G zugänglich zu machen. Hier muß ich aber mal gucken, welche Datenmenge das ist ;)
Mir schwebt eigentlich vor, in festen Zeitabständen einen Snapshot zu machen (das kann mjpg-streamer auch, aber dann müßte ich auch noch NFS mounten oder SMB), parallel dazu die Wetterstationsdaten auszulesen, jene per Overlay über das Webcam-Bild zu legen und daraus dann erst dem Zeitraffer-Film zu machen. Letztlich wären ja bei 960×720 noch Pixel frei, wenn man ein HD-Ready-Filmchen daraus machen wollte … Da könnten dan auch noch rrd-Graphen Platz finden … Mal schauen; erst einmal muß ich am Wochenende den Platz optimieren, hinsichtlich Objekt wie auch WLAN-Abdeckung – noch gibt’s gelegentlich leider Dropouts:

Soundtrack: »Lonely for TV« from »Not From Georgia« (»Eagle Rock Entrées«), License: CC-BY-NC-SA.