search

w3c / webcodecs

WebCodecs is a flexible web API for encoding and decoding audio and video.
https://w3c.github.io/webcodecs/
Other
937 stars 131 forks source link

Spec differentiates between ImageDecoder initialization with unsupported non-image MIME type and an unsupported image MIME type #794

Open aosmond opened 3 weeks ago

aosmond commented 3 weeks ago

There is a WPT that checks for a NotSupportedError promise rejection when the MIME type "junk/type" https://github.com/web-platform-tests/wpt/blob/53a1437dcfc754a3dc8ffe0bd34f9a6524e49fcf/webcodecs/image-decoder.https.any.js#L163

This conflicts with a strict reading of the spec:

From https://w3c.github.io/webcodecs/#imagedecoder-constructor: "If init is not valid ImageDecoderInit, throw a TypeError."

From https://w3c.github.io/webcodecs/#valid-imagedecoderinit: "1. If type is not a valid image MIME type, return false."

From https://w3c.github.io/webcodecs/#valid-image-mime-type: "A valid image MIME type is a string that is a valid MIME type string and for which the type, per Section 8.3.1 of [RFC9110], is image."

From https://w3c.github.io/webcodecs/#configure-the-image-decoder "1. Let supported be the result of running the Check Type Support algorithm with init.type." "2. If supported is false, run the Close ImageDecoder algorithm with a NotSupportedError DOMException and return "processed"."

If we put all this together, my reading of it says that if the MIME type supplied is anything besides "image/XXX", we should throw a TypeError in the ImageDecoder constructor. If we don't support XXX, then we should reject the ImageDecoder [[completed promise]] and ImageTrackList [[ready promise]] with NotSupportedError.

Is this what we want? I don't have any strong feelings either way, just want to understand if the test is wrong, or if this is an inconsistency in the spec that we want to correct.

dalecurtis commented 3 weeks ago

Thanks for filing! We don't want to through type errors for things that should just be rejected through the normal support checks -- this was updated in https://github.com/w3c/webcodecs/pull/707 for the other codecs, but it looks like I forgot to update ImageDecoder.

dalecurtis commented 3 weeks ago

Actually, your point is more subtle. The text does say if it's not image/xxxx it should through a type error. I know Safari supports video-in-img, so maybe this is too strict though.

@youennf @jernoble @padenot in case they have opinions on the current wording.

My original intent was to allow for things like video/mp4 if desired by the user agent. Chrome doesn't have current plans to do this, but I don't see any reason to forbid a UA from support if they want to.