Re: On reserving and releasing resources

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