Hallo,
beim Import von MKV-Dateien in TS-Doctor 5.0.14 entstehen bei bestimmtem H.264-Material fehlerhafte Zeitstempel. TS-Doctor 4.2.22 verarbeitet dieselben Dateien auf demselben Rechner korrekt.
Umgebung
- TS-Doctor 5.0.14 (Build 070000), Windows 11 Build 26300
- Vergleich: TS-Doctor 4.2.22 (Build 070000), parallel installiert
- Material: DVB-S2-Aufnahmen von Astra 28,2° Ost, H.264 1920x1088i, 25 fps, Main@4.0, AC3 2.0
- Die MKV wurden mit mkvmerge (MKVToolNix 100.0) aus den per TS-Doctor reparierten Aufnahmen erzeugt
Vorgehen
1. MKV in TS-Doctor öffnen (Import)
2. Nichts schneiden
3. "Neue Datei erzeugen" als TS
Ergebnis mit 5.0.14
- Die erzeugte TS ruckelt bei der Wiedergabe (MPC-HC) weich, etwa alle 1 bis 2 Sekunden.
- DVR-Studio UHD 2.07 schlägt für diese Datei unsinnige Schnittbereiche vor (z. B. die ersten 40 Minuten) und setzt Fehlermarkierungen auf der Tonspur.
- Dieselbe MKV über 4.2.22 (Import per tsMuxeR): ruckelfrei, DVR-Studio unauffällig.
- Die MKV selbst spielt ruckelfrei.
Betroffen ist nur Material, das Vollbilder und Halbbildpaare mischt (adaptives PAFF):
- ITV3 HD (Poirot): stark betroffen
- BBC HD (Father Brown, Great Canadian Railway Journeys): betroffen in den Passagen mit Halbbildpaaren, sonst sauber
- Rein halbbildkodiert (Channel 5 HD), rein vollbildkodiert (ITV1 HD) und 720p50: unauffällig
Import-Protokoll (import_0.log) für die Poirot-MKV, Auszug
0 video h264 copy 1920x1080, 25.00 fps carried unchanged
22:25:13.527 W output stream 0 does not keep the frame rate it claims; its decode timeline was re-anchored
22:25:13.527 I wrote 359942 packets from 359942 read, 2 copied and 0 converted streams, 45715 timestamp nudges, 0 damaged packets skipped, 0 PCR packets inserted for DVB, 244605 PES headers marked as aligned
Der Fehler entsteht also schon beim Import: mux2ts nimmt 25 fps an, der Strom liefert in den Halbbild-Passagen aber Pakete im 20-ms-Abstand. Daraufhin werden 45.715 Zeitstempel verschoben. Das vollständige Protokoll hängt an.
Zum Vergleich die rein halbbildkodierte Aufnahme (Channel 5 HD): Dort erkennt der Import 50.00 fps, meldet 0 timestamp nudges und markiert alle 222.503 PES-Köpfe als aligned. Das Ergebnis ist ruckelfrei.
Messung 1: Zeitstempel der erzeugten Dateien
Mit ffprobe habe ich die PTS aller Videopakete eines Zeitfensters ausgelesen, sortiert und die Abstände gebildet (auf ms gerundet).
Poirot (ITV3 HD), Laufzeit 1:32:17
erste 120 s ab 40:00, 150 s
Original-TS 40 ms 78 %, 20 ms 22 % 20 ms 86 %, 40 ms 14 %
MKV 40 ms 78 %, 20 ms 22 % 20 ms 86 %, 40 ms 14 %
TS ueber 4.2.22 40 ms 100 % 40 ms 100 %
TS ueber 5.0.14 40 ms 78 %, 20 ms 13 %, 0 ms 7 %, 20 ms 50 %, 0 ms 28 %, 40 ms 15 %,
60 ms 1 %, 120 ms 1 % 120 ms 2 %, 60 ms 2 %
DTS-Abstaende der TS ueber 5.0.14:
40 ms 88 %, 0 ms 10 %, 20 ms 2 % 40 ms 55 %, 0 ms 40 %, 20 ms 5 %
Father Brown (BBC HD), TS ueber 5.0.14
erste 120 s (mit Halbbildpaaren) 40 ms 78 %, 20 ms 13 %, 0 ms 7 %, 120 ms 1 %
ab 40:00 (nur Vollbilder) 40 ms 100 %
"0 ms" heißt: Der Abstand liegt unter 0,5 ms, die Stempel sind aber nicht exakt gleich. Viele Halbbilder bekommen also praktisch denselben Zeitstempel wie das Bild davor, und das wird durch Sprünge von 60 bzw. 120 ms wieder ausgeglichen. In der MKV sind die Zeitstempel noch korrekt.
Messung 2: dekodierte Bilder
Original-TS und erzeugte TS habe ich mit ffmpeg dekodiert (-f framemd5) und die Bilder verglichen. Paketzahl und Ton sind in allen Fällen identisch.
Original ueber 5.0.14
Poirot (ITV3 HD, gemischt) 138.396 122.276 (-16.120, ueber die ganze Folge)
Father Brown (BBC HD, gemischt) 66.212 65.691 (-521, am Anfang und am Ende)
Gr. Canadian Railway J. (BBC HD, gemischt) 43.111 42.722 (-389, am Anfang und am Ende)
All Creatures (Channel 5 HD, Halbbilder) 68.476 68.476 bitidentisch
Endeavour (ITV1 HD, Vollbilder) 139.621 139.621 bitidentisch
720p50 129.661 129.661 bitidentisch
Zum Vergleich ueber 4.2.22: Poirot 138.387 Bilder
Der Decoder verwirft also bei gemischtem Material die Bilder mit kollidierenden Zeitstempeln. Bei Poirot fehlt in den Minuten 40 bis 50 jedes vierte Bild.
Die Bilddaten selbst werden unverändert übernommen. NAL-Statistik laut TS-Doctor-Log für Poirot:
- Original: Slices 371.053, IDR 2.792, SEI 191.948, AUD 186.919 (bei rund 138.400 Bildern, also etwa 35 % der Bilder als Halbbildpaar mit eigenem AUD)
- TS über 5.0.14: Slices 371.053, SEI 191.948, AUD 186.935
- TS über 4.2.22: AUD 138.391 (tsMuxeR fasst die Halbbildpaare zusammen)
Eine kurze Beispieldatei (MKV und Original-TS) kann ich gerne bereitstellen.
Zwei Nebenbefunde aus demselben Test, falls von Interesse:
1. Beim Kommandozeilenaufruf mit AUTOFIX LOG nennt das Log von 5.0.14 eine Ausgabegröße, die um genau 20.000 TS-Pakete (3.760.000 Byte) kleiner ist als die tatsächlich geschriebene Datei. Auch die CRC im Log weicht von der aus 4.2.22 ab, obwohl die Ausgabedateien beider Versionen Byte für Byte identisch sind (geprüft an sieben Dateien). Möglicherweise werden Größe und CRC protokolliert, bevor der "repair buffer" geschrieben ist.
2. Wird TSDoctor.exe per CreateProcess auf einem eigenen, nicht sichtbaren Windows-Desktop gestartet (lpDesktop), bleibt 5.0.14 beim Programmstart hängen: Stage.log endet nach Stufe 12. 4.2.22 läuft in derselben Konstellation durch.
Viele Dank und viele Grüße
Ich verstehe das Vorgehen nicht wirklich :o ?!?!?!
Du nimmst was vom SAT auf (also wohl "TS").
Du machst da rum mit mkvmerge (WARUM?) und kriegst "MKV"
Du importierst die MKV wieder in den TS Doc, schnippelst (oder auch nicht) und kriegst beim Speichern wieder "TS"
Klingt für mich recht sinnfrei !?!?!?
Ja, also "sinnfrei" würde ich das nicht nennnen. :)
Ich nehme vom Satellit auf, schneide dann und erzeuge .mkv, ja.
Die Rückwandlung nach .ts ist gar nicht das eigentliche Ziel, sondern Zwischenprodukt bei dem folgenden (selten nötigen, aber durchaus vorkommenden Schritt). Ich merke nach der Erzeugung der .mkv Version, dass die Schnittpunkte nicht richtig lagen. Entsprechend geht es um ein Nachschneiden. Beim Import von .mkv in TS Doctor wird automatisch .ts erzeugt und in diesem Vorgang entsteht das geschilderte Phänomen, d.h. beim Nachschneiden (mit dem Ziel, daraus dann wieder die - besser geschnittene - .mkv zu machen) entstehen die Artefakte.
P.S.: mit mkvmerge deshalb, weil ich einen Altbstand von .ts Dateien habe, die ich per Skript halt auf einmal anpacke und dazu verwende ich halt mkvmerge. Ist eine Design-Entscheidung meinerseits.
also doch sinnfrei ;D
Schneide die Aufnahme mit dem Doc, guck Dir die Schnittpunkte an (gibt eine Preview Funktion), passe ggf an, und wenn alles ok, exportiere dann.
Das "tausendmal hin-und-her Wandeln" ist nicht gerade hilfreich, da zwischen MKV (mp4) und TS jedesmal wichtige Informationen verloren gehen, die sich der spätere Import dann wieder mit der Wünschelrute zusammenreimen muß.
Ein paar Samples zum Reproduzieren wären hilfreich. Aktuell lass ich ein paar Aufnahmen auf BBC One HD und ITV3 HD laufen aber es kann gut sein, dass dort die Probleme nicht reproduzierbar sind.
Zitat von: Cypheros am Oktober 02, 2026, 15:17:34aber es kann gut sein, dass dort die Probleme nicht reproduzierbar sind.
Beachte, dass er ZWEIMAL konvertiert und importiert.
Da würde mich schon meine eingebaute Faulheit vor bewahren ;D
Mir ist auch nicht bewusst, dass BBC Voll- und Halbbilder mischen sollte, deren Encoder ist ja eigentlich seit Jahrzehnten fix und benutzt gar kein kompliziertes Zeuchs. (ITV weisich nich, da ist ja Werbung...)
Also ich hab mal ne Testaufnahme bei ITV-3 gemacht. Emmentaler, äääh Emmendale (ist aber vom Gehalt her dasselbe ;D )
Der Doc hat keine verlässliche Möglichkeit, die Schnittpunkte automatisch zu finden. Das Logo ist sehr opaque und Audiosprünge sind auch nicht vorhanden (vom EPG und TTX reden wir gar nicht erstmal).
Also IBM.. (immer besser manuell).
Durch die extrem hohe Kompressionsrate (aka: miese Bildqualität) ist es oft schwer einen "guten" Schnittpunkt zu finden, aber es geht schon mit etwas Mühe.
Gezuckt oder gestottert hat nix, auch keine Klötzchen irgendwo. Am Anfang sah es kurz nach Stottern aus, aber ich geh mal davon aus, das war im Original schon drin.
Ich finde also bei dieser Aufnahme kein Problem :-X
Zitat von: Cypheros am Oktober 02, 2026, 15:17:34Ein paar Samples zum Reproduzieren wären hilfreich. Aktuell lass ich ein paar Aufnahmen auf BBC One HD und ITV3 HD laufen aber es kann gut sein, dass dort die Probleme nicht reproduzierbar sind.
Danke für die Rückmeldung. Samples schicke ich gleich per PN (Download-Link).
Drei Hinweise zum Reproduzieren mit eigenen Aufnahmen:
1. Der Fehler zeigt sich nicht an der Aufnahme selbst, sondern erst beim Import einer MKV. Die Aufnahme muss also zuerst nach MKV gewandelt werden (bei mir: mkvmerge 100.0, TS -> MKV ohne weitere Optionen) und diese MKV dann in TS-Doctor 5 geöffnet werden.
2. Es braucht Passagen, in denen der Encoder Halbbildpaare statt Vollbilder schreibt. Bei Poirot (ITV3 HD) kommen sie in der ganzen Folge vor und überwiegen ab etwa Minute 40. Bei Father Brown (BBC) stehen sie nur am Anfang und am Ende der Sendung.
3. Die beiden Sender verpacken Halbbildpaare in der TS unterschiedlich. ITV3 HD gibt jedem Halbbild ein eigenes PES-Paket mit eigenem Zeitstempel; die 20-ms-Abstände stehen also schon in der TS. Bei der BBC stecken beide Halbbilder in einem PES-Paket mit einem Zeitstempel; die TS zeigt dort nur 40-ms-Abstände. In der MKV von mkvmerge ist in beiden Fällen jedes Halbbild ein eigener Block mit eigenem Zeitstempel und einer Dauer von 20 ms.
Eine Beobachtung dazu, noch nicht gegengeprüft: mkvmerge trägt bei der gemischt kodierten Poirot-MKV im Spurkopf eine Default Duration von 40 ms ein. Bei der Vergleichsaufnahme aus dem ersten Beitrag, die den Fehler nicht zeigt (All Creatures Great and Small, Channel 5 HD, nur Halbbilder; als Sample dabei), sind es 20 ms. Der Import meldet passend dazu 25,00 bzw. 50,00 fps. In der Poirot-MKV folgen die Blöcke in den Halbbild-Passagen aber im Abstand von 20 ms; im Sample ab Minute 40 sind das 83 % der Abstände. Ob der Import die Bildrate tatsächlich aus diesem Feld nimmt, prüfe ich am Wochenende mit einer MKV, in der nur dieser eine Wert geändert ist.
Danke für die Samples. Das Problem wurde gefunden und behoben. Das war nicht mehr so schwierig wie gedacht nach deiner guten Vorarbeit bei der Analyse der Ursache. :D
Die kommende Version 5.0.15 wird auch diese Art von Dateien problemlos importieren können.
Zitat von: Cypheros am Oktober 02, 2026, 21:43:47Danke für die Samples. Das Problem wurde gefunden und behoben. Das war nicht mehr so schwierig wie gedacht nach deiner guten Vorarbeit bei der Analyse der Ursache. :D
Die kommende Version 5.0.15 wird auch diese Art von Dateien problemlos importieren können.
Danke, das ist wirklich freundlich und sehr erfreulich!
Die aktuelle Version 5.0.15 sollte die MKVs jetzt korrekt importieren auch wenn ich Mam Recht geben muss, was den Workflow angeht.
Besser ist es dem TS-Doctor die originalen TS-Aufnahmen zur Verfügung zu stellen, denn bei der Konvertierung in MKV gehen viele wichtige Informationen verloren, die der TS-Doctor nutzen könnte.