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 16:04:24 +0100
Message-ID: <CAMvTgcdgtgfa27v1XTyxCD8iqv24q_zmdrJjqXqGd8x3q4FDzQ@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
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

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