[ExtractStream] Re: Status of Windows tools

[Dale E. Reed Jr.]

> I'm currently rewriting the input buffering and in the process of 

Why? I fail to undestand the point of the complex circular buffer
in ExtractStream and some of the other apps based on it. When I
ported ConvertStream over to Win32 I yanked all that out. I can
only assume they were trying to squeeze every little performance
out of the poor tivo processor, or liked writing complicated code. :)

My OS has I/O buffering and such built into it. I'm sure I could
have made ConvertStream faster, but knowing the eventual goal was
to convert a stream coming over the wire at a limited speed (1MB),
I didn't want to put any effort into my. My P3 750 was bored as
it was. :)

> debugging it. Extracted a full one hour show last night, but it's 
> obvious it's dropping bytes somewhere, still. Hopefully by next 
> week...

Its not that its "dropping" bytes. There is a real shift here in
how the tivo uses the tystream data and how we are trying to use it.
The tivo's method has sync built into it fundamentally (pulling both
signals from one source keeps them synced). Trying to take two 
completely indivial streams (m2a and m2v) and sync them without any
timecode in them is going to be challenging.

I think getting something like the ConvertStream+NetMplex marriage
where the seperation and re-attach happens like it does on the tivo is 
going to produce the synced audio and video that we are all looking for.

Dale