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:48:12 +0200
Message-ID: <516FA53C.4060105@ericsson.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
CC: robert@ocallahan.org, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-04-17 12:06, Adam Bergkvist wrote:
> On 2013-04-17 01:09, Robert O'Callahan wrote:
>> To be concrete, here's what I think we should do:
>> -- Introduce a new subtype of MediaStream, let's call it
>> BundleMediaStream but I don't care what it's called. This stream
>> represents a bundle of tracks from other MediaStreams, where the
>> application controls the track set.
>> -- Move the current MediaStream constructors to BundleMediaStream.
>> -- Move addTrack/removeTrack to BundleMediaStream.
>> -- Specify that for MediaStreams other than BundleMediaStream, the UA
>> always controls the track set.
>> This means for any MediaStream, either the UA controls the track set, or
>> the application does, but not both. I think this is a helpful
>> simplification for implementations and at the spec level.
>> How does that sound?
> I like this idea at first glance.
> The model to let an application-managed MediaStream (BundleMediaStream)
> inherit from MediaStream is simple but gives us, IMO, a lot. The only
> drawback I can see is that the event handlers, used to listen to how the
> UA adds and removes tracks, are available on BundleMediaStream as well.
> We could add a new common base type to get around that, but I don't
> think it's a deal breaker.

Could we not pick parts from Travis' proposal of Aug last year ([1])?

I.e. a some kind of BaseMediaStream class (with no add/removeTrack 
methods) what the UA deliver to the application with the onaddstream 
event/successful gUM.

And that the MediaStream constructor extends the BaseMediaStream (adds 

The advantages would be that existing code that does "new MediaStream" 
would not break, and that we could also do another extension for a 
LocalMediaStream (better name wanted!) delivered by gUM that adds a 
"revoke" method that abandons the access to all microphones/cameras.


> /Adam
Received on Thursday, 18 April 2013 07:48:38 UTC

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