Stream wird nicht repariert

Begonnen von dip, Mai 29, 2010, 11:44:10

« vorheriges - nächstes »

dip

Ich verwende SmartCutter zum Schneiden von ts streams, die ich mit meiner Dreambox DM8000 aufgenommen habe. Manchmal scheinen die streams Fehler zu enthalten, weil SmartCutter beim Einlesen des Streams abstürzt. Ich habe ein entsprechendes Testfile zu den Programmierern von SmartCutter geschickt und als Antwort bekommen:

It turns out, the previous sample's last frame is broken. Sadly, it's a key frame. This crashes the program. If we eliminate that broken frame manually, Smart Cutter can read in and process the sample correctly.

Es ist zwar eine Version angekündigt, die dieses Problem beheben soll, bisher ist die Version aber noch nicht verfügbar.

Ich habe daher versucht mit TS Doctor die Datei zu reparieren und mir deshalb eine Lizenz von TS Doctor gekauft. Leider sagt TS Doctor, dass keine Fehler enthalten sei und die von TS Doctor "gefixte" Version bringt SmartCutter auch zum Abstürzen.

Ich wollte eine solche fehlerhafte Datei beifügen, dies ist aufgrund der Größe (5MB bzw. 9MB) nicht möglich. Wie kann ich denn eine solche Datei mal hochladen, damit geprüft werden kann, ob darin tatsächlich kein Fehler enthalten ist oder der Fehler von TS Doctor nur nicht erkannt wird? Ich habe sowohl die aktuelle Version 1.0.45 als auch die Beta Version 1.0.47 ausprobiert.

Wenn ich übrigens die Datei durch ts4np durchlaufen lasse, stürzt anschließend SmartCutter nicht mehr ab. Allerdings sind dann die PID gelöscht, so dass ich die Datei nur noch bedingt auf meiner Dreambox verwenden kann. Wenn ts4np den Fehler beseitigen kann, müsste das soch auch mit TS Doctor gehen, oder?

Cypheros

Hi,

stimmt! Der TS-Doctor sollte die Datei reparieren sofern sie wirklich defekt ist. Du kannst mir das Testfile einfach mailen unter support ät cypheros.de

Gruß
Cypheros

dip

Hallo Cyheros,

ich habe gerade die zwei testfiles mit zwei e-mails geschickt.

Mal schauen, ob du etwas ungewöhnliches daran finden kannst.

Viele Grüße
Dieter

Cypheros

Hallo,

habe mir die Dateien gerade eben angeschaut und konnte keinen Fehler im Stream finden. Habe auch mit anderen Tools die Streams untersucht und nichts problematisches gefunden. Die Dateien haben tatsächlich ein I-Frame am Ende aber keinen Fehler. Da bei Videostreams keine Länge angegeben wird bei PES-Paketen, könnte es natürlich sein, dass das letzte Paket noch unvollständig ist. Eine Aufnahme endet ja ganz spontan und in den meisten Fällen nicht am Ende eines PES-Pakets. Das ist kein Fehler sondern ein ganz normaler Effekt.
Ich sehe das eher als ein Programmfehler beim Smartcutter.

Gruß
Cypheros

dip

Danke für die schnelle Antwort.

Ist natürlich gut möglich, dass SmartCutter eine eigentlich zulässige Konstellation nicht akzeptiert und abstürzt. Ich hoffe ja auch auf eine entsprechende gefixte Version (wird bereits seit zwei Wochen ständig angekündigt...).

Gewundert hat mich nur, dass nach Durchlaufen von ts4np der Stream plötzlich in SmartCutter funktioniert. Hier scheint ts4np also irgendetwas mit dem problematischen Frame zu machen.

Bei den streams handelt es sich immer um Sat-Aufnahmen, die natürlich nach Ablauf der programmierten Zeit einfach gestoppt werden. Da ist dann das Ende vermutlich irgendwo. Hast du noch eine Idee, wie ich die streams fixen könnte, so dass das Ende "sauberer" ist (was auch immer das heißen mag). Soweit ich dich verstanden habe, wird das über TS Doctor nicht gehen, weil es eigentlich kein Fehler im stream ist, oder?

Viele Grüße
Dieter

Derrick

..schneid doch einfach mit dem tsdoc ein kleines stück hinten ab ;)

Das ist sowieso sone sache mit den schnitten bei H.264. Die gops sind teilweise mächtig lang. Wenn ich z.b. bbc hd schneide, gehe ich 1s vom gewünschten anfang zurück. Dann kommt das bild beim player wie gewünscht beim start. Der wunsch nach framegenauen schneiden scheint mir dann auch eine ziemliche illusion. Was wir empfangen ist zwar qualitativ i.o. aber es ist ein endprodukt, das nicht zum genauen schnitt gedacht ist. Deshalb sind die HD feeds meist auch in mpeg2_4:2:2.


www.cypheros.de