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

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 18 Apr 2013 09:37:57 +0200
Message-ID: <516FA2D5.3090805@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Robert O'Callahan <robert@ocallahan.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-04-17 23:43, Martin Thomson wrote:
> On 17 April 2013 14:39, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Thu, Apr 18, 2013 at 8:59 AM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>>
>>> This sounds good to me.  I was going to go even further and suggest
>>> that track sets in MediaStream could be made immutable, but that
>>> changes the model we've been assuming too much.
>>
>>
>> I don't think we can do that --- IIUC, gUM streams, PeerConnection remote
>> streams and media-element streams can all dynamically add and remove tracks
>> as the source progresses.
>
> That's may be true for PeerConnection, though it doesn't have to be,
> depending on how we intend to resolve certain media path issues.  My
> expectation for gUM was that the output would be stable from a track
> perspective at least.  But you are right, it's probably unworkable.
> My vain hope was to confine that sort of dynamism to processing-type
> APIs.
>
I think the question of whether all MediaStream's could be immutable 
(i.e. not allow tracks to be added or removed) is partly up to 
implementers. I think we could live with that in a first version if very 
complex to support, but OTOH it seems that this is not the case based on 
the feedback so far.
Received on Thursday, 18 April 2013 07:38:21 UTC

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