Intent to Implement: WebCodecs
No spec or design doc yet, but there is some rough WebIDL at https://github.com/WICG/web-codecs/blob/master/webcodecs.idl.
Efficient, low-level access to built-in (software and hardware) media encoders and decoders.
Interoperability and Compatibility
The main risk is that other browsers do not implement it.
Edge: Public support (co-editing the spec)
Firefox: Public support (more specifically, "under consideration" more details at https://github.com/mozilla/standards-positions/issues/209 )
Safari: Negative signals (concerns over keeping it fingerprinting neutral)
Web / Framework developers: Positive (https://discourse.wicg.io/t/webcodecs-proposal/3662/)
Decoders will frequently be used with HtmlMediaElement for rendering media. Making sure it easy to render easily, performantly, and with low latency is important.
Many developers have requested that WebCodecs be easily used from WASM. Making sure that works easily, performantly, and with low latency is important.
Developers have requested that video decoders be easily used with WebGL for using decoded video frames on WebGL textures. Making sure that works easily, performantly, and with low latency is important.
WebCodecs would benefit from having libraries built on top that do things such as:
Encode and then containerize (mux) encoded media into formats such as mp4
Decontainerize (demux) and then decode media from formats as HLS
Buffer, decode, and playout media with low latency from an unreliable media transport (in other words, a jitter buffer)
WebCodecs could benefit somewhat from polyfills to experiment with the API, but that would not bring any of the performance benefits or access to hardware codecs.
Significant documentation and outreach would likely be helpful, especially for advanced uses of codecs, such as spatial and temporal scalability
There may be increased fingerprinting surface
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Link to entry on the Chrome Platform Status
Requesting approval to ship?
This is likely to amplify the codec fragmentation that already troubles the web. What are your thoughts on that?
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJrXDUE_E0P4GbwwRfWA1TtL1QTp65C2pDaHrffsN%3D2RjScmsg%40mail.gmail.com.
By exposing more low level information, I think that there will be more diversion points which will further reduce the chance of web developers having the time and energy to cover all variants. It is also plausible that a browser may support different sets of codecs on different abstraction levels. For instance, a platform might have APIs to get video data from a stream to the screen, but lack the ability to get individual pixels.
Since the codec fragmentation is a one of the web's weak spots, I wonder if you have considered the implications. You have probably thought more about video decoding than I have recently.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07e3a1c0-2c67-79b6-dcaf-86762071a472%40gmail.com.