Hi Chris,
On 12/17/21 3:24 PM, Chris Cunningham wrote:
Contact emails
*
chcunning...@chromium.org
*
Explainer
*
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.
*
And the proposed change here is to remove temporalLayderId as a
top-level key on EncodedVideoChunkMetadata, right?
*
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.
*
The proposed change here is to start throwing without a timestamp key in
the VideoFrameInit dictionary, for all "image" types except VideoFrame
and HTMLVideoElement, correct?
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 signal
Web 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
*
Can you clarify the timing of the proposed removal? Do you intend to
send deprecation messages in M99, and if so, for how long? Or do you
intend to deprecate and remove all at once in M99?
*
*
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5667793157488640
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6eSpjBUfdEUsQk0ekp9W1dAZHJNoeEFL8tDBR9PR%3DZhbjMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/f8130ca5-23df-7625-b4cc-51169d47c0f8%40chromium.org.
