Re: [w3ctag/design-reviews] WebCodecs support for AV1 screen content coding tools (Issue #912)

> Can we have a green light for the contentHint part? It is generic and makes sense for most encoders.

We don't necessarily "green light" proposals (we aren't an approval body) - but if you are asking whether the feature makes sense, the `contentHint` feature seems like a well-intended, non-controversial feature so we're happy with that.

>  I don't think that we need to try to combine codec specific options even if they have similarities in different codecs.

That wasn't really what I was suggesting when I asked that question, it was a counterargument on the "this is AV1 only" remark - at least if there is an equivalent feature it would make sense to have it interoperable, e.g., `hevc: { forceScreenContentTools: true}`.

> As the [spec](https://www.w3.org/TR/webcodecs/#dom-videoencoderconfig-contenthint) says codec specific knobs always take precedence.
> Tough one! As Eugene says, codec specific knobs take precedence so this would give you AV1 without screen content coding tools. 

So the reason why I asked this very question is because it smells of counterintuitive behavior. If `contentHint: 'detail'` for example would enable screen content coding, there is likely an expectation that `forceScreenContentTools: false`  should keep it enabled - since it implies it is a boolean flag *forcing* the feature to be enabled, that being false would imply not forcing it to be enabled, so it disabling screen content coding would be fairly counter intuitive. The other risk is cascaded configs and copypasta code canceling behavior as a potential footgun...

We would like to see an alternative consideration (the explainer doesn't have any "alternatives considered") for better developer ergonomics if possible.

The naming is not straightforward as well, but that's a feature of the codec so we don't have strong feelings about that detail. Overall, I think having a feature to do per-codec config overrides is a necessary and useful feature, but we think it would be helpful to foolproof the API a bit more for non-codec experts .

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/912#issuecomment-1829413490
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/912/1829413490@github.com>