Thoughts on a newer version of ExtractStream

[Stealth Dave]

Okay, I've been going over the ExtractStream/ConvertStream code, as well
as looking over the mplex code supplied with the latest ExtractStream,
and came up with a few ideas on where the code might be progressed.
Chances are that some of the more talented programmers on this list have
probably already come up with the same thoughts, but I'll express them
here anyway.

First, let me preface this by saying that while I am a programmer, I am
*not* a C or C++ programmer. "You're a programmer who doesn't know 'C'?
How can this be?" you ask. Well, I'm a web developer. My programming
languages of choice are ASP, Perl, PHP, etc. I did take a basic C
programming course in college and have written a few (very simple)
programs in C, but my expertise lies elsewhere.

>From my own experimentation and reading the comments on this list, there
are two main complaints with the current version of ExtractStream is
that 1) it creates separate Audio/Video streams and as a result 2) it is
very difficult to get the Audio/Video to sync up properly. Also from
the comments on this list, the latter is most likely related to the
former. This solution might seem overly simplistic, but I'll propose it
anyways: why not combine the mplex code with with ExtractStream code and
solve both problems?

I'm sure that there are many logistical problems with this that I'm not
aware of, but the idea is not as off-the-wall as it might seem. As near
as I can tell, ExtractStream decodes the video and audio streams one
block at a time (32k of data per block) and then slaps the data onto the
end of the files specified by VIDEO_OUT and AUDIO_OUT. If we instead
insert a multiplex step in there which combines the audio and video mpeg
streams *before* writing the file, we solve the problem of sync AND
create a single file as output. The downside is that ExtractStream
makes Tivo do all the work, but we could get around this by getting the
raw Tivo stream using the existing ExtractStream and netcat-ing the
output to the client to do the a/v separation and multiplexing.

Hopefully I'm not just pointing out the obvious here. Times like these
make me wish I had taken more computer classes. But since I didn't, I
can at least start some intelligent discussion on the matter. As they
say on the internet; those who can't start flame wars! :)

-- 
David E. Still phone:818.980.6909
dave@s... http://www.stilldesigning.com