Splitstream and constant sequence issues

[joe666boxer@y...]

--- In ExtractStream@y..., cerevant@y... wrote:
> Here's what I found - my stream jumps to a sequence number of
> 0x2d1c40 without using a size 0 record first. (Display Stream dump 
> below) This might be truly bogus, I don't know the format that well.

I have serious reservations about that last chunk. I've noticed one
other thing in these records: there is another sequence, the last 64
bits of the record header. I've never seen this sequence go down. It
stays constant for a while, then goes up by some random number, stays
constant for a while, etc. The last two records in chunk 2, I assume,
are these:

00 39 42 E0 30 28 5F C0 00 00 00 C9 16 D7 E5 C4 size=00394 (video)
00 01 06 E0 30 00 89 94 00 00 00 C8 F9 03 1E 98 size=00010 (vid-P)

notice how the long sequence actually decreased. What's even more
interesting is that the long sequence becomes:

00 36 04 C0 30 2D 1C 40 00 00 00 00 00 00 00 00 size=00360 (audio)

all zeros! It would be really interesting to see what chunk 4 looks like.

In your other post, you wrote:

> Stream 2:
> 1st convert sequential failure 
> - Audio 22k, Video 284k
> 2nd convert *also* had a sequential failure. 
> - Audio 6.8M, Video 125.7M
> 3rd convert again, seq fail 
> - Audio 19k, Video 259k
> 4th starts with missing first frames & audio failure, then seq fail.
> - Audio 6.8M, Video 125.5M

Are the short pieces of audio long enough for you to recognize them?
do they actually belong to the program? If you concatinate the audio
files, do you get a continous sounding file?

WillieB9000 has the same kind of problem and he's promised to send me
several streams with these symptoms

> 
> Anyway, it looks like my first point was more important: the sequence 
> numbers need to be reset somehow if a chunk is thrown out. I'm not 
> sure how it recovered when I sampled the second time and got bad 
> chunks - I guess there must be cases where the sequence numbers pick 
> up with the next chunk.

As I said in the previous post, I think reseting the sequence is a
really bad idea. It recovered because there was an extra chunk. Of
course, you're welcome to compile your version of splitstream with any
modifications that'll make it work for you.

> 
> I did a quick hack and made the predict values global, and set them 
> to zero when a chunk gets thrown out. I get interesting results: 
> there are sequence errors, but they are almost always 1024 chunks 
> from the last error, and they are always in the first record. I 
> doubt this is the best way to handle this, but I wanted to confirm 
> that it would recover at least somewhat better. The result was a bit 
> unusual - the audio was late at the beginning, dead-on at the end.

But do you get crap in the stream (bad video blocks, audio screeches,
etc)?

I know I've got more questions than answers, but I'd like to get to
the bottom of this.

Thanks
Joe