Signaling codec resource exhaustion (formerly Custom error types)

[Djuffin]

Currently WebCodecs rely on DOMExceptions with different names, but DOMException names are deprecated .
For proper and granular error reporting WebCodecs might need a special error type, like WebGpu pipeline error.

We might also need a special error type for rejecting promises and reporting errors via VideoEncoder and VideoDecoder callbacks.

[chrisn]

Looking at the list of DOMException names it's only IndexSizeError, InvalidAccessError, TypeMismatchError, and URLMismatchError that are marked as deprecated. The WebCodecs spec doesn't use any of those so I think we're OK in that regard.

[aboba]

Can we use EncodingError to indicate an issue with the data provided to the Encoder/Decoder, and something else (e.g. OperationError) to indicate a resource issue (e.g. hardware encoder resource no longer available)?

[xingri]

@Djuffin, @aboba If it is possible, can I get a reference on the current working in progress?
Would like to investigate any possible changes on application side.

[chrisn]

Discussed in Media WG meeting, 30 May 2023, minutes.

[xingri]

Discussed in Media WG meeting, 30 May 2023, minutes.

Thanks @chrisn for the update.

[aboba]

@Djuffin @padenot Has there been any progress in implementing this?

[padenot]

None.

[Djuffin]

I'm looking at how to suffice signal that we ran out of HW encoders or decoders.
Most logical behavior seems simply reporting QuotaExceededError
and then I realized that it's basically Resource Reclamation, that we already have in the spec.

So we don't even need to change much. But we'll need to adjust the definition of the active encoder/decoder i.e. declare newly created encoder/decoder that hasn't outputted anything yet - inactive. Then UA will be able to reclame it immediately after it realized that there is no system resources for it.