Ein Video um 90° oder 180° drehen: das Flag oder die Pixel

Zwei Vorgänge, die gleich aussehen und es nicht sind

Eine Videodatei lässt sich auf zwei Arten drehen. Die erste schreibt eine kleine Anweisung in den Container — eine Display-Matrix in der MP4- und QuickTime-Familie —, die sagt: „Zeige dies um 90 Grad gedreht.“ Die Pixel bleiben unberührt, der Vorgang dauert so lange, wie ein paar Dutzend Byte neu zu schreiben, und er ist vollständig umkehrbar. Die zweite dekodiert jedes Bild, verschiebt die Pixel und komprimiert sie erneut. Das dauert Minuten statt Millisekunden, kostet eine Generation verlustbehafteter Kompression und lässt sich nicht rückgängig machen.

Der Haken am Flag ist, dass es nur ein Ratschlag ist. Ein Player muss den Container lesen, die Matrix finden und sie anwenden, und nicht jeder tut das. Web-Player befolgen es uneinheitlich, manche Schnittprogramme importieren die rohen Bilder und ignorieren die Anweisung, manche Receiver und ältere Fernseher haben sie nie gelernt, und einige Werkzeuge wenden sie ein zweites Mal an, obwohl der Player es schon getan hat — so landet ein Clip kopfüber. Das Flag ist sofort da, verlustfrei und wird manchmal missachtet; die Neukodierung ist langsam, verlustbehaftet und wird immer befolgt. Einen dritten Weg, der beides wäre, gibt es nicht.

Dieses Werkzeug hat den zweiten Weg bewusst gewählt und sagt es in einer Zeile unter seinen Bedienelementen: Die Drehung wird ins Bild selbst geschrieben, nicht in ein Flag, das manche Player ignorieren und andere doppelt anwenden — deshalb wird neu kodiert. Das ist eine ehrliche Beschreibung des Codes. Die Tabelle unten zeigt den Handel vollständig, damit du dich entscheiden kannst, bevor du die Minuten investierst.

Dein querliegender Handyclip braucht vielleicht gar keine Drehung

Das ist der häufigste Grund, weshalb Leute bei einem Drehwerkzeug landen, und meist die falsche Reparatur. Ein Telefon nimmt mit fest eingebautem Sensor auf und schreibt ein Rotations-Flag, das beschreibt, wie du es gehalten hast. Die Datei ist also korrekt: Die Pixel liegen im Querformat, das Flag sagt „Vierteldrehung“, und jede Anwendung, die das Flag liest, zeigt das Video aufrecht. Zeigt eine Anwendung es quer, ist diese Anwendung im Unrecht, nicht die Datei.

Das Werkzeug zeigt das vorhandene Flag nicht an, und das ist die nützlichste fehlende Funktion. Es liest die Maße des Clips aus einem versteckten Videoelement der Seite, und Browser melden diese Maße bereits nach Anwendung der Drehung — ein Hochformat-Handyclip erscheint also als Hochformat, völlig richtig, ohne dass irgendetwas sagt, ob das an den Pixeln liegt oder an einem Flag. Von innen lässt sich beides nicht unterscheiden. Prüfe es draußen: Öffne den Clip in zwei verschiedenen Playern. Zeigt einer ihn aufrecht und der andere quer, gibt es ein Flag, die Datei ist in Ordnung, und Neukodieren kostet dich nur Qualität. Zeigt ihn jeder Player quer, liegen die Pixel wirklich quer, und dies ist das richtige Werkzeug.

Eine Beruhigung, falls du es trotzdem tust. Dieser ffmpeg-Build wendet ein vorhandenes Rotations-Flag an, bevor dein Filter läuft, die gewünschte Drehung fügt sich also mit dem Flag zusammen statt dagegen zu arbeiten: Die Ausgabe ist das, was die Vorschau zeigte, und trägt danach kein Flag mehr. Einen doppelt gedrehten Clip bekommst du nicht. Du hast nur eine Neukodierung bezahlt, die du vielleicht nicht gebraucht hättest.

Die Spiegel-Kästchen, die Live-Vorschau und die Datei

Das Werkzeug zeigt eine Live-Vorschau: dein Clip läuft, per CSS gedreht, damit du den Bildausschnitt vor dem Bestätigen siehst. Die Idee ist gut, und eine Zeit lang stimmte sie für alle Kombinationen bis auf vier. Die Vorschau schrieb ihre Transformation als drehen, dann skalieren, und CSS setzt das von rechts nach links zusammen — die Spiegelung kam also zuerst, die Drehung danach. Die Filterkette macht es umgekehrt: transpose zuerst, die Spiegelungen danach angehängt. Drehen und Spiegeln sind nicht vertauschbar, diese beiden Reihenfolgen ergeben also nicht dasselbe Bild, und eine Vierteldrehung mit genau einem gesetzten Spiegel-Kästchen erzeugte eine Datei, die eine halbe Drehung von der Vorschau entfernt war. Die Vorschau schreibt jetzt skalieren, dann drehen, was sich als drehen-dann-spiegeln zusammensetzt und zur Kette passt. Die Datei war immer die richtige; gelogen hat das Bild, das man sich von ihr machte.

Beide Reihenfolgen durch denselben Encoder zu schicken klärt die Sache. Beim selben Testclip erzeugten transpose=1,hflip und hflip,transpose=1 zwei verschiedene Bilder — andere Bytezahl, andere Prüfsummen —, während dieselbe Anweisung zweimal ausgeführt byteidentische Ausgaben lieferte; der Unterschied ist also echt und kein Encoder-Rauschen. Setzt man beide Spiegel-Häkchen, verschwindet die Abweichung: transpose=1,hflip,vflip und hflip,vflip,transpose=1 ergaben dasselbe Bild, denn ein Spiegelpaar ist eine halbe Drehung, und eine halbe Drehung vertauscht mit allem.

In der Praxis stimmen jetzt alle sechzehn Knopf-Kombinationen mit der Vorschau überein, und der Zwei-Durchgang-Umweg, den dieser Artikel empfahl — erst drehen, herunterladen, dann den Download noch einmal nur mit der Spiegelung laufen lassen — ist nicht mehr nötig. Findest du eine Kombination, bei der die Datei nicht zu dem passt, was du gesehen hast, lohnt sich eine Meldung: das wäre ein neuer Fehler, nicht dieser.

Was mit dem Ton passiert, und warum die Datei wächst

Der Ton wird nie unverändert übernommen. Behältst du ihn, wird er zu AAC mit 192 kbit/s neu kodiert, bei WebM-Quellen zu Opus mit derselben Rate; entfernst du ihn, werden die Audio-Argumente zu -an, was die Spur ganz löscht statt sie stummzuschalten. Bereits verlustbehafteten Ton neu zu kodieren ist eine zweite Generation, und obwohl 192 kbit/s großzügig genug sind, dass die meisten nichts hören, ist es nicht nichts. Zählt der Ton und muss das Bild nicht perfekt sein, ziehe in Betracht, den Ton zuerst zu extrahieren und danach wieder hinzuzufügen.

Das Bild wird mit libx264 bei preset ultrafast und CRF 23 kodiert. Ultrafast ist das schnellste der elf Geschwindigkeits-Presets und das ineffizienteste: Es überspringt den Großteil der Analyse, mit der ein Encoder bei gleicher Qualität weniger Bits verbraucht — der richtige Kompromiss für einen einzelnen Browser-Thread und der falsche für die Dateigröße. Beim Testclip kam eine 6-sekündige 1080x1920-Datei von 493 466 Byte nach einer 90-Grad-Drehung mit 513 371 Byte zurück. Dem Video wurde nichts hinzugefügt; es brauchte schlicht mehr Bits, um dasselbe Material schlechter zu speichern. Erwarte bei deinen eigenen Clips dasselbe Muster: Drehen ist kein Kompressionsschritt, und es als solchen zu behandeln enttäuscht.

Häufige Fragen

Ist eine Vierteldrehung nach links schlechter als nach rechts?

Nein. Es ist derselbe Vorgang mit anderem Parameter: transpose=1 im Uhrzeigersinn, transpose=2 dagegen. Beide bewegen jedes Pixel genau einmal, kosten dieselbe Zeit und lösen dieselbe eine Neukodierung aus. Auch der 180-Grad-Knopf ist nicht schlechter, obwohl er mit zwei Spiegelungen statt zwei Drehungen umgesetzt ist — hflip,vflip und transpose=1,transpose=1 auf demselben Bild lieferten byteidentische Ausgaben, die Abkürzung ist also exakt und obendrein schneller.

Warum ist meine gedrehte Datei größer als das Original?

Weil sie neu kodiert wurde und die Encoder-Einstellungen Tempo vor Größe stellen. Das Werkzeug nutzt libx264 mit preset ultrafast, das kaum etwas von der Analyse leistet, mit der ein langsameres Preset dasselbe Bild in weniger Bits presst, bei einem konstanten Qualitätsziel von CRF 23. Wurde das Original von einem geduldigen Encoder komprimiert — dem Chip eines Telefons oder einem Schnittprogramm, das über Nacht exportiert —, braucht ein eiliger zweiter Durchgang bei ähnlicher Qualität tatsächlich mehr Platz. Beim Testclip wurden 4 Prozent mehr gemessen; eine gut komprimierte Quelle kann stärker wachsen. Es ist nichts schiefgegangen; du siehst die Kosten einer Neukodierung, den Preis des universell kompatiblen Wegs.

Mein Video steht auf dem Telefon aufrecht und liegt auf dem Rechner quer. Was tun?

Das ist die Signatur eines Rotations-Flags, das ein Programm befolgt und ein anderes ignoriert — die Datei ist also nicht kaputt. Ist das einzige Programm, das es falsch macht, eines, das du kaum nutzt, lass die Datei in Ruhe. Muss sie überall stimmen — weil du sie hochlädst, jemandem schickst oder in ein Schnittprogramm importierst, das Flags ignoriert —, dann kodiere sie hier neu und nimm eine Generation Verlust in Kauf für eine Datei, an der es nichts mehr misszuverstehen gibt. Kodiere keine Datei neu, die dort, wo es dir wichtig ist, schon richtig ist.

Dreht das Werkzeug einen Clip je versehentlich zweimal?

Nicht für die Drehung selbst. Der ffmpeg-Build hinter dem Werkzeug wendet ein vorhandenes Rotations-Flag vor deinem Filter an und schreibt keines in die Ausgabe: Eine Vierteldrehung auf einem geflaggten Clip ergibt insgesamt eine Vierteldrehung, nicht zwei. Auch die Vorschau stimmt mit der Datei überein: Sie setzte ihre CSS-Transformation in der umgekehrten Reihenfolge zur Filterkette zusammen, was eine Vierteldrehung mit genau einer Spiegelung eine halbe Drehung von dem entfernte, was du bestätigt hattest — korrigiert wurde das auf der Vorschauseite, nicht an der Ausgabe.

Kann ich hier ohne Neukodierung drehen?

Nein. Das Werkzeug hat einen Weg, und der führt durch den Encoder; es gibt keinen Nur-Flag-Modus und keine Stream-Copy-Option. Das ist eine bewusste Entscheidung, kein Versehen — eine reine Flag-Drehung ist der Vorgang, der am ehesten eine Datei erzeugt, die auf dem Rechner, auf dem du sie repariert hast, richtig aussieht und auf dem Rechner des Empfängers falsch, ein schlechtes Ergebnis für ein Werkzeug, dessen Nutzer das meist nicht prüfen können. Willst du ausdrücklich den Metadaten-Weg, brauchst du ein Kommandozeilenwerkzeug oder einen Container-Editor. Willst du eine Datei, die überall stimmt, ohne darüber nachzudenken, ist es diese.