August 2, 2001 9:37 AM

Originally posted by Marc:
I had the same problem, to such an extent that I removed the sequence bogus checking entirely. The output is much cleaner, but not perfect. It's basically the same as the output I get from ConvertStream - kinda works, kinda doesn't.

Source for my changes are here and the TiVo compiled binary is
here

Whatever works, go with it BUT...

As has been repeated many times before, the "bogus" messages are not errors, just informational. There should be a few every once in awhile, and a lot at the end.

In TiVo v1.3 captured video, checksumming was used. In v2.0.1, sequences are used. ExtractStream assumes the latter. If you don't follow the sequencing, then you'll get small (less than 1 second) audio/video clips from unrelated programs, and that will drive most multiplexers nuts.

Remember you're dealing with encoding hardware that writes directly to the disk given chunks of disk allocated by some driver. Why the encoder quits writing to a chunk and then continues writing to another chunk is unknown... but that's what it's doing, and the sequence numbers allow you to keep it straight.

The majority of the bugs we've seen have to do with the sequence number restarter: after loosing sequence, how do we know where to start again. The code that believes it knows the restarting pattern is:

Code:
if (!PredictSequence || (TempSequence & 0xF0F0F0) == 0x205040) // start/restart

The obvious problem is: if the sequence restarter code is incorrect, we could loose major chunks of valid data (if we don't see the restarter, then everything after that will be bad, until we see a restarter we like).

Since you seem to know how to program, monitor what's being thrown away and see if it's a variation of the above pattern.

Hypothetically, this code could also be the source of the sync problems (I don't know -- I don't have sync problems). The sequencing tracks video data only. When we loose sequence, the rest of the chunk is thrown away, including all audio. We've worked with a few variations of this, and the "discard the rest of the chunk" approach has worked best. Maybe there's a way to determine if a few of the upcoming audio packets should be saved. Worse, maybe some of the audio that has already been processed should have been thrown away.

Nick has a better grasp on the sequencing code, he might have a different opinion.