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

On reserving and releasing resources

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 8 May 2012 16:06:49 +0200
Message-ID: <4FA92879.1000202@ericsson.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
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 

(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!).

Received on Tuesday, 8 May 2012 14:07:22 UTC

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