W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2011

RE: Defining the split on WebRTC deliverables

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>
Message-ID: <9768D477C67135458BF978A45BCF9B38381C7701@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
>-----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? *
>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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:08 UTC