MOV in GIF umwandeln

In vielen deutschen Firmen läuft die interne Fehlererfassung über ein System, dessen Kommentarfeld ein Video zwar annimmt, aber nicht abspielt — es zeigt nur einen Downloadlink, den außer der Person, die ihn setzt, kaum jemand anklickt. Ein GIF dagegen läuft direkt im Kommentar an, ohne einen einzigen Klick, und genau deshalb wird ein kurzer Bildschirmmitschnitt oder ein am Telefon gefilmter Fehler dorthin oft als GIF eingefügt.

Ein iPhone oder eine Kamera liefert das aber als MOV, und dazwischen liegt der eigentliche Grund für diese Seite: nicht ein defektes Video, sondern zwei Formate, die aneinander vorbeireden, bis eines von beiden umgewandelt wird.

Das ist der Rat, der am meisten bringt, und er ist keine Einstellung auf dieser Seite. Die Bilder werden immer vom Anfang der Datei genommen, ohne Möglichkeit, einen Startpunkt zu setzen — und ein am Telefon gefilmter Clip beginnt fast immer mit einer Hand, die sich vom Auslöser entfernt, und einer halben Sekunde des Falschen im Bild.

Die Fotos-App am iPhone kürzt einen Clip in etwa zehn Sekunden, ohne ihn neu zu kodieren, per Ziehen an zwei Reglern; unter Windows funktioniert die Fotos-App genauso. Auf den Moment zugeschnitten, der den Fehler tatsächlich zeigt, wird alles andere auf dieser Seite leichter — die Datei ist kleiner, die Zehn-Sekunden-Voreinstellung hört auf, eine Einschränkung zu sein, und die Schleife landet auf dem richtigen Bild.

Der Abstand ist hier größer als bei jeder anderen Quelle auf dieser Seite. Ein aktuelles iPhone zeichnet 4K bei 30 oder 60 Bildern pro Sekunde auf — 3840 Pixel breit, bis zu sechzig vollständige Bilder pro Sekunde, in einem Codec, der die meisten Bilder nur als kleine Unterschiede zum vorherigen beschreibt. Das GIF, das dabei herauskommt, ist 480 Pixel breit bei zwölf Bildern pro Sekunde, jedes Bild vollständig gespeichert und auf 256 Farben begrenzt.

Das ist keine übervorsichtige Voreinstellung, sondern die Grenze des Formats: GIF wurde 1987 für ein paar hundert Pixel große Bilder definiert, kennt keine Bewegungskompensation und keine über eine Sequenz geteilte Palette. Zwölf Bilder pro Sekunde sind die niedrigste Rate, die noch als Bewegung wirkt, 480 Pixel passen in ein Kommentarfeld, und zehn Sekunden sind der Punkt, an dem die Dateigröße unangenehm wird.

Ein Telefon zeichnet die Bilder im Querformat auf und speichert dazu einen Vermerk, wie es gehalten wurde. Dieser Vermerk wird beim Einlesen berücksichtigt, ein hochkant gefilmter Clip wird also zu einem hochkant stehenden GIF und nicht zu einem seitlich liegenden Querformat.

Das ist nicht selbstverständlich — etliche Werkzeuge, die GIFs aus Video erzeugen, ignorieren die Drehung, und das Ergebnis liegt dann auf der Seite, was oft dem Telefon oder der filmenden Person angelastet wird, obwohl es am Werkzeug liegt. Der einzige Nebeneffekt hier ist die Dateigröße: Ein hochkantes GIF bei derselben Breite hat pro Bild mehr Pixel als ein querformatiges, etwa 480 mal 854 statt 480 mal 270.

Die drei Einstellungen multiplizieren sich fast genau miteinander. Die Bildrate von zwölf auf vierundzwanzig zu verdoppeln verdoppelt die Zahl der vollständigen Bilder und ungefähr auch die Dateigröße. Von 480 auf 800 Pixel Breite zu gehen entspricht etwa dem 2,8-Fachen der Fläche und landet nah daran auch bei den Byte.

Die günstigste Verbesserung ist deshalb fast nie die Bildrate. Zwölf Bilder pro Sekunde wirken bei allem außer schnellen Schwenks flüssig genug, und dasselbe Budget in die Breite gesteckt macht Text lesbar und ein Gesicht erkennbar. Mit der Voreinstellung anfangen, das Ergebnis ansehen, dann eine Sache ändern.

Die Längeneinstellung akzeptiert bis zu sechzig Sekunden, dahinter liegt eine feste Grenze von 600 Bildern. Bei der Standardrate von zwölf Bildern pro Sekunde sind das fünfzig Sekunden, bei vierundzwanzig sind es fünfundzwanzig. Wird mehr angefragt, ist das GIF einfach kürzer als verlangt, ohne Fehlermeldung.

Der Grund ist, dass der Encoder alle Bilder im Speicher hält, während er arbeitet, und ein Browser-Tab bei einer sehr langen Sequenz vorher an seine Grenzen stößt. In der Praxis greift die Grenze selten, weil ein GIF, das lange genug dafür wäre, ohnehin zu groß für einen Ticket-Kommentar wäre.

Ein GIF-Bild verweist auf höchstens 256 Farbeinträge. Hier wird die Palette für jedes Bild einzeln berechnet statt einmal für den ganzen Clip — das kostet etwas Größe, ist aber die einzige Variante, die echtes Filmmaterial übersteht, denn eine einzige globale Palette würde alles nach einem Schnitt in den Farben des vorherigen Bildes darstellen.

Ein Dithering findet nicht statt. Es würde Bandbildung verstecken, zerstört aber auch die Ähnlichkeit zwischen aufeinanderfolgenden Bildern, auf der die Kompression eines GIFs beruht — ein gedithertes GIF aus Video wäre deutlich größer. Sichtbar wird das bei Verläufen: ein Himmel, eine gestrichene Wand, eine Wange in weichem Licht zeigen Streifen. Strukturiertes Material — Gras, Stoff, ein unruhiger Raum — versteckt den Effekt fast vollständig.

GIF hat nie eine Tonspur gehabt. Bei einem Bildschirmmitschnitt ist das meist nebensächlich, bei etwas am Telefon Gefilmtem häufig nicht — ein Klick, ein Fehlerton, eine gesprochene Erklärung machen manchen Clip erst verständlich.

Den Clip einmal ohne Ton ansehen, bevor er umgewandelt wird. Funktioniert er trotzdem, ist das GIF die richtige Wahl. Wenn nicht, ist das Ziel eher zu ändern als das Format — viele Ticketsysteme und Chat-Werkzeuge akzeptieren inzwischen auch einen direkten MP4-Upload, selbst wenn sie GIFs im Vorschaubild bevorzugt anzeigen, und ein MP4 desselben Clips ist kleiner, schärfer und hörbar.

Wirkt das erste Ergebnis zu grobkörnig oder zu klein, lohnt sich selten die Feinarbeit an den Reglern — meist lohnt sich ein zweiter Clip mehr. Etwas näher heranfilmen, damit weniger vom Bild für den eigentlichen Fehler übrig bleiben muss, oder das Motiv ruhiger halten, damit die Palette pro Bild nicht ständig neu justiert werden muss, verändert das Ergebnis stärker als jede Kombination aus Breite, Bildrate und Länge.

Das gilt besonders für einen Fehler, der sich reproduzieren lässt: Ein zweiter Versuch mit fester Kamera, gutem Licht und einem kurzen, klar abgegrenzten Ausschnitt liefert fast immer ein lesbareres GIF als der erste, spontan mit der Hand gefilmte Take, egal wie viel an den drei Reglern nachjustiert wird.

Überall dort, wo eine Fläche ein Bild rendert und einen Videoplayer ablehnt: ein Wiki, das nur Bilder erlaubt, eine README ohne eigenen Player, ein Ticketsystem, dessen Vorschau nur Bilder verarbeitet, ein Chat, der GIFs automatisch abspielt und Video nicht. Dort schlägt ein GIF, das ohne Klick läuft, jedes Video, das niemand öffnet.

Überall sonst liefert derselbe Clip als MP4 eine Datei, die vielleicht ein Zwanzigstel so groß ist, mit allen Farben und dem Ton. Es lohnt sich, kurz nachzuschauen, was das Ziel tatsächlich unterstützt, bevor Zeit in die Palette gesteckt wird — die Antwort hat sich auf den meisten Plattformen in den letzten Jahren geändert.

Ein Bildschirmmitschnitt aus einer internen Anwendung — der eigentliche Klassiker für ein Ticketsystem — hat oft große, ruhige Flächen: ein Fensterhintergrund, eine Toolbar, die sich über Sekunden nicht ändert. Genau das komprimiert ein GIF gut, weil sich von Bild zu Bild wenig unterscheidet, selbst ohne die Bewegungskompensation, die ein Videoformat hätte.

Ein am Telefon gefilmter Fehler ist das Gegenteil: Kamerawackeln, wechselndes Licht, ein bewegter Hintergrund — jedes einzelne Bild unterscheidet sich vom vorherigen stärker, und die Palette muss entsprechend öfter neu justieren. Zwei Clips gleicher Länge und gleicher Auflösung können deshalb sehr unterschiedlich groß werden, je nachdem, ob eine Bildschirmaufnahme oder eine Handykamera dahintersteckt.

Jeder Schritt läuft lokal: Die MOV-Datei wird demuxt, die Bilder werden vom eigenen Videodecoder des Geräts dekodiert, jedes wird auf seine Palette reduziert, und das GIF wird im Arbeitsspeicher zusammengesetzt. Nichts, was den Clip enthält, wird dabei verschickt — im Netzwerk-Tab lässt sich das während der Umwandlung nachprüfen.

Die übliche Alternative ist, das Video auf einer Website hochzuladen, die das Ergebnis auf der eigenen Domain behält und einen Link ausgibt — ein Fehlerclip aus der internen Software liegt dann auf einem fremden Server mit einer URL, die sich erraten lässt. Für ein Ticket, das interne Bildschirminhalte, Kundendaten oder Zugangsdaten im Hintergrund zeigt, ist das ein Risiko, das sich völlig vermeiden lässt. Hier entsteht stattdessen eine Datei, und es ist die einzige Kopie davon.