Revise hardwareAcceleration based on consensus decision.

[dalecurtis]

• It's now a hint instead of being required.
• Values are noPreference, preferSoftware, and preferHardware.

Fixes: #239

---

Preview | Diff

[padenot]

We need to have a bit of prose somewhere that does the rejection in the case the UA decides to reject, right? I thought we had something in the current text but I can't find anything.

Probably just a rather vague line in the valid VideoDecoderConfig steps or something.

[dalecurtis]

We need to have a bit of prose somewhere that does the rejection in the case the UA decides to reject, right? I thought we had something in the current text but I can't find anything.

Probably just a rather vague line in the valid VideoDecoderConfig steps or something.

Yeah I thought we had one as well. Done.

[youennf]

As discussed in #239, I tend to prefer a more descriptive default value.
@dalecurtis mentionned renaming no-preference to prefer-efficiency if we can all agree on this default behavior.

[dalecurtis]

I defer final decision to @aboba @padenot, I prefer no-preference.

[aboba]

no-preference is fine. I've also seen "balanced" used.

[padenot]

I find this rather descriptive. In passing this value, the author explicitly signals that they don't have any particular preference, and defers to the UA to make the decision on what decoder to use, based on the scenario characteristics (on battery power, video resolution, etc.).

[dalecurtis]

Bump @youennf @padenot . Thanks!

[youennf]

I am fine with a MUST. I would try to be more straightforward in the way to state it.
Something like: To prevent any fingerprinting issue, the hardwareAccelaration preference value MUST have no effect on rejection of a given configuration.

[dalecurtis]

@youennf the current text is accurate, I've changed the wording slightly (avoid => prevent, SHOULD => MUST), but per editors consensus rejection using the preference will be allowed if it doesn't expose any fingerprinting information.

[youennf]

rejection using the preference will be allowed if it doesn't expose any fingerprinting information.

Can you describe what is the advantage of the current PR wording?
For instance, what are the cases where using the preference would trigger/prevent rejection and would not expose fingerprinting information?

[dalecurtis]

We've discussed this extensively on the issue, but to recap: the advantage is a clearer articulation of capabilities to developers (ideally resulting in a better end user experience) for UAs which have exposed equivalent information through Media Capabilities or other mechanisms.

• Per the issue thread this is important to developers -- both Zoom and VLC have expressed a desire to manage deny-lists for robustness and/or select their own internal software codecs when necessary.
• Data from @padenot and Zoom supports those requests. @padenot indicated that WASM is performant enough for low complexity operations that Firefox is replacing significant internal pieces with it. Zoom has confirmed independently that WASM is as performant or better for low resolutions (<=360p) using H264.

As for cases where it won't reveal additional fingerprinting, that's going to depend on the UA's implementation of other APIs. If a UA doesn't expose Media Capabilities or doesn't reveal hardware acceleration through the powerEfficient bit (or some other mechanism), a UA implementing WebCodecs will need to ignore the hardwareAcceleration value entirely.

For example, in Chromium software decoders are known based on major version, so no additional information is revealed with the no-preference or prefer-software values. MediaCapabilities reveals hardware presence via the powerEfficient bit for both encoding and decoding, so IsConfigSupported() provides zero additional information in our implementation. I expect this to be similar for most UAs, but if not they are required by this text to ensure zero impact on fingerprinting.

[youennf]

MediaCapabilities reveals hardware presence via the powerEfficient bit

In that case, let's be specific, being open-ended makes the whole sentence weak, I believe we can safely remove 'or other web exposed capability systems the User Agent may provide'.
FWIW, the probability for another capabilities mechanism is probably low and it is safer to revisit the issue if such a new mechanism happens.

[dalecurtis]

Done, I've made the text clearer.

[chcunningham]

@padenot @aboba friendly ping to take a look at the latest here

[padenot]

I find this rather descriptive. In passing this value, the author explicitly signals that they don't have any particular preference, and defers to the UA to make the decision on what decoder to use, based on the scenario characteristics (on battery power, video resolution, etc.).

[chcunningham]

We need to have a bit of prose somewhere that does the rejection in the case the UA decides to reject, right? I thought we had something in the current text but I can't find anything.
Probably just a rather vague line in the valid VideoDecoderConfig steps or something.

Yeah I thought we had one as well. Done.

This is covered by step 3 of the Check Configuration Support algo.
https://www.w3.org/TR/webcodecs/#config-support

3. If the User Agent can provide a <a>codec</a> to support all entries of the
    |config|, including applicable default values for keys that are not
    included, return `true`.

It intentionally doesn't reference individual attributes of the config, since that would be a long list and the current text is pretty clear. This algo is invoked for both IsConfigSupported() and for the support checks that take place during configure().

I'll take the liberty of reverting @dalecurtis commit to check this in the config validation steps. The semantics of that algo are "is your input valid" which we want to distinguish from "supported". This algo is called earlier on in the synchronous steps of the methods that take configs and produces rejection via TypeError (invalid input).

[chcunningham]

LGTM. Looks like all comments are addressed. On naming, sticking w/ "no-preference" given majority approval.