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

Re: On reserving and releasing resources

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 09 May 2012 12:02:09 +0200
Message-ID: <4FAA40A1.7070503@alvestrand.no>
To: public-media-capture@w3.org
FWIW, 1 is what the current Chrome implementation does (according to Per).

On 05/08/2012 04:06 PM, 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).
> (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 Wednesday, 9 May 2012 10:02:40 UTC

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