-
Notifications
You must be signed in to change notification settings - Fork 129
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
Why is isTypeSupported() promise-based? #750
Comments
Nor is the MediaSource one. For a promise based API; the use if MediaCapabilities may be more suited. |
The reasoning behind this is that the Web Codecs version (especially for the video side of things) goes much more in depth (and isn't based on the mime type alone), and provides an authoritative answer based on the current characteristics of the host, that can change over time (so it isn't generally possible to add a caching layer to avoid system calls, things we'd usually do to avoid speccing an async method). An example would be: let videoCharacteristics = {
codec: "avc1.64001e',
width: 3840,
height: 2160,
framerate: 60,
hardwareAcceleration: "prefer-hardware"
};
VideoEncoder.isTypeSupported().then(s => {
console.log(s.supported);
}); which is a reasonable thing to ask: can the browser encode h264 high profile, 4k at 60Hz in hardware (as to not strain the CPU because the developer knows full well that the input frames will be already on the GPU). This can return positively, and a minute later, this can return negatively because e.g. the GPU that did support encoding with those characteristics has been unplugged.
Besides, as shown in implementation today, the set of codecs supported by Web Codecs and other APIs is different.
|
Okay, but the video one is called I was looking at whatwg/html#6324 which wants a "simple" MIME type-based query as well and it made me wonder how this one would be different. |
#152 (review) and #213 has lots of background on this. |
But by the time the promise is resolved, the answer may already be obsolete regardless. So using a promise or a sync call do not resolve the issue that By the time you create the encoder, those characteristics may no longer be supported for the incoming encoder. |
This is not a problem that can be solved by a specification, only at the application level by handling failures, that are to be expected. The promise allows getting the best info possible in this dynamic environment, the sync version doesn't. https://w3c.github.io/webcodecs/#config-support mentions this. |
As background, |
Let's close this. |
canPlayType()
on media elements is not, why is this one?The text was updated successfully, but these errors were encountered: