Cypheros Multimedia Forum

Moin,

eine Sache fiel mir juengst auf:
Es macht einen Unterschied, ob ich (von VTi-Enigma-KabelTV-Aufnahmen in .ts) z.B. vier Schnitte aufgeteilt "in einem Rutsch" schneiden lasse, oder ob ich die vier Schnittbereiche jeweils einzeln nacheinander schneiden lasse.

Beim "Einzel-Schnitt" findet sich immer ein Adaptation Field Packet (with Payload und PCR) als drittes Packet im Stream, und das fehlt bei den Folgedateien beim "Sammel-Schnitt". Die jeweils erste Datei weist in allen Faellen dieses Adaptation Field Packet auf.

Ist das so evtl. gar gewollt? Wenn ja, dann sei angemerkt, dass dies u.U. Programme welche den .ts weiterverarbeiten (oder anzeigen) sollen, durcheinander bringt bzw. bringen kann. Zumindest bei mir...

Das Verhalten ist auch zu beobachten, wenn ich eine andere Anzahl von Schnittbereichen festlege, oder z.B. Ausgabeformat .m2ts auswaehle. Die Strukturen von MP4 und MKV sind mir leider nicht so gelaeufig; da kann ich das nicht verifizieren.

Ich hab auch noch nicht ueberprueft, ob's vielleicht in V4 anders war...

Nein, Schnittverhalten hat sich nicht geändert. Es werden bei TS-Dateien weder Adaptationfields hinzugefügt, noch entfernt. Allerdings werden die Kabelnetzbetreiber immer sparsamer mit der Datenrate und komprimieren, was das Zeug hält. I-Frames werden seltener und auch alle anderen Systemdaten werden auf ein Minimum reduziert.

Schnelles Internet über Kabel ist heutzutage wichtiger als gute Bildqualität 

Unbenommen...

Aber ich fuerchte, ich habe mich (mal wieder, sorry) nicht richtig ausgedrueckt:

Ich persoenlich wuerde es besser finden, wenn bei beiden Schnittarten dieselben Ausgabedateien (mit Adaptation Field ;-)) erzeugt wuerden.
Aber grundsaetzlich kann ich mich auch mit der seriellen Einzelbearbeitung anfreunden.

Wie gesagt erzeugt der TS-Doctor keine Adaptation Fields und löscht auch keine. In der Regel trägt ein Adaptation Field den PCR und kommt so alle 20 bis 50 ms.

Ob der direkt vor einem I-Frame liegt an dem geschnitten wird oder nicht ist reiner Zufall.

Auch auf die Gefahr hin, rechthaberisch zu wirken und/oder zu nerven:

Wenn ich
- in einer Aufnahme mehrere Schnittbereiche festlege und diese Info in einer .tsdcuts-Datei speichere
- diese Schnittbereiche aufteile, d.h. in einzelne Ausgabedateien schreiben lasse
- danach in weiteren Anlaeufen immer dieselbe .tsdcuts einlese, und die weiteren Schnittbereiche einen nach dem anderen einzeln in eigene Ausgabedateien wegschreiben lasse (d.h. jeweils die uebrigen Schnittbereiche loesche)
- selbstverstaendlich ohne selber die Schnittbereiche an sich nochmal zu veraendern

dann
- ist die zweite Schnittbereichsdatei (und alle weiteren) um genau 1 Packet kleiner beim Sammelschnitt gegenueber den Einzelschnitten (188 Bytes bei .ts, 192 bei .m2ts)
- dieses 1 Packet mehr in den Einzelschnittdateien enthaelt immer ein Adaptation Field mit PCR, und das "fehlt" halt in den Sammelschnitteinzeldateien fuer eine saubere Weiterverarbeitung

Mir ging es nicht darum, dass der Doc irgendetwas von selbst hinzufuegen oder loeschen wuerde; das habe ich auch nicht behauptet. Aber er schreibt bei Einzelverarbeitung genau 1 Packet mehr (aus der Originaldatei!) in die weiteren Ausgabedateien als bei der Sammelverarbeitung. Dieses eine Packet mehr liegt immer ganz am Anfang (das dritte Packet im Stream/in der Datei), und es enthaelt das Adaptation Field mit PCR.

Dazu habe ich auch mal zwei .log-Dateien hier angehaengt (1x vom Sammelschnitt mit vier Ausgabedateien, 1x vom Einzelschnitt des zweiten Bereichs).
Zwar steht in beiden Logs, dass mit Packet 0000002E09DB gestartet wuerde, aber genau dieses eine, erste Packet fehlt in der Ausgabedatei beim Sammelschnitt.

(Die Ausgabedateien von V2.1.44 bei Verwendung derselben .tsdcuts aus V5 zeigen uebrigens dasselbe Verhalten, sind bei mir aber allesamt um genau 40ms [laut Log] groesser, was aber auch mit unterschiedlichen Doc-Einstellungen zusammenhaengen kann/wird. Das bestaetigt definitiv die Aussage, dass beim Schnittverhalten nichts geaendert wurde. Die hatte ich aber ebenfalls nicht infrage gestellt.)

Kleines Edit:
Wenn der Doc alle vier Schnittbereiche in eine einzelne Ausgabedatei schreibt, ist dieses Adaptation Field Packet mit PCR ebenfalls in der Ausgabedatei am Anfang der weiteren Schnittbereiche vorhanden. (Der HxD-Suchfunktion nach hexadezimalen Zeichenketten sei Dank!)
Damit bleibt fuer mich als einziger Schluss, dass das gesammelte Schreiben einzelner Schnittbereichsdateien fehlerhaft zu sein scheint. Auch wenn's schon immer so war.

Mach doch mal einen Screenshot mit dem TS Packet Viewer. Du wirst sehen, dass die ersten beiden Pakete immer eine PAT und eine PMT sind, egal wieviele Schnittbereiche.

Klar, aber auch dies war ja nie Gegenstand meiner Argumentation...

Ich hatte immer vom "dritten" Packet geschrieben.

Vielleicht helfen ja tatsaechlich Bilder vom TS Packet Viewer:
(ich habe zur Verdeutlichung, dass es sich tatsaechlich um dieselben Bereiche handelt, immer auf das entsprechende erste Packet positioniert, das ueberall enthalten ist)

Originaldatei:


Alle Schnitte in eine einzelne Ausgabedatei:


Der zweite Schnittbereich einzeln geschnitten:


Der Anfang der zweiten Ausgabedatei beim Sammelschnitt:


Hier sieht man (meiner Ansicht nach klar wie dicke Tinte), dass beim letzten Bild (nach PAT und PMT) das Packet 002707A3 aus der Originaldatei (mit dem Adaptation Field und PCR sowie Payload) fehlt, obwohl laut Log immer ab demselben Quellpacket haette exportiert werden sollen. Deshalb im naechsten Post die zugehoerigen Schnittlog-Dateien, denn ich habe "die maximale Anzahl von Dateianhängen pro Beitrag erreicht".

Aber wie auch immer:
Es ist Deine Entscheidung, das Verhalten konsistent zu programmieren, oder eben nicht. Ich habe ja eine funktionierende Umgehung im Doc, und muss halt jeden Schnittbereich einzeln schneiden (wenn's auch mit steigender Zahl an Schnittbereichen muehsam wird).
Und falls tatsaechlich mal wie angekuendigt frame-genaues Schneiden implementiert werden sollte, haette sich die Sache mit den Schnittbereich-Einzelschnitten fuer mich sowieso erledigt. Derzeit scheint sich auch das TSCutter.GUI vielversprechend zu entwickeln.

...und hier die angekuendigten Logdateien:

Hab ich momentan keine Lösung für. An dem eigentlichen Schnitt hat sich nichts geändert mit der neuen Version und ich will das zur Zeit auch nicht anpacken, da sonst die Gefahr zu groß ist, dass andere Probleme daraus entstehen.

Ich werde aber in einer zukünftigen Version diese ganze Schnitt und I-Frame-Suche überarbeiten.

Das kann ich gut verstehen, wenn's auch traurig (fuer mich!) ist... 

Aber offenbar wird diese Funktion auch nicht so ganz haeufig verwendet, sodass es bisher niemandem aufgefallen ist. Wie erwaehnt, passiert(e) dasselbe auch schon in 2.1.44, und noch aeltere Versionen habe selbst ich nicht mehr probiert.

Vielleicht bastel' ich mir in der Zwischenzeit selber was mit Raw Packet Copy, wenn's mich zu sehr stoert bei Aufnahmen mit mehreren Schnittbereichen. Die Nummern des "fehlenden" Packets am Anfang der Schnitte stehen ja im Log bereits drin.