Cypheros Multimedia Forum

Hallo zusammen,

ich hätte eine Frage zur Empfindlichkeit und internen Bewertung der Fehler- und Warnmeldungen im TS-Doctor nach dem Schneiden, Reparieren oder Anaylsieren.

In der Vergangenheit habe ich Warnungen oft ignoriert, weil ich davon ausgegangen bin, dass sie keinen sichtbaren Einfluss auf die Wiedergabe haben. Bei genauerem Hinsehen habe ich jetzt bei einer Aufnahme aber festgestellt, dass auch hinter manchen Warnungen komplette Datenblöcke fehlen können, die dann tatsächlich sichtbare Bildaussetzer verursachen – wenn man denn weiß, wo sie im Stream auftreten.

Mir geht es dabei nicht nur um reines Interesse, sondern vor allem darum, Aufnahmen zu kennzeichnen, bei denen solche Fehler vorkommen. So kann ich entscheiden, ob ich einen Film bei nächster Gelegenheit noch einmal aufnehme, falls er im Fernsehen wiederholt wird.

Aus diesem Grund habe ich mir eine kleine App in Python geschrieben, die die vom TS-Doctor erzeugte Log-Datei analysiert und die Ergebnisse nach meinen eigenen Kriterien bewertet (z. B. eigene Schwellenwerte oder Gewichtungen für bestimmte Fehlertypen). Aktuell arbeite ich an einer zweiten Version, die direkt die TS-Datei selbst analysiert – also wenn die Log-Datei gelöscht wurde –, um zu prüfen, ob ich auf ähnliche Ergebnisse komme wie TS-Doctor in der Log-Datei.

Meine App gibt z. B. folgendes Ergebnis aus:
Zeitstempel / Letztes Paket / Aktuelles Paket / Bedeutung
00:30:08.852 / 9 / 12 / Drei TS-Pakete fehlen in der Folge
01:04:55.593 / 12 / 3 / Mehrere Pakete übersprungen oder beschädigt
01:37:05.778 / 10 / 2 / Ebenso eine Lücke in der Datenreihe

Daher meine Frage an den Entwickler bzw. an die Community:
Gibt es im TS-Doctor selbst eine Möglichkeit, die Empfindlichkeit oder Bewertungslogik der Fehler- und Warnmeldungen anzupassen (z. B. über eine versteckte Option, INI-Datei oder Parameter)? Oder sind diese Einstufungen vollständig intern festgelegt?

Ich möchte den internen Ablauf nicht ,,nachbauen", sondern nur besser verstehen, wie flexibel die interne Bewertung ist, bevor ich meine eigene Analyse weiter ausbaue.

Viele Grüße

Michael

Ich kann zwar leider Deine Frage nicht beantworten, und kenne auch Dein Script nicht, moechte aber nichtsdestoweniger schon einmal drauf hinweisen, dass zwischen "9" und "12" nicht unbedingt nur DREI Pakete fehlen, sondern 3+x*16... mit "x ist Element der Natürlichen Zahlen inkl. 0"
Es haengt halt davon ab, ob Du auch bereits noch andere Counter beruecksichtigst, oder z.B. statt einem 188-Byte-TS einen 192-Byte-TS (eben mit einem zusaetzlichen Block Counter) vorliegen hast.

Im Log des Doc ist das ja aufgeteilt nach ES, aber in Deiner direkten TS-Analyse ist das selbstverstaendlich zu erwaegen.

Ansonsten: Auch wenn die Log vom Doc weg sein sollte, kann man diesen die TS-Datei ja einfach erneut pruefen lassen, und schon hat man eine frische .log. Der Doc braucht wahrscheinlich auch nicht (viel) laenger fuer die Analyse...

Es gibt da keine "Bewertung", nur simple Zähler für Warnungen(mögliche Fehler) und wirkliche Fehler.

Warnungen werden zum Beispiel bei Sprüngen des ContinuityCounters gezählt. Nicht immer bedeutet das nämlich, dass hier tatsächlich Pakete fehlen. Möglicherweise wurde sie bei der Aufnahme entfernt, da sie redundante Daten, wie Fülldaten oder ähnliches enthalten. Auch bei der Umschaltung der Regionalprogramme kommt es immer wieder zu solchen Problemen.

Der Fehler-Zähler hingegen, zählt tatsächliche Fehler, wie falsche CRC-Werte oder falsch formatierte Pakete (fehlerhafter Header, falsche Größe, etc.).

Der TS-Doctor repariert nach dem Schneiden beim Speichern einer Datei automatisch den Continuity Counter. Das ist wohl eine eingebaute ,,Reparaturmaßnahme", um den Stream formal wieder konsistent zu machen, aber die Sprünge sind natürlich noch real vorhanden.

Ein erneuter TS-Doctor-Lauf, als Prüfung einer fertig geschnittenen TS-Datei, erkennt diese Sprünge nicht mehr, weil der Continuity Counter beim Export ,,repariert" wurde. Die Datei ist formal in Ordnung, enthält aber die drei inhaltlichen Lücken weiterhin.

Zitat von: Cypheros am Oktober 22, 2025, 19:07:53Es gibt da keine "Bewertung", nur simple Zähler für Warnungen(mögliche Fehler) und wirkliche Fehler.

Warnungen werden zum Beispiel bei Sprüngen des ContinuityCounters gezählt. Nicht immer bedeutet das nämlich, dass hier tatsächlich Pakete fehlen. Möglicherweise wurde sie bei der Aufnahme entfernt, da sie redundante Daten, wie Fülldaten oder ähnliches enthalten. Auch bei der Umschaltung der Regionalprogramme kommt es immer wieder zu solchen Problemen.

Der Fehler-Zähler hingegen, zählt tatsächliche Fehler, wie falsche CRC-Werte oder falsch formatierte Pakete (fehlerhafter Header, falsche Größe, etc.).

Vielen Dank für die Erklärung – das ergibt absolut Sinn.

TS-Doctor unterscheidet ja bewusst zwischen formalen Fehlern und bloßen Warnungen, da ContinuityCounter-Sprünge nicht zwangsläufig echte Datenverluste bedeuten müssen.

Meine kleine Analyse-App setzt genau an diesem Punkt an: Sie interpretiert diese Sprünge nicht rein technisch, sondern aus praktischer Sicht – also im Hinblick auf tatsächlich wahrnehmbare Störungen im Bild oder Ton.

Damit ergänzt sie TS-Doctor für meine Zwecke sinnvoll, indem sie die Warnungen aus der ersten Logdatei gezielt auswertet und sichtbar macht, wo sich in der Wiedergabe möglicherweise etwas bemerkbar macht.

Mit anderen Worten: TS-Doctor sorgt für einen formal korrekten Transportstream, meine kleine App hilft, die reale Wiedergabequalität zu beurteilen.

Zitat von: tsduser am Oktober 22, 2025, 16:40:19Ich kann zwar leider Deine Frage nicht beantworten, und kenne auch Dein Script nicht, moechte aber nichtsdestoweniger schon einmal drauf hinweisen, dass zwischen "9" und "12" nicht unbedingt nur DREI Pakete fehlen, sondern 3+x*16... mit "x ist Element der Natürlichen Zahlen inkl. 0"
Es haengt halt davon ab, ob Du auch bereits noch andere Counter beruecksichtigst, oder z.B. statt einem 188-Byte-TS einen 192-Byte-TS (eben mit einem zusaetzlichen Block Counter) vorliegen hast.

Im Log des Doc ist das ja aufgeteilt nach ES, aber in Deiner direkten TS-Analyse ist das selbstverstaendlich zu erwaegen.

Ansonsten: Auch wenn die Log vom Doc weg sein sollte, kann man diesen die TS-Datei ja einfach erneut pruefen lassen, und schon hat man eine frische .log. Der Doc braucht wahrscheinlich auch nicht (viel) laenger fuer die Analyse...

vielen Dank für den Hinweis – genau solche Details sind hilfreich!

Ja, der Continuity Counter ist ja nur 4 Bit breit und läuft nach 15 wieder auf 0, sodass theoretisch zwischen ,,9" und ,,12" eben nicht zwingend nur drei Pakete fehlen, sondern 3 + x·16. Das berücksichtige ich auch in meiner Auswertung, um den Abstand korrekt zu interpretieren.

Bei der Analyse gehe ich immer von einem Standard-188-Byte-TS aus (ohne zusätzlichen Block-Counter), da TS-Doctor seine Logs ja ebenfalls auf dieser Basis erzeugt.

Meine App nutzt ausschließlich die Werte aus der ersten TS-Doctor-Logdatei – also die, die beim Schneiden entstehen – und wertet daraus die Sprünge aus. Damit kann ich nachvollziehen, wo es im Stream tatsächlich zu erkennbaren Unregelmäßigkeiten gekommen ist.

Dein Hinweis mit dem erneuten Log-Durchlauf ist auch gut – aber nach dem Export sind die Sprünge ja ,,geglättet".

Ja, OK. Mein Missverstaendnis...
Deswegen pruefe ich auch immer die (hoechstens per Raw Cutter vorne und hinten gekuerzte) QUELL-Datei. Die liefert bei jedem erneuten Durchlauf eine gleichlautende Logdatei.

Was der Doc beim Speichern (egal ob mit oder ohne Schnitt) alles mit dem .ts anstellt, kann ich ja nicht (oder nur in Details auf einer hoeheren Ebene) beeinflussen. Wie z.B. das Abschneiden des 4-Byte-(!)-Counters bei den nicht gerade unueblichen 192-Byte-Streams, der den gesamten TS-Stream "absichert" und nicht nur den jeweiligen ES.

PS: Ich selber bin mit der Interpretation von "Fehler" und "Warnung" im Doc auch nicht immer einverstanden... ;-)

Zitat von: tsduser am Oktober 23, 2025, 07:09:43Was der Doc beim Speichern (egal ob mit oder ohne Schnitt) alles mit dem .ts anstellt, kann ich ja nicht (oder nur in Details auf einer hoeheren Ebene) beeinflussen. Wie z.B. das Abschneiden des 4-Byte-(!)-Counters bei den nicht gerade unueblichen 192-Byte-Streams, der den gesamten TS-Stream "absichert" und nicht nur den

Im "üblichen" DVB-Format werden nur 188 Byte Pakete gesendet (Sat, Antenne, Kabel). Die 192 Byte Pakete (BDAV-Format/.m2ts) stammen von den Bluray-Playern und wurde von Sony ersonnen. Wikipedia: https://en.wikipedia.org/wiki/.m2ts
Mit den zusätzlichen 4 Bytes wird nichts abgesichert. Das ist ein zusätzlicher Timer und ein paar Copyright-Bits, welche vom Sat-Receiver eingefügt werden.

Wenn du unbedingt willst, kannst du die Aufnahme ja auch im BDAV/.m2ts-Format speichern, dann bleiben die 4 Bytes erhalten, bzw. werden eingefügt, wenn nicht vorhanden.

Zitat von: tsduser am Oktober 23, 2025, 07:09:43PS: Ich selber bin mit der Interpretation von "Fehler" und "Warnung" im Doc auch nicht immer einverstanden... ;-)

Nunja, aber wenn TS-Pakete fehlen sollte das definitiv als "Fehler" und nicht als "Warnung" interpretiert werden.

Es sollte aber als "Warnung" verstanden werden ob es sich nicht vielleicht um ein Empfangsproblem handelt, denn diese Warnungen habe ich immer mal wieder gehabt.