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

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.


>
>>
>> A reasonable alternative that requires less new syntax would be to
>> make addTrack/removeTrack throw an exception when called on a
>> MediaStream that wasn't constructed via a MediaStream constructor.
>> However, I think introducing a new type is cleaner.
>>
>> Rob
>> --
>> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
>> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
>> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q
>> qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq
>> qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq
>> qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
>
>

Received on Wednesday, 17 April 2013 07:33:16 UTC