Schnitt GOP-Erkennung

[pgroe]

Hi!

ist inzwischen schon einige Zeit her, dass ich wegen I-Frame Erkennung zum "Bildfehler-freien" Schnitt gefragt habe.
Für MPEG4 scheint das inzwischen ja auch ganz gut zu funktionieren. Deshalb wollte ich mal fragen, ob das für MPEG2 auch noch möglich ist, oder ob es vielleicht schon gehen sollte

Grüße,
pgroe

[Cypheros]

Steht auf dem Plan 

[Derrick]

..zumindest für mpeg2 ist das aber schon lange überfällig. Wenn ich die fummelei mit der einfachen navigation in pj.x vergleiche, braucht das rad ja auch nicht wieder neu erfunden zu werden

[Gunnar]

Also der Schnitt von MPG2-Streams mit dem TSD ist (bei mir) nur als Katastrophe zu bezeichnen. Noch nicht mal im Entferntesten wird der ausgeählte I-Frame beim Schnitt verwendet. Ist mir unerklärlich wieso TSD in dieser Funktion so versagt.

Gruß Gunnar

[Cypheros]

Sorry Gunnar,

Priorität = Priorität + 1

Kommt bald.

[Gunnar]

Danke.

Gruß Gunnar

[Derrick]

..vorerst kannst du ja pj.x zum beschnippeln von ts mit mpeg2 nehmen (1:1 binary copy). Falls noch eine reparatur ansteht bzw. irgendwelche streams entfernt werden sollen, kannst du im 2. schritt immer noch den TSD nehmen. Zum entfernen von werbung ist das aber weniger geeignet. Da würde ich pj.x zum demuxen nehmen und hinterher wieder zu PS muxen (z.b. mit imagomuxer).

[pgroe]

Hi.

finde ich super, dass das Feature bald kommt.

Mit muxen und demuxen ist das so ne Sache - ich hab da viele schlechte Erfahrungen mit Audio-Video-Synchronizität gemacht. Von daher ist mir die Lösung mit TSDoctor nicht nur wegen der Bequemlichkeit deutlich lieber.

Grüße,
pgroe

[Derrick]

Solange die verschiedenen elementarstörme die selbe länge haben, dürfte es keine probleme mit synchronität geben. Wenn es allerdings fehler in den aufnahmen gibt, können die einzelnen ströme nach dem demuxen unterschiedlich lang sein. dann gibt es natürlich asynchronen ton nach dem muxen. Pj.x gleicht allerdings die audiolänge dem videostrom an, sodass es wieder stimmt.

[Cypheros]

.... Pj.x gleicht allerdings die audiolänge dem videostrom an, sodass es wieder stimmt.

Kann der TS-Remuxer (unter Tools) im TS-Doctor zumindest für AC3-Ton inzwischen auch.

[pgroe]

Hallo!

Nachdem der letzte Post ja schon rund 2 Monate her ist, wollte ich mal mein Interesse nochmal deutlich machen und fragen, ob sich schon was getan hat.

LG pgroe

[Cypheros]

Hi, Mpeg2-Parsing wird bereits im TS-Remuxer verwendet um auf GOP-Anfang zu schneiden. Im Schnittmodul ist es aber leider noch nicht fertig.

[pgroe]

Freut mich zu hören, dass sich schon was getan hat. Bin gespannt darauf, wenn es fertig ist

[pgroe]

Ich habe gerade gesehen, dass in der neuen Beta die Funktion nun auch beim Schneiden dabei ist. Finde ich super!

Habe mir gleich die Beta heruntergeladen und werde sie mal kräftig testen

Grüße,
pgroe

[pgroe]

Hallo,

ich habe inzwischen einige Tests mit der I-Frame Funktion gemacht und musste leider feststellen, dass es hin und wieder nicht exakt gepasst hat.

Ich habe verschiedene Codecs (ffdshow hauptsächlich, daneben MS DTV-DVD, als Splitter Haali) und verschiedene Cut-Out / Cut-In Kombinationen probiert mit folgendem Ergebnis:
Habe ich sowohl Cut-Out, als auch Cut-In auf einen Frame, der neben dem Zeit-Code mit einem "I" gekennzeichnet war, gelegt, hatte ich zwar nur minimale Bild-Fehler, aber eigentlich nie einen "perfekten" Schnitt (ohne Bildfehler, was einen richtgen GOP-Schnitt ausmachen sollte).
Danach habe ich probiert, den Cut-Out einen Frame vor den I Frame zu legen, was die Bildfehler allerdings verschlimmert hat.
Als Drittes habe ich den Cut-Out und Cut-In jeweils auf einen Frame nach dem mit "I" markierten Frame gelegt und hatte einen Schnitt mit Bildfehler und einen "perfekten" Schnitt (ohne Bildfehler).
Das ganze habe ich mit beiden Codecs probiert - jeweils mit dem gleichen Ergebnis.

Quellmatierial war ein normaler, fehlerfreier TS-Mitschnitt eines DVB-S Streams (von RTL2).

Was mir noch aufgefallen ist: Die I-Frame-Suche (Knopf bei den 1F, 1Sek, 10Sek, usw. Sprungfunktionen) stoppt manchmal auf dem I-Frame, manchmal 1-2 Frames dahinter. Wem kann ich da mehr trauen, was die tatsächliche I-Frame-Position betrifft? Der Anzeige neben dem Zeitcode (rechts unten) oder der I-Frame-Suche? Oder liegt die Wahrheit irgendwo in der Mitte?

Desweiteren stellt sich noch die Frage, warum der Schnitt nun nicht immer "perfekt" ist? Ist die I-Frame Erkennung noch nicht zuverlässig (was in der Beta-Phase natürlich verständlich wäre, ich aber aufgrund verschiedener anderer Beobachtungen für die unwahrscheinlichere Variante halte) oder identifiziert der die I-Frames schon richtig, schneidet dann aber leider nicht exakt an der vorher markierten Stelle?

Vielen Dank schonmal für die Antwort!
Grüße,
pgroe