Krakeliges ts

[TheHorse]

Ich hab ein oberfaules Topfield-File (in über einem Jahr nur einmal vorgekommen, nämlich jetzt!):
--> PID 0x8FF -> packet 4961 @ pos. 934172 out of sequence (4/3) (shifting..)
stopped...
java.lang.ArrayIndexOutOfBoundsException: 194
at X$WORK.rawparse(X.java:5843)
at X$WORK.working(X.java:4632)
at X$WORK.run(X.java:4291)

(Die Zeilennumern stimmen bei mir evtl. nicht mehr mit den Basisversionen überein!)

Brutale Abhilfe eines MPEG-Dummies, der sich radikal über jede Packetgröße hinwegsetzt (ich daselbst):
Pushbuffergröße verdoppelt:
X.java, ~5656
byte[] push189 = new byte[378]; // old: byte[] push189 = new byte[189];

Nunmehr:
--> PID 0x8FF -> packet 4961 @ pos. 934172 out of sequence (4/3) (shifting..)
-> TS bit error in packet 3529087 @ pos. 663469860
packs: 11081436 100% 2847156224
video: fr/ct/1p/cg/og/dg 119989/1/0/9620/0/0
videolength: 119989f @ 01:19:59.560
avg. nom. bitrate 3178433bps (min/max: 638400/7717200)

Aber das Dinge spielt ohne tragische Verluste an der Hakelstelle und auch danach gibt es nach erstem Anschein keinen Grund für Entsetzensschreie.

Gibt es eine elegantere Methode, das Problem around zu worken?

[dvb.matt]

na guck mal bei dir (weil WIR ja nich mehr wissen wo des bei dir iss ;) ) bei Zeile 5843 nach:
at X$WORK.rawparse(X.java:5843)
dann könn ma nochma genauer hingucken, wenn du sachst wo.

die Vergrößerung auf 389 ist theoreth. unproblematisch.
der soll da ja eh immer 188 lesen und einen mehr puffern (nächsten 0x47) bei 189.
allerdings weiß ich jetz grad nich, ob die Überlänge irgendwo anders stört.

mir siehts jedenfalls so aus, das viell. das eine Paket (3/4) evtl. zu kurz/lang ist, also durch binären Cut der nicht packet-aligned war.

[TheHorse]

// PES id, if packet start
===> pesID = (start) ? ((255&push189[4+addlength])<<24 | (255&push189[5+addlength])<<16 | ...

Ich kann nicht sagen, wie groß addlength da beim Crash war. Wahrscheinlich war push189[4] schon falsch im ts. (Debuggen muss ich noch üben - heißt auf Deutsch, ich kann's gar nicht. :x )

[dvb.matt]

addlength
dacht ich schon, sowas.
adaption_field_length kann, soll aber nicht einen Wert annehmen, größer als das Pack (mit 4+184) daherkommt.

aber schön, dass vom Viterbi(FEC) für des Pack bereits ein Bitfehler vermerkt wurde..

wir werden da noch einen Längencheck für addlength einfügen und evtl. die Reihenfolge bis zur Errormessage ändern. (dann kanns mit den 189 bleiben)

wie war der Geschwindigkeitsunterschied zw. 189<->389 ?

[TheHorse]

wie war der Geschwindigkeitsunterschied zw. 189<->389 ?An "unkrakeliger" Aufnahme nachgeprüft (die andere schmiert ja einmal ab):
Bei 189: 1:51.500
bei 379: 1:48.046
für 34 min Aufnahme.

also eher schneller :?: :?: :?: oder wahrscheinlich im Rahmen der I/O-Bandbreiten des OS. Also nix Auffälliges.
Aber, wenn's ts OK ist, dann dürfte er doch nur bis 189 scheiben und der Rest bleibt halt leer. Kann doch keinen Tempo-Unterschied ausmachen, oder?

EDIT: Attachment gelöscht, lucike's Board zuliebe.

[dvb.matt]

Kann doch keinen Tempo-Unterschied ausmachen
na doch.
der readBuffer bei PushbackInputStream() behält die vorausgelesenen Bytes und muß nicht diese nicht mehr nachladen.

Da die vorausgelesenen, aber nicht benötigten 389-188=201 bytes im Buffer fürn nächsten read nach vorn geschoben werden (müssen), verkehrt sich eine Erhöhung aber u.U. ins Gegenteil, weil sich die Zeit zum 'Verschieben und Neulesen' umsomehr potenziert (oder wie sagt man? :lol: )


zum Prob hab ich mal was around geworked:
(wenns funzt, kann mans ja zum fix rüberhieven)
-----------
fix: array exception, caused by erroneous TS packets
bad packets will be dropped now
(nevertheless it will psb. crash on private_data (pesID==0x1BD))

X.java
@internal class WORK
@method rawparse(), line ~5824

(1)replace code block


counter = (0xf & push189[3]); // packet counter 0..f
addlength = (addfield>1) ? (0xff & push189[4])+1 : 0; // adaption field length

//DM18092003+ fix
progress.setValue((int)((count-base)*100/(size-base))+1);
yield();

// pid inclusion
includeloop:
while (include.length>0) {
for (int v=0; v<include.length; v++)
if (pid==include[v])
break includeloop;
continue pvaloop;
}

if ((addfield&1)==0)
continue pvaloop;

if (addlength>183 || (addlength>180 && start))
error=true;

if (error){
Msg("--> PID 0x"+Integer.toHexString(pid).toUpperCase()+" -> TS bit error in packet "+packet+" @ pos. "+(count-188)+", dropping..");
continue pvaloop;
}

// PES id, if packet start
pesID = (start) ? ((255&push189[4+addlength])<<24 | (255&push189[5+addlength])<<16 |
(255&push189[6+addlength])<<8 | (255&push189[7+addlength])) : 0;
// PSI id, if packet start
psiID = (start) ? pesID>>>16 : 0;

ttx = false;
if (pesID==0x1BD)
ttx = ((0xFF&push189[12+addlength])==0x24 && (0xFF&push189[13+addlength+(0xFF&push189[12+addlen gth])])==0x10) ? true : false;
//DM18092003-

int pidcheck=-1;
for (int a=0;a<TSPidlist.size();a++) { // find PID object

[TheHorse]

Ich merk grad, mein Attachment-Auszug war wohl zu kurz. Da habe ich scheinbar nur Audioframes erwischt. Wollte lucike's Server schonen. :(

Im vollen Krakel-ts läuft's nun durch.
An der Krakelstelle werden weder Audioframes ersetzt, noch kommt überhaupt irgendwann die TS bit error-Meldung. (Die add am Schluss sind beim Topfield normal.)
Nun brat mir einer 'nen Storch.

--> PID 0x8FF -> packet 4961 @ pos. 934172 out of sequence (4/3) (shifting..)
packs: 11081436 100% 2847156224
video: fr/ct/1p/cg/og/dg 119989/1/0/9620/0/0
videolength: 119989f @ 01:19:59.560
--> MPEG Audio (0xC0) on PID 0x900

Audio PTS: first packet 09:50:45.947, last packet 11:10:45.611
Video PTS: start 1.GOP 09:50:46.501, end last GOP 11:10:46.061
-> adjusting audio at video-timeline
=> src_audio: MPEG-1,Layer2,48000Hz,stereo,192kbps,CRC @ 00:00:00.000
-> 13 frame(s) (312ms) added @ 01:19:59.256
audio frames: wri/pre/skip/ins/add 199982/0/0/0/13 @ 01:19:59.568 done..

Und jetzt wird's noch bunter: Wenn ich vorne ein kleines Stück abschneide, dann gibt es überhaupt keine shiftet packets mehr an der Krakelstelle und ich krieg laut X ein absolut reines Ergebnis.

[dvb.matt]

Ich merk grad, mein Attachment-Auszug war wohl zu kurz. Da habe ich scheinbar nur Audioframes erwischt. Wollte lucike's Server schonen. :(
yepp..


Im vollen Krakel-ts läuft's nun durch.
An der Krakelstelle werden weder Audioframes ersetzt, noch kommt überhaupt irgendwann die TS bit error-Meldung. (Die add am Schluss sind beim Topfield normal.)
Nun brat mir einer 'nen Storch.
recht so, weil das iss auf'm PID 0x1500, und der iss eh' ignored.
die Umstellung 'verbessert' die natürliche Auslese aka Evolution.. :D

--> PID 0x8FF -> packet 4961 @ pos. 934172 out of sequence (4/3) (shifting..)

Und jetzt wird's noch bunter: Wenn ich vorne ein kleines Stück abschneide, dann gibt es überhaupt keine shiftet packets mehr an der Krakelstelle und ich krieg laut X ein absolut reines Ergebnis.
joo, so rund 1MB halt..

[TheHorse]

joo, so rund 1MB haltRrrichtig, iss ja klar. Mein erstes Posting im Thread betraf ja das ungeschnittene. Hab irgendwie geistig die shifted-Stelle mit der Biterror-Stelle verwechselt. (Dringend Brainware-Upgrade erforderlich.)

[dvb.matt]

achso, die Erhöhung hängt ja von noch mehr ab.
der Buffer selbst ist derzeit nur mit 200 definiert(1)(3), und lesen tut er nur 189(2).
also push189 alleine zu vergrößern bringt damit IMO doch nichts... :|

[equote:9c2ec7b47a]
(1)PushbackInputStream in = new PushbackInputStream(new FileInputStream(file),200);
...
(2)in.read(push189,0,189);
...
(3)in = new PushbackInputStream(new FileInputStream(nextfile),200); //DM18092003
[/equote:9c2ec7b47a]

weil das iss auf'm PID 0x1500, und der iss eh' ignored
Eigentlich sorgt des hier: [equote:9c2ec7b47a]if ((addfield&1)==0) continue pvaloop;[/equote:9c2ec7b47a] schon für das Verwürfnis, weil packets ohne payload sind sowieso uninteressant.
Aber man muß ja nun nich jeden Pup loggen.. :wink: