> OK, cool. I don't quite see (mostly because I don't really
> understand network programming) how a web-based session based
> on sfront would work. When I click on the link, it opens
> up a streaming RTP port and invokes some sort of handler
> program. The handler program gets the header, makes sa.c
> and compiles it into a new executable. Presumably, it
> then forks off the new executable, and somehow hands off
> control of the RTP port socket to the new one? Is that
> right?
Yes, that's roughly how I envision it.
> Of course, in the strict by-the-book standard, the SAOL
> and SASL are being delivered from the same server (or set
> of servers), so presumably the name matching is handled at
> encode time.
Yes, the specific sfront issue is more dependent on the
architecture of sfront itself right now ...
} Any chance that current versions of these documents
} [IS 14496-3sec1, the main Audio part, and IS 14496-1,
} the MPEG-4 Systems standard] will be made
} available for download by non-MPEG members soon?
> Sadly, I can't make any promises about this. [...]
Thanks for doing anything you can on this, while personally
I'm more interested in coming up with a set of physical models
in SAOL, that would result in complete compositions being small
enough not to stream (after all, PC.mp4 is 27K, around the size
of a small webcam JPEG, and its 90 seconds long), I think its
really in the best interest of the MPEG folks to encourage
Open-Source implementations ... if it weren't for the quality
ISO reference code for MPEG 2 (as well as excellent review
articles like David Pan's to get people up to speed), I have no
doubt that we'd be downloading music using someone proprietory
format today instead of using MP3's ...
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:39 EDT