Zurückvorspulen ruckartig nach Bearbeitung von Filmen mit TS Doctor / VU+-Receiv

[nyenyon]

Hallo,

ich habe ein VU+ Ultimo 4K und nutze den TS Doctor um Werbung und Überhänge in Filmen zu entfernen. Mir ist jedoch aufgefallen, dass das Vor/Zurückspulen nach der Bearbeitung der Videodatei sich anders verhält. Bei dem Original kann man, vor allem wenn man schnell zurück/vorspult (so 32x, 64x) die Bilder schnell vorbeihuschen sehen, Bei den Filmen nach der Bearbeitung ist das nicht der Fall. Es ist stark ruckartig und es werden bedeutend weniger Bilder angezeigt (so z.b. alle 5 Sekunden, obwohl ich 32x zurückpule). Auf das Spulgeschwindigkeit scheint es keine Auswirkung zu haben. Er spult genauso schnell. Nur eben werden die Bilder bedeutend weniger "aktualisiert".

Ich hoffe ich konnte das irgendwie verständlich machen. Gibt es dafür eine Lösung/Option?

Besten Dank
  nyenyon

[Cypheros]

Das passiert, wenn die Index-Dateien fehlen für die I-Frames.

Wenn Du die Aufnahme von Receiver auf den Rechner holst, muss Du die Zusatzdateien .eit , .ts.ap, .ts.sc, .ts.meta ebenfalls mit kopieren.
Der TS-Doctor erstellt für die neue geschnittene Aufnahme dann die entsprechenden Index-Dateien neu.

Diese müssen dann ebenfalls wieder komplett auf die VU+ in das Verzeichnis wo die Aufnahmen sind, hineinkopiert werden. Anschließend sollten auch die Bilder wieder wie gewohnt aktualisiert werden.

Alternativ kannst Du über Werkzeuge/"TS Index Creator" die wichtigen Index-Dateien .ts.ap und .ts.sc nachträglich erstellen.

[nyenyon]

Eigentlich mache ich das auch so.... Meine VU speichert es alles direkt auf ein NAS und ich bearbeite sie auch direkt von dort aus.... Der Neue Film hat dann auch alle diese Dateien. Ich schaue aber am Wochenende nochmal genauer hin und melde mich dann...

[Cypheros]

Sind das H.264 oder H.265 (DVB-T2) Aufnahmen?

[nyenyon]

das sind h265 (DVB-T2HD) Aufnahmen.

Nach dem Schneiden gibt es zwar die ts.sc Dateien, aber keine ts.ap-Datei. Wenn ich das über Werkzeuge versuche und dann die ts-Datei auswähle, passiert nichts: keine ts.ap-Datei und auch keine Reaktion/Antwort vom TS-Doctor, dass er irgendetwas gemacht hat...

[nyenyon]

Hier mal ein Beispiel. Das Original.png kommt von der Aufnahme durch die VU. Geschnitten.png sind die Dateien nach dem Schnitt.

[nyenyon]

noch was: die Generierung der sc/ac-Datei habe ich in den Optionen standartmäßig aktiviert...

[nyenyon]

ahh. verstehe...

ich kann ggf. mal eine Aufnahme zur Verfügung stellen...

[Cypheros]

Ja, wir sind da dran. Index-Erstellung bei Enigma für H.265 funktioniert noch nicht.

[nyenyon]

cool 

[Cypheros]

Die aktuelle Version 2.1 erstellt auch für H.265 die entsprechenden Index-Dateien für Enigma.

[Moonbase]

Ketzerische Frage: Kann es sein, dass die Sachen nicht gut gemuxt werden nach dem Schnitt?

Wenn ich (Beispiel) SD-Material schneide (2.1.22/2.1.26) und mir danach das Video (.ts) mit z.B. VLC oder KODI ansehe, scheinen Sprünge VORWÄRTS viel größere Schritte zu machen als Sprünge RÜCKWÄRTS – die gehen entweder in superkleinen Schritten oder springen gar VORWÄRTS.

Lustigerweise kann ich diese .ts-Datei dann über MKVToolnixGUI remuxen (in einen .mkv container) und das Seeken funktioniert perfekt!

[Cypheros]

Der Mux hat nichts mit den Sprüngen bei VLC und Kodi zu tun, da eine TS-Datei keinen Index für die Sprünge enthält. Darum brauchen Enigma-Receiver die Indexdateien .sc und .ap.

MKV ist ein ganz anderes Container-Format.

Also nicht Äpfel mit Birnen vergleichen.

[Mam]

Vorwärtssprünge sind vom Prinzip her immer "gröber", als Rückwärtssprünge.

Das liegt an der Komprimierung.
Man kann ja im Vorfeld nie genau wissen, wieviel Platz die nächste Szene hat. Die Datei wird also um einen "geschätzten Mittelwert" weit "vorgespult". Anschließend wird dann weitergelesen, bis wirklich wieder ein stabiles Bild gefunden wurde. Dabei kommt es natürlich oft vor, dass der Mittelwert zu groß gewählt war und man dadurch den richtigen Zielpunkt überspringt und beim nächsten Punkt landet.

Rückwärts hingegen ist einfacher. Da liegen die dekodierten Daten noch im Cache und dieser wird durchsucht, um den letzten Zielpunkt aufzusuchen. Erfolt der Rückwärtssprung allerdings in einen Bereich, der zu weit entfernt ist, als er noch im Cache sein könnte, so wird dieselbe Methode angewandt, wie bei Vorwärtssprüngen. Dann landet man meistens auch an der falschen Stelle.

Diese Dinge laufen innerhalb der (De)Codecs ab, der TS Doc hat darauf keinen Einfluß, er übermittelt nur den gewünschten Zielpunkt. Codecs unterschiedlicher Ersteller implementieren das natürlich jeder anders, so dass LAV Filter andere Ergebnisse liefern, als Microsoft oder Elgato. Unter Umständen sollte man deshalb mal die Codecs wechseln und ausprobieren, welcher mit dem vorhandenen Videomaterial am besten zurechtkommt. Das kann natürlich von Video zu Video wechseln...

Man könnte das Verhalten deutlich verbessern. Aber das würde beim Laden der Datei einen vollständigen Scan aller Frames erfordern, wobei erkannte IFrames in eine Liste eingetragen werden (die jeweilige Dateiposition). So macht es z.B. Adobe Premiere. Dieser Durchlauf dauert aber je nach Material bis zur Originalspielzeit des Videos und bei einigen Codecs (meist den "Hardwaredecodern") kann man die Dateiposition gar nicht korrekt auslesen.

[Moonbase]

Man lernt jeden Tag dazu ... danke für die interessante Erklärung!