Re: Has MediaStream the stop() method?

On 1/2/2014 10:42 AM, Iñaki Baz Castillo wrote:
> Hi Stefan, thanks for your response. Comments inline:
> 2014/1/1 Stefan Håkansson LK <>:
>>> What is wrong with a MediaStream.stop() method that calls
>>> stop on every track?
>> I think it is mostly about clearness. If the same track is part of more
>> than one MediaStream, and you call stop on one of them - should the
>> track stop in the other one(s) or not?
> What I mean is a MS.stop method that iterates over all the MST and
> call stop() on each. So if a track also belongs ot other MS then the
> behaviour would be the same as if the user call stop() on the given
> MS. I see no problem, MS.stop is just a convenient method.

I agree.  All that leaving it out of MediaStream means is that every 
framework will implement their own version of it, and if a framework has 
a bug dealing with changes to the underlying browser implementations 
(new track types, etc), that bug will be painful to fix since there's a 
huge problem with frameworks getting fixed in stone by webpages/apps 
(the never-update problem).

Obvious convenience functions like this both make it easier to use, 
especially for non-experts looking to make simple use of 
WebRTC/MediaStreams/gUM, and reduce the chance of application bugs. THey 
also fit in with the idea of providing mid/higher level simple-to-use 
functionality, and the proposed lower-level nuts-and-bolts expert-level 
access.  IMHO.

>> I think the design has been iterated many times (last time was during
>> the f2f meeting at TPAC), and most people are happy as it is. It is not
>> that hard to loop over the tracks in a MediaStream!
> Probably not, but what about if MS has tracks other than audio and
> video tracks (i.e. text tracks)? Maybe this does not make sense but
> let's see what happen in the future. I would not like that today's
> applications become broken in the future
> because MS get new kind of tracks and the today's code just call
> stop() on audio and video tracks.


>> I think that if we should add anything, then it would be a stop/return
>> on the source level - sort of allowing the app to return the right to
>> use a source in a more direct way than having to stop all tracks the
>> source serves. But so far there has not been a strong desire for this
>> feature.
> How to access the "source level"? Currently what we get via gUM is a
> MS, the source is implicit and not addressable.

This is similar to the issues surrounding the 'doohickey'...

Randell Jesup -- rjesup a t mozilla d o t com

Received on Sunday, 5 January 2014 17:41:46 UTC