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

Re: Has MediaStream the stop() method?

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Thu, 2 Jan 2014 16:42:02 +0100
Message-ID: <CALiegfnWDig0WB5NRvSeX2EPbf=y98Sq2BV36CUQBCCKR-AsAQ@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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.


> Another reason is that if stop is
> on MediaStream level only there is no way to return the right to use
> e.g. the camera only but retain the right to use the microphone. Dealing
> with stop on MediaStreamTrack level is more straightforward.

Of course, I am not against MST.stop() but just in favour of *also* a
MS.stop(). If the user just want to revoke video permission then user
MST.stop().


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


Best regards.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Thursday, 2 January 2014 15:42:50 UTC

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