Re: Releasing media stream created by gUM

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


On 21 October 2013 20:08, Harald Alvestrand <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.
>
>
>