Lippensynchronitätsstörungen in Videos

Mal ein rein technischer Hinweis:

Leser schrieben, dass der heute-journal-Ausschnitt, den ich gerade zu Claus Kleber zeigte, nachverteilt sei, der sei nicht Lippensynchron. Oder gar ein politischer Fake.

Nein, der ist nicht nachvertont, das Ausgangsmaterial war einwandfrei und warum sollte der sich selbst nachvertonen? Zumal ich das ja im Fernsehen live gesehen habe.

Ich kann es mir erst heute abend nach der Arbeit genau ansehen, aber an dieser Stelle ein technischer Hinweis zu einem Problem, dem ich in den letzten Wochen schon nachgespürt habe. Es geht nämlich um genau das Problem, dass Ton und Bild nicht mehr synchron sind.

Ich verwende zur Videobearbeitung das einschlägig bekannte und zum Quasi-Standard gewordene ffmpeg (zwischendurch mal den Ableger avconv).

Nun muss man folgendes wissen: Moderne Videocodierungsverfahren speichern nicht mehr jedes Bild einzeln, sondern immer mehrere als Group of Pictures, abgekürzt GOP. Dabei wird nur das erste Bild vollständig dargestellt, während die nächsten Bilder nur als Differenz zum vorhergehenden gespeichert sind. Wenn etwa jemand nur den Kopf und die Lippen etwas bewegt, ist es günstiger, nur den Unterschied abzulegen und nicht jedesmal das ganz Bild. Das ist eine wesentliche moderner Videocodierung. Bei der Kompression versucht die Software herauszufinden, was wann günstiger ist. Kommt bei einem Szenenwechsel ein ganz anderes Bild, ist das immer günstiger, neu anzufangen, während bei einem feststehenden Hintergrund wie die heutejournal-Kulisse die Differenzen günstiger sein können. Normalerweise begrenzt man das auch auf gewisse Zeit, damit das maximal über ein, zwei Sekunden geht. Es ist Euch vielleicht schon beim Zappen zwischen den Programmen auf DVB-T aufgefallen, dass manchmal nur Teile des Bildes erscheinen und dann erst nach einer halben oder ganzen Sekunde das volle Bild. Das ist genau dieser Effekt, und beim Umschalten hat der Empfänger dann das Vollbild verpasst, kann nur die Differenzen darstellen bis er das nächste Vollbild bekommt.

Will man nun einen Ausschnitt aus einem Video schneiden, hatte ffmpeg bisher zwei Strategien (abhängig von der Reihenfolge der Parameter, ob man den Startpunkt vor oder nach dem Eingabevideo angibt), die aber beide Nachteile haben:

• Eine Strategie ist, das Video ohne Qualitätsverlust zu schneiden und das auch sehr schnell zu tun, indem man einfach zu der GOP zu springen, in der das benötigte erste Bild des gewünschten Ausschnittes liegt und ab dieser GOP GOP-weise zu kopieren. Vorteil: schnell und verlustfrei. Nachteil: Nicht exakt, weil das Ergebnis einige Bilder vor dem gewünschten Start anfängt und auch mal eine ganze Sekunde zu früh anfangen kann.

  Kann man verwenden, wenn man danach weiterbearbeitet, man also lieber ein paar Bilder mehr drin hat, als zu warten und Qualität zu verlieren.

• Die andere Strategie ist, den Videostrom Bild für Bild zu dekodieren, also die Codierung aufzuheben, einen regulären Vollbilderstrom daraus zu machen, das passende Bild abzuwarten und ab da wieder neu zu codieren. Vorteil: Passt exakt. Nachteil: Langsam und Qualitätsverlust durch Neucodierung. Kann dadurch sogar größer werden.

  Kann man verwenden, wenn man sowieso umkodiert oder skaliert oder sowas.

Bei Audio tritt das nicht so auf, den Ton kann man in der Regel Bild-passend schneiden.

In einer neueren Version von ffmpeg hat man versucht, das Problem zu lösen und die erste Strategie (GOP-Kopie) so zu verbessern, dass das Ergebnis genau passt. Man macht im Prinzip das erste, kopiert also schnell und verlustfrei die GOPs und gibt dann als Videostart einen negativen Offset an. Hat man also durch die GOP beispielsweise drei Bilder zuviel, dann gibt man als relativen Start des Videoschannels zum Gesamtvideo -3/50 Sekunden (bei 50 Bildern pro Sekunde, ansonsten entsprechend analog) an.

Das funktioniert. Theoretisch. Man hat dann drei Bilder zuviel mit drin, die einfach nicht angezeigt werden (sollen).

Das dumme daran ist: Nicht jede Software kommt mit negativen Offsets klar. Deshalb kann es vorkommen, dass so ein Video auf einer Software völlig normal, auf einer anderen aber nicht mehr lippensynchron aussieht, weil die den Ton richtig abspielt, beim Video aber die überflüssigen Bilder, und damit der gesamte Videochannel gegenüber dem Audiochannel verrutscht.

Genau so ist mir das passiert: Videos schaue ich normalerweise mit mplayer, weil schnell, kommandozeilig und komfortabel, aber gerade der kann das nicht. Deshalb habe ich der Sache mal nachgeforscht.

Normalerweise sollte das Problem aber nicht auftreten. Mache ich nämlich solche Ausschnitte wie den von Kleber, gehe ich in zwei Schritten vor: Zuerst aus dem Originalvideo den Ausschnitt wie oben beschrieben nach erster Strategie, weil schnell und verlustfrei. Auch für’s Archiv. Da muss man nicht lange warten, bis das alles umcodiert ist. Und dann im zweiten Schritt den Schnipsel flott runterskalieren und komprimieren auf Blog-Format. Geht schnell, weil nur ein paar Sekunden.

Da letzteres ohnehin eine Neucodierung mit sich bringt, sollte das Problem danach eigentlich nicht mehr auftreten, weil dann wieder der Offset auf Null steht. Hat bisher auch funktioniert.

Irgendwas scheint aber nun schief gelaufen zu sein.