[ExtractStream] Thoughts on a newer version of ExtractStream

Dale E. Reed Jr. daler at n...
Tue, 02 Oct 2001 00:34:07 -0700


Stealth Dave wrote:

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


The only big issue with this is that the poor tivo processor
is so underpowered that putting anything more than an extraction
process on it will greatly affect the performance of using it
during the extraction.


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


This is already in the works. (see below)

> 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! :)


netmplex already exists on the linux side. However, it fundamentally
has the same problem since it receives the streams seperated. The new
win32 app we're working on has convertstream on the front in so that it
splits the streams and puts them back synced. As soon as I figure out
whats wrong with the netcat frontend (or whereever its loosing frames)
I'll try to get it out. For now I just use netcat to get the stream 
over to win32 and then use the app to create the mpg.

Dale