splitt option, die 2te

[CharlyH]

Hallo!

Zum Einstand:
Als Fan von ds.jar habe ich mich riesig darüber gefreut, das Du dvb.matt einen Weg gefunden hast, dieses starke Projekt doch in irgendeiner Form fortzuführen. Und dann als Open Source ... einfach Spitze. Besten Dank.


Aber zur Sache:
Ich beschäftige mich seit ein paar Tagen (nein, falsch ... Nächten) mit dem Splitting während des Konvertierens. vollständige Berücksichtigung der cut-Points aus dem Vorschau-specials-Dialog (nicht nur des Start-cuts)
Koordination mit der Volume-splitting option
verschiedene Methoden bei der Behandung der Teile
Dabei ist mir die folgende Erscheinung aufgefallen: (mit der aktuellen v0.81.4)Quell-Datei: dBox 1, R2D2-DVB2000-Rec v1.19d, Länge 641.198.080 Bytes
Sender VIVA-tv (Astra 19.2 Ost), MPEG2-Video/-Audio, muxed on the fly

Dateilänge nach MPG=>M2P Konvertierung ohne Splitt: 638.536.357 Bytes
Splitting mit 305MB => Teil 1: 319.817.191 Bytes
=> Teil 2: 318.666.250 Bytes
-------------------------------------------------
=> Summe: 638.483.441 Bytes

Splitting mit 203MB => Teil 1: 212.862.634 Bytes
=> Teil 2: 212.861.435 Bytes
=> Teil 3: 212.699.936 Bytes
-------------------------------------------------
=> Summe: 638.424.005 Bytes

Splitting mit 153MB => Teil 1: 160.432.850 Bytes 159.385.541 Bytes
=> Teil 2: 160.433.454 Bytes 159.384.229 Bytes
=> Teil 3: 160.432.424 Bytes 159.384.051 Bytes
=> Teil 4: 156.869.392 Bytes 159.384.662 Bytes
152MB => Teil 5: 254.649 Bytes
-------------------------------------------------
=> Summe: 638.168.120 Bytes 637.793.081 Bytes
Verlorengehende Pakete habe ich sowohl optisch, als auch beim Debuggen erstmal nicht finden können.
Vielleicht findet ja einer von Euch, der sich mit MPEG besser auskennt als ich, einen Fehler oder eine andere Erklärung für diese Abnahme der Gesamtsumme, je mehr Teile es werden. (Eine Neue Platzspar-Methode habe ich da ja sicher nicht entdeckt :D )

Die entstehenden herrenlosen B-Frames an den Schnitten zu entfernen, kann doch nicht soviel ausmachen und das sollte doch eigentlich auch nur im demux-Modus passieren.

Das Demux-Log zeigt keine Auffälligkeiten oder Fehler im Stream.
Ausser vielleicht "-> 16986 stereo/jointstereo change(s) detected...", aber das hat VIVA verbrochen.

mfg CharlyH

[dvb.matt]

MPG=>M2P Konvertierung ... andere Erklärung für diese Abnahme der Gesamtsumme
yap.

einfach mal die JCheckBox("toX: ensure 1st PES-packet start with video") ausschalten..
(sonst werden alle anderen Pakete bis zum ersten IMHO I-Frame VideostartPack verworfen, weil manche Spieler es nicht mögen, wenns dem nicht so ist)
das gilt dann natürlich für jeden Splitt-Teil..


mfg

[CharlyH]

Danke.
Dieses Verfahren erklärt auch die schwankende Größenordung des Verlusts. Der Abstand zwischen diesen I-Frames liegt nach meiner Erfahrung meist zwischen 200 und 400kB. Je Schnitt kann also der Verlust zwischen fast Null und diesem Maximalwert liegen ... und das kommt hin.

Irgendwie ist das Ausschalten aber auch nicht die entgültige Lösung.
Vielleicht sollte ich mal versuchen, den Splitting-Algo anzupassen, damit direkt vor diesem I-Frame gesplittet wird, statt die Pakete zu verwerfen. Oder eins vorher.
Na mal sehen, ob ich das hinkriege. 'N bisschen Quellcode studieren und üben muß ich da bestimmt noch. :)

cu cH.

[dvb.matt]

wie wärs denn der Einfachheit halber vorerst z.B. 1MB Overlap beim Splitt einzustellen?

mfg

[CharlyH]

:D Zu einfach. Lern ich ja nix bei. :D Und eigentlich hab' ich sowieso nur schriftlich sichtbar nachgedacht.
Zum anderen hätte ich rein gefühlsmäßig am liebsten eine reversible Methode. Also mit der Mögichkeit, ...

Kurze Unterbrechung.
Ich muß mal schnell jubeln ... Tooor (BRD - Berti's Scotties, Min.26 Bobic, 1:0) :shock: :roll: ... Rudi, Rudi, Rudi. Delling raus, Delling raus. :D :D :D
Mann, kommentieren Delling und Netzer heute aber stromlinienförmig. :D

... die Teile wieder zusammen zu bauen und danach wieder die Quelldatei zu haben (jedenfalls mit möglichst wenigen binären und gar keinen sichtbaren Unterschieden). Mhh ... könnte man mit dem 1MB Overlap schon hinbekommen. Aber wohl nicht so leicht. Vielleicht mit Hilfe des Timecodes...

Verflixt, der war ja schon wieder von Bobic fast drin. Und einen Elfer gibts auch noch. Jaaa (49 Min. Ballack, 2:0) ... da ist ja richtig was los. :!:
Ich muß jetzt erstmal das Spiel gucken. Bis später.

[CharlyH]

So, da bin ich wieder. Der Vollständigkeit halber:
Den Schotten ist in der 60. nur noch das 2:1 gelungen. Danach hat man aber auf jedenfall nicht gesehen, daß wir ab der 67. wegen Gelbrot einer mehr waren. Trotzdem gute Leistung, bei dem Regen.

Ich bin mir nicht ganz im Klaren, ob X.java das Stück mit dem Overlap-Timecode nicht vielleicht schon im Griff hat... . Muß ich direkt mal testen.

Die andere Sache habe ich inzwischen auch probiert, allerdings mit mäßigem Erfolg.einfach mal die JCheckBox("toX: ensure 1st PES-packet start with video") ausschalten.Leider ist diese Option offenbar noch nicht die entgültige Erklärung. Veränderungen sind zwar vorhanden, bleiben aber relativ gering und der Gesamttrend ist leider unverändert. Dabei dachte ich wirklich, das wär's gewesen.
Dateilänge nach MPG=>M2P Konvertierung ohne Splitt: 638.536.357 Bytes
Splitting mit 305MB => Teil 1: 319.817.191 Bytes
=> Teil 2: 318.670.338 Bytes
-------------------------------------------------
=> Summe: 638.487.529 Bytes

Splitting mit 203MB => Teil 1: 212.862.634 Bytes
=> Teil 2: 212.861.427 Bytes
=> Teil 3: 212.704.024 Bytes
-------------------------------------------------
=> Summe: 638.428.085 Bytes

Splitting mit 153MB => Teil 1: 160.432.850 Bytes 159.385.541 Bytes
=> Teil 2: 160.433.146 Bytes 159.384.205 Bytes
=> Teil 3: 160.432.408 Bytes 159.384.027 Bytes
=> Teil 4: 156.877.568 Bytes 159.384.638 Bytes
152MB => Teil 5: 264.581 Bytes
-------------------------------------------------
=> Summe: 638.175.972 Bytes 637.802.992 Bytes
Steht die Frage, worauf das zurückzuführen ist? Funktioniert da das Abschalten nicht richtig? Woran könnte es sonst noch liegen...

[dvb.matt]

die Teile wieder zusammen zu bauen und danach wieder die Quelldatei zu haben
das sollteste so auch erreichen, wenn der beschriebene Knopp aus ist. (und dann ohne Overlap)
jedenfalls was den Inhalt der transportierten IDs/PIDs angeht, die Verpackung dagegen ist aber meistenteils nicht mehr 1:1. probiers halt mal aus.

nicht die endgültige Erklärung
es gibt da z.B. noch stuffing Packs, die (immer) verworfen werden. (0xBE)
IMO werden die von deiner verwendeten SW generiert.

mfg

[CharlyH]

die Teile wieder zusammen zu bauen und danach wieder die Quelldatei zu habendas sollteste so auch erreichen, wenn der beschriebene Knopp aus ist. (und dann ohne Overlap)Ja, nich'wahr, das hatte ich mir nach Deiner ersten Erklärung oben eigentlich auch gedacht und mich dann gewundert, weil's nichts wurde.
jedenfalls was den Inhalt der transportierten IDs/PIDs angeht, die Verpackung dagegen ist aber meistenteils nicht mehr 1:1. probiers halt mal aus.Die Teile zusammen müßten also zwar nicht das Ur-Quellfile selbst ergeben, aber das was man erhält, wenn man das Quellfile ohne splitting durch die Konvertierung laufen ließ. Deshalb habe ich ja auch diese Länge als Vergleichsbasis mit angegeben und nicht die Ur-Länge.
Mehr als die Längenangaben zur Überprüfung zu benutzen, kann ich leider momentan noch nicht. Vielleicht werde ich ja in einiger Zeit mehr zu MPEG auf Paket- und Bitstream-Ebene gelernt haben, so daß ich dann in den Stream reinkriechen kann. Aber das dauert noch etwas :D
nicht die endgültige Erklärung es gibt da z.B. noch stuffing Packs, die (immer) verworfen werden. (0xBE)
IMO werden die von deiner verwendeten SW generiert.
Das solche vom DVB2k-Rec generiert werden, habe ich auch schon festgestellt. Ich muß mich mal informieren, wozu die eigentlich gut sind. Aber die werden ja, wie Du schon sagst, immer verworfen. Also auch bei der Konvertierung ohne splitting, mit deren Ergebnis ich vergleiche und zu dem ich nach dem Wiederzusammensetzen eigentlich wieder kommen sollte. Die sind aus der Vergleichsbasis also schon raus.

[CharlyH]

So, hat ja etwas gedauert.
Jetzt habe ich die verantwortliche Code-Sequenze für dieses Verhalten aber lokalisiert (: Feature, nicht Bug!).
Gilt für das Splitting von MPG-Files: @X.java (~line 10375), @class makeVDR, @method writeMPG()
if (i==IDs.size()) {
if (newID!=0xE0 && !video && cBox[23].isSelected())
return options; // must start with video
--> data = searchHeader(data,type,overhead); // 'vergessliche' Funktion ;)
if (data.length==0)
return options;
IDs.add(""+((newID>0xDF)?newID:(0x100+newID)));
}
Aufruf von: @class WORK (~line 5450), @method vdrparse()
else if (ToVDR==2)
options = makevdr.writeMPG(data,options,demux,6);
In der gegenwärtigen Form wird ein Volume-splitt stur nach soundsoviel Megabytes gemacht. Wann da im Stream ein Systemheader oder ein I-Frame (oder was auch immer) kam oder kommt, wird nicht beachtet, sondern einfach zum nächsten Volume gesprungen. Einzig für komplette Pakete wird gesorgt. Die Splitt-Funktion ist also noch ziemlich rudimentär.
Die aufgeführte Code-Sequenz sucht am Anfang eines neuen Files (so auch eines neuen Volumes) erst mal nach einem Systemheader und 'vergisst' so an jedem Splitt die Daten zwischen der Splitt-Adresse und dem erstem folgenden Systemheader.
Das muß, zumindest bei jedem Splitt (=inneren Schnitt), berücksichtigt werden. Also entweder die 'vergessenen' Daten noch mit in das vorherige Volume zu schreiben, ehe der Splitt ausgelöst wird oder den letzten Systemheader zu merken, um eben schon unmittelbar davor zu splitten.
Ich arbeite dran. cu CharlyH.

[dvb.matt]

fleißig :)
verantwortliche Code-Sequenze ... (: Feature, nicht Bug
das hab ich gestern/heut auch gemerkt :(
auch, dass damit meine erste Aussage bzgl. tompg unrichtig wahr.. :oops:

IIRC war damals der Hintergrund, dass viele Spieler mucken, wenn zu Beginn noch Reste von andern Daten stehen.
weiterverwendet hab ich nur toVDR Sachen (insbes. zusätzl. Audios), und da fehlts ja :D

. Die Splitt-Funktion ist also noch ziemlich rudimentär
die 'toXYZ' Sachen sowieso..
hab auch immer betont, dass die nicht wirklich 'gut' sind :)
beim demux merken wir uns dafür aber den letzten Sequ/GopHeader via options[20] oder so, damit des passt...