MPEG2 nach demuxen unsynchron

[Daywalker]

Hallo dvb.matt ich hab da ein Problem.... :(

Ich habe da noch einige MPEG2 Files die ich damals mit der 30 Tage Demo vom Cyberlink PowerDirector geschnitten hatte. Diese [wichtigen!] MPG's wollte ich nun zu einer DVD Authoren (mit TMPGEnc Author). Leider bekomme ich hier einen GOP SequenceHeader Error (siehe ZIP). Dachte ich mir kein Problem, stellst bei X einfach auf "ensure each GOP has a sequencehader" und nochmal demuxen. Das mit dem GOP Header funzt dann auch 1A nur kann X den Ton nicht vollständig demuxen. Daraufhin habe ich den Ton mit TMPGEnc demuxed und dann Video und Audio damit wieder gemuxed. Das Ergebnis ist leider nicht mehr 100%ig synchron. Selbst wenn ich Audio und Video mit TMPGEnc demuxe und wieder muxe gibt's eine Fehlermeldung (aber nur mit 180 s, siehe ZIP).

Kann ich da noch was retten? Logs anbei....


[equote:4a738b4be1="Edit Admin"][center:4a738b4be1]Attachment gelöscht und lokal archiviert

Lucike[/center:4a738b4be1]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:4a738b4be1]

[dvb.matt]

probieren:
- zum Vergleich: demux auf ID 0xC0 beschränken, ob dann auch die inserts/skips kommen
- 'global pts shift' auf einen Wert <> 0 (sodaß die PTS nicht bei 0 beginnen) setzen
- 'spec.2' -> 'get only enclosed PES packs' aus

[Daywalker]

probieren:
- zum Vergleich: demux auf ID 0xC0 beschränken, ob dann auch die inserts/skips kommen
- 'global pts shift' auf einen Wert <> 0 (sodaß die PTS nicht bei 0 beginnen) setzen
- 'spec.2' -> 'get only enclosed PES packs' aus

Leider keine Änderung (wenn ich alles korrekt eingestellt habe).

Wenn ich "take only first Audio PTS for sync" noch zusätzlich aktiviere sind die inserts/skips weg (siehe Versuch-2), aber das File ist nicht vollständig...


[equote:607366ebb7="Edit Admin"][center:607366ebb7]Attachment gelöscht und lokal archiviert

Lucike[/center:607366ebb7]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:607366ebb7]

[dvb.matt]

hmm.. nich schön

mit der id beschränkung meinte ich dass er nur den 0xc0 nimmt (video komplett ignoriert und nicht wirkt), also rechts neben dem preview fenster eintragen..

dann viell. biglog für die ersten 5 sekunden, damit ma die wirklichen PTS Werte und so verfolgen kann..

[Daywalker]

hmm.. nich schön

mit der id beschränkung meinte ich dass er nur den 0xc0 nimmt (video komplett ignoriert und nicht wirkt), also rechts neben dem preview fenster eintragen..

dann viell. biglog für die ersten 5 sekunden, damit ma die wirklichen PTS Werte und so verfolgen kann..

OK, aber ich habe die Log's extrem gekürzt.....da ich hier keine 70 MB Files anhängen kann ( ...Gott sei Dank :D :D )

[dvb.matt]

OK, aber ich habe die Log's extrem gekürzt.....
ähem, leider steht das wesentliche in den ".." :(

drum zielte meine Aussage (dann viell. biglog für die ersten 5 sekunden) daraufhin, lediglich 5 sec (im ganzen) zu bearbeiten.
am einfachsten geht das mit "i" (quickinfo demux der ersten 5MB)

mfg

[Daywalker]

OK, aber ich habe die Log's extrem gekürzt.....
ähem, leider steht das wesentliche in den ".." :(

drum zielte meine Aussage (dann viell. biglog für die ersten 5 sekunden) daraufhin, lediglich 5 sec (im ganzen) zu bearbeiten.
am einfachsten geht das mit "i" (quickinfo demux der ersten 5MB)

Ah, sorry matt, ich kenn mich halt mit den umfangreichen Funktionen von X doch nicht so aus... :D Anbei jetzt die entsprechenden Log's mit Hilfe von "i" und jetzt komplett.

Einstellungen:

Versuch 3:
----------
various: PES(&Sub)-ID/PID list: 0xC0
specials2: take only first Audio PTS for sync: aus
get only enclosed PES packets: aus
global PTS shift (in hours): 2
others: big log file: ein


Versuch 4:
----------
various: PES(&Sub)-ID/PID list: 0xC0
specials2: take only first Audio PTS for sync: ein
get only enclosed PES packets: aus
global PTS shift (in hours): 2
others: big log file: ein


[equote:d35f932d8d="Edit Admin"][center:d35f932d8d]Attachment gelöscht und lokal archiviert

Lucike[/center:d35f932d8d]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:d35f932d8d]

[dvb.matt]

joo, damit kann ich um.. :)

[dvb.matt]

unterdessen kannste doch die mpgs mal nach .ts wandeln (wo X nichts wesentliches verschlimmbessert) und diese dann durch das Supertool von Johann jagen.
Es liest sich jedenfalls so, dass es mittlerweile perfekte Ergebnisse auch bei arg verhunzten Daten abliefert, und das in der Hälfte der Zeit..

[Daywalker]

unterdessen kannste doch die mpgs mal nach .ts wandeln (wo X nichts wesentliches verschlimmbessert) und diese dann durch das Supertool von Johann jagen.

Das Ergebnis ist das Gleiche als wenn ich den Stream gleich mit TMPGEnc demuxe und anschließend wieder muxe. Unsynchron!

....und das in der Hälfte der Zeit..

Das konnte ich bis jetzt noch nicht feststellen da es immer in den selben Pfad der Quelldatei demuxt. Das müsste man mal auf unterschiedlichen Platten testen können.... :D

[dvb.matt]

aha...

IMO liegt das Prob bei dem audio darin, dass die PTS, nachdem die ersten 17 frames eingefügt wurden, sich im folgenden ungleich der framelänge verschoben haben. (wohl durch das schnittprog)
lt. log gibts derzeit da keinen reset auf den nächsten Wert (dumm, wenn wie's hier ausschaut eine neue zeitlinie eingeleitet wird)

daher ne kleine Änderung zum eintragen:
-an die zwei Stellen in x.java (ac3/mpa) wo slloop=false;
x++; gesetzt wird, kommt unmittelbar drunter timeline=ptsval[x]; (=reset und testweise ersatz für 'timeline-=Audio.Time_length;')

konnte bisher keine pos./neg. Wirkungen auf meine sonstigen files feststellen. (hab selbst solchn stotter-fehlerfile aber nicht bei der hand)

[Daywalker]

daher ne kleine Änderung zum eintragen:
-an die zwei Stellen in x.java (ac3/mpa) wo slloop=false;
x++; gesetzt wird, kommt unmittelbar drunter timeline=ptsval[x]; (=reset und testweise ersatz für 'timeline-=Audio.Time_length;')

Habe die Änderungen eingebaut. Das Ganze wurde jetzt etwas synchroner.... :D aber es ist immer noch nicht ok. Gegenüber wenn ich das File rein mit TMPGEnc bearbeite hat es jetzt nur noch 76 s anstelle von 180 s buffer underflows (siehe Pic Fehlermeldung). Das Biglog-File war ja von den ersten 5 MB's. Ich habe jetzt mal versucht auch Biglog's anzufertigen wo die 1. Werbung, die 2. Werbung und das Ende mit PowerDirector geschnitten (eher verhunzt) wurde. Vielleicht hilft das noch etwas weiter...schätze PD machte auch hier Schrott.

Auf alle Fälle schon mal vielen Dank für Deine bisherigen Bemühungen!! :)


[equote:0ffd4345f2="Edit Admin"][center:0ffd4345f2]Attachment gelöscht und lokal archiviert

Lucike[/center:0ffd4345f2]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:0ffd4345f2]

[dvb.matt]

nich so schnell, eins nach dem andern.

erst mal schauen, ob das eine Auswirkung auf die häufigen Audio inserts/skips Wechsel hat, was es sollte.. (also wenn 'take only first AudioPTS..' aus ist)
das bei "00:12:07.008" Schluß war mit Audio hängt womöglich auch da dran.

lt. dem take4 ist die Option aber noch an, was dann keine Änderung bewirken kann.
also deaktivieren und damit wieder nur die Audio ID durchlaufen lassen, und wenn die Inserts/skips weniger/normal sind und es die 45min 'durchhält', dann Video ID mit dazunehmen und berichten.
(die logs in take4 sind daher leider erstmal umsonst :( )

die Änderung sollte jedenfalls so lauten:

} // end while

timeline -= Audio.Time_length;
slloop=false;
x++;
if (ins[1]>0)
Msg("-> "+ins[1]+" frame(s) ("+(ins[1]*((long)Audio.Time_length/90L))+"ms) inserted @ "+sms.format(new java.util.Date(ins[0]/90L)));

/*** test reset PTS after inserting 081.5a ***/
timeline=ptsval[x];

continue readloopdd;
} // end if slloop
...

} // end while

timeline -= Audio.Time_length;
x++;
slloop=false;
if (ins[1]>0)
Msg("-> "+ins[1]+" frame(s) ("+(ins[1]*((long)Audio.Time_length/90L))+"ms) inserted @ "+sms.format(new java.util.Date(ins[0]/90L)));

/*** test reset PTS after inserting 081.5a ***/
timeline=ptsval[x];

continue readloop;
}


die Tmpg Meldung ist IMHO erstmal unkritisch..
(mit ifoedit gemuxt dürfte's noch weniger probs machen)

mfg

[Daywalker]

...erst mal schauen, ob das eine Auswirkung auf die häufigen Audio inserts/skips Wechsel hat, was es sollte.. (also wenn 'take only first AudioPTS..' aus ist)
das bei "00:12:07.008" Schluß war mit Audio hängt womöglich auch da dran.

lt. dem take4 ist die Option aber noch an, was dann keine Änderung bewirken kann.
also deaktivieren und damit wieder nur die Audio ID durchlaufen lassen, und wenn die Inserts/skips weniger/normal sind und es die 45min 'durchhält', dann Video ID mit dazunehmen und berichten.


Habe die Änderungen am Code vorgenommen und je ein short und ein biglog (biglog per "i") mit folgenden Einstellungen erstellt:

01'er Logs:
-------------
PES(&Sub)-ID/PID list: 0xC0
take only first Audio PTS for sync: aus
get only enclosed PES packets: ein
global PTS shift (in hours): 0

02'er Logs:
-------------
PES(&Sub)-ID/PID list: 0xC0
take only first Audio PTS for sync: aus
get only enclosed PES packets: aus
global PTS shift (in hours): 1

Sobald ich jedoch Audio PTS for sync ausschalte hagelt es Audio inserts/skips :(

Edit1
Audio hängt sich bei "00:12:07.008" komischerweise nur auf wenn ich Audio und Video gleichzeitig demuxe... :?:

Edit2
Würden Dir ca. 9 MB vom Anfang des Files (rausgeschnitten per MPEG2Cut v1.14) besser weiterhelfen? Könnte da evtl. kurzzeitig etwas Webspace auftreiben...


[equote:d8f8079d05="Edit Admin"][center:d8f8079d05]Attachment gelöscht und lokal archiviert

Lucike[/center:d8f8079d05]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:d8f8079d05]

[dvb.matt]

hagelt es Audio inserts/skips
solang das nicht geklärt ist, bringt alles andre nichts..

Edit1
das wäre dann doch ein andres Prob wie des hier (http://forum.dvbtechnics.info/viewtopic.php?p=549#549)

Edit2
wenn, dann müßteste das binär vom orig. MPG rausschneiden (mpg2cut würde das IMO zusätzl. verändern, auch wenns auf den ersten Blick nicht so aussieht)
aber ich werd mich dann melden...

mfg

[dvb.matt]

s'geht weiter

Anm: betrifft noch immer alles nur Audio:

die vorgegebenen PTSs in dem File erzwingen leider immer wieder inserts/skips, wenn man alle PTS beachtet (was X tut).

mit dieser zweiten Änderung (erste hier im Topic wird vorausgesetzt) werden nur noch die PTS fürn Sync-erhalt (im Audiostrom selbst) herangezogen, die bytegenau für ein Framesynchword gelten.
(dem PES-Header folgte also unmittelbar das synchword)

bei den allermeisten DVB-Daten (PVA,TS,div.MPG) ist das sowieso der Fall (senderabhängig), daher wird sich da IMO nichts ändern.
bei VOB und MPG, die auf Packetgrößen getrimmt sind (2048,2304..) werden dann aber alle Zwischen-PTSs nicht mehr verwendet (die nämlich u.U. nicht passen)
entsprechend wird Audio etwas seltener auf eigenen Sync hin geprüft (alle ~500ms statt ~100ms) und evtl. Frameinserts landen u.U. an geringfügig anderer Stelle.

Der Sync zum Video verändert sich dadurch nicht.

um das besser testen zu können, ist hier der Einfachheit halber die 'spec' Option 'generate info ttx..' mißbraucht.
also 'an' = simple sync, 'aus' = strong sync wie bisher.


X.java
für AC3: (zeile ~764x)

...
audbuf.reset();
audbuf.write(frame);

//test 081.5++ simple sync: only if ptspos[x+1] equals n (on frame boundary)
if (cBox[42].isSelected() && ptspos[x+1]!=-1 && ptspos[x+1]<n)
x++;

if ( (ptspos[x+1] == -1) || (ptspos[x+1] > n ) ) {
if (!vptsdata || (vptsdata && awrite)) {
...


für MPA: (zeile ~818x)

...
header_copy[3] &= 0xCF;
header_copy[2] &= ~2;

/******** message *****/
//if (options[30]==1) System.out.print(" tl"+timeline+" /px "+ptsval[x]+" /1_"+ptsval[x+1]+" /p1-tl "+(ptsval[x+1]-timeline)+" /pp1 "+ptspos[x+1]+" /n "+n);

//test 081.5++ simple sync: only if ptspos[x+1] equals n (on frame boundary)
if (cBox[42].isSelected() && ptspos[x+1]!=-1 && ptspos[x+1]<n)
x++;

/******** frame is in last pes packet or packet end not yet reached *****/
if ( (ptspos[x+1] == -1) || (ptspos[x+1] > n ) ) {
if (vptsdata && !awrite)
...

[Daywalker]

Wenn ich 'generate info ttx' anschalte sind die inserts/skips fast weg. Ich habe das .mp2 File mal in .wav umgewandelt und grob analysiert. An einigen Stellen herrscht im Stream 'Stille' fast immer in der Nähe von Cuts an denen PowerDirector rumgebastelt hat. Zudem habe ich mal ein Pic von meinen Einstellungen gemacht. Habe quasi nur ttx an oder ausgeschaltet....


[equote:4789366b09="Edit Admin"][center:4789366b09]Attachment gelöscht und lokal archiviert

Lucike[/center:4789366b09]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:4789366b09]

[dvb.matt]

fast immer in der Nähe von Cuts an denen PowerDirector
ja, der hat da Lücken mit reingebracht, also zeitliche Abstände für die keine physischen Frames existieren. eigentlich nicht in Ordnung.

die inserts/skips fast weg
finde, das sieht bedeutend besser aus.
und es bestätigt nur, dass dort falsche Einträge gesetzt wurden.
denn zu den 'ausgewählten' Syncpoints passt PTS-Fortschritt zu phys. Frame-Fortschritt, zwischendrin jedoch nicht. (von 'Power ..' kann da keine Rede sein...)

da es fürs Audio mit X nicht besser geht (will sagen, so wäre es IMO akzeptabel, ein paar inserts fallen ja noch durch den Video-sync raus)
können wir uns jetzt ums Video kümmern.

Anm: die Änderung müßte man noch ein bischen anpassen, da es wohl streams gibt, wo nie oder ganz selten ein synchword und PTS ohne offset zusammenfallen. also brauchts auch bei simple sync gelegentliche Zwangspunkte, wenn die über gewisse zeit 'ausbleiben'..

nu also A+V zusammen:
dabei mit der x voschau soweit vor die "00:12:xxx" vorrücken, das mit cut-in/out bzw. "i" in einem rel. kleinen biglog der Aussetzpunkt von audio in bezug zu video eintritt und abgebildet werden kann..

[Daywalker]

nu also A+V zusammen:
dabei mit der x voschau soweit vor die "00:12:xxx" vorrücken, das mit cut-in/out bzw. "i" in einem rel. kleinen biglog der Aussetzpunkt von audio in bezug zu video eintritt und abgebildet werden kann..

Ich hoffe mal ich habe das wie gewünscht hinbekommen.
Gleiche Einstellungen, ttx an.


[equote:d0160fa850="Edit Admin"][center:d0160fa850]Attachment gelöscht und lokal archiviert

Lucike[/center:d0160fa850]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:d0160fa850]

[dvb.matt]

hi,
#s166 _65448000 #e167 _65466000 /#s166 _3549600 #e167 _3567600
#s168 _65462400 #e169 _65505600 /#s168 _3567600 #e169 _3610800
GOP84 (s168) beginnt 40ms (=3600t) früher als GOP83 (e167) endet, deswegen hört Audio auf..
allerdings wärs interessant, warum das bei GOP84 so ist.

leider ist das bisherige biglog dafür nicht mehr aussagekäftig genug.
deswegen würd ich drum bitten, dasselbe mit der angehängten erweiterten X.java (ist noch einiges mehr geändert, spielt hier IMO aber nicht rein) nochmals zu loggen.
(kann ruhig vorn unten hinten noch ein paar GOPs weniger sein..)
obwohl ich vermute, dass es nachher auch nicht 'einfach' gelöst werden kann, denn das ist ja das leidige Prob. mit dem PTS Rückschritt.

zudem ist es komisch, dass beim cut-in kein B-Frame verworfen wird, obwohl das I-Frame nicht TRef=0 hat..

mfg


[equote:1189c8b020="Edit Admin"][center:1189c8b020]Attachment gelöscht und lokal archiviert

Lucike[/center:1189c8b020]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:1189c8b020]

[Daywalker]

...deswegen würd ich drum bitten, dasselbe mit der angehängten erweiterten X.java (ist noch einiges mehr geändert, spielt hier IMO aber nicht rein) nochmals zu loggen.

Würde ich gerne machen, aber der Anhang hat leider 0 Bytes...

[dvb.matt]

sollte gehen..

[Daywalker]

Ok, neuer X.java Code eingebaut, gleiche Einstellungen wie vorher, ttx an.


[equote:d25c8b0aa2="Edit Admin"][center:d25c8b0aa2]Attachment gelöscht und lokal archiviert

Lucike[/center:d25c8b0aa2]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:d25c8b0aa2]

[dvb.matt]

ok.
Problem erkannt. (PD hat sichs an der Schnittstelle etwas einfach gemacht, sozusagen). es ist allerdings zugegebenermaßen dennoch konform (was ich von den Tonprobs. nicht sagen kann)
mal sehn, ob sich X leicht anpassen lässt... (ich denke ja, weils eindeutig ist)

bis dahin haste also erstmal logfrei.. :wink:

[dvb.matt]

es ist zwar nicht der Weisheit letzter Schluß, aber mit den Änderungen 'könnte' es jetzt u.U. doch (richtig) durchlaufen.

also methode 'goptest()' in der gestrigen X.java austauschen.
dann 'ttx' an für audio und der rest wie sonst gewohnt, also 'get only enclosed PES..' auch an (weil das ja kein Prob. war)..

wenn mind. 2mal B-frames gedroppt werden, ist das ein 'gutes' Zeichen...


[equote:74a8a55547="Edit Admin"][center:74a8a55547]Attachment gelöscht und lokal archiviert

Lucike[/center:74a8a55547]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:74a8a55547]

[Daywalker]

..Problem erkannt... ...mal sehn, ob sich X leicht anpassen lässt... (ich denke ja, weils eindeutig ist)...

bis dahin haste also erstmal logfrei.. :wink:

Ahh SUPER! :)
Bin schon gespannt... :D

[dvb.matt]

das eine sollte noch mal getauscht werden für mehr konformität..


[equote:d7fdc5daa5="Edit Admin"][center:d7fdc5daa5]Attachment gelöscht und lokal archiviert

Lucike[/center:d7fdc5daa5]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:d7fdc5daa5]

[Daywalker]

wenn mind. 2mal B-frames gedroppt werden, ist das ein 'gutes' Zeichen...

Dann sieht das mal nicht schlecht aus! :)

Die entstandenen Files habe ich mit TMPGEnc gemuxed. Es ist wieder mal die typische Fehlermeldung "77 s buffer underflow" nach dem muxen gekommen wobei ich nicht ganz verstehe was da für ein Problem vorliegt. Das MPEG File scheint aber synchron zu sein!! Ich habe mal die Fehlermeldung von TMPGEnc Author (damit authore ich meine DVD's) beigelegt. Die rote Meldung kann ich ja mit X fixen, aber wie sieht es mit der 2. Meldung aus? Könnte dies diesen "buffer underflow" verursachen? Und muss ich mir da Sorgen machen? (nur rein der Interesse halber)

Die insert Audio Frames werde ich noch checken ob das krass im Video rüberkommt. Ebenso werde ich mal die anderen Video-Files durchlaufen lassen. Aber das dauert ein wenig...

Auf alle Fälle schon mal RESPEKT! :)

EDIT:
Ooops, habe gerade die neueren Änderungen gesehen....mache nochmal einen Test :D


[equote:66bd1880e2="Edit Admin"][center:66bd1880e2]Attachment gelöscht und lokal archiviert

Lucike[/center:66bd1880e2]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:66bd1880e2]

[Daywalker]

Ich habe jetzt mal alle betroffenen Files (8 Stück) mit X demuxed und mit TMPGEnc gemuxed. Bei 3 Files erhalte ich nach dem Muxen einen "buffer underrun" mit 77, 7 und 12 s. Die MPEG's sind alle synchron! Also liegt das mit dem buffer nicht an der Meldung GOP is too long, denn das Problem haben alles Files. Den GOP header konnte ich bei allen fixen.

Habe wohl per Zufall ausgerechnet das File mit den meisten Fehlern zum Testen hergenommen... :roll: :D

Die Audio skips/inserts sind unschön... :( Die Original-MPEG's werden komischerweise im Softwareplayer (PowerDVD, WinDVD) ohne Fehler abgespielt....ich denke mal hier greift wohl so eine Art Fehlerkorrektur?

Ansonsten ist das Ergebnis spitze! Beim Ton werde ich mal sehen ob ich da noch was per Hand optimieren kann (auch wenn's ewig dauert). Werden diese Änderungen im Code Bestandteil der nächsten X-Version, oder war das nur für diesen speziellen Fall.....?


[equote:88511850b8="Edit Admin"][center:88511850b8]Attachment gelöscht und lokal archiviert

Lucike[/center:88511850b8]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:88511850b8]

[dvb.matt]

"buffer underrun"
wenn ich das richtig seh' hat das bastelfile irgendwo ne peak von 10.4Mbps? (min/max) du hast aber auf vorn (erste) auf max 9.8 setzen lassen. (AFAIK errechnet tmpg seine muxrate entsprechend)
wenn du die X logs von den anderen noch hast kannste ja gucken, ob die auch so hoch gehen (ich meine nicht).

Code Bestandteil der nächsten ..
IMO schon, aber in überarbeiteter Form und nicht so bald.
denn da gibts noch ein paar mehr Sachen auszubügeln, die spätere Erweiterungen erschweren.