W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

Re: addTrack/removeTrack on gUM streams and PeerConnection remote streams

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 17 Apr 2013 19:30:45 +1200
Message-ID: <CAOp6jLYeqMiyyMkTp1rYn0-K=7_n69s5fTDQ20HdddKffczN7Q@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Wed, Apr 17, 2013 at 6:55 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

> To me, it sounds unjustified.
> The following code:
> getUserMedia(... function(inflexibleStream) {
>      flexibleStream = BundledMediaStream(**inflexibleStream);
>      ... the success callback in existing code ....
> }... )
> will provide a stream with 100% exactly the behaviour we have today. So
> implementations have to support the same behaviour in the new model as in
> the old model - you're not preventing any complexity that we currently have.

The MediaStream constructor that takes a MediaStream parameter is
underspecified; the spec just says "the given stream is cloned" and does
not say whether the two streams share the underlying track set or not. I
had assumed the track sets would not be shared --- the new stream would
have a copy of the original stream's current track set, and would not be
updated as the original stream's track set changes --- but you have assumed
they will share a single underlying track set.

Note that if the track set is shared then the spec text "separate
MediaStream instances can be manipulated and consumed individually" is
misleading since addTrack/removeTrack on one stream would affect the other

q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Wednesday, 17 April 2013 07:32:00 UTC

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