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

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