Contact emails
*chcunning...@chromium.org <chcunning...@chromium.org>*Explainer *https://github.com/w3c/webcodecs/blob/main/explainer.md <https://github.com/w3c/webcodecs/blob/main/explainer.md> *Specification *https://w3c.github.io/webcodecs/ <https://w3c.github.io/webcodecs/>*Summary *We've identified two areas where our implementation violates the specification. We've implemented parallel correct paths for authors to use and would like to deprecate the original bad paths. The issues affect VideoFrame construction and the EncodedVideoChunkMetadata dictionary.*Blink component *Blink>Media>WebCodecs <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs>* Motivation *We've identified two areas where our implementation of WebCodecs violates the specification. We've considered changing the spec, but prefer to instead fix the implementation. The specified behavior is cleaner and less error prone. The changes are breaking, but the workarounds are trivial and WebCodecs usage is currently very low (we just shipped in Chrome 94, only engine to ship so far). https://chromestatus.com/metrics/feature/timeline/popularity/3464 <https://chromestatus.com/metrics/feature/timeline/popularity/3464>Details:1. The spec defines the temporalLayerId attribute as a member of the SvcOutputMetadata dictionary which is nested under the EncodedVideoChunkMetadata dictionary (metadata.svc.temporalLayerId). But Chrome places the temporalLayerId directly on the top level EncodedVideoChunkMetadata dictionary (metadata.temporalLayerId). As of Chrome 98, either option is available. 2. The spec requires that the VideoFrame(CanvasImageSource, ...) constructor include a timestamp argument (VideoFrameInit.timestamp) for CanvasImageSource types that don't implicitly have a timestamp (e.g. HTMLCanvasElement). Failing to include the timestamp should result in a TypeError, but Chrome currently defaults the timestamp to zero. Chrome will respect the timestamp if one is given.*Initial public proposal *https://groups.google.com/a/chromium.org/g/blink-dev/c/7UlTzFMbTFs/m/Rib4ca4-BQAJ <https://groups.google.com/a/chromium.org/g/blink-dev/c/7UlTzFMbTFs/m/Rib4ca4-BQAJ> *TAG review *https://github.com/w3ctag/design-reviews/issues/612 <https://github.com/w3ctag/design-reviews/issues/612>*TAG review status *Complete*Risks Site breakage *Both changes can break sites. For temporalLayerId, we're not able to add metrics for it's usage (dictionary member), but we have a reasonable sense for which sites may be affected and will reach out directly. For the VideoFrame constructor, we added UKM metrics to count usage of the bad path and a "may deprecate" warning. These metrics landed in M97 (beta). So far, no usage of the bad path. *Interoperability and Compatibility *Gecko: Supportive. Paul Adenot approved the PRs that defined the specified behavior. We discussed changing the behavior of the VideoFrame constructor but both prefer to fix the implementation if that can be done without huge developer pain. WebKit: No signalWeb developers: No signals. *Debuggability *Fixing the VideoFrame constructor may reduce the need for author debugging. The current defaulting behavior (timestamp = 0) may at first seem helpful, but is problematic if you then send the VideoFrame to a VideoEncoder, where timestamps are used to guide bitrate control. *Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? *Yes. https://github.com/web-platform-tests/wpt/tree/master/webcodecs <https://github.com/web-platform-tests/wpt/tree/master/webcodecs> *Flag name *None yet. We'll implement a flag and announce in a follow up "Ready for Trial" thread.*Requires code in //chrome? *False*Estimated milestones *99*Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5667793157488640 -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6eSpjBUfdEUsQk0ekp9W1dAZHJNoeEFL8tDBR9PR%3DZhbjMQ%40mail.gmail.com.
