blogdoch — jetzt wird zurückgeblogt
Hmm. Anyone already solved this issue with “motion” capturing 1920×1080, i. e. Full HD, streams?
Jun 10 06:12:10 death motion: [5] Retrying until successful connection with camera Jun 10 06:12:10 death motion: [5] netcam image height (1080) is not modulo 16 Jun 10 06:12:20 death motion: [5] Retrying until successful connection with camera Jun 10 06:12:20 death motion: [5] netcam image height (1080) is not modulo 16
Hrmpft. This is really annoying.
My little webcam project today caught this:
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):
Lustige Heimkehr gestern; mein o2 Joggler, ein 2009 auf der Insel auf den Markt gebrachtes, Atom-powerd »Standtablet« mit Linux als OS und Flash als Applikationsplattform, zeigte mir eine gänzlich andere Oberfläche als vorher, und insbesondere war kein Schreensaver aktiv — es brannte sich also ein Standbild für, worst case, 4 Tage ins LCD ein.
Freitag morgen, als ich die Zweitwohnung in Berlin verließ, lief noch die alte Software von o2 (nur die o2 Kalender-Anwendung hatte o2 schon vorher durch eine für Googles Kalenderdienst ausgetauscht; war mir relativ egal, da der Kalenderdienst von o2 eh’ auf den britischen Markt zugeschnitten war); bei der Rückkehr am Dienstagabend lief OpenPeaks Software.
Gut, daß o2 Ihr Produkt loswerden wollte, hatte man im Vorfeld per SMS — ja, die Joggler hatten auch ohne SIM eine »IMEI« und eine SMS-Nummer im britischen o2-Netz — den Nutzern mitgeteilt. Und dementsprechend habe mich meine Joggler natürlich über den fraglichen Zeitraum abgeschaltet. Während im deutschen gilt »die Zeitfestsetzung garantiert keine Spannungsfreiheit« (Standardspruch bei Zeitungsanzeigen von Energieversorgern, die eine Stromabschaltung wegen Wartungsarbeiten ankündigen), gilt im britischen offenbar »die genannten Zeiten sind nur ein Beispie, wir tun, was wir wollen, wann wir es wollenl«; wie anders soll man ferngesteuerte Neuinstallationen über eine Woche nach dem kommunizierten Termin einordnen?
An sich ist die neue Version durchaus nett; was mich aber auf die Palme bringt sind primär zwei »Details«:
Grade der letzte Punkt geht mir ziemlich gegen den Strich, denn jener Joggler diente ganz primär als meine kleine Squeezebox, mein (Internet-) Radio bzw. mein (vom Server in Güterloh gestreamt) mp3-Player — im Großen und Ganzen ist jener Joggler jetzt eine ziemlich teure LCD-Uhr.
Aus meiner Sicht als billig und gerecht denkender Anwender, hat o2 (UK) sich durch diese Aktion — mit der Ausschaltung über den angekündigten Eingriffszeitraum wurde die Zustimmung dazu deutlich und wirkungsvoll verweigert — der Datenveränderung, -unterdrückung bzw. -löschung gem. §303a StGB schuldig gemacht:
§ 303a Datenveränderung
(1) Wer rechtswidrig Daten (§ 202a Abs. 2) löscht, unterdrückt, unbrauchbar macht oder verändert, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft.(2) Der Versuch ist strafbar.(3) Für die Vorbereitung einer Straftat nach Absatz 1 gilt § 202c entsprechend.
»Was tun?«, sprach Zeus. Anders als bei Sonys Playstation, wo man immerhin noch die theoretische Wahl hat(te), der funktionalen Kastration durch Sony neue Firmware oder der Reduktion der mehrere hundert Euro teuren Konsole auf einen ziemlich unhandlichen und stromfressenden DVD-Player zuzustimmen (ohne neue Firmware kein PSN-Zugriff mehr, mithin keine Onlinespiele mehr; mit neuer Firmware wurden einst beworbene Funktionen nun willkürlich unterdrückt), lies o2 einem nicht einmal die solche. Und griff munter nach Gutsherrenart auf mein System zu, als sie ihm habhaft wurden. #FAIL
Gretchenfrage ist also: »War o2 für diese Datenveränderung legitimiert?« Aus meiner Sicht nein, denn auch ein Gerät im Eigentum, welches einen Onlinedienst nutzt, darf aus meiner bescheidenen Sicht nicht einfach durch den Anbieter beliebig umkonfiguriert werden bis hin zur Löschung/Unterstrückung vom vom Geräteeigentümer aufgespielten Daten. Comments?
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?
What’s the suggested plugin, or shall I use multiple, for properly integrating my now WordPress-powered blog with Twitter and Facebook?
I want to be able to selectively post to Twitter and/or Facebook, and want to record external responses (replies/retweets on Twitter, comments on Facebook) in WordPress as well. Posting comments on FB-derived ones in WP will still break the discussion, but that I intend to think about after some trial period.
Furthermore I’m looking for a different Android-App than the one called ‘WordPress’ in the MarketPlayStore, since this one seems to break EXIF data on image upload :-(
So, my dear followers: Any hints appreciated on #tw and FB as well as on the blog :-)
Grade mit meinem Multi-Link-AP kurz nach dem Halt in Hannover Hbf ausprobiert, als der USB-Stick mir Vodafone-SIM LTE signalisierte:
Tue Apr 24 07:34:48 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9082ms rtt min/avg/max/mdev = 38.021/42.213/51.538/4.231 ms
Zum Vergleich, D1 mit baugleichem Stick (Huawei K5005) und o2 mit Huawei E1550:
Tue Apr 24 07:34:49 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 11814ms rtt min/avg/max/mdev = 216.279/3340.028/7213.291/2193.227 ms, pipe 8/
Tue Apr 24 07:34:49 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9778ms rtt min/avg/max/mdev = 208.762/291.890/508.182/78.296 ms
Alles, wohlgemerkt, aus dem schon wieder fahrenden ICE.
(Die Verbindung läuft über OpenVPN (per UDP) über dedizierte Endpunkt-IPs an einem Server im ‘Festnetz’, die über die jeweile PPP-Verbindung der USB-Mobilfunkmodems geroutet werden. Das alleine ist schon ein Big Win bei den laufend abbrechenden PPP-Sessions wegen Abdeckungsmangel …)
Ein bißchen später, so in Höhe Gifhorn im ICE 541, sieht das dann allerdings auch anders aus:
Tue Apr 24 07:57:09 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 10064.308/12367.812/15869.452/1888.586 ms, pipe 10
Tue Apr 24 07:57:08 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 8 received, 20% packet loss, time 57635ms rtt min/avg/max/mdev = 984.208/2262.540/3884.146/834.960 ms, pipe 3
Tue Apr 24 07:57:07 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 85126ms rtt min/avg/max/mdev = 590.445/1558.000/4091.427/1151.067 ms, pipe 2
Internet im ICE — noch immer ein Abenteuer ;) Zum Abschluß — auch der Reise ;) — nochmal Pings aus dem stehenden ICE im Bahnhof Berlin.-SPandau, mit LTE bei D2:
Tue Apr 24 08:58:11 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=1 ttl=64 time=886 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=2 ttl=64 time=1327 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=3 ttl=64 time=334 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=4 ttl=64 time=107 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=5 ttl=64 time=107 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=6 ttl=64 time=155 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=7 ttl=64 time=94.9 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=8 ttl=64 time=103 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=9 ttl=64 time=112 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=10 ttl=64 time=221 ms --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9494ms rtt min/avg/max/mdev = 94.927/345.152/1327.262/399.590 ms, pipe 2
Tue Apr 24 08:58:11 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=1 ttl=64 time=69.6 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=2 ttl=64 time=65.4 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=3 ttl=64 time=69.4 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=4 ttl=64 time=65.5 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=5 ttl=64 time=57.1 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=6 ttl=64 time=59.9 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=7 ttl=64 time=62.1 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=8 ttl=64 time=60.8 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=9 ttl=64 time=61.0 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=10 ttl=64 time=71.0 ms --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 57.137/64.225/71.063/4.502 ms
Tue Apr 24 08:58:12 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=1 ttl=64 time=687 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=2 ttl=64 time=729 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=3 ttl=64 time=229 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=4 ttl=64 time=559 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=5 ttl=64 time=319 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=6 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=7 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=8 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=9 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=10 ttl=64 time=239 ms --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9367ms rtt min/avg/max/mdev = 229.667/372.074/729.099/193.154 ms
Leider ist o2 derzeit, was die RTT angeht, deutlichst im Hintertreffen; 200ms bei einer HSPA-Verbindung ist … unzureichend :-(
Ich habe mein HTC Sensation nun rund eine Woche mit dem aktuellen Android-Major-Release (Android 4.0 aka Ice Cream Sandwich, kurz: ICS) laufen, und mehr und mehr trübt sich der Blick.
Toll, was mit CSS alles geht …
Der Browser hat z. B., wie ich heute herausfand, einen ‘coolen’ Bug mit dem WordPress-Theme des Blogs von @_refugee_ — ein doppelter Tap auf den Bildschirm vergrößert den linken Rand, ein Wisch nach links schiebt dann leider aber den Hauptbereich unter den Layer mit Christians Foto und Tweets.
Auf dem ollen Milestone mit der CM7-Variante von Android 2.3.7 existiert das Problem nicht. Lustigerweise werden mir keine mobilen Seiten mehr angeboten, es kommt immer die »echte« Web-Version — mag aber sien, daß ich das abgestellt habe, und nur nicht wiederfinde, wo zum Henker man das konfiguriert (im Browser (genannt »Internet« *sigh*) jedenfalls nicht. (Nachdem deutsche Verleger von Smartphone-Nutzern Geld verlangen, was sie anderen Webbrowsern kostenlos bereitstellen, ist das Abschalten der Kennung, ein mobiler Browser zu sein, nur konsequent, IMHO. Und nein, den »Schutz« kann selbst ein Jurist nicht als »wirksam« ansehen.)
Gingerbread kennt die Probleme nicht
Ferner scheint kein (Bild-) Datenaustausch per Bluetooth vom Milestone zum Sensation mehr zu funktionieren, jedenfalls kommt auf dem Sensation erst nach einem erneunen Paaring überhaupt eine Anfrage an, und seit dem freudigen »nicht mehr nachfragen«-Haken und Klick zur Verbindungsannahme … tut sich nix mehr. Immerhin kann man jetzt auf dem Sensation, wie schon auf dem CM-Gingerbread-Milestone, das blödsinnige Abschalten der Sichtbarkeit bei Bluetooth abstellen.
Ach ja, und der DB Navigator mag nicht mehr in den Kalender schreiben …
Wie unfähig kann ein Handyhersteller eigentlich sein? Bei Motorola stellt sich mir diese Frage nicht mehr, nachdem nun endgültig das Vertrauen in jenes Unternehmen verloren ging. Das hochpreisige Motorola Milestone wird faktisch vom Hersteller nicht mehr supportet; erst nach über einem Jahr bequemt man sich – vielleicht, denn Termine ankündigen und sie später nicht einzuhalten ist das Einzige, das Motorola bislang hinsichtlich einer aktiuellen Android-Version für das Milestone zustande gebracht hat –, die schon jetzt veraltete Android-Version 2.2 auf das Milestone zu bringen. Aktuell ist heute leider schon 2.3, mit 3.0 (zumindest für Tablets) anklopfend, wenn Motorola – vielleicht, vielleicht auch nicht – endlich 2.2 zu liefern sich willig zeigt.
Ein Armutszeugnis — und gewiß eine Warnung an alle potentiellen Interessenten des Motorola Xoom-Tablets, welches aktuell als erstes Android-3.0-Gerät am Markt am Markt erwartet wird, nicht auf Produkt- oder Kundenpflege nach dem Kauf zu setzen. Denn das, so lehrt die Erfahrung, bieten chinesische Nachbauer noch eher als Motorola. Und anders als Motorola unterbinden jene nicht die Selbsthlfe; Motorola hingegen sperrt den Kunden auch noch von der gekaufenten Hardware durch kryptographische Verfahren aus.
Mein Milestone mit Android 2.1 Update 1 hat jedenfalls nach wie vor Probleme mit dem Autofokus, der Blitz löst, scheinbar tagesformabhängig, mal nur Sekundenbruchteile aus und die QUalität der Videos ist nach wie vor unterirdisch. Die Fotoprobleme bestehen wohlgemerkt mit der Android-eigenen Kamera-Anwendung als auch mit Vignette, Camera 360 und Co.
‘Immobilien auf den milestone ich kann nicht installieren . Diesel test angesprochen blog eintrag über google android 2.0’
Tja, schade, Better Terminal Emulator Magic – wie es auf meinem China-Billigst-Androiden-Pad drauf war – rennt auf dem Magic unter 2.2 nicht, auf dem Milestone mit Android 2.0 läßt es sich gar nicht erst installieren :(