Archive for the ‘code’ Category
Google nimmt den Fehdehandschuh auf
Nachdem Apple recht offensichtlich (und dumm) Google angreift (siehe Voice-App und weiteres) nimmt Google jetzt den Fehdehandschuh auf. Mit der Ankündigung in naher Zeit den H.264-Support aus Chrome zu entfernen stellt sich Google erstmals offen gegen Apple.
Mit einem Browser-Marktanteil von rund 10% (12+% in den Staaten) hat Chrome eine Verbreitung erreicht, die für Site-Betreiber relevant ist. Wenn dieser Browser in Zukunft die derzeit einzige Alternative zu Flash-Videos nicht mehr unterstützt müssen sich Sitebetreiber eine Alternative überlegen. Die Lösung wird für die meisten sicher nicht darin bestehen, alle Videos zusätzlich als WebM-Video anzubieten. Wer diesen Aufwand scheut wird wieder bei Flash landen. Die Massage von Google richtet sich also an die ZDFs und BBCs der Welt und lautet: “Hört auf, eure Flash-Player durch HTML5-Player zu ersetzen.”
Es gibt inzwischen vernünftige Browserweichen, die den iOS-Usern den Video-Tag mit H.264 geben und anderen den Flash-Player einspielen. In Zukunft werden diese Weichen eine weitere Regel abfragen: if(USERAGENT.indexOf(‘Chrome’) != -1) ladeFlashPlayer();
Eine schlechte Nachricht für das Netz, für Chrome-User und für Android-User. Und ein neues Zeichen (nach der Ankündigung eines Tablet-only Android 3), dass Google keine langfristige Strategie hat.
[Update] Google fühlt sich offensichtlich nach der massiven Kritik (u.a. daring fireball und zdnet) genötigt, sich näher zu erklären. Ausserdem kündigen sie (in einem Update der Erklärung) an, für Safari und Explorer WebM-Plugins anzubieten. Mit Hilfe von ‘canPlayType’ (JS-Funktion, die z.B. bei der Frage canPlayType(‘[mime-type];[codec="codec-string"]‘) z.B. den Wert ‘maybe’ oder ‘probably’ zurückgibt) sollen dann auch diese Browser WebM abspielen können. Allerdings ist dies nach meiner Meinung keine optimale Lösung, da die meisten Browserweichen wahrscheinlich eher nach Browser/OS entscheiden werden, welche Video-Player-Lösung ausgeliefert wird. Ausserdem würde mich sehr wundern, wenn über die Plugin-Schnittstelle dieser Part des Browsers ohne weiteres angesprochen werden kann.
Irgendwie scheint sich meine Vermutung, Google hätte keine langfristige Strategie, zu bestätigen. Offensichtlich haben sie nicht mit so einem Sturm der Entrüstung gerechnet und versuchen jetzt die Wogen zu glätten. [/Update]
[Update2] Unter dem Titel “The Ambiguity of ‘Open’ and VP8 vs. H.264” ist ein ausgezeichneter Artikel über die Plug-In-Frage erschienen. Besonders interessant sind die Ausführungen über die Erweiterungsmöglichkeiten von Firefox, Chrome und Opera vs. Safari und IE9. Erstere spielen Videos über eigene Decoder ab, letztere handeln den video-Tag über die OS-eigenen und vor allem erweiterbare Decoder ab. [/Update2]
2cm-GPS-Genauigkeit für alle!
Die Genauigkeit eines heute Verfügbaren GPS-Empfängers liegt – je nach Quelle und Empfänger – bei 3 bis 50 Metern. Im Prinzip wäre GPS geeignet wesentlich genauer zu arbeiten. Allerdings wird die Genauigkeit durch natürliche und künstliche Einflüsse beeinflusst. Da diese Einflüsse aber auf alle Empfänger wirken kann man diese Abweichungen eigentlich rausrechnen. Dazu wird die Abweichung von einem Gerät berechnet, bei dem die exakte Position bekannt ist. (Eigentlich wird nicht die Abweichung der Postition berechnet, sondern die Abweichungen der Signallaufzeit zu den einzelnen Satelliten). Ein solches Differenzsignal nennt sich sperrig RTCM (Radio Technical Commission for Maritime Services) und kann von teureren Empfängern benutzt werden.
Ein normaler GPS-Empfänger ist ein recht nervöser Zeitgenosse. Ohne Korrektursignal springt die Position selbst dann, wenn man sich nicht bewegt.
Mit einem korrigierten Signal erreicht man – je nach Quelle – eine Genauigkeit von bis zu 2cm. Grade in unwegsamem Gelände (Häuserschluchten!) erhöht sich die Genauigkeit deutlich weil der Empfänger nur sehr wenige Satelliten sieht und Abweichungen (z.B. absichtliche Zeitverzögerungen) der einzelnen Signale sich besonders deutlich auswirken.
Für dieses Korrektursignal gibt es seit einigen Jahren sogar das Internetprotokoll Ntrip (Networked Transport of RTCM via Internet Protocol). Die Daten werden dabei im Wesentlichen in einen HTTP-Stream verpackt auf Anfrage ausgesendet. In Deutschland gibt es dutzende Server, die die Korrekturdaten für verschiedene Positionen senden. Allerdings sind offensichtlich alle geschützt und/oder kostenpflichtig. Mit dem schönen Namen SAPOS (Satellitenpositionierungsdienst der deutschen Landesvermessung) bieten die Länder verschiedene Dienste (siehe AdV) mit unterschiedlicher Genauigkeit an, die über unterschiedliche Medien übertragen werden. In Berlin sendet der RBB zum Beipsiel auf 88,8 ein Signal mit dem eine Genauigkeit von unter 2m berechnet werden können. Genauere Daten sind allerdings bei allen Bundesländern nur kostenpflichtig zu erhalten. Mit 10 Cent pro Minute dürfte es sich um den teuersten behördlichen Dienst überhaupt handeln.
Jetzt ist es aber nicht so, dass der Betrieb einer Referenzstation und die Bereitstellung der Korrekturdaten Raketenwissenschaft ist. Zwar wird dabei mit relativistischen Effekten gerechnet aber die Formeln sind bekannt und zum Teil als OSS (RTKLIB) verfügbar. Inzwischen gibt es immer mehr Empfänger die sich dazu bringen lassen, die Rohdaten rauszurücken und bieten damit alles, was man als Referenzstation benötigt. Ein Set aus einem Navilock 551EUSB für ca. 30 € betrieben an einem Beagleboard für 150 € unter Ångström Linux, vernünftig kalibriert und mit dem Netz verbunden würde einen hervorragenden Ntrip-Server liefern.
Ein solcher Korrekturserver könnte jedes online verbundene Smartphone mit einer Genauigkeit im Zentimeterbereich ausstatten. Zusammen mit den inzwischen verfügbaren Gyroskopsensoren in aktuellen Androidgeräten und iPhones würden AR-Programme plötzlich wirklich Spass machen.
Es bleibt also die Frage, wer in Zukunft umsonst solche Referenzmessungen anbietet. Hallo Google? Hallo Nokia? Aber eigentlich ist es ja ein hervorragendes Crowdsourcing-Projekt.
Hier lang gehts zu weiteren Informationen:
- Einfache Einführung zu GPS: http://ivvgeo.uni-muenster.de/Vorlesung/GPS_Script/einfuehrung_historisches.html
- SAPOS Berlin: http://www.stadtentwicklung.berlin.de/geoinformation/sapos/
- Tobis Wendorff zu 40cm Low Cost Messung: http://openstreetmap.tobwen.de/fossgis2010_gps.pdf
- Beagleboard: http://beagleboard.org/
- User’s Guide ublox: http://www.zogg-jm.ch/Dateien/Update_Zogg_Deutsche_Version_Jan_09_Version_Z4x.pdf
- Navilock ublox5 GPS-Receiver bei Conrad: http://www.conrad.de/ce/de/product/372874/NAVILOCK-552ETTL-GPS-ENGINE-MODULE-TTL
- GPS-Community: http://www.kowoma.de/gps/
- OSS gpsd: http://gpsd.berlios.de/
- International verfügbare Ntrip-Server: http://www.rtcm-ntrip.org/home
Chronik eines angekündigten Dilemmata
Heute habe die iOS-Developer die Beta von 4.2 erhalten und es ist genau das passiert, was ich am Wochenende noch gegenüber dem KingOfJS befürchtet habe: die Umlautumschaltung für die Tastatur auf dem iPad wurde auf den Stand vom iPhone zurückversetzt. D.h. man erreicht den häufigsten Umlaut nicht mehr durch längeres Halten der Taste sondern muss ihn durch Wischen ansteuern. Nur die 3.2er Versionen für das iPad hatten die wesentlich einfachere und logischere Variante mit dem längeren Halten. Mein Gesprächspartner meinte noch, dass Apple das Feature dann wenigsten einstellbar machen würde. Ich war mir sicher, dass Ninja-Steve weitere Punkte in den Einstellungen nicht akzeptieren würde. Leider hab ich Recht behalten.
FUCK!
Neue Touch-Bibliothek: Sencha
Mit Sencha ist eine neue Touch-Bibliothek verfügbar, die antritt, verschiedene Plattformen zu unterstützen. Neben iPhone und iPad soll auch Android supportet werden. Sencha ist aus Ext-JS hervorgegangen.
Standard-UI-Elemente mit HTML5 gebaut.
Bisher ist eine Beta verfügbar, die nach meinen erstens Tests auch schon recht gut funktioniert. Nur beim rotieren gibt’s noch einige Probleme.
erste html5-flash-h.264-ogg-video-wollmilchsau
Mit dem SublimeVideo von Jilion kommt (hoffentlich bald) das erste JS-Framework auf den Markt, dass eine transparente Behandlung von HTML5- und Flash-Videos gestattet. Im HTML-Code steht der Video-Tag und das Framework wählt an Hand der Fähigkeiten des Browser die richtige Technik und den richtigen Codec für den Browser aus.
In der ersten Version wird der Player offensichtlich noch keine Pre-Rolls unterstützen. Aber ich bin mir sicher, dass Playlists mit dem Framework sehr einfach zu implementieren sind. Auch Skins und Themes dürften per CSS sehr leicht umzusetzen sein.
Für die Broadcaster stellt sich nun nur noch die Frage, ob sie Firefox mit Ogg unterstützen wollen, oder lieber nur H.264 verwenden möchten, das von Webkit und Flash geladen werden kann (und offensichtlich eine wesentlich bessere Qualität bietet). Mit Ogg wäre der Speicherbedarf größer und Caching und CDN aufwendiger.
Um sicher zu sein, dass es sich wirklich um einen HTML5-fähigen Browser handelt kann man ja vorher noch einen Test machen …
webanalytics crap – oder: warum xml einen schlechten ruf hat
Zu meinen Aufgaben im neuen Job gehört die Analyse verschiedener WebAnalytics-Tools. Am Ende dieser Analyse soll eine Liste stehen, die es uns und unseren Kunden leicht macht, den richtigen Anbieter auszuwählen. Neben der einfachen Benutzung der Tools und der Qualität der erhobenen Daten untersuche ich dabei die Möglichkeiten der APIs. Wie kommt man mit anderen Systemen an die Daten, wie schnell reagiert die API, welche Daten kann man abfragen? Aber vor allem: “In welchem Format kann man die Daten erhalten?”
Alle großen Anbieter (Omniture, At Internet, Nedstat) bieten dabei XML als Ausgabeformat an. Toll denkt man sich da. Als jemand der seit Jahren mit XML arbeitet und schon etliche Mashup-Projekte gemacht hat träumt man dann schon von tollen neuen Charts und großen Monitoren im Entrée unserer Kunden.
adobe vs. apple *popcornhol*
Disclaimer: Ich habe ein gehacktes iPhone. Eher aus Nostalgie als aus Notwendigkeit. Ebenso hätte ich eine gehackte PS3, wenn ich eine PS3 hätte. Und ich habe mit clicktoflash auch einen gehackten Browser. Ich würde aber nie auf die Idee kommen, dass die Nutzungsbedingungen irgendeines Herstellers oder gar einer Site mich an der Nutzung eines Gerätes in meinem Sinne hindern könnten.
Tim Pritlove (ein ausgewiesener Gegner von Flash) hat zu dem Thema “Adobe vs. Apple’ (formally known as friends) einen schönen Post von Lee Brimelow entdeckt und tweetet:
Adobe is pissed: http://bit.ly/chw8Oc Popcorn!
Der Artikel hat es in sich. Es geht nicht wieder – wir erinnern uns – um die grundsätzliche Frage, wie abgrundtief schlecht es sei, dass Apple Flash auf iPhone, iPod Touch und iPad nicht zulässt. Immerhin ist Flash heutzutage die beherrschende Technologie im Web:
Warum eigentlich Adobe seine eigenen Entwickler ohrfeigt
adobe r.i.p.
Die Erweiterung von Betriebssystemen oder anderen Drittanbieterprodukten oder -geräten, wie dem iPhone oder iPad wird schwieriger für unsere Produkte wodurch unsere Nutzer gewogen sein könnten, andere Technologien zu benutzen, was unser Geschäft beeinträchtigen würde.
Adobe hat heute öffentlich bekannt gegeben, dass sie ein wirtschaftliches Problem mit Apple haben. Insbesondere haben sie ein Problem mit der Tatsache, dass Apple kein Flash mag. Denn Adobe mag Flash. Lange Zeit war Adobe sogar davon überzeugt, dass man mit Flash Geld verdienen könne. Unklar bleibt allerdings, warum sie es nie getan haben. Im Verkauf von X-Trillionen CS[x]-Lizenzen war kein Sex.
ipad ist da – deutsche verlagsbranche schläft noch tief und fest
Für die Frontend-Designer und -Entwickler der großen Publisher wird die nächste Woche anstrengend. Einige Manager von Axel Springer, der WAZ-Gruppe und Gruner & Jahr halten wahrscheinlich schon ihr iPad in den Händen und rufen – nach facebook – ihr Lieblings-’Produkt’ auf. Und was sie dort sehen wird ihnen nicht gefallen.
pre-roll für html5 video tag
Das iPad wirft einen großen Schatten voraus. Am 3. April wird plötzlich eine hochkarätige Userschaft auf die Seiten der Publisher und Broadcaster surfen und erschrocken feststellen, dass alles stumm ist und eine festgemeisselte Buchstabenwüste sie zum lesen der Inhalte zwingt. Es kann kein Flash *KREISCH*! So wundert es nicht, dass sich NYT und Fox gezwungen sehen, eine Alternative für Flash anzubieten damit die iPad-Nutzer nicht auf bewegte Bilder verzichten müssen. Allerdings haben sie und auch alle Flash-Player-Anbieter ein erhebliches Problem: Pre-/Mid-/Post-Roll oder überhaupt Playlisten sind im HTML5-Standard nicht vorgesehen.
Da denke ich mir so: HTML5, Video-Tag, src-Attribut, Events? Und die Antwort sind 8 Zeilen JavaScript-Code. Nur als Proof-of-Concept und nicht zur Produktion gedacht (blödes Time-Out-Handling, ich weiss…). Aber das Script macht auch nichts weiter, als zu überprüfen, ob die Werbung durchgelaufen ist und wenn das der Fall ist, den Hauptfilm zu laden. Mit ein wenig Arbeit könnte man auch noch zwischendurch Werbung schalten und ein Banner wäre natürlich auch kein Problem.
