Splitstream and constant sequence issues

[cerevant@y...]

--- In ExtractStream@y..., joe666boxer@y... wrote:
> 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).

Sounds reasonable...

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

*sigh* Of course I concentrated on the other :)

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

I was sure this was the case, but is there some way we could validate 
the sequence numbers at the beginning of the next chunk? Maybe if 
you get a bad audio sequence, keep checking the video sequences in 
the chunk (still leaving it out of the output) until you get to the 
next chunk? Maybe save the last audio & video record in a chunk 
(even if the chunk is discarded) for validation of the beginning of 
the next chunk? I know we are getting into some pretty ugly logic 
here...

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

Indeed :)