Re: [mediacapture-main] Fitness distance steps 4 and 5 are inconsistent with the rest of the spec (#933)

> If they're not necessarily IDL dictionaries we shouldn't link to the definition of IDL dictionaries when talking about existence of fields.

True.

> The implementation of SelectSettings does not require that we have a list of IDL Settings dictionaries that are checked individually (and, for example, the Chromium implementation doesn't follow that approach). It can be the case that support for a particular property is determined by calling some system API and taking a code path that covers multiple dictionaries simultaneously.

That is usually also the only practical implementation because the total number of all possible settings dictionaries is the product of number of all possible settings for each property supported by the implementation and the source.
 
> > Could the step 4 be clarified to be `If constraintValue is a boolean, but the setting of the property is not`? The term _the setting of this property_ is used elsewhere in the spec.
> 
> This doesn't make sense because if you define a type in IDL (and you have to do it for constraints) the only possible values have to correspond to that type. Having a step to cover the case where the value does not correspond to its type is unnecessary/incorrect since that value wouldn't exist.

`MediaTrackConstraintSet` WebIDL defines pan constraint to be of type `(boolean or ConstrainDouble)` so _constraintValue_ for pan can be a boolean where as `MediaTrackSettings` WebIDL defines pan setting to be of type `double` so it definitely is not a boolean. So the value does correspond its type but not its setting's type. IMHO that makes sense.

> There are already definitions of fitness distance for strings, doubles and booleans, so I see no need to define anything different for those properties.

For all positive numeric constraints, the fitness distance is the result of the formula
  `(actual == ideal) ? 0 : |actual - ideal| / max(|actual|, |ideal|)`.
What if a site calls `navigator.mediaDevices.getUserMedia({iso: 400})` and there is a source which does not support ISO? An implementation should compute (or simulate to compute) the fitness distance between the constraints and all possible settings dictionaries. It is clear that _ideal_ is 400 in this case but what is _actual_? There is no actual ISO. The source does not support ISO. So that definition would need an addition stating that the fitness distance in this case is 1 because there are no actual value. But that is exactly what the step 5 tries to do.

Of course, it is possible to remove the step 5 and integrate it in and repeat at steps 7 and 8.

> IMO, we should just return to the [old fitness distance definition](https://www.w3.org/TR/2020/CRD-mediacapture-streams-20200924/#dfn-fitness-distance) and just add an extra step on how to calculate its value for the (boolean or ConstraintDouble) type.

Wouldn't that basically be a combination of the current steps 4 and 7?


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 March 2023 18:41:23 UTC