W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: Has MediaStream the stop() method?

From: Randell Jesup <randell-ietf@jesup.org>
Date: Sun, 05 Jan 2014 12:40:38 -0500
Message-ID: <52C99916.9050303@jesup.org>
To: public-webrtc@w3.org
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 <stefan.lk.hakansson@ericsson.com>:
>>> 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.

Right.


>> 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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC