Web Codecs

[padenot]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebCodecs
• Specification or proposal URL: https://github.com/WICG/web-codecs
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): No bug
• Mozillians who can provide input (optional): @padenot

Other information

This specification is under consideration.

We've been participating in the elaboration of the explainer in the WICG repo, and are actively engaging with other vendors to design this.

The amount of unanswered problems and open questions on this emerging specification is high (as expected: it's a complex problem, and it's early in the design process), but the current APIs available to perform encoding and decoding on the web are severely limiting at the moment.

[dbaron]

So I think we've used under consideration as "we're currently discussing what position to take" (sometimes for too long!), whereas defer means that we want to wait for further information in order to take a position. But perhaps (given that I'm responding 5 months later!) we now have more information?

@padenot , what do you think of it these days?

[padenot]

This is worth prototyping (and we're following closely and participating to the design discussions), for the following reasons:

• this steers away from the accidental design of all the APIs around encoding and decoding of media on the web (that have been designed to solve use-cases in an ad hoc way, over the years), and designs a system instead of solving a use-case, which is what we should do in general, and haven't done in this particular domain
• this proposes a path that is not only designed carefully to be composable with existing APIs, but also extensible by authors in JS and WASM, and to allow solving all use-cases possible when it comes to media (including really re-implementing higher-level constructs such as HTMLMediaElement or MediaRecorder, without real loss of performance)
• this solves real problems that developers have, judging by the issues opened on media-related specs, stackoverflow questions asked, and generally the apps that are not available on the web but available on other platforms

Additionally, it's been decided in the W3C Audio Working Group that further development of the Web Audio API standard will not include encoding and decoding capabilities, to focus on on processing. Encoding and decoding is better served by its own API.

[martinthomson]

There is a view of this that less rosy in that this design is likely incompatible with our strategy for confidential calling in WebRTC. But that doesn't need to change this outcome.