W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2012

Re: On reserving and releasing resources

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 18 May 2012 14:07:27 +0200
Message-ID: <4FB63B7F.2040704@ericsson.com>
To: Cullen Jennings <fluffy@iii.ca>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 05/17/2012 09:03 PM, Cullen Jennings wrote:
> On May 8, 2012, at 8:06 AM, Stefan Hakansson LK wrote:
>> Basically getUserMedia can have two different meanings:
>> 1. It is merely a way for the user to give consent to the
>> application to use devices (and the user is involved in selecting
>> which devices). The devices would not be reserved, activated or
>> start producing data until there is a consumer (e.g. a video
>> element) for the MediaStream delivered by getUserMedia.
>> 2. It is rather a way to grab those resources, activate them and
>> have them start producing data (regardless of whether the data is
>> consumed or not).
> Regardless of what it is (and I always assumed it was 2), we need the
> API to provide a function to do 2. Otherwise you can't make apps that
> don't get their resources stollen. I'm not sure we need an API that
> provides 1 but perhaps we do.

THis was discussed at the telco May 9th; the result was that 2. was the 
way forward. Anant got the actions to draft text, action 2 and 3 here: 


>> (I'm sure there are also other interpretations). I think that these
>> aspects have not been discussed very much, but they have big
>> implications.
>> For example, if we assume meaning 2. above, an application could
>> not be written to do getUserMedia at load time (to have that done
>> if/when there is a need to use the MediaStream) as this would block
>> other applications from using e.g. camera and mike.
>> On the other hand, if we assume meaning 1., the situation could be
>> that once the application needs the MediaStream, the devices are
>> blocked by another application (which is using e.g. camera and
>> mike), so there would be an error even though getUserMedia worked
>> out OK.
>> I also think it has implications on when to release devices. With
>> meaning 1., it would probably make sense to release devices once
>> there are no consumers of the MediaStream(s) they generate. With
>> meaning 2., devices should probably be released only if the user
>> revokes (via the browser chrome) the consent to use them or if all
>> MediaStream's that the device delivers to have "ended" (by the app
>> calling the "stop" method).
>> I think it would make sense to spend a little while discussing this
>> tomorrow (and on this list!).
>> Br, Stefan
Received on Friday, 18 May 2012 12:07:58 UTC

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