Schlagwort-Archive: web

Google begräbt H.264 (im Internet)

Und das meine ich genau so provokativ wie es dort in der Überschrift steht. Wie sie das machen/gemacht haben und warum das gut ist folgt in den nächsten Absätzen. Ich werde nicht auf technische Details eingehen und manches geschriebene wird dem ein oder anderen sauer aufstoßen, schlicht falsch sein, oder nicht alle Seiten der Geschichte gleichmäßig beleuchten. Auch ein wenig Polemik ist sicher dabei. Lasst eurem Ärger freien Lauf und verbessert mich wo ihr nur könnt. Aber vor allem: Informiert euch, nicht nur hier, sondern auch an anderer Stelle.

Worum geht es?

Das Web, bzw. die Seiten darin sind (zum Großteil) in HTML geschrieben, eine Auszeichnungssprache, die Text so verpackt, dass er von z.B. Browsern formatiert dem Nutzer präsentiert werden kann. Der Standard bisher dafür ist HTML Version 4. An der neuen Version dieses Standards in Version 5 wird zur Zeit gearbeitet, sie ist aber auch schon in einigen Browsern integriert und kann dort genutzt werden. Ein Bestandteil, den HTML4 bisher vermissen ließ ist das Darstellen von Audio und Video ohne den Zwischenschritt über den Flash-Player. So werden mit HTML5 Videos direkt in Webseiten einbettbar sein, und ohne zusätzliches Plugin abspielbar werden. Für diesen Zweck braucht es einen (oder auch mehrere) Video-Codecs, die in einen Browser integriert sein müssen, damit dieser das Video abspielen kann.

Der Stein des Anstoßes: H.264/MPEG-4 AVC

H.264 ist ein Video-Codec. Ein sehr effizienter noch dazu. Eingesetzt wird er in vielen Bereichen, zum Beispiel ist er einer der drei erlaubten Video-Codecs für Blu-ray-Discs und für das aussenden über DVB ist er seit 2004 ebenfalls zugelassen. Apple als ein großer Verfechter dieses Codecs verwendet ihn für alle aktuellen Plattformen, speziell in Safari und Safari-Mobile, also den Standard-Browsern auf Mac und iOS-Devices. Aber auch Microsoft und Google integrieren ihn im Internet Explorer bzw. Chrome.

Unbeliebt macht diesen Codec allerdings der Umstand, dass man unter bestimmten Umständen Abgaben dafür zahlen muss, will man ihn verwenden. Gerade für Hersteller quelloffener Browser, wie das Paradebeispiel Firefox eine kaum zu überwindende Hürde. Das Geld dafür könnte man sicher aufbringen (sogar Microsoft hat sich da als ein Art Sponsor angeboten und ein H.264 Plugin für Firefox unter Windows veröffentlicht), die Implementierung von H.264 würde sich allerdings arg mit der Philosophie, die hinter Firefox steht, beißen.

Jetzt mag mancher, der sich mit dem Thema am Rande schonmal beschäftigt hat, sagen: "Aber H.264 ist doch jetzt Lizenzkostenfrei."

Das ist soweit auch richtig, die MPEG LA (die Firma die sich um das Eintreiben von Lizenzgeldern für den Großteil der MPEG-Codecs kümmert) hat gesagt, dass H.264 bis zum Ende der Laufzeit der aktuellen Lizenz kostenfrei für die Benutzung im Web bleibt. Was die wenigsten wissen: Diese Lizenz kann alle fünf Jahre geändert/erneuert werden (siehe AVC/H.264 FAQ). Zudem gilt dies wie gesagt nur für freies Internet Video, nicht aber für De-/ und Encoder und auch nicht für Inhalte für die der Endkunde Geld zahlt.

Das mag mancher nicht als so kritisches Problem sehen, aber für das Netz als freies Informationsmedium ist ein mit Patenten hinterfütterter Codec wie H.264 alles andere als nützlich, vielleicht sogar schädlich.

Das Begräbnis

Google hat im Mai letztes Jahr dem Netz einen neuen freien Codec "geschenkt". WebM. WebM soll als der Videocodec für das Netz in Browsern, Settop-Boxen, eigentlich allem das ans Internet angeschlossen werden kann verfügbar gemacht werden um Video direkt und ohne die zu Hilfenahme von Flash abgespielt werden. Der entscheidende Vorteil an WebM? Der Codec ist frei (BSD-Style), und wird es auch bleiben. Das heißt jeder, der möchte kann Inhalte (egal ob kostenlose oder zu bezahlende), De- und Encoder, Hardware (wie Settop-Boxen und Kühlschränke) in der Welt verbreiten ohne das jemand dafür Geld verlangt oder verlangen wird.

WebM ist bisher in Google Chrome (bzw. Chromium), Firefox 4 (zur Zeit in der Betaphase), Opera (ab 10.60) und sogar im Internet Explorer (ab Version 9) implementiert. Die Liste der Unterstützer ist angenehm lang, und mit einigen Big-Playern des Internets das wir heute kennen gespickt. Zusätzlich hat Adobe angekündigt, dass auch Flash WebM als Video-Codec implementieren wird.

Das alles waren aber nur die Vorbereitungen zur eigentlichen Beerdigung. Die erfolgte gestern (11.01.11) mit Googles Ankündigung H.264-Unterstützung aus Google Chrome zu entfernen. Damit werden laut aktuellen Statistiken aber Mitte des Jahres (den Rausschmiss von H.264 aus Chrome, die Releases von Firefox 4 vorrausgesetzt) der Großteil der bei den Nutzern installierten Browser WebM, aber nicht H.264 unterstützen. Safari wird zu diesem Zeitpunkt der einzige Browser (mit nennenswerter Verbreitung) sein, der WebM nicht unterstützt.

Einige Informierte werden jetzt mit dem Argument kommen, dass WebM mit Sicherheit auch bald mit Patentverletzungen bombardiert werden wird. Vermutlich richtig, aber ich denke Google wird sich das Ding sicher nicht ans Bein gebunden haben, ohne über so etwas genug Gedanken verschwendet zu haben.

Die anderen werden sagen, dass WebM gegenüber H.264 gewaltig im Hintertreffen ist. Das mag ebenso wahr sein, zumindest in einigen Fällen, aber bevor x264 aufgetaucht ist war H.264 zu encodieren auch nicht gerade ein Spass für die ganze Familie. WebM wird wachsen und die Liste der Unterstützer läßt mich optimistisch sein.

Der Beerdigungskaffee

Viele mögen es nicht gut finden das Google diesen Weg geht, vielleicht weil sie vor kurzem ihr komplettes Video-Archiv auf H.264 umgestellt haben, oder weil sie ein scheißteures iPhone gekauft haben und damit bald kein Youtube mehr schauen können (Bitte Ruhe bewahren liebe Fanboys, alles nur Spaß). Wiederum andere werden den Tag kaum erwarten können, an dem das H.264-freie Release von Chrome übers Auto-Update geflogen kommt. Veränderungen sind in den meisten Fällen mit Schmerzen verbunden, und auch diese wird einigen weh tun, aber manchmal sind die Schmerzen es einfach wert getragen zu werden.

WebM mag nicht der Weisheit letzter Schluss sein, ich sehe WebM eher als einen Start in ein besseres, freieres Netz, und vielleicht auch als einen Anreiz für andere freie Codecs zu produzieren.

Wie auch immer, ich finde heute ist ein guter Tag für das Netz, seine Benutzer und vor allem für die freie Verbreitung von Inhalten. Punkt.

Lighttpd mit vHosts unter Ubuntu Hardy

Seit einiger Zeit tendiere ich dazu Lighttpd dem guten alten Apachen vorzuziehen. Hauptgrund dafür ist aber weniger die immer wieder hervorgehobene bessere Performance (nicht umsonst setzen z.B. YouTube und MySpace auf den Ultraleichtflieger), sondern das mir die Konfiguration einfach etwas unkomplizierter erscheint als beim, vielleicht etwas mächtigeren, aber dafür auch unübersichtlicheren Apachen. Eigentlich auch egal, denn jeder sollte ja selbst entscheiden wem er den Vorzug gibt.

Eingerichtet wird Lighty hier mit PHP 5 und dem Modul 'simple_vhost', mit dem sehr einfach mehrere virtuelle Hosts angelegt werden können.

Wenn wir fertig sind, werden die Seiten unter folgender Ordner-/Dateistruktur organisiert sein:

/var/www/servers - quasi das Hauptverzeichnis des Webservers, hierin werden die virtuellen Hosts angelegt

/var/www/servers/example.com - Ein Beispiel für einen virtuellen Host

/var/www/servers/example.com/htdocs - Hier landen die Dateien, die beim Aufruf von "http://example.com" angezeigt werden sollen

/var/www/servers/example.com/logs - Hier werden die Logdateien gesammelt

/var/www/servers/example.com/server.conf - In dieser Datei wird die Konfiguration für den Host vorgenommen

So, aber nun direkt rein ins Getümmel und die Installation starten:

Installieren

  1. sudo apt-get install lighttpd php5-cgi

Module aktivieren

Danach werden die oben angesprochenen Module aktiviert ('fastcgi' wird für die Anbindung an PHP benötigt):

  1. sudo lighty-enable-mod fastcgi
  2. sudo lighty-enable-mod simple-vhost

Nach einem 'sudo /etc/init.d/lighttpd force-reload' sollte der der Webserver bereits unter http://localhost erreichbar sein.

Lighttpd Testseite

Konfiguration von mod_simple_vhost

Ausgegangen von der oben erklärten Ordnerstruktur müssen die drei Optionen des 'mod_simple_vost' in der Datei '/etc/lighttpd/conf-available/10-simple-vhost.conf' folgendermaßen konfiguriert werden:

  1. simple-vhost.server-root = "/var/www/servers/"
  2. simple-vhost.document-root = "/htdocs/"
  3. simple-vhost.default-host = "example.com"

Anstatt 'example.com' muss dort natürlich eure Standarddomain stehen!

Danach sollten die angelegten vHosts unter der jeweiligen Domain erreichbar sein.  Dazu ein kleines Beispiel:

Wenn im Browser die Adresse 'http://zeroathome.de/dingsbums.html' aufgerufen werden würde, würde das zur Anzeige der Datei '/var/www/servers/zeroathome.de/htdocs/dingsbums.html' führen.

Nach einem '/etc/init.d/lighttpd force-reload' können neue vHosts unterhalb von '/var/www/servers/' angelegt werden.

Konfiguration der einzelnen vHosts

Problem bei dieser Variante der vHost-Konfiguration ist, dass die Konfiguration der einzelnen Hosts nicht so einfach ist. Doch Opensource wäre nicht was es ist, wenn es nicht auch dafür eine relativ einfache Lösung gäbe. (Die Grundversion stammt übrigens von hier, wurde von mir nur leicht angepasst: http://redmine.lighttpd.net/projects/lighttpd/wiki/HowToSupportConfigurationPerVirtualHost)

Dazu wird die folgende Zeile in die Datei '/etc/lighttpd/conf-available/10-simple-vhost.conf' eingefügt, die dazu führt das ein kleines Skript ausgeführt wird:

  1. include_shell "/var/www/servers/config_servers"

Anschließend wird die Datei '/var/www/servers/config_servers' angelegt und mit diesem Inhalt befüllt:

  1. #!/bin/bash
  2.  
  3. for VHOST in `find /var/www/servers/ -mindepth 1 -maxdepth 1 \( -type d -or -type l \) -exec test -e "{}/server.conf" \; -exec basename "{}" \; 2>/dev/null` ; do {
  4. echo "\$HTTP[\"host\"] == \"$VHOST\" {"
  5. echo "var.vhost_name = \"$VHOST\""
  6. echo "var.vhost_path = \"/var/www/servers/$VHOST\""
  7. cat "/var/www/servers/$VHOST/server.conf"
  8. echo "server.errorlog = \"/var/www/servers/$VHOST/logs/error.log\"",
  9. echo "accesslog.filename = \"/var/www/servers/$VHOST/logs/access.log\""
  10. echo "}"
  11. } ; done

Zu guter Letzt wird die Datei noch ausführbar gemacht:

  1. sudo chown www-data:www-data /var/www/servers/config_servers
  2. sudo chmod u+x /var/www/servers/config_servers

Dann natürlich noch ein '/etc/init.d/lighttpd force-reload' und die neue Konfiguration ist übernommen.

Die Konfigurationsdatei muss dann, wie oben bereits erwähnt unter '/var/www/servers/example.com/server.conf' liegen um berücksichtigt zu werden. Nachdem eine neue Konfigurationsdatei hinzugefügt wurde oder eine vorhandene geändert wurde, muss immer ein '/etc/init.d/lighttpd force-reload' erfolgen, sonst ist die Konfiguration nicht wirksam!

Fertig!

So, das wars bereits. Ein Grundkonfigurierter Lighty fertig für die Arbeit als lokaler oder Internet-Webserver. Wenn gewünscht gibts demnächst noch einige Erweiterungen, wie zum Beispiel SSL oder WebDAV.

Alle Angaben natürlich wie immer ohne Gewähr und alles auf eigene Gefahr und so!

Meine Top 5 Web Applikationen

Hier kommen mal die Top 5 meiner Lieblingswebapplikationen, also diejenigen Applikationen, die man (theoretisch) von jedem Ort dieser Welt aus bedienen kann, vorrausgesetzt der Ort verfügt über einen Internet-Zugang und einen geeigneten Browser.

Remember The Milk

Da wäre zunächst Remember The Milk, schnell umschrieben eine To-Do-Liste auf Steroiden. Zusammen mit dem Firefox-Addon zur Integration in Google Mail für mich die kompletteste To-Do-Liste, die man derzeit im Web finden kann. Ausserdem gibt es Unterstützung für

  • Google Calendar
  • iGoogle
  • iPhone/iPod touch
  • Blackberry/Windows Mobile (nur mit kostenplichtigem pro-Account)
  • mobile Browser (z.B. auf Handys)

Einen Überblick über alle Funktionen von Remember The Milk gibt es hier.

Instapaper

So einfach wie Instapaper auch gestrickt ist, so genial ist es auch. Über ein Bookmarklet im Browser lassen sich Seiten, für die man gerade keine Zeit hat sie zu lesen, fürs spätere Lesen aufbewahren. Ursprünglich für das iPhone entworfen sollte Instapaper aber auch in allen anderen Javascript-fähigen Browsern funktionieren. Klein aber fein, kann man da nur sagen.

delicious

Ich denke über delicious.com brauche ich nich allzu viele Worte zu verlieren. So gut wie jeder kennt den Social-Bookmarking Service. Zusammen mit der Firefox-Erweiterung (Tools für andere Browser sind ebenfalls vorhanden) ein gutes Tool um seine Bookmarks auf verschiedenen Rechnern benutzen zu können. Oder eben auch um neue interessante Seiten zu finden, Social Bookmarking eben 😉

Google Apps

Definitiv meine meistgenutzte Applikations-Gruppe. Man mag ja zu Google stehen wie man möchte, aber die Kombination von Mail-Client, Kalender, Feed-Reader und Dokumenten-Verwaltung ist für mich im Moment nich mehr wegzudenken. Mein kompletter Mail-Verkehr läuft über GMail, natürlich mit Backup zu Hause. Meine Termine verwalte ich mit Google Calendar in Kombination mit Remember The Milk. Mit dem Google Reader kann ich von jedem Rechner aus meine Feeds durchblättern und mich nicht durch tausende ungelesene Nachrichten wühlen wenn ich mal ein paar Tage vom heimischen Rechner getrennt bin. Google Docs ist mit Sicherheit (noch) keine vollständige Office-Suite wie OpenOffice.org z.B. aber für den Standard-Kram reicht es allemal. Auch die Möglichkeit der Kollaboration an Dokumenten ist ein guter Grund Google Docs mal zu testen.

Daneben gibt es natürlich noch einige andere Dinge in der Google-Welt, wie zum Beispiel Google Maps und das Google Notebook, das ich allerdings nicht so sehr gelungen finde bisher, da gibt es deutlich bessere Alternativen.

soup.io

Ein Anbieter für Tumblelogs, also kleine Blogs (aber auch wieder kein Microblogging), auf denen einzelne Bilder, Links und ähnliches schnell gepostet werden können. Bei mir dient soup.io hauptsächlich als Linkblog in dem verschiedene Dienste zusammenlaufen. Unter anderem meine Shared Items aus dem Google Reader, meine Delicious Links, meine Unreads bei Instapaper. Quellen können im RSS-Format beliebig hinzugefügt werden, oder man kann eben manuell Posts hinzufügen (praktischerweise über ein Bookmarklet)

Und jetzt noch eine kleine Challenge: Versucht mal auf der "Jetzt auf Soup"-Seite von soup.io (oben auf "Jetzt auf Soup" klicken) nach ganz unten zu scrollen...wers schafft bekommt ein Eis (oder vll doch lieber eine heiße Schokolade, bei dem Wetter)!

Und ihr?

Irgendwelche Ergänzungen eurerseits? Irgendwas was ich auf jeden Fall mal testen sollte? Her damit! Am besten per Kommentar, per Jabber (zeroathome@jabber.ccc.de) oder per identi.ca (http://identi.ca/zero)