Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conformance against enumerated assertions in VideoConfiguration #141

Open
wilaw opened this issue Dec 14, 2019 · 2 comments
Open

Conformance against enumerated assertions in VideoConfiguration #141

wilaw opened this issue Dec 14, 2019 · 2 comments
Labels

Comments

@wilaw
Copy link

wilaw commented Dec 14, 2019

[Filed on behalf of the CTA wave project Technical Working Group]

If you ask a teenager if they can drive according to the State driving code, they will likely tell you yes. However one teenagers opinion of how well they drive maybe quite different to another's. What you should ask instead is whether they have passed the state driving test and received a drivers license, as this is proof that they have reached an objective level of conformance relating to the driving code.

We mention this as an analogy to a current issue we see with the MC spec. With respect to the HdrMetadataType, ColorGamut and TransferFunction properties of a VideoConfigration, the MC API will attest to whether the device "supports" these capabilities. However, different user-agent vendors will have differing opinions on what support entails. For example with Color Gamat - "If the attached output device also supports the specified color, the UA needs to be able to cause the output device to render the appropriate color, or something close enough.". How does W3C write a conformance test for "close enough"?

The specs referenced, such as sRGB, DCI P3 and BT.2020 - define the gamats but not conformance points. Similarly for the HDR metadata types defined by [SMPTE-ST-2086] - [SMPTE-ST-20894]. Even if a device can interpret the metadata, the screen may not actually display it. Similarly, it may accept Bt2020 color data and then map everything to 709.

So the request is for Media Capabilities, where possible, to reference conformance points alongside each of the technical specs involved in VideoConfiguration properties. In this way we can be sure that we get the same answer across different user-agents when presented with the same hardware. The teenagers will tell us a consistent story ;)

Cheers
Will

@mwatson2
Copy link

This is a mis-understanding of the API. Perhaps some further words of clarification are required ?

The question answered by the MC API is whether the requested format is supported at all. That is can the data be sensibly interpreted or should the site not send this format at all, even if it has no other format available. The UA should probably answer this question based on whether the data can be rendered in a way that will not cause the user to think the UA is broken. This is typically easy for the UA to answer since sensibly implemented UAs will not attempt to render a format they do not support at all.

Site may of course also be interested in a different question, for the case where the site has several formats available and the MC API says that several of those are supported. That is which of the available formats should be used ? This is much more subjective, but it is intended this question be addressed by CSS extensions describing the capability of the display.

Here the state driving test analogy holds up, but begs the question, which state ?

@chrisn
Copy link
Member

chrisn commented Dec 13, 2023

The relevant CSS spec for display capabilities is https://drafts.csswg.org/mediaqueries-5. I agree that "something close enough" seems hard to test against, but am unsure what changes are needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants