W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2013

Re: Releasing media stream created by gUM

From: Kevin Dempsey <kevindempsey70@gmail.com>
Date: Tue, 22 Oct 2013 09:54:33 +0100
Message-ID: <CAMvTgcfKo3YedWNDiLOA=3Tn3fPjUJhu_Xmp2izvw1ZN3aUnAQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-media-capture@w3.org
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:

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.
Received on Tuesday, 22 October 2013 08:55:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:20 UTC