- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 8 May 2012 16:06:49 +0200
- 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 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 Tuesday, 8 May 2012 14:07:22 UTC