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

On 2013-04-17 09:32, Stefan Håkansson LK wrote:
> On 2013-04-17 08:55, Harald Alvestrand wrote:
>> On 04/17/2013 01:09 AM, 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?
>>
>> 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.
>>
>> I don't see what advantage we get by the existence of the intermediate
>> object that justifies the complexity of adding it to the model.
>
> I see it differently. I think Robert has a point in that it is confusing
> when both the UA and the application can modify a MediaStream.
>
> I think that is especially the case for MediaStream's on the receiving
> end of a PeerConnection. The MediaStream received is conceptually a copy
> of the one sent by the remote party. But if the application at the
> receiving end can add and remove tracks it gets a bit confusing I think.
> You easily end up in discussions if such changes should propagate back etc.

I agree with Stefan here. This is one of the reasons why I proposed to 
have a different type for "inbound" MediaStreams in the past.

/Adam

Received on Wednesday, 17 April 2013 07:41:17 UTC