We've identified two minor 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.

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 (one liners) and WebCodecs usage remains very low (we just shipped in Chrome 94, only engine to ship so far). https://chromestatus.com/metrics/feature/timeline/popularity/3464 Details are as follows: 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. This seems helpful, but is problematic if you then send the VideoFrame to a VideoEncoder, where timestamps are used to guide bitrate control. Chrome will respect the timestamp if one is given.

Specification

Specification link


Specification being incubated in a Community Group

Status in Chromium

Blink>Media>WebCodecs


No active development

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • No signal
  • No signal
  • No signals

Owner

Last updated on 2022-01-07