Intention behind VideoFrame allocationSize and copyTo always throwing when format is null, even when requesting RGB conversion #920
Description
There's a part of the design of the WebCodecs API whose intention is unclear to me:
The allocationSize and copyTo methods of VideoFrame throw when the frame's format is null. While this by itself makes sense, given that a null format is supposed to model frame formats that WebCodecs can't represent, both methods accept an additional format option which can be used to retrieve the frame data in any of the four RGB formats (RGBA, BGRA, RGBX, BGRX). My assumption had always been that even when the frame's format is null, setting the format option to an RGB format would allow me to get those methods to work again. However, this is not the case. The spec clearly instructs UAs to throw, always, if the frame's actual format is null, no matter the options.
The reason I find this design decision strange is because you can still access this data if you really want to: Computing allocationSize for an RGB format is trivial, and since all VideoFrames can be drawn to a canvas or converted to a bitmap, that means all VideoFrames can also be converted to an RGB format by simply drawing them to an offscreen canvas and then doing a getImageData readback.
Given that every VideoFrame already knows how to convert itself to RGB (no matter the internal format), for ease of use, I would argue allocationSize and copyTo should behave like this: Throw when called with the frame's format, but perform a conversion to RGB if an RGB output format is provided in the options.