Probleme mit PTS Wrap/PCR Wrap mit Freemake

[siegi2000]

Hallo!

Ich nehme mit einer Linuxmaschine den freien digitalen Stream von UPC in Wien auf.
Normalerweise prüfe ich nur den Stream mit dem TSDR und wenn keine Probleme auftauchen verwende ich Freemake um den Stream zu konvertieren.
Ca in 15% der Aufnahmen (ich habe rund 500 Aufnahmen durch den TSDR geschickt) habe ich jedoch PTS/PCR Wraps, bei denen sich Freemake aufhängt, wenn ich die Daten nicht mit dem TSDR neu erzeuge.
Ein neu erzeugter File schreibt dann am Ende des Logfiles etwa folgenden Text:

Starting at packet 00000002 PTS: 00:00:00.837 (26:13:15.122)
No cutting at the end needed
PTS wrap > (33 bit) at packet 004940C3 on PID 07D1 detected!
PTS wrap < (33 bit) at packet 00494116 on PID 07D1 detected!
PTS wrap > (33 bit) at packet 0049411F on PID 07D1 detected!
PTS wrap > (33 bit) at packet 00494DC6 on PID 07F9 detected!
PCR wrap between packet 00494DC1 and packet 00494E36 on PID 07D1 detected, PCR: 00:17:29.587
Ending at packet 0832E2CD PTS: -19:24:23.578 (06:48:51.544)

1. Es stellt sich für mich die Frage, warum PTS und PCR-Wraps in der Fehlerübersicht am Ende nicht angeführt werden, sondern TSDR 0 Fehler meldet.
Weiß das zufällig wer von euch?

Der zweite Punkt ist folgender:
Wenn ich einen fehlerhaften Stream mit PTS/PCR Wrap mit TSDR neu erzeuge, dann beschneide ich ihn und schreibe ihn neu.
Jetzt kommts! Wenn ich diesen neu erzeugten Stream in Freemake öffne, hängt sich Freemake wieder auf.
Wenn ich den ursprünglichen UPC-Stream in TSDR nochmals öffne, die Schneidmarken etwas verschiebe und den File ein 2. Mal erzeuge, dann konvertiert Freemake den neu erzeugten File problemlos.
Das war bisher schon rund 70 mal genau so der Fall. Anscheinend passiert beim 2. Mal neu erzeugen irgendwas, was beim 1. Mal nicht passiert.
Hat jemand von euch eine Idee dazu?

Da es mein erster Eintrag in ein Forum ist, bitte ich gleich um Entschuldigung, wenn ich irgendwelche Regeln verletzten haben sollte.

lg

Siegi

[Cypheros]

So ich hab die TS-Doctor-Fragen mal an die richtige Stelle verschoben.

1. Ein PCR-Wrap ist kein Fehler sondern eine technische Notwendigkeit. Der PCR-Timer ist ein 33 Bit-Zähler, der nach etwa 27 Stunden sein Maximum erreicht und dann wieder auf Null springt. Leider rechnen viele Programme nicht damit und stürzen ab oder machen sonstige Fehler. Darum sollte der Wrap entfernt werden indem alle Timer (PCR/PTS/usw.) so korrigiert werden, dass kein überlauf mehr stattfindet.

2. Keine Idee. Lösung: Der TS-Doctor erzeugt zu jedem Vorgang ein Log. Vergleiche die beiden Logs, dann siehst Du den Unterschied. Oder Poste die Logs hier, dann schauen wir mal drüber.

[siegi2000]

Hallo!

Danke für die Info. Ich vergleiche 2 Logs und melde mich dann.

lg Siegi

[Djfe]

eventuell hilft's zu checken ob der TSD auch so eingestellt ist, dass er die PCR-Wraps entfernt (kann man nämlich deaktivieren)

man kann auch dafür sorgen, dass die Timecodes komplett resetted werden, wenn kein PCR-Wrap da ist

Einstellungen -> Korrekturverhalten -> links unten: Timer-Korrekur
sollte auf "Bei PCR Wrap ohne weitere Fragen gestellt sein", bzw. auf "Immer patchen", wenn der Timer immer zurück gesetzt werden soll

Wenn "Fragen wenn nötig" ausgewählt ist, könnte hier schon ein Grund für die Probleme liegen (falls du die Frage während der Analyse mit Nein beantwortet hast)

[ErichV]

Bei der PCR-Wrap Entfernung ist es sinnvoll, die *.ts Datei zuerst zu fixen ("Neue Datei erzeugen"), bevor der Schnitt vorgenommen wird.
Beides gleichzeitig kann erfahrungsgemäß dazu führen, dass der PCR-Wrap nicht korrekt entfernt wurde.

[Djfe]

echt? ist mir neu!
@Cypheros kannst du das bitte fixen? sollte doch möglich sein

[Cypheros]

in 95% aller Fälle funktioniert das auch. Falls Du mal einen den 5% der Fälle hast, lad mir dir Aufnahme hoch.

[siegi2000]

Hallo!

Vielen Dank für die Infos. TSDR ist so eingestellt, dass die Timer Korrektur ohne zu fragen gemacht wird.
Ich habe heute wieder eine Aufnahme mit PTS Wrap erhalten.
Ich habe diese in einem Durchgang geschnitten und neu erzeugt. Der erhaltene File war nicht in Freemake konvertierbar.
Dann habe ich die Schneidemarken verändert und den File neu erzeugt. Dann hat es geklappt.
In den Logfiles gibt es auch wirklich einen relevanten Unterschied (neben den Unterschieden, die sich durch die veränderten Schneidemarken ergeben). Ich zeige hier nur den unteren Teil der Logs und markiere die unterschiedlichen Zeilen mit Smileys am Anfang.
Wie es aussieht wird nicht jedes Mal der Timer gepatcht, obwohl der einzigen Unterschied nur die veränderten Schneidemarken sind.
Diese Zeile fehlt beim ersten Mal neu erzeugen im Log:
Patching timer PCR/PTS/DTS/ESCR with offset 00:23:16.289

Hat wer von euch eine Idee dazu?

lg

Siegi


1. Logfile
....
Cut  in at PCR: 00:17:58.520 (26:08:49.643)
Cut out at PCR: 02:32:03.440 (28:22:54.563)
First packet  : 00273F81
Last packet   : 012E6A28
Using current PCR as start PCR

Starting at packet 00273F81 PCR: 00:17:58.483 (26:08:48.981)

PTS wrap > (33 bit) at packet 00517AD2 on PID 0C81 detected!
PTS wrap < (33 bit) at packet 00517B10 on PID 0C81 detected!
PTS wrap > (33 bit) at packet 00517B8F on PID 0C81 detected!
PTS wrap > (33 bit) at packet 00518094 on PID 0C8B detected!
PCR wrap between packet 005180D4 and packet 0051810E on PID 0C81 detected, PCR: 00:21:54.731
Cutting the end at packet 012E6A29 PCR: 02:14:05.407 (01:52:10.670)

File sizes:
            Z:\VDR Z\The_Tree_of_Life\2014-12-11.00.45.21-0.rec\The Tree of Life -  -  - ARTE VDR_fixed.ts 2,82 GB [CRC=B289B003]
Cutted packets at the beginning: 94303
Cutted packets at the end: 1754889
Discarded packets (to synch audio/video): 1204
Discarded packets (not needed): 1123197

PID stream sizes
$0C81: 2,6 GB
$0C8B: 195,3 MB

ERRORS : 0
WARNINGS : 0

Speed: 54,5 MBytes/sec
Duration: 00:00:56



2. Logfile
....
Cut in  at PCR: 00:16:37.080 (26:07:27.578)
Cut out at PCR: 02:33:22.160 (01:53:28.940) [with PCR wrap]
First packet  : 00244C1D
Last packet   : 013164B4
Using current PCR as start PCR
Patching timer PCR/PTS/DTS/ESCR with offset 00:23:16.289

Starting at packet 00244C1D PCR: 00:16:36.930 (26:07:27.428)
PTS wrap > (33 bit) at packet 00517AD2 on PID 0C81 detected!
PTS wrap < (33 bit) at packet 00517B10 on PID 0C81 detected!
PTS wrap > (33 bit) at packet 00517B8F on PID 0C81 detected!
PTS wrap > (33 bit) at packet 00518094 on PID 0C8B detected!
PCR wrap between packet 005180D4 and packet 0051810E on PID 0C81 detected, PCR: 00:23:16.284
Cutting the end at packet 013164B5 PCR: 02:16:45.768 (01:53:29.479)

File sizes:
            Z:\VDR Z\The_Tree_of_Life\2014-12-11.00.45.21-0.rec\The Tree of Life -  -  - ARTE VDR_fixed 4.ts 2,88 GB [CRC=D278EBCF]
Cutted packets at the beginning: 92948
Cutted packets at the end: 1559677
Discarded packets (to synch audio/video): 1140
Discarded packets (not needed): 1146917

PID stream sizes
$0C81: 2,7 GB
$0C8B: 199,2 MB

ERRORS : 0
WARNINGS : 0

Speed: 36,1 MBytes/sec
Duration: 00:01:27

[Cypheros]

Im ersten Fall wird der PCR-Wrap in der Analyse nicht erkannt. 

Das sollte nicht passieren

[siegi2000]

TSDR erkennt schon, dass es einen PTS Wrap gibt, da mir dieser bei der Überprüfung gemeldet wird. Ich überprüfe nämlich vor dem Schneiden alle Filme. Ich erzeuge nur Filme mit Fehlern und Wraps neu. Solche ohne Fehler und ohne Wraps konvertiere ich direkt in Freemake.
TSDR erkennt somit das Wrap-Problem, hats aber anscheinend bei Schneiden dann nicht gepatcht.

[Cypheros]

Er patched es nicht, wenn Du auf die Frage ob der Wrap behoben werden soll auf "Nein" klickst.

[Djfe]

Wird eventuell die Batchverarbeitung verwendet? Dann erscheint der Dialog nicht

[siegi2000]

Ich habe TSDR ist so eingestellt, dass die Timer Korrektur ohne zu fragen gemacht wird.
Damit, dass mir TSDR einen Wrap meldet (wie ich oben geschrieben habe), habe ich die Meldung im Log-File gemeint. Sorry das war unklar formuliert.

[Djfe]

am besten du lässt Cypheros das Original mal als Sample auf seinen FTP zukommen -> dann kann er sich das ansehen und den Fehler korrigieren

[Cypheros]

Gute Idee