- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 01 Oct 2013 16:44:52 +0200
- To: public-media-capture@w3.org
On 09/30/2013 02:36 AM, Rob Manson wrote: > I drew this diagram recently in an attempt to put together a clear > picture of how all the flows work/could work together. It seems to > resonate with quite a few people I've discussed it with. > > NOTE: This was clearly from the perspective of the post-processing > pipeline scenarios we were exploring. > Code: > https://github.com/buildar/getting_started_with_webrtc#image_processing_pipelinehtml > > Slides: > http://www.slideshare.net/robman/mediastream-processing-pipelines-on-the-augmented-web-platform > > > But the question marks in this diagram really relate directly to this > discussion (at least in the write direction). > > It would be very useful in many scenarios to be able to > programatically generate a Stream (just like you can with the Web > Audio API). Plus all the other scenarios this type of overall > integration would unlock (zoom, etc). > > And then we would be able to use this Stream as the basis of a > MediaStream. Just a nit - I'd strongly object to using the name "Stream". The term has been horribly abused in so many ways, starting with Unix System 7's "Stream" model (the "solution for which Berkeley Sockets was a quick hack"). Pairing "Stream" with some modifier preserves a modicum of sanity. (I know of one effort that is using "Stream" as "stream of bytes", aka "the TCP model", and I think there's also one using "Stream" as "stream of records", aka "the OSI Transport model". Neither is a media stream (or a MediaStream), of course. A plague on both their houses' names, I say.)
Received on Tuesday, 1 October 2013 14:45:22 UTC