What should the shape of the API be? about webcodecs HOT 3 CLOSED

Based on our experience implementing VideoDecoder in Chromium, @chcunningham and I reviewed these options and we are implementing option D.

• A (replacing streams every time): Replumbing is less elegant than in-band signaling in the cases we considered. Consider a potential app implementation of seeking:

demuxer.readFrom(time).then((config, readable) => {
  decoder.configure(config).then(writable => readable.pipeTo(writable));
});

• B (out-of-band with same stream): Buffering is inherent in WritableStream, we cannot reliably synchronize in- and out-of-band signals without replacing streams.
• C (out-of-band with new stream): Basically the same as A.
• D (in-band): Using preventCancel and preventAbort, the whole pipeline does not need to be torn down on failure. Main downside is that streams contain multiple types of messages. Here the app implementation is much simpler because the configuration does not need to be separately plumbed:

demuxer.seek(time)

• E (in-band with implicit configuration): Same as D with more complexity.

It still remains to be seen if preventAbort/preventCancel/signal solutions are intuitive enough to be required for first-time use of WebCodecs. It would be a bad outcome if apps always wrap decoders to provide a different interface.

from webcodecs.

After thinking on this over the weekend, I think option A/C is worth considering further. If we provide a configure() that replaces the streams (and aborts the old ones), then clients can use preventAbort/preventCancel to polyfill any of the other options. This may be the safest path while we wait to see what happens with flush in streams.

from webcodecs.

Obsolete. See explainer updates (decouple from streams).

from webcodecs.