- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Fri, 9 Dec 2011 22:47:41 +0000
- To: Harald Alvestrand <harald@alvestrand.no>, Rich Tibbett <richt@opera.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
>-----Original Message----- >From: Harald Alvestrand [mailto:harald@alvestrand.no] > >On 12/07/2011 01:38 PM, Rich Tibbett wrote: >> Would there be any issues with moving 'Section 3: Stream API' from the >> WebRTC API spec to the Media Capture API spec? * > >Yes. > >The discussion so far has indicated that the nature of the beasts within >a MediaStream is critically tied to their on-net representation as >mediated by a PeerConnection. This close connection is mirrored in >current implementation strategies for MediaStream. > >I am not at all happy at the thought of potentially revectoring >MediaStream to be chiefly a mechanism for local applications. I think coming to terms with these two major scenarios is what this task force is all about. >Given the time it took me to get my head out of the "it's a stream of >bytes" fallacy, I wouldn't like to encourage others to be caught in the >same trap. You obviously bring a lot of prior context to this discussion. As a relative newcomer to the scene, it would be very helpful to me (and others I believe) if you shared any relevant mailing list discussions that could help bring folks like me up to speed on the WebRTC group's current thoughts on the MediaStream and how it is viewed from the RTC point of view. For example, what's the "stream of bytes fallacy", and why is it a poor view of a MediaStream? Also, would love more info on what you say just below: >A MediaStream is not a stream of bytes. At some points it can be >represented as one; at other poitns it may create one. But it isn't one.
Received on Friday, 9 December 2011 22:48:41 UTC