[ExtractStream] Thoughts on a newer version of ExtractStream

[Stealth Dave]

Glad to hear that this is already being worked on! A couple of
questions, though:

1.	Will there be a Linux version as well as win32? I can run most apps
(including TMPEGEnc) through WINE, but native Linux apps are much better
(obviously).
2.	The current version of ConvertStream only works on 1.3 Tivos, while
most Tivos are currently running 2.0.1. Is this being addressed in the
new app?
3.	Has *anyone* figured out how to get rid of that f@&$#*g green bar on
the left-hand side!

Also, have you tested your app with Tivo stream files created by
ExtractStream -s? If it works, you may wish to consider releasing the
current revision as-is and release an updated netcat-enabled version
later. Many people, including myself, are able to mount nfs and/or
samba partitions on the Tivo and can copy tyStreams without requiring
netcat. This would *certainly* be appreciated by everyone trying to get
their audio synced!

In any case, thanks for responding and letting us know of your progress.
If you feel comfortable with sharing your code, please let me know. I
may not be a C programmer per se, but I do know just enough to be
dangerous. ;)

- Stealth Dave


On 02 Oct 2001 00:34:07 -0700, Dale E. Reed Jr. wrote:
> 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
> 
> 
> 
> 
> 
> To unsubscribe from this group, send an email to:
> ExtractStream-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
> 
-- 
David E. Still phone:818.980.6909
dave@s... http://www.stilldesigning.com