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

RE: Thoughts on converging MediaStream and Stream objects

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Fri, 9 Dec 2011 22:38:35 +0000
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38381C76BC@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
>-----Original Message-----
>From: Harald Alvestrand [mailto:harald@alvestrand.no]
>On 12/09/2011 10:52 PM, Travis Leithead wrote:
>>> -----Original Message-----
>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>> I think you are misled by an accident of naming.
>>> If anything should be converged with the Stream API (something I'm not
>>> at all sure of), it should be the MediaStreamTrack.
>>> The sharpest difference is that a Stream is a byte pipe; a
>>> MediaStreamTrack is a control surface for an underlying implementation
>>> where the concept of "byte" doesn't even have to be meaningful.
>> I certainly understand the difference between the MediaStreamTrack
>> and the Stream-as-a-byte-pipe, however I didn't make the connection to
>> why/how you think the two should be converged? Can you explain in more
>> detail?
>A MediaStream is a container for zero or more MediaStreamTracks, with
>the ability to connect those as an unit to a <video> tag, a
>PeerConnection or some other consuming entity, and that's just about
>everything it is. It doesn't resemble a Stream at all.
>My main point is that Stream and MediaStream should *not* be converged.

So, we both agree on this point.

I think what's missing from my understanding of your previous mail is how 
you perceive a MediaStreamTrack. Is it merely a control channel, or is it
a container for stream data, or am I viewing the objects (media streams and 
tracks) in a completely different way? 
Received on Friday, 9 December 2011 22:39:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:34 UTC