Cargolifter / Tropical Islands

Alle Jubeljahre fahre ich mit dem Mountainbike mal durch die Krausnicker Berge. Oben auf dem Wehlaberg steht seit 2003 ein Aussichtsturm, der einen schönen Blick auf die nur wenige Kilometer entfernte imposante Cargolifter-/Tropical Islands-Halle bietet.

Bei guter Sicht erkennt man von dort sogar die Wasserdampf-Wolken aus den Kühltürmen des über 90 km entfernten Kraftwerks Boxberg. Hier gibt’s noch einige Bilder aus dem Jahr 2007, die bei sehr guter Sicht gemacht wurden.

Cargolifter-/Tropical Islands-Halle

RSS: Der Weg von Google Reader zum Selbsthosting

Jahrelang ging in Sachen RSS eigentlich kein Weg am Google Reader vorbei: die zentrale Sammelstelle für RSS-Feeds bot zum einen ein sehr gutes Webinterface. Zum Anderen gab es – ganz Google-typisch – ein API, mit welchem alle möglichen RSS-Reader-Apps sprachen. So war es möglich seine Feeds am Desktop direkt im Google Reader „abzuarbeiten“ und dann unterwegs nahtlos z. B. in Reeder auf dem iOS-Gerät weiterzulesen.

Google entschied sich dann, den Google Reader zum 1. Juli 2013 abzuschalten. Die Benutzungszahlen waren wohl rückläufig und das Produkt erwirtschaftete vermutlich nicht ausreichend Umsatz*. Nun standen wir™ also da.

Innerhalb kürzester Zeit nach Googles Ankündigung wurden dann die möglichen Alternativen zusammengetragen (natürlich las ich über die meisten in meinen Feeds im Google Reader…). Dienste wie Feedly, Feedbin, Feed Wrangler und mehr standen nun zur Ablösung des Google Reader bereit. Auch Fever als selbst gehostete Variante war wieder eine Option.

Fever hatte aber auch 2013 noch das selbe Problem wie 2009 (schon damals hatte ich meine Lizenz gekauft): Es war ausschließlich im Webbrowser zu benutzen. Fever hatte zwar mittlerweile ein API bekommen, aber keiner der bekannten RSS-Client-Apps unterstützte diese. Schon gar nicht mein damals favorisierter RSS-Reader Reeder.

So wechselte ich vom Google Reader zu Feedly. Zum Glück hatten nämlich Feedly und die anderen Dienste das Potenzial erkannt und begannen Google Reader-kompatible APIs zu bauen. Und die App-Entwickler begannen gleichzeitig den Support für alternative APIs einzubauen. So dauerte es nicht sehr lange, bis Programme wie Reeder auch mit Feedly und Konsorten sprechen konnten.

Feedly war dann auch über ein Jahr meine RSS-Feed-Zentrale. Vor Kurzem bekam ich zufällig mit, dass Reeder* zwischenzeitlich auch etwas mit dem API von Fever anfangen kann und so probierte ich es noch mal. Und siehe da – es funktioniert genauso problemlos wie all die Jahre mit Google Reader und zuletzt mit Feedly.

Ich habe mir bei Feedly meine RSS-Abonnements als OPML-Datei ex- und diese bei Fever wieder importiert. Das ging alles sehr schnell und genau so schmerzfrei wie vor einem guten Jahr der Umstieg von Google Reader zu Feedly.

Mein Feed-Aggregator ist jetzt also seit einigen Wochen selbstgehostet und ich habe Feedly seitdem nicht eine Sekunde vermisst. Mein Account bei Feedly ist mittlerweile auch schon gelöscht.


Ich glaube Google Reader hatte nie Werbung eingeblendet; es dürfte also ein reines Verlustgeschäft für Google gewesen sein – zumindest finanziell

oder zwischenzeitlich neu erschienene RSS-Reader wie z. B. der sehr schöne Unread

FFmpeg beim Erstellen von Standbildern auf die Beine helfen

Um in einem Videoplayer Vorschaubilder beim Bewegen der Maus über die Zeitleiste anzuzeigen, erstellt man vom jeweiligen Video ausreichend viele Standbilder und gibt diese dem Videoplayer zeitcodiert mit.

Das Erstellen eines Standbildes kann mit FFmpeg (bzw. avconv unter debianoiden Linuxen) relativ einfach erledigt werden:

ffmpeg -y -i videofile.mp4 -ss 10 \
-f image2 -s 1280x720 -vframes 1 \
-threads auto -an screenshot.jpg

FFmpeg bekommt in diesem Beispiel mit mit dem Argument -ss 10 gesagt, im Video zum Zeitpunkt 10 Sekunden „vorzuspulen“ (im Sinne von „den ganzen Film decoden und an der entsprechenden Stelle anhalten“) und ein Standbild dieser Stelle abzuspeichern. Ist der Zeitpunkt nah am Anfang des Videos geht das recht schnell. Je weiter sich der Zeitpunkt vom Start entfernt, desto länger dauert der ganze Vorgang; wir reden hier von etlichen Sekunden schon bei relativ kurzen Videos von wenigen Minuten Länge. Wenn man jetzt z. B. 80 dieser Bilder aus einem Video benötigt, dauert das schnell mal an die 10 Minuten. Und wenn man dann nicht nur eins, sondern rund 30.000 Videos hat, wird’s schnell ungemütlich.

Zum Glück gibt es einen Trick, wie ich gestern gelernt habe: Fast-Seeking.

Hierbei springt FFmpeg an den dem Zeitstempel am nächsten liegenden Keyframe, von dort zum gewünschten Zeitstempel und erzeugt dann den Screenhot. Sehr praktisch und für den gegebenen Anwendungsfall absolut ausreichend.

ffmpeg -y -ss 10 -i videofile.mp4 \
-f image2 -s 1280x720 -vframes 1 \
-threads auto -an screenshot.jpg

Was hat sich im Befehl geändert? Lediglich die Position des Arguments -ss 10: Steht dieses vor dem Input-Argument (-i) aktiviert FFmpeg das Fast-Seeking. Wer möchte kann auch eine Kombination von Slow- und Fast-Seeking einsetzen (das nennt sich dann Combined Seeking), die Details kann man auf der Wiki-Seite nachlesen.

Damit war es möglich die Dauer für das Extrahieren der 80 Screenshots eines Videos von 10 Minuten auf 5 Sekunden zu reduzieren. Es liegen immerhin rund zwei Größenordnungen zwischen den Werten – damit sind dann auch 30.000 Videos durchaus in vertretbarer Zeit abzuarbeiten.

OS X und das Terminal – The Good Parts

Craig Hockenberry veröffentlichte einen umfangreichen Artikel zur Kommandozeilen-Arbeit unter OS X. Er vermittelt hauptsächlich Terminal- und Shell-Grundlagen, was aber nicht bedeutet, dass ein gestandener Unixer (der seine Terminal-Zeit vielleicht eher auf Linux-Maschinen denn unter OS X verbringt) hier nicht noch etwas lernen kann. Sollte man sich bookmarken, was ich hiermit auch tue :-)