[ExtractStream] Random SplitStream Thoughts...

[Stealth Dave]

Have you given any thoughts to adding multiplexing capabilities to
SplitStream? The source for mplex is available from
http://mjpeg.sourceforge.net, and splitstream does calculate the correct
time offset. It would be nice to be able to spit out a properly synced
mpeg file in one shot.

As an alternative, an option to output the time offset in a format that
could easily be parsed by a bash or perl script (or whatever) would also
be beneficial so that one could set up a script to separate the streams
from the ty stream and then sync them up in one shot.

Obviously, the former would be quicker and take up less disk space, and
the latter would be much easier to program. Either would be useful.

Looking forward to seeing your additions.

- Stealth Dave

On Fri, 2002-02-08 at 22:39, Roger Merchberger wrote:
> Well, folks -- I've been perusing the SplitStream code, and I've come
> to a few interesting conclusions:
> 
> 1) I think that splitstream can be made to work faster by allocating
> a lot more memory & increasing the file input/output buffers - right
> now it only allocates memory for 1 chunk at a time, which is
> 128Kbytes. So, the program grabs 128K bytes in, splits & spits it out
> 2 seperate files (audio & video) - that seems like it'd cause a lot
> of hard drive thrashing - but I won't know for sure until I change
> the program to allocate more memory for the streams before I/O
> happens... By my (admittedly *very* rough) calculations, there's
> approx. 12,500 chunks per hour of High-quality recorded Tivo video. I
> was figuring on buffering 100 chunks at a time, which would cause the
> computer to utilize 12.8 Meg of RAM during execution - methinks
> anyone doing video extraction should be able to afford that much
> memory allocation, but I'll make sure the program is kind & gentle to
> those that might be "RAM challenged." (although, if the program goes
> to swap, that might actually hamper performance - but I dunno if a
> command-line proggie can access swap...)
> 
> 2) From what I can read in the code, there *are* bugs in SplitStream.
> 
> 2a) The first is very minor: the 128K memory allocated for the stream
> is never freed in the program, as far as I can see. Granted, as soon
> as the program exits, it'll be returned, but if the program abends
> the memory is lost until reboot. Admittedly, losing 128K is peanuts -
> but I'm glad I noticed that, because if I'm not careful, after my
> changes are done and the program misbehaves, losing 12M is a *bad
> thing*.
> 
> 2b) This one is fairly minor: When the memory is (asked to be)
> allocated, it's never checked to see if the memory allocation request
> actually went thru. Again, with the megamemory of today's machines,
> it's "a safe bet" that 128K is available, but for some reason it
> didn't go, it was never checked - and the program would run amok (or
> at least die horribly). Again, I must be more careful to make sure
> the memory is allocated, or else the expanded program could do
> "really bad things."
> 
> I'm starting to learn a lot more about C again -- hopefully I can
> finally learn it for good & keep a good chunk of it in my brain this
> time... ;-)
> 
> Well, I've been plinking with allocating memory & stuff, and I've
> gotten a better handle on it now, I think...
> 
> I'll be testing changes to the new zss code in a few days.
> 
> Laterz,
> Roger "Merch" Merchberger
> 
-- 
David E. Still phone:818.980.6909
dave@s... http://www.stilldesigning.com