HIQaH! QaH! TAG!

I'm requesting a TAG review of Media Source Extensions for WebCodecs.

The Media Source Extensions API (MSE) requires applications to provide fragments of containerized media (such as fragmented MP4, WebM, or MP3) to be able to buffer and play that media. If the application already has the media in a parsed and structured form, it can cost extra latency and code complexity to package that media into a container and feed it to MSE. As the web platform is evolving to give applications lower-level abstractions for efficiently encoding and decoding media via the WebCodecs API, MSE can use WebCodec's media structures to let applications more efficiently feed their media to MSE. We propose additional MSE methods to provide web authors easy ability to buffer "containerless" media as an alternative to existing MSE methods that required containerized, "muxed" media.

• Explainer (minimally containing user needs and example code): https://github.com/wolenetz/mse-for-webcodecs/blob/main/explainer.md
• Security and Privacy self-review: https://github.com/wolenetz/mse-for-webcodecs/blob/main/security-privacy-questionnaire.md
• Primary contacts (and their relationship to the specification):
  • Matt Wolenetz (@wolenetz, Google) - MSE spec co-editor and editor of this new feature.
• Organization/project driving the design: Google Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • Chrome Status: https://www.chromestatus.com/features/5649291471224832
  • MSE specification issue: https://github.com/w3c/media-source/issues/184#issuecomment-720771445
  • Chromium feature bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1144908

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Media WG
• The group where standardization of this work is intended to be done ("unknown" if not known): Media WG
• Major unresolved issues with or opposition to this design: None. Minor open questions are listed in the Explainer's Open Questions section

You should also know that...

• The review is early in the prototyping and design stage because we expect to learn from early implementation feedback more precise answers to the Explainer's Open Questions section, so we'd like to get a rough design reviewed to help refine eventual implementation and specification for this feature.

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @wolenetz