EDIT: Ich habe ein Beispielvideo und die Log-Datei per FTP im Ordner „wvladik“ hochgeladen.
MCEBuddy-Version und -Typ (32-Bit oder 64-Bit):
2.4.7 64-Bit
Betriebssystem und -Typ (32-Bit oder 64-Bit):
Windows 7 64-Bit
Zusammenfassung des Problems oder Vorschlags:
Dieses Video stammt von DVB-S2, aufgenommen mit Windows Media Center vom spanischen TV-Sender M+ Formula1. Dieser Fehler tritt jedoch bei allen Aufnahmen dieses Senders auf. Aufnahmen von BBC HD, iTV HD UK zeigen diesen Fehler nicht.
Schritte zur Reproduktion des Fehlers:
Konvertierung des Videos mit jedem Profil – das Video ist beschädigt, da ffmpeg beim Remuxen von MPEG-TS durcheinandergerät. Wenn ich das Remuxen überspringe und „Unprocessed MP4“ verwende (d. h. immer noch ffmpeg zum Kopieren), ist das Video ebenfalls beschädigt.
Ich werde die Log-Datei zusammen mit dem Video anhängen. In der Log-Datei sieht man den Fehler:
2017-08-26T21:14:06 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000000006f46fa0] Non-monotonous DTS in output stream 0:2; previous: 260157215, current: 260153615; changing to 260157216. This may result in incorrect timestamps in the output file – dieser Eintrag wiederholt sich ständig.
Das resultierende Video ist sehr ruckelig/verzögert, während das Original-WTV in WMC flüssig abläuft.
Ich habe mir deine Logs angesehen, sie sind voller Fehler in deiner Quelldatei:
2017-08-26T21:12:46 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000000006f46fa0] Non-monotonous DTS in output stream 0:2; previous: 11552016, current: 11550215; changing to 11552017. This may result in incorrect timestamps in the output file.
Deshalb ruckelt es. Wenn du das über eine TV-Tuner-Karte aufzeichnest, überprüfe deren Treiber – es scheint beschädigte/nicht konforme Daten zu senden. Versuche, sie gegebenenfalls zu aktualisieren (auch wenn die Wiedergabe korrekt funktioniert, sind die Daten selbst beschädigt; verschiedene Decoder gehen damit unterschiedlich um). In diesem Fall kann ffmpeg beim Remuxen die Fehler nicht ausgleichen.
Du kannst versuchen, das Remuxen zu umgehen, indem du die Option Skip remuxing in den Experteneinstellungen des Konvertierungsauftrags aktivierst – vielleicht kann der Encoder diese Fehler kompensieren. Dies funktioniert nur, wenn du die Donator-Version von Comskip besitzt.
Ich habe die ffmpeg-Fehlermeldung in der Log-Datei gesehen, aber das bedeutet nicht, dass etwas mit dem Video nicht stimmt … vielmehr gibt es ein Problem mit dem ffmpeg, das von MCEBuddy verwendet wird.
Das Video (original wtv) läuft in mce7, mpc-hc, kodi und plex flüssig (deshalb bezweifle ich, dass etwas damit nicht stimmt), laut der Log-Datei hat das aktuelle ffmpeg jedoch Probleme mit der Frame-Timing.
Am Tuner liegt nichts. Ich verwende denselben Tuner für ALLE Aufnahmen und hatte nie ein Problem – AUSSER bei Aufnahmen dieses Senders. Ich vermute, sie nutzen eine Option im h.264-Encoder, die das aktuelle ffmpeg nicht sauber verarbeitet.
Was das Überspringen des Remuxings betrifft: Ich habe es versucht, aber da ich ein Profil verwende, bei dem ffmpeg das Video lediglich in die mp4-Datei kopiert, kommt es erneut zum Stottern.