Sicherer Schnitt zwecks späterer Weiterverarbeitung

[geohei]

Hallo.

Mein ultimatives Ziel ist noch immer ...
1. .ts HD (H.264, AC3, ...) Überprüfung wegen möglicher Aussetzer bzw. Bild-/Tonfehler
2. Smart Encoding um framegenau schneiden zu können.

Also das was Project.X/Cuttermaran mit MPEG-2, MP2, AC3 konnte.

Zu 1. : TSD scheint hier das Richtige zu sein.
Zu 2. : Bin noch auf der Suche ...

Da ich meinen Berg an .ts Streams aber reduzieren will (die Platten füllen sich), möchte ich eine temporäre Lösung zu 2. Ich plane mittels TSD zu schneiden, aber nur auf den I Frames. Wenn ich dann einmal die richtige Schnitt Software gefunden habe, kann ich immer noch zu einem späteren Zeitpunkt framegenau nachschneiden.

M.a.W. ... ich will mit TSD am ersten I Frame vor dem gewünschten Schnitt und am ersten I Frame nach dem gewünschten Schnitt den In/Out Cutting Point setzen. Somit enthält der erste und der letzte GOP die gewünschten framegenauen Schnittpunkte.

Damit sollte ich später die GOPs an den Extremitäten framegenau schneiden können, oder?

Um ganz sicher zu sein dass ich keine Dummheit mache, möchte ich lieber hier nachfragen, ob meine Überlegung richtig ist. Wenn ich mich vertan habe sind die Streams weg!

[peterfido]

Ich bekomme trotz I-Frame vor und nach dem Schnitt gelegentlich Fehler. Diese sorgen am Ende dafür, dass der TV bei der Wiedergabe kurz an der Schnittstelle das Bild anhält. Der Ton läuft aber weiter. Ich würde sagen, da passt der Schnittpunkt nicht hundertpro (doch kein I-Frame ?). Meine Vermutung: durch die Nutzung der Filter werden diese dem Doc falsch gemeldet. Oder der Umstand, dass der Ton nicht in unmittelbarer Nähe zum Bild in dem Stream liegt. Das verkompliziert auch das Smart-Encoding. Soll also das Bild flüssig weiterlaufen, kommt es zu Zwitschereffekten / Sprüngen im Ton.

Manchmal läuft es auch sauber durch. Das nächste 'Problem' ist, dass die Sendeanstalten und das Leben schwer machen. Oft wird der Ton erst wenige Sekunden nach Werbeende wieder im richtigen Format gesendet. Dann kommt dann oft noch so ein 'Pling' mit einer Texteinblendung. Oft nervt auch die halbbildschirmfüllende und somit interessante Bilddetails verdeckende Werbung für eine besonders 'interessante' Sendung in Kürze mitten im Film. Gelegentlich lösche ich auch Aufnahmen einfach wieder. Z.B. weil nicht überall HD drin ist, wo HD drauf steht, ... 

Ansnonsten will ich die Aufnahmen nur für mich archivieren und da stören erkennbare Schnitte nicht wirklich.

[ErichV]

Wenn die Videos später noch framegenau geschnitten werden sollen, würde ich ca. fünf Sekunden Vor- und Nachlauf einplanen.
Insbesondere für den Smart-Rendering-Prozess bei H.264 Videostreams können Referenzen zu anderen Bildern notwendig sein, um Verpixelungen im Endprodukt zu vermeiden.
Bei klassischen MPEG-2 GOPs sollte hingegen ein Schnitt am ersten I-Frame vor und nach dem Film ausreichen.

[geohei]

Wenn die Videos später noch framegenau geschnitten werden sollen, würde ich ca. fünf Sekunden Vor- und Nachlauf einplanen.
Insbesondere für den Smart-Rendering-Prozess bei H.264 Videostreams können Referenzen zu anderen Bildern notwendig sein, um Verpixelungen im Endprodukt zu vermeiden.

Das wars was ich hören wollte!
Danke!

Diesbezüglich eine Frage - können Frames innerhalb eines GOPs auf Frames ausserhalb dieses GOPs verweisen (H.264)?

[ErichV]

Diesbezüglich eine Frage - können Frames innerhalb eines GOPs auf Frames ausserhalb dieses GOPs verweisen (H.264)?

Ich habe bei manchen H.264 Aufnahmen schon GOPs gesehen, die 1 bis 2 Sekunden der Wiedergabezeit ausmachen. I-Frames bilden hier nicht immer zwingend den Abschluss einer GOP und weisen daher Referenzen zu anderen Bildern auf. Programme, die Smart-Rendering beherrschen, wandeln das erste Frame üblicherweise in ein IDR-Frame um, welches Referenzen zu Frames, die dem besagten IDR-Frame vorausgehen, unterbinden soll.
Bildverweise außerhalb einer GOP sind mir unbekannt.

[geohei]

Ich habe bei manchen H.264 Aufnahmen schon GOPs gesehen, die 1 bis 2 Sekunden der Wiedergabezeit ausmachen. I-Frames bilden hier nicht immer zwingend den Abschluss einer GOP und weisen daher Referenzen zu anderen Bildern auf. Programme, die Smart-Rendering beherrschen, wandeln das erste Frame üblicherweise in ein IDR-Frame um, welches Referenzen zu Frames, die dem besagten IDR-Frame vorausgehen, unterbinden soll.

I-Frames sind bei H.264 AFAIK per Definition werder der Anfang, noch der Abschluss eines GOPs. Das sind die IDR Frames. Obwohl, ref. c't 10, 2015, Seite 142, kann man erkennen, dass ein P-Frames nach einem IDR-Frames auf eine anderes P-Frame vor (!) diesem IDR-Frames verweist. Das dürfte es doch nicht geben ... ?!

Bildverweise außerhalb einer GOP sind mir unbekannt.

Dachte ich bisher auch. Bin mir aber nicht mehr so sicher ...

Ich habe jetzt testweise einen H.264 SD & HD Stream mit TSD gefixed (10 Sekunden Vorlauf und 10 Sekunden Nachlauf), und anschliessend VideoReDo TVSuite 5.1.2 zwecks framegenauem Bildschnitt benutzt.

SD:
Stream nach TSD fixed: 515.833 KB (00:41:33)
Nach dem VideoReDo Schnitt: 544.631 KB (00:41:09)

VideoReDo hat also etwas hinzugefügt! Ein nachträgliches Fixen mit TSD kürzte den Stream etwas (PES Längenfehler wurde wieder angezeigt), aber es waren immer noch 537.111 KB  (00:41:09). VideoReDo fügt also etwas hinzu, was TSD beim Fixen nicht entfernt.

HD:
Stream nach TSD fixed: 2.424.594 KB (00:41:31)
Nach dem VideoReDo Schnitt: 2.424.290 KB (00:41:09)

Bei HD war das nicht der Fall. Ich schnitt um 21 Sekunden und die Datei war danach kleiner (wie man es erwartet). Ein nachträgliches Fixen mit TSD (PES Längenfehler wurde wieder angezeigt) reduzierten es weiterhin auf 2.415.966 KB  (00:41:09).

Das Endresultat nach SD & HD Schnitt mit VideoReDo konnte ich mir auf einer GigaBlue und am Rechner (W7, VLC) korrekt anschauen. Ausser bei der GigaBlue hat beim Ende mindestens 1 Sekunde gefehlt. Auf dem VLC war das nicht der Fall!

[ErichV]

I-Frames sind bei H.264 AFAIK per Definition werder der Anfang, noch der Abschluss eines GOPs. Das sind die IDR Frames. Obwohl, ref. c't 10, 2015, Seite 142, kann man erkennen, dass ein P-Frames nach einem IDR-Frames auf eine anderes P-Frame vor (!) diesem IDR-Frames verweist. Das dürfte es doch nicht geben ... ?!

Bei einigen H.264 Streams gibt es gar keine IDR Frames. Dort bilden dann die I-Frames (nicht zwingend jedes davon) den Anfang einer GOP.
Frames, die dem IDR-Frame folgen, dürfen im Prinzip keine Referenzen zu Bilder, die vor diesem IDR-Frame liegen, herstellen. Leider, wie man sieht, wird dieser Grundsatz in der Praxis nicht immer eingehalten. Deshalb, um auf Nummer sicher zu gehen, kann es kein Fehler sein, ein paar Sekunden vor und nach dem Ende der Aufnahme für den späteren Feinschnitt aufzuheben. Fünf Sekunden Vor- und Nachlauf waren bei mir bis dato immer ausreichend, du kannst aber auch gerne etwas mehr nehmen.

Dachte ich bisher auch. Bin mir aber nicht mehr so sicher ...

Ich habe jetzt testweise einen H.264 SD & HD Stream mit TSD gefixed (10 Sekunden Vorlauf und 10 Sekunden Nachlauf), und anschliessend VideoReDo TVSuite 5.1.2 zwecks framegenauem Bildschnitt benutzt.

SD:
Stream nach TSD fixed: 515.833 KB (00:41:33)
Nach dem VideoReDo Schnitt: 544.631 KB (00:41:09)

VideoReDo hat also etwas hinzugefügt! Ein nachträgliches Fixen mit TSD kürzte den Stream etwas (PES Längenfehler wurde wieder angezeigt), aber es waren immer noch 537.111 KB  (00:41:09). VideoReDo fügt also etwas hinzu, was TSD beim Fixen nicht entfernt.

HD:
Stream nach TSD fixed: 2.424.594 KB (00:41:31)
Nach dem VideoReDo Schnitt: 2.424.290 KB (00:41:09)

Bei HD war das nicht der Fall. Ich schnitt um 21 Sekunden und die Datei war danach kleiner (wie man es erwartet). Ein nachträgliches Fixen mit TSD (PES Längenfehler wurde wieder angezeigt) reduzierten es weiterhin auf 2.415.966 KB  (00:41:09).

Mich überrascht auf dem ersten Blick, dass die Aufnahme nach dem Schnitt durch VideoReDo bei dir kleiner ist als beim TS-Doctor. Dateien, wo Smart-Rendering zum Einsatz kommt, waren bei mir bis jetzt immer größer als beim TS-Doctor.
Allerdings hast du bei deinem Vergleich den Stream des TS-Doctors nur gefixt und nicht geschnitten. Würdest du mit dem TS-Doctor am ersten I-Frame vor und nach dem Film schneiden, so wird ersichtlich, dass die Dateien durch das Re-Encoding an den Schnittstellen immer größer sind. Mit anderen Worten: Der Stream des TS-Doctors ist bei dir deshalb größer, weil diese Aufnahme 22 Sekunden länger läuft.
Was mich eher zum Staunen bringt, ist die Tatsache, dass bei SD die Datei durch die Bearbeitung mit VideoReDo um vieles größer ist. Entfernt man mit dem TS-Doctor auch dort den überschießenden Anteil von 24 Sekunden, so ist es doch erstaunlich, dass durch Smart-Rending eine Datei entsteht, die um ca. 10 % mehr Datenballast mit sich schleppt. Dennoch kann auch hier noch etwas eingespart werden, indem die Datei nochmals durch den TS-Doctor geschickt wird (nebenbei wird auch gleich der PES Längenfehler auf einen sicheren Wert gepatcht). Deshalb sollte der Workflow, wie es auch von Cypheros in einem anderen Thread empfohlen wurde, wie folgt aussehen:

1. TS-Doctor
2. Smart-Rendering Software
3. TS-Doctor

Mit Referenzen außerhalb der GOPs hat dies in meinen Augen nichts zu tun.
Da du aber soeben gezeigt hast, dass P-Frames, die dem IDR-Frame folgen, auf andere Frames, die vor dem IDR-Frame liegen, verweisen, würde ich nicht unterschreiben, dass Bildverweise nur innerhalb einer GOP möglich sind. Andererseits glaube ich, dass eine solche Referenz im Extremfall nur zwischen zwei GOPs bestehen kann. Deshalb ist man meines Erachtens mit einem Vor- und Nachlauf von mind. fünf Sekunden auf der sicheren Seite.

[geohei]

Bei einigen H.264 Streams gibt es gar keine IDR Frames. Dort bilden dann die I-Frames (nicht zwingend jedes davon) den Anfang einer GOP.

Wie sieht mat in TSD eigentlich ob es sich um ein I- oder IDR-Frame handelt?

Fünf Sekunden Vor- und Nachlauf waren bei mir bis dato immer ausreichend, du kannst aber auch gerne etwas mehr nehmen.

Ack! Bei meinen Tests habe ich 10 Sekunden davor und danach genommen!

Mich überrascht auf dem ersten Blick, dass die Aufnahme nach dem Schnitt durch VideoReDo bei dir kleiner ist als beim TS-Doctor. Dateien, wo Smart-Rendering zum Einsatz kommt, waren bei mir bis jetzt immer größer als beim TS-Doctor.

Du redest vom HD Stream ...
Nein. Ist ja normal. Erstens fehlen 22 Sekunden und zweitens werden ja nur 2 GOPs neu berechnet! Das fällt nicht ins Gewicht!

Allerdings hast du bei deinem Vergleich den Stream des TS-Doctors nur gefixt und nicht geschnitten. Würdest du mit dem TS-Doctor am ersten I-Frame vor und nach dem Film schneiden, so wird ersichtlich, dass die Dateien durch das Re-Encoding an den Schnittstellen immer größer sind. Mit anderen Worten: Der Stream des TS-Doctors ist bei dir deshalb größer, weil diese Aufnahme 22 Sekunden länger läuft.

Die Streams von TSD habe ich folgendermassen bearbeitet.
Gewünschtes Cut-In Frame - 10 Sekunden - erster I-Frame davor
Gewünschtes Cut-Out Frame + 10 Sekunden + erster I-Frame dahinter
Alles in allem sind da also insgesamt 20-25 Sekunden zuviel im Stream!

Als Basis für den den VideoReDo Cut habe ich dann dieses TSD genommen!
(hatte ich vergessen zu erwähnen - sorry!)

Deshalb sollte der Workflow, wie es auch von Cypheros in einem anderen Thread empfohlen wurde, wie folgt aussehen:

1. TS-Doctor
2. Smart-Rendering Software
3. TS-Doctor

Genau das hat mir vorhin auch gedümpelt. Ich werde es in der Tat vorerst einmal so testen. Es ist allerdings sehr umständlich und zeitaufwendig! Scheint aber z.Z. das Optimalste zu sein wenn man unbedingt framegenau schneiden möchte.

BTW ... was ist vorzuziehen um framegenau zu schneiden? "Smart Cutter" oder "VideoReDo TVSuite"?

[ErichV]

Wie sieht mat in TSD eigentlich ob es sich um ein I- oder IDR-Frame handelt?

Beim TS-Doctor werden IDR-Frames auch als I-Frames in der Schnittanzeige interpretiert.

BTW ... was ist vorzuziehen um framegenau zu schneiden? "Smart Cutter" oder "VideoReDo TVSuite"?

Ich habe mich für VideoReDo entschieden, vor allem auch deshalb, weil der Funktionsumfang ein größerer ist (z. B. wandle ich ab und zu HD Aufnahmen für meine Eltern in eine DVD-Struktur um, damit sie diese dann auch auf ihrem DVD-Player abspielen können).
In Bezug auf den framegenauen Schnitt hat mir die VideoReDo TV Suite die saubersten Ergebnisse geliefert, wo andere Programme hingegen Artefakte an den Schnittstellen produziert haben (du wirst hier im Forum User finden, die wiederum das Gegenteil von mir behaupten ... anscheinend dürften hier auch die vielen verschiedenen Grafikkarten ein Wörtchen mitreden). Auf meinem WD TV Live Streaming Media Player konnte ich ebenso keine Verpixelungen an den Schnittstellen feststellen. Professionale Videobearbeitungsprogramme haben mir gezeigt, dass die Schnittstellen einwandfrei mit VideoReDo reencodiert wurden.
Am besten du testet jede für dich in Frage kommende Smart-Rendering Software einmal aus.