Audio- und Videozergögerung in Matroska

Falls nur zwei Stream beachtet werden gilt: negativer Delay bei einen Stream ist das Gleiche wie ein positiver Delay beim anderen Stream.
Wo welche Delays gesetzt werden hängt davon ab:
a. was unterstützt der Kontainer (mp4 z.B. erlaubt nur positive Delays)
b. was wählt der User (wenn der Kontainer jeden Stream einen eigenen Delay geben kann, kann man da rumspielen wie man will)
c. was unterstützen die Decoder/Splitter nicht alle Player unterstützen positive und negative Delays in allen Streams.

Nebenbei sei angemerkt, dass beim Remuxen von HDTV Content auch gerne mal vfr Material entsteht um Fehler in Stream bzw. dem seinen Headern zu kompensieren.
Wenn man es mit vfr Material zu tun hat, sollte man nie vergessen die Timestream(s) mit zu beachten.

Cu Selur

Zitat von Selur

(mp4 z.B. erlaubt nur positive Delays)

Nein, sowohl negative als auch positive Delays sind möglich.

Zitat von Nel-son

Ich dachte nun, dass beim muxen einer MKV das setzen eines Delays immer unwiderruflich ist, so dass man später nicht mehr Delays manuell auslesen muss. Ist wohl falsch. Weiß einer was es mit der Videoverzögerung im Audiostream auf sich hat? Eigentlich setzt man Delay doch im Audio- oder UT-Stream, nicht im Video?

Die Delayinformationen jeder Spur (egal ob Video, Audio oder Untertitel) sind im Matroska-Container hinterlegt. Beim Demuxen werden die Spuren wieder in ihre Rohformate geschrieben, welchen entsprechende Speichermöglichkeiten fürs Delay fehlen. (absehen von den Untertitel-Formaten)

Wenn die Videospur als Basis angenommen wird (was oft der Fall ist, da Audiospuren meist eine geringere Komplexität und feinere "Granularität" haben, also leichter hinreichend exakt zu schneiden sind), gibt es für die Audiospur folgende Möglichkeiten, ein synchrones Ergebnis auszugeben (was also beim erneuten Multiplexen nicht verschoben werden muss, um Synchronität wiederherzustellen):

• Synchroner Start (der erste Audioblock hat den gleichen Zeitstempel wie das erste Videoframe): optimal.
• Negativer Delay (es existieren bereits Audioblöcke zeitlich vor dem ersten Videoframe): Beim Demultiplexen könnten so viele Audioblöcke weggelassen werden, bis der Audioblock mit der geringsten Timecode-Differenz zum ersten Videoframe zur Ausgabe kommt
• Positiver Delay (es existieren bereits mehrere Videoframes, bevor der erste Audioblock kommt): Beim Demultiplexen müsste die Tonspur mit bekannten Audioblöcken gleicher Kanalkonfiguration (und evtl. Bitrate bei CBR-Audio) aufgefüllt werden, um die Verschiebung mit stillem Material zu ersetzen

Wird die Tonspur dagegen ohne Korrektur einer Verschiebung demultiplext, wird alternativ meist im Dateinamen ein Hinweis hinterlassen, welche Verschiebung beim erneuten Multiplexen zu wählen sei.

Was nun eac3to unter welchen Voraussetzungen kann, habe ich leider keinen Überblick; der Ausgleich einer positiven Verschiebung der Audiospur zur video-Basis durch Auffüllen mit Stille ist aber insofern aufwändig, dass dafür Ersatz-Audio-Blöcke in bekannten Formaten vorliegen müssen...

Meines Wissens tut eac3to genau das (im Gegensatz zu mkvextract), zumindest für die gängigsten Formate. Das müßte man aber auch im eac3to-log sehen können.

Zitat

Nein, sowohl negative als auch positive Delays sind möglich.

Okay, MP4Box unterstützt nur positive delays.

mp4box unterstützt beides. Wann hast Du es das letzte mal getestet? Vor knapp einem Jahr wurde da ein Bug gefixt.

Yo, definitiv schon ne ganze Weile her, dass ich das getestet hatte,.. werde ich mir wohl noch mal angucken.

MediaInfo zeigt bei den Tonspuren "Delay relative to video" an, d.h. die Differenz vom Start des ersten Videobildes zum Start des ersten Audiosamples. Wenn dort "-24ms" steht, heißt dies, daß die Tonspur 24ms vor der Videospur beginnt.

Was ist denn überhaupt das Ziel der Übung? Wenn Du die mkv-Dateien per mkvmerge aneinanderhängst, sollte mkvmerge das alles von selbst synchron halten. An den Schnittstellen kommt es dabei zu kleinen Sprüngen, vermutlich kann Dein Videoplayer damit nicht gut umgehen. Das Problem ist für die Player nicht ganz trivial, da Timecodes in mkv fast immer einem gewissen Jitter unterliegen bzw. teilweise fehlerhaft gemuxt sind. Kleine Unterschiede werden deshalb manchmal absichtlich "verschluckt", was ggf. durch Seeken behoben werden kann. Nutzt Du LAV Filters oder etwas anderes?

Wenn Dein Player damit nicht klarkommt, mußt Du schlimmstenfalls erneut encodieren - zumindest den Ton. Vielleicht kann man auch etwas frickeln, je nachdem wie viel Du bereit bist an Arbeit reinzustecken und wie groß die Timecode-Lücken sind. Ziel wäre dann, die Timecodelücken aufzufüllen bzw. überstehenden Ton rauszuschneiden. Darum bei solchen Aktionen immer bereits in AviSynth o.ä. zusammenfügen, damit man hinterher alles aus einem Guß hat.

Zitat von Nel-son

Ich hol das Thema nochmal hoch, da ich jetzt ein Video habe mit "Delay relative to video" von 31ms. Das heißt, dass die Tonspur 31ms nach der Videospur beginnt., das heißt eine Audioverzögerung. Richtig?

Korrekt.

Zitat von Nel-son

Möchte ich das ganze mit AviSynth korrigieren wäre delayaudio(0.31) zu wählen

Kommt drauf an. Kann sein, daß der Sourcefilter das bereits automatisch macht, wenn Du direkt aus z.B. mkv oder mp4 list. Müßte bei L-Smash und ffms2 der Fall sein. (Wenn Du also sowohl Video als auch Ton über einen dieser Filter lädst.)

Zitat von Nel-son

wenn nur neu gemuxt werden soll in MKVMergeGUI bei Audioverzögerung 31ms.

Kommt drauf an. Wenn Du direkt von mkv liest, macht mkvmerge das eigentlich automatisch. Bei mp4 auch, da gibt es aber teilweise Fallstricke. Ich glaube aber nur bei negativen Delays in mp4 und dann nur bei bestimmten Varianten. Bin mir da auf Anhieb nicht ganz sicher.