Re: [mediacapture-main] How to implement web-compatible camera downscaling?

> That  problem seems unique to Chrome, because of its choice to not fully utilize the full expressiveness of the constraints language.

I don't think Chrome has a problem with this. No one has filed Chrome bugs against this behavior. 

> That concept is already in the spec, as evidenced by Firefox and Edge users not having this problem.

No, the concept of native modes or their discovery is not in the spec. Chrome supports rescaling and its constraints algorithm returns rescaled resolutions over native ones when they result in lower fitness values as defined by the spec.
FF and Edge only support native resolutions and they return native resolutions. There is nothing in the spec to suggest that native modes should be preferred over rescaled ones when the rescaled ones have a better fitness. The fact that you we are discussing possible spec changes in order to support both rescaling and native modes over rescaled modes just confirms this.

> To turn this around, assuming no interest in a new constraint, what might you be interested in pursuing to narrow the current browser gap in output from the constraints algorithm?

Currently the main priority for Chrome is to be spec compliant. There are many parts of the spec that Chrome does not implement and the priority is to focus on those. The browser gap is a lot greater in those areas and that is therefore the priority for Chrome.
With respect to the output of the constraints algorithm, it is spec compliant and users have not filed bugs so far complaining about it. Thus, changes in this area have low priority.
In particular, we are not willing to pursue the proposal of changing the semantics of the constraint keywords due to the reasons already explained. We are willing to consider other proposals that do not change the meaning of the keywords, even if they are not based on new constraints. 
An option that comes to mind is changing the fitness function so that it penalizes nonnative candidates more than native ones, but with a finite penalty so that they still satisfy the constraint and without redefining keywords.
Something like 
  fitness = (requires_processing ? 1000.0 : 0.0) + |actual -ideal|/max(|actual|,|ideal|)

This would actually introduce the native-mode discovery that the authors originally intended and it would still allow users to control rescaling. Applications that require a specific (potentially rescaled) resolution would use exact on the basic set. Applications that prefer but do not require rescaled would use exact on an advanced constraint.
I still have to analyze the full consequences of such a change, especially but, in principle, it seems a lot more reasonable than redefining keywords and naked values.

-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/472#issuecomment-321085922 using your GitHub account

Received on Tuesday, 8 August 2017 21:23:48 UTC