[ExtractStream] Random SplitStream Thoughts...

Roger Merchberger zmerch7 at y...
Fri, 8 Feb 2002 23:29:53 -0800 (PST)


--- Stealth Dave <stealthdave@s...> wrote:
> 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.

No, the thought hadn't occured to me - but not for lack of
imagination, but for lack of C programming skills, and *big* lack of
how MPEG works. Looking at the source for mplex might help, but I'm
(currently) really rather clueless about video in general -- I'm just
an old hacker. ;-)

As my cluelessness recedes, I'd be happy to see if I could add that
functionality to SplitStream.

For now, my C abilities are still:

for (int c1=1; c1 < 40; c1++) {
try_something();
compile()
nuts_it_didnt_work();
why_the_hell_not();
damn_that_was_stupid();
}

I've just finished a program that consumes all available memory, to
practice with malloc() and arrays of pointers...

The source & executable are here:
http://www.30below.com/~zmerch/tivo/showmem.c -- and
http://www.30below.com/~zmerch/tivo/showmem.exe

Again, they're simplistic, but I'm just (re)learning C again (for
about a week) so it'll be a little slow coming...

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

Okay, lemme see if I can remember this with all that nasty C floating
around my head right now:
bash - bad...
perl - good... ;-)

the changes I've made to splitstream (called zss on my site) output
all the info to a logfile, or to stdout (not stderr) so it shouldn't
be too hard to grep the info thru perl... I can change the format so
that it would be more perl-friendly, but that might remove the
human-friendly at the same time (they *rarely* go hand-in-hand)...

[by the by, I don't have anything against bash itself - it's right
handy for one-liner scripts (beats the hell out of a .bat file on
Win2K!) but anything more involved than that, I find IMHO it's easier
in perl...]

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

AFAICT, syncing the two streams should be pretty easy [to understand]
- between what Joe told us about how the audio offset seemed to work,
it should just be a matter of dropping 'x' number of frames off of
whichever stream is ahead - and that should only be a few frames for
most normal streams...

The tough part is going to be figuring out how Joe figured out how
the streams lag WRT each other, dropping the correct # of frames, and
knitting them back together in an MPEG stream...
Ah, well... that may come with a little time... ;-)

Laterz,
Roger "Merch" Merchberger

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com