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.


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 link

Specification being incubated in a Community Group

Status in Chromium


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


Last updated on 2022-04-07