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 
add/removeTrack).

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.


[1] 
http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0143.html

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

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