What does `allocationSize` return if formats in the source and destination are null?
padenot opened this issue · comments
It is technically possible to have a non-empty AudioData with a null [[format]], if getting an AudioData after decoding and it's not "recognized".
If output uses a recognized AudioSampleFormat, assign that format to [[format]]. Otherwise, assign null to [[format]].
If allocationSize is called on this fresh AudioData, 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.
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.