To WebCodecs origin trial / experimental users: Chrome 94 is expected to release <https://www.chromestatus.com/features/schedule> to stable channel on Sep 21st. Please see below for breaking changes and new features for WebCodecs in this release.
WebCodecs will ship in M94, which means this is the final email of this sort. Breaking changes in future releases will be rare and will include a deprecation period. Thank you all for your patience as we iterated on the design! Breaking changes in M94 General - VideoDecoder, VideoEncoder, AudioDecoder, AudioEncoder, and ImageDecoder are now only exposed in secure contexts <https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#when_is_a_context_considered_secure> (generally https or localhost). - Chrome will reclaim decoders and encoders (calling error() callback w/ QuotaExceeded) that are inactive (no codec API calls, no outputs generated) for 1+ minutes. Developers are encouraged to avoid constructing new codecs until new activity is imminent. This frees up system resources (including for use by the same site running in a separate tab). - In a later release (no sooner than 96), we will reclaim codecs more aggressively, per the rules in https://www.w3.org/TR/webcodecs/#resource-reclamation. This includes narrow cases of active codecs running in background tabs. These rules are crafted to avoid breaking core use cases (RTC, media production, audio rendering, etc...). Please have a look at this plan and raise concerns in our github. Additionally, please update sites to prepare for this change. - Site developers can use the command line flag --disable-features=ReclaimInactiveWebCodecs to disable reclamation locally. VideoEncoder - VideoEncoderConfig.latencyMode <https://w3c.github.io/webcodecs/#ref-for-dom-videoencoderconfig-latencymode> defaults to "quality" <https://w3c.github.io/webcodecs/#dom-latencymode-quality>. Apps that want "realtime" <https://w3c.github.io/webcodecs/#dom-latencymode-realtime> (e.g. RTC) should take care to set this attribute accordingly. In previous releases the default behavior was platform/codec specific. - VideoEncoderConfig.hardareAcceleration <https://w3c.github.io/webcodecs/#ref-for-dom-videoencoderconfig-hardwareacceleration> attribute's values are changed: "allow", "deny", and "require" are now "no-preference", "prefer-software", and "prefer-hardware" <https://w3c.github.io/webcodecs/#enumdef-hardwareacceleration> respectively. The semantics are unchanged in Chrome (we treat the preferences as strict requirements). VideoDecoder - VideoDecoderConfig.hardwareAcceleration <https://w3c.github.io/webcodecs/#dom-videodecoderconfig-hardwareacceleration> attribute's values changed, matching the change for VideoEncoder above. VideoFrame - VideoFrame.allocationSize() <https://w3c.github.io/webcodecs/#ref-for-dom-videoframe-allocationsize> will throw an InvalidStateError exception if called on a closed VideoFrame. - VideoFrame.colorSpace <https://w3c.github.io/webcodecs/#dom-videoframe-colorspace> is no longer nullable. AudioData - AudioData.allocationSize() <https://w3c.github.io/webcodecs/#ref-for-dom-audiodata-allocationsize> will throw an InvalidStateError exception if called on a closed AudioData. Noteworthy additions in M94 - AudioDataCopyToOptions.format <https://w3c.github.io/webcodecs/#ref-for-dom-audiodatacopytooptions-format%E2%91%A5> allows for sample format conversion to "f32-planar" <https://w3c.github.io/webcodecs/#dom-audiosampleformat-f32-planar> for easy integration with WebAudio's AudioBuffer and AudioWorklet. - Added SharedArrayBuffer support for all "BufferSource" usage (AudioData.copyTo(), VideoDecoderConfig.description, ImageDecoder, etc...) - When hardwareAcceleration = no-preference, VideoEncoder will automatically fallback to software if hardware encoding hits an error. - Reduced copies when passing canvas-backed frames to VideoEncoder. - Added a 'duration' attribute to EncodedAudioChunk interface Best, Chris -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6eSpL9OUG8SEweyJ9iaesrsa0y7Uwi4%2BXtEbTzS1bcQF3-g%40mail.gmail.com.
