Re: Releasing media stream created by gUM

On 10/22/2013 10:54 AM, Kevin Dempsey wrote:
> I thought that addTrack and removeTrack were going to be 
> remove/disabled on streams created by gUM (and the remote streams from 
> RTCPeerConnection). At least that is the conclusion I got from reading 
> this thread: 
> http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0127.html

That could be a reason for revisiting that decision....?

>
>
> On 21 October 2013 20:08, Harald Alvestrand <harald@alvestrand.no 
> <mailto:harald@alvestrand.no>> wrote:
>
>     On 10/18/2013 10:50 AM, Kevin Dempsey wrote:
>
>         In earlier versions of the gUM spec, the stream created by a
>         getUserMedia() call had a stop() method that ended all the
>         tracks, reduced the reference count on the track sources and
>         if that reference count reached zero, the source was stopped
>         (and recommended that any 'on-air' indicator was removed).
>
>         In recent versions of the spec the stream doesn't have a
>         stop() method, but MediaStreamTrack does. However, this stop()
>         method stops the source regardless of whether any other track
>         is using that source. I know that the 'best practices' section
>         recommends that sources should not be shared but the
>         MediaStreamTrack stop() function's "kill switch" behaviour
>         forces that upon implementors.
>
>         So under the current spec, the release the stream created by
>         getUserMedia() you have to call stop on all tracks it has (one
>         audio and one video maximum). This will also kill the sources
>         and therefore end any track also using those sources.
>
>         Can we also have the earlier behaviour in a function on the
>         returned stream (perhaps not called stop() to reduce possible
>         confusion)?
>
>     Possibly the closest equivalent to the old behaviour is to call
>     MediaStream.removeTrack() for all the tracks. We don't have a
>     reference counter that can be counted down yet, but when all
>     references to the tracks that take input from a source are lost,
>     we would expect the source to stop.
>
>
>