Open padenot opened 1 year ago
Or just throw.
The spec does seem to be written to assume that [[format]]
cannot be null
. For VideoFrame
we do expect null
in cases where the frame exists but readback in a WebCodecs format is not possible, and allocationSize()
in that case throws (https://w3c.github.io/webcodecs/#dom-videoframe-allocationsize).
I agree that this is unlikely to occur in practice. In Chrome, we already decode into formats not supported by WebCodecs, but always convert them in copyTo()
.
It looks like Chrome's implementation will produce a closed AudioData
if an unconvertible format ever actually showed up (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webcodecs/audio_data.cc;l=213;drc=1d2715064cc686e5eac4e41f34dbc212d47deff1). This is probably a reasonable approach if the AudioData
cannot be output, whereas just having a null
format
makes more sense if only copyTo()
is unavailable.
It is technically possible to have a non-empty
AudioData
with anull
[[format]]
, if getting anAudioData
after decoding and it's not "recognized".If
allocationSize
is called on this freshAudioData
, what happens in step 5 of its algorithm?We might be able to just return the number of bytes in the resource.
In practice, it might be the case that implementations can't hit this -- at least Gecko supports all specced audio sample formats.