Vor einer Woche habe ich ja schon drüber geblogt, daß es von verschiedenen Herstellern mittlerweile sog. »Open-Source-Router« gibt, d. h. herstellerseits nicht nur nicht aktiv zu unterbinden versucht wird, daß alternative Firmware die Möglichkeiten der Hardware und die Wünsche des Käufers besser in Einklang bringt, sondern diese Entwicklung, die mit dem Linksys WRT54G vor etlichen Jahren begann, sogar aktiv untersützt wird.
Nachdem ich einen meiner Fonera 2.0g-Router in einen wireless Server für Webcams überführt habe, stieß ich jetzt auf den Fonera 2.0n, spricht eine vermeintlich bessere Version dieses Routers – eingebauter Switch (wie seinerzeit der WRT54g) statt »nur« einem zus. Port wie beim 2.0g, WLAN nach 802.11n (-Draft?) mit theoretisch ca. 100 MBits/sec netto statt »nur« 802.11g (2,4 GHz, max. 54 MBiz/sec brutto = ca. 20 MBit/sec netto) – zu einem auch nicht soo schlechten Preis (rd. 80 EUR derzeit). Tja, nur auf der Suche nach Hinweisen, warum mein geliebtes PWC-Modul nicht mehr in den Kamikaze-Releases von OpenWRT zu finden ist – damit ich auch meine alten VGA-Außen-Webcams auf stromsparende Kistchen klemmen kann –, stieß ich auf folgenden Forumsbeitrag:
Openwrt doesn’t support the fonera2n and thus doesn’t know the fonera2n+mipsel K(ernel)MOD packages have to be compiled against 2.6.21 as the ralink drivers which are binary…only support 2.6.21
Na doll; da hat sich also jetzt FON auf das gleiche Abstellgleis begeben wie vor Jahren Linksys, Asus und wie sie alle heißen, die auf die Broadcom-Plattform samt Broadcom-WLAN gesetzt haben — und da es von Broadcom, wie von Ralink, keine Open-Source-Treiber für jene Hardware gibt, stehen alle WRT- oder Asus-500g-Besitzer wie ich insofern im Regen, daß es nur einen, heute uralten, 2.4er Kernel für die Plattform geben kann und somit auch keine Treiber, die 2.4 nicht (mehr) unterstützen. So wird es denn auch in ein, zwei Jahren den Fonara-2.0n-Eigentümern gehen, deren Hardware an Softwareneuerungen nicht partizipieren kann. Schade; grade von einem Unternehmen wie FON hätte ich erwartet, daß sie auf eine Plattform setzen, die voll von Open-Source-Treibern unterstützt wird (so, wie es bei der Fonera 2.0g auch der Fall war).
Naja, ich werde dann wohl eine ältere OpenWRT-Version für meinen Asus 500g Deluxe nehmen, komischerweise gab’s für White Russian noch pwc-Treiber; für Kamikaze finde ich irgendwie nix fertiges; ich werde also wohl auch eine Buildumgebung mir noch einrichten müssen — wieder mal nix mit »mal eben schnell flashen« :-?
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):
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:
Noch im Spätsommer 2009 sollen RTL und Vox über HD+ von SES Astra zu empfangen sein, im Januar 2010 sollen dann Sat.1, ProSieben und Kabel Eins folgen.
Die Plattform HD+ ist senderunabhängig […]. Denn HD+ umfasst auch ein Bezahlmodell und die nötige Technik wie Smartcards. So plant RTL beispielsweise, für seine beiden HD-Programme RTL und Vox nach dem ersten Jahr Gebühren zu verlangen. Bisherige HD-Receiver sind mit neuen Modulen für den Standard CI-Plus nicht kompatibel.
Nächster Versuch also von SES Astra einerseits und den führenden Privatsendern, wieder angeführt durch die RTL-Gruppe, mit irreführenden Marken – ein Plus bietet »HD+« nur den Sendern und dem Anbieter SES Astra; der Endkunde hat Einbußen im Geldbeutel und in der Nutzung seiner bezahlten Hardware hinzunehmen bei diesem technologisch überflüssigen System – beim TV-Konsumenten über die Schiene »hochauflösendes Fernsehen« Geld abzuzwacken und dessen Rechten einzuschränken, wie das c’t-Magazin ausführt:
Philips bringt im April [2009] erste Fernsehgeräte mit integriertem Empfänger für digitales Kabelfernsehen (DVB-C) und einem „CI-Plus“ genannten Interface auf den Markt. Wer ein passendes CI-Plus-CAM (Conditional Access Module) und eine gültige Abokarte besitzt, kann damit unverschlüsseltes wie verschlüsseltes digitales Kabelfernsehen empfangen – wie zuvor schon mit CI-Receivern ohne „Plus“.
Doch während die Daten beim bisherigen – offiziell „DVB-CI“ genannten – Verfahren nach dem Passieren des CAM unverschlüsselt sind, sichert ein CI-Plus-Gerät den kompletten Signalverlauf gegen äußere Eingriffe.
Auch die Durchsetzung von analogen Kopierschutzmechanismen ist sichergestellt: Der Digital-TV-Anbieter legt für jedes „Programm“ (ein TV-Kanal oder eine einzelne Sendung) fest, ob der analoge Ausgang mit einem Kopierschutz (Macrovision) belegt wird oder etwa bei HDTV-Sendungen nur Videobilder in Standardauflösung liefert. Schließlich wird auch der Jugendschutz mittels nicht deaktivierbarer PIN-Abfrage strikt eingehalten.
Jeder CI-Plus-Empfänger besitzt schließlich seinen eigenen Satz an Schlüsseln und Zertifikaten, um im Falle einer Kompromittierung des Sicherheitssystems einer Receiver-Reihe diese Geräte deaktivieren zu können. […]
[…] Vor allem aber gibt es keine Sicherheit, dass der Empfang verschlüsselter Programme auch morgen noch klappt: So wechselte Kabel BW im Mai 2008 die Verschlüsselung für die über sein Netz ausgestrahlten Pay-TV-Programme von Kudelskis Nagravision auf NDS’ Videoguard, […]. Selbst Humax’ LCD-TV LDE-HD32C lässt sich trotz Premiere-HD-Zertifizierung nun nicht mehr in Baden-Württemberg zum Empfang des Pay-TV-Senders einsetzen, […]
Man sollte sich den ganzen Artikel mal zu Gemüte führen um zu begreifen, welche tiefgreifenden Einschnitte in die häusliche (digitale) Verwendung die TV-Anbieter hier über das Trojanische Pferd HDTV durchzusetzen versuchen; so sieht diese »Plus«-Spezifikation wohl auch vor, daß der TV-Sender je Sendung bestimmen kann, ob Aufnahmen, sofern er sie überhaupt erlaubt, beliebig oft oder nur für eine vom Sender bestimmte Zeit abgespielt werden darf. Auch das Überspringen von Werbeblöcken – Standard bei jedem aktuellen Festplattenreceiver – oder das sog. Timeshifting – eine live angesehene Sendung anhalten (also ab jetzt speichern) und später ab dieser Stelle weiterschauen; auch dies übrigens seit Jahren ein Feature der VDR-Software für Linux, lange bevor T-Entertain überhaupt auf eine Powerpoint-Folie geschrieben wurde – kann und wird der TV-Sender kontrollieren.
Nachdem die Politik als Handlanger der Medienindustrie Umgehungen von Verschlüsselungsmaßnahmen kriminalisiert hat, geht nun die Industrie hin und entrechtet die Verbraucher konsequent weiter. Nicht der Besitzer eines Aufnahmegerätes entscheidet in Zukunft, wann er eine Sendung sich ansehen möchte; der TV-Sender, der hierfür auch noch zusätzliche Bezahlung vom Verbraucher verlangt, klebt da ein Verfallsdatum drauf und schon ist der Krieg der Sterne nach z. B. vier Wochen nur noch ein nutzloser Datenhaufen auf der Festplatte, da das Ansehzeitfenster sich geschlossen hat.
Schöne neue Welt — von der in Ansätzen sich T-Entertain-Nutzer schon heute ein Bild machen können, denn diese Plattform sperrt seit langem bereits bei diversen Sendern/Sendungen die Mitschnitt- und Timeshift-Funktion.
Narf! Zu spät, Navigon, zu spät! Am Wochenende habe ich mir CoPilot Live für Android gekauft (mit D-A-CH für irgendwas bei 30 EUR); der Download über WLAN mit o2-HSDPA-Link schlug leider wiederholt nach >60% des 300-MB-Downloads des Kartenmaterials fehl — zu Hause, per WLAN mit T-VDSL-Link gab es kein Probleme. (Vermutung: irgendwas hat o2’s Datenverarbeitungsinfrastruktur mit den Binaries gemacht – JPEG for Binaries? –, den Fehler auf oder unterhalt TCP sollte ja erkannt und behoben werden.) Einen konkreten Test konnte ich leider noch nicht machen — die Rückfahrt aus dem Kurzurlaubsdomizil allerdings bestritt ich mit Wiselink und war recht angetan. Denn anders als AndNav2 (BETA), welches >2 Minuten für die Berechung der Strecke Kist-Gütersloh benötigte (und beim ungeduldigen Abbruch noch nicht fertig war damit — wieviele Jahre braucht AndNav2 dann wohl für einen Weg von Gütersloh nach Barcelona?), bekam Wiselink auch meine baustellenbedingt unfolgsamen Fahrmanöver gut mit und berechnete in Sekunden(bruchteilen teils) einen neuen Weg.
Was mir bei CoPilot definitiv noch fehlt sind Stauinformationen (TMC, whatever) :(
Jul 8 22:27:32 greebo kernel: [133096.115253] r8169: eth0: link down
Da ging sie hin, die Fonera 2, und ward’ weder im WLAN noch auf dem Ethernet mehr gesehen. Stabilität – zumindest bei Nutzung von UMTS als Uplink – scheint keine herausragende Stärke der Fonera-2-Software zu sein. (Bevor wer meckert: die 2.2.5.0 hat sich binnen zwei Stunden jeweils selbst stranguliert; das es fast einen Tag jetzt gut gegangen ist, ist insofern erfreulich — und ein Armutszeugnis für diese Firmware.)
Nunja, nachdem fon in Deutschland einen Prozeß verloren hat und dabei als »schmarotzend« bezeichnet wurde, darf man gespannt sein, in welche Richtung sich fon und die Fonera-2-Firmware weiterentwickled …
Es war ein Notwehrkauf, wirklich, das müßt Ihr mir glauben! Vertrag lief aus, ich habe Grundtarif und Optionen ausgemistet und dann nur 1,00 EUR … Ja, was hätte ich den tun sollen? ;)
Als stolzer Besitzer einer Panasonic Lumix TZ7, der ich nun bin, mußte die Lumix natürlich nun mal beweisen, wie sie sich denn mit meiner Linux-Infrastruktur versteht.
Anschluß per USB also: check. Das spart einerseits das Gehampele mit Kartenlesern und zum anderen ggf. den Spaß, eine SDHC-Karte in einem SDonly-Leser zu zermarmeln. Nachteil ist natürlich die Notwendigkeit, ein weiteres Proprietär-zu-USB-Kabel mitschleppen zu müssen, der USB+AV-Anschluß ist non-standard …
Insofern also – wie nach den entsprechenden Einstellungen auf der Lumix aber auch erwartet – keine negativen Überraschungen. Nachdem der Datentransfer also gesichert ist, stand die Begutachtung der Datenschäzte, die die Lumix ablegt, an. Für das von ifranz improvisierte Testvideo schmeißt ffmpeg folgendes aus:
Leider habe ich derzeit weder die Möglichkeit, H.264 zu streamen (abgesehen von externen Diensten wie z. B. Vimeo, auf die ich ggf. noch zurückgreifen werde) oder sinnvoll zu bearbeiten (Ausblenden z. B. von Gesichtern) noch ist das Blog-Layout auf 1280 Pixel breite Videos ausgelegt, sodaß auch hier wieder nur ein kleines Flash-Video präsentiert werden kann:
Leider bestand El Burro auf der Unkenntlichmachung, daher ist die Qualität des 800k-FLVs leider nicht so, wie bei direkter Konvertierung der 16 MBit/sec-H.264-Quelle möglich. Ich bitte dies zu entschuldigen.
Die Bearbeitung der .MTS-Dateien (steht das für »MPEG Transport Stream«?) ist angenehm unkompliziert unter Linux, schon ein simples »ffmpeg -i 00009.MTS -ar 22050 -ab 128k -aspect 16:9 -b 800k -f flv -s 480×270 00009.flv« wandelt die 201 MB der Testaufnahme in einen handlicheren – aber qualitativ auch deutlich schlechteren – 14 MB kleinen Flash-Stream.
Insofern: Der nächste Urlaub mag nun kommen; allerdings fehlt mir nach wie vor eine gescheite Bildkatalogisierungssoftware, um die Myriaden von Mediendateien – alleine meine alte Sony DSC-P10 zählt über 4200 Aufnahmen, deren 2 MPix-Vorgänger sprang damals von 09999 auf 00000 und das N95 zählte zuletzt auch schon über 3700 getätigte Aufnahmen – sinnvoll verwalten und, insbesondere, wieder auffinden zu können. Von der zukunftssicheren Lagerung ganz zu schweigen …
Tja, heute bleibt der Fernseh’ aus, die Telekom gibt kei’ Zeit nicht raus …
Wirklich ein überlegenes Konzept, welches T-Home da mitsamt Microsoft für massenmarktauglich hält. Und ausgereift wie Junger Gouda … Bei Umbauten an der »Medien-Ecke« mußte ich die Gerätschaften, darunter auch ein T-Home X301T für mein zwangsweises T-Entertain-Paket, stromlos machen. Hernach war dann das enterTainment dahin — die überlegene Technologie verschluckte sich am Zeitserver, der zwar vom Desktop aus per “ntpq -p” seine Peers nannte, mit der X301T aber nicht reden wollte:
»Geräteinitialisierungsfehler«, nee, Jungs, iss’ klar. Ein Hoch, wieder einmal, auf die Sat-Schüssel und den dran hängenden VDR, der rennte natürlich sofort weiter.
Offensichtlich war das Gateway-Problem von o2 heute Nachmittag gar kein wirklicher Ausfall des Gateways, wie es die Fehlermeldung suggerierte, vielmehr scheint dort eine Maschinerie zu agieren, die nicht immer hilfreich funktioniert bzw. sinnhafte Fehlermeldungen produziert.
Ich hatte versucht, www.active-film.com aufzurufen — diese URL hatte ich unterwegs gelesen und war neugierig. Der Internetzugang von o2 meldete sich wie gepostet als dysfunktional, der Quervergleich mit Vodafone ergab dann eine andere Fehlermeldung; der beispielhafte Aufruf von www.heise.de danach tat den auch via o2, der von besagter URL nach wie vor nicht.
Jetzt, am späten Abend des 30.12.08, bekomme ich vom Laptop aus (über die eigene Infrastruktur, OpenVPN sei Dank) NXDOMAIN für www.active-film.com – und der nachmittags gespeicherte Bookmark auf dem Vodafone-N95 bringt jetzt “Internet: Server nicht bereit” beim Aufruf jener URL. Wann, oh, wann, portiert mal jemand OpenVPN oder meinethalben auch »nur« CIPE auf Nokia Series 60 3rd Release? Diese ganze Vermauschelung bei den Mobilfunkern schmeckt mir gar nicht …
