- From: Kevin Dempsey <kevindempsey70@gmail.com>
- Date: Tue, 22 Oct 2013 16:04:24 +0100
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <CAMvTgcdgtgfa27v1XTyxCD8iqv24q_zmdrJjqXqGd8x3q4FDzQ@mail.gmail.com>
Yes, that is right, for me at least. I can also imagine there may be people who would not want to "revoke" permissions from cloned media streams. On 22 October 2013 14:51, Stefan Håkansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 10/22/13 1:33 PM, Kevin Dempsey wrote: > > I am trying to create a simple wrapper that can be used to embed webrtc > > phone-like functionality into pages provided by a third party. There is > > nothing to prevent multiple copies of this wrapper (or other gUM using > > code) from being included on a single page. > > > > If both 'apps' presented on a single page, call getUserMedia and each > > get a stream with a track that is derived from the same source. When one > > of the apps has finished with its stream how can it ensure that it is > > stopped without affecting the other app's stream. > > Ok, so you'd want a way to handle each getUserMedia generated > MediaStream separately. Say gUM call A returned MediaStream A, while gUM > call B returned MediaStream B; if you "revoke" gUM A you'd like all > tracks coming from that call (including cloned ones) to stop, but not > MediaStream B (or clones generated from it) to be affected. > > Is that right? > > > > > I don't think that I can rely on garbage collection as the page using my > > wrapper may still have a reference to the stream. (I suppose it may also > > have cloned the stream but that would be a deliberate attempt to break > > things, so I not particularly worried about that). > > > > > > On 22 October 2013 11:58, Stefan Håkansson LK > > <stefan.lk.hakansson@ericsson.com > > <mailto:stefan.lk.hakansson@ericsson.com>> wrote: > > > > On 10/18/13 11:53 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. > > > > Kevin, could you elaborate on what functionality you are missing? And > > note that stop() on a track will only stop the source for this > context - > > if there is another app using the same source it will continue to > work. > > > > * Is it a way to revoke access to input devices (for this app)? I > guess > > not since you can do that by stop() on the corresponding track(s). > > > > * Is it a way to allow your app be a bit careless in its book keeping > > (stop() on a track would indeed stop the source from feeding data > into > > other tracks in the same app)? > > > > * Is it a way to tell the UA that a MediaStream is not needed any > more > > (so it can be garbage collected)? > > > > > > > >
Received on Tuesday, 22 October 2013 15:04:52 UTC