- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Jun 2017 13:49:59 +0000
- To: public-media-capture@w3.org
guidou has just created a new issue for https://github.com/w3c/mediacapture-main: == Questions about Section 3. == I would like clarification for the following case: Let's say the system has a single camera that can provide frames at 60Hz. There are two getUserMedia callsA. One requests an exact frame rate of 30Hz, and the other one requests an exact frame rate of 60Hz. Chrome currently allows both calls to succeed. For the first track, Chrome drops every other frame, so the track has an effective frame rate of 30 Hz. For the second track no frames are dropped, so it has the requested 60Hz. Section 3 says _"User Agent processing, such as downsampling, may be used to ensure that all tracks have appropriate media"_, so processing to get a 30Hz track seems compliant. The question is what should getSettings return? Chrome currently returns 30Hz for the first track and 60 Hz for the second track, which I think is what a user would expect. However, the spec says that settings don't belong to the tracks, but to the source. More specifically, it says _"Sources have constrainable properties which have capabilities and settings. The constrainable properties are "owned" by the source and are common to any (multiple) tracks that happen to be using the same source (e.g., if two different track objects bound to the same source ask for the same capability or setting information, they will get back the same answer)."_ This part suggests that returning 30Hz and 60Hz could be a violation of the spec, unless one considers the source to be not the camera, but the processed 30Hz stream. Interestingly, the definition of getSettings() says _"The getSettings() method returns the current settings of all the constrainable properties of the object, whether they are platform defaults or have been set by the applyConstraints algorithm.", where _object_ is the track, so this part of the spec suggests that settings might belong to tracks after all. So, should Chrome be "fixed" to return 60Hz for the track with 30Hz? Note that this is relevant to other properties for which Chrome currently provides processing. Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/466 using your GitHub account
Received on Friday, 16 June 2017 13:50:05 UTC