Why is isTypeSupported() promise-based? about webcodecs

[jyavenard]

Nor is the MediaSource one.

For a promise based API; the use if MediaCapabilities may be more suited.

[padenot]

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.

MediaCapabilities can also more or less answer this question (and is async for the same reasons), but is one API level higher: it deals in terms of webrtc, recording, talks about power efficiency, smoothness. Those are not relevant for the Web Codecs user who wants to know if a VideoEncoder.configure(...) will succeed without having to attempt to initialize a temporary VideoEncoder.

Besides, as shown in implementation today, the set of codecs supported by Web Codecs and other APIs is different.

HTMLMediaElement, including MediaSource are at the top of the API abstraction level and are playback-only anyway.

[annevk]

Okay, but the video one is called isConfigSupported() if I understand it correctly. This method is called isTypeSupported() and only takes a MIME type (as a string).

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.

[padenot]

#152 (review) and #213 has lots of background on this.

[jyavenard]

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).

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.

[padenot]

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.

[dalecurtis]

As background, canPlayType() has always been a pain to implement due to its synchronous nature. In Chrome, it requires blocking / synchronous coordination between 2+ processes on the render thread to answer authoritatively. I'm strongly against ever shipping any synchronous media detection API in any form again.

[padenot]

Let's close this.