Seit einigen Wochen beobachte ich folgendes Verhalten des TS-Remuxers:
ts-Dateien (vorher repariert mit TSD), die einen AC3/5.1 Audiostream haben, werden durch die Umwandlung mit dem TS-Remuxer (in mkv, ts, m2ts) ausnahmslos um ca 50 % aufgeblasen. Das Ergebnis ist selbst mit dem VLC-Player nur noch ohne Ton abspielbar.
Das remuxed.log ist riesig und enthält im Wesentlichen folgende Zeilen:
First valid video frame found at PTS: 00:00:00.847
First AC3 frame PID $17EA at PTS: 24:34:51.154 / frame size: 1792 / 5.1/48kHz
AC3 missing frame on PID $17EA at PTS: 24:34:51.122 silence inserted
AC3 missing frame on PID $17EA at PTS: 24:34:51.090 silence inserted
AC3 missing frame on PID $17EA at PTS: 24:34:51.058 silence inserted
AC3 missing frame on PID $17EA at PTS: 24:34:51.026 silence inserted
AC3 missing frame on PID $17EA at PTS: 24:34:50.994 silence inserted
...
...
Bei weiterer Recherche stellte ich fest, dass die mit TSD reparierten ts-Dateien einen Audio-Versatz für die AC3-Spur von 10...24h (MediaInfo) aufweisen. Die Originaldateien aus der Dreambox zeigen einen Versatz von wenigen 100 ms.
Da ich an den Einstellungen des TSD seit langer Zeit keine Änderungen vorgenommen habe, bin ich ratlos, was hier los ist. Ich bitte um Hilfe
Mike
Hast Du mal das Log von der vorherigen Reparatur durch den TS-Doctor? Dabei muss was schief gelaufen sein.
Z.B. dieses Log. Die Reparatur schloss ab mit 0 Fehlern und 2 Warnungen (Wechsel von 6- auf 2-kanaligem AC3). Wie gesagt, es passiert nur bei AC3/5.1 und das immer, nicht bei AC3/2.0.
Das Problem ist mal wieder ein PCR-Wrap.
First video PTS is 7938702816 24:30:07.809
Last video PTS is 131874424 00:24:25.271
First PCR is 2381596526700 24:30:07.279
Last PCR is 39544961851 00:24:24.628
PCR wrap at 02:00:36.439 detected!
Duration of video stream is 783096042 02:25:01.067
Video PCR to PTS difference -673 ms
$17E8: Delay to video stream = -390ms
$17E9: Delay to video stream = -390ms
$17EB: Delay to video stream = -390ms
$17EA: Delay to video stream = -432ms
$17F2: Delay to video stream = -480ms
$17F3: Delay to video stream = 6480ms
Remove PCR wrap
Lass die Datei zuerst ohne Schnitt durch den TS-Doctor laufen, bis der PCR-Wrap weg ist. Anschließend schneiden und dann sollte die Konvertierung klappen.
Offenbar verursacht der Wrap ein Versatz bei Bild und Ton, den der Remuxer durch einfügen von Füllpaketen auszugleichen versucht.
Ich bin momentan dabei dem Problem mit den PCR-Wraps auf den Grund zu gehen.
Die Originalaufnahme, zu der das vorige Log gehörte, habe ich nicht mehr. Da der Fehler aber bei jeder Aufnahme mit AC3/5.1 auftritt (egal welcher Sender), habe ich Deinen Vorschlag mal eben auf die Schnelle bei einer neuen Datei gemacht.
Ein PCR-Wrap wird beim ersten Einlesen der Original ts-Datei durch den TSD nicht gemeldet. Ungeschnitten durchlaufen lassen. Neue Datei wieder eingelesen und Schnittpunkte gesetzt. Geschnittenen Datei mit VLC abgespielt: AC3/5.1 wird synchron wiedergegeben. Mit tsRemuxer umgetopft in mkv. MKV-Datei ist tatsächlich nicht mehr größer als die ts-Datei. ABER: Wiedergabe der mkv-Datei mit VLC bleibt stumm. Erst nach 6' beginnt der Ton. Der parallel vorhandene mp2-Ton dagegen läuft synchron. MediaInfo gibt für diese mkv-Datei bei der AC3-Spur einen Video-Versatz von 1 ms und bei der mp2-Spur von 10 ms an. Dagegen gibt MediaInfo für die geschnittene ts-Datei 6'01" bei AC3 und 9 ms bei mp2 an. Diese ts-Datei wird wie oben erwähnt mit VLC jedoch synchron bei beiden Audiospuren wiedergegeben...
Das ist irgendwie unheimlich. Ich schicke mal alle 3 Logs mit (Ungeschnitten, Geschnitten, Remuxed*).
Danke für Deine Mühe
Mike
*Remuxed.log gekürzt
Hallo,
ich denke das Problem wird hervorgerufen durch die Option "Füge AC3 5.1 Frames ein, wenn nötig" unter EInstellungen/Optionen/Korrekturverhalten. Deaktiviere das mal und versuch es erneut.
Zusätzlich ist Dein MKVToolnix schon sehr alt und Du solltest mal auf eine aktueller Version (5.8.0 oder so) wechseln.
Jepp, mit deaktivierter Option läuft alles glatt durch, sogar ohne vorherige Reparatur der gesamten Originaldatei. Was ich aber partout nicht raffe ist, dass ich die Option seit jeher eingeschaltet hatte. Sie hat ja vermutlich auch einen Sinn, sonst hättest Du sie ja nicht eingebaut, oder? Dieses Problem hatte ich jedoch noch nie. Erst seit einigen (wenigen) Wochen tritt das Problem auf. Hast Du an der Stelle etwas verändert?
Zu der Uraltversion von MKVToolnix. Nach einem kurzen Ausflug auf die aktuellste Version bin ich zurückgekehrt zur alten Version. Die mit der neuen Version erstellten mkv-files machen Probleme mit dem VLC-Player beim Navigieren innerhalb des Films. Es dauert manchmal eine Minute bis die aufgerufene Filmposition endlich angezeigt wird. Das dauert mir zu lange, wenn es nur darum geht, kurz die Konsistenz der Synchronisation zu überprüfen. Die "alten" mkv-files reagieren im VLC blitzschnell.
Mike
Wenn du beim VLC Media Player in den Einstellungen unter "Extras" --> "Einstellungen" --> Einstellungen anzeigen (Alle) --> Input/Codecs --> Demuxer --> Matroska bei "Dummy Elemente" ein Hakerl setzt, dann kann auch in den neuen Dateien einwandfrei navigiert werden. ;)
Danke, Erich, für den Tipp. Habe MKVToolnix 5.4.0 installiert, den VLC nach Deiner Angabe eingestellt und siehe da, es navigiert sich wieder schnell wie vorher. Ich hoffe nur, dass der Hinweis bei der Häkchenbox (schlecht für fehlerhafte Streams) nun nicht bedeutet, dass eventuelle Fehler (Synchronität) unentdeckt bleiben.
Schönen Abend noch
Mike
Selbst die mit mkvtoolnix Version 6.0.0 erstellten Files sollten sich jetzt einwandfrei an jeder Position ansteuern lassen. Auf die Synchronität hat diese Einstellung im Prinzip keine Auswirkung (wenn Ton und Bild asynchron sind [z. B. aufgrund fehlender Pakete im Video- und/oder Audiostream], dann ist dies in beiden Situationen der Fall). Mithilfe der von mir genannten Option kommt der VLC Media Player mit Elementen, die bei mkvtoolnix ab Version 5.9.0 in der *.mkv Datei hinzugefügt wurden, besser zurecht. Ich vermute, dass die zukünftigen Versionen des vlc media players sofort mit den "neuen" *.mkv Dateien zurecht kommen werden. ;)
Vielen Dank für diese zusätzlichen Infos, Erich.
Mike