Splitstream and constant sequence issues

[joe666boxer@y...]

--- In ExtractStream@y..., cerevant@y... wrote:
> Test results:
> 
> Stream 1:
> 2nd convert had 3 bad chunks. Result had a minimal (< .5 sec), 
> constant audio lag.

A few bad chunks are always there. I think extractstream is
overzeleous and extracts more than it should, especially near power of
2 chunk numbers (which is consistent with the way data seems to be
organized on the tivo).

> 
> 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
> 

This is the case we have to really concentrate on. My tivo doesn't
seem to create any of these.

> I dusted off the debugger and I see two problems with the code:
> 
> 1) When you throw out a chunk, you don't reset the sequence number. 

I found that reseting the sequence number does more harm than good. I
don't reset it precisely because of the additional chunks that
extractstream throws into the mix. So if there is a sequence: v1, v2,
v3, vxxx, v4, v5, ..., which happens alot, we'll just ignore vxxx and
keep on going on our merry way. If you reset sequences, then you're
liable to getting bad data into the stream, which more often than not,
crashes players or causes very noticable video/audio problems.

> In my stream, there is a "bad sequence number" (see #2) in the first 
> record of the 3rd chunk (audio). 

Let's continue this in the other post where posted the results of
displaystream.


Thanks
Joe