Intent to Ship: MediaStreamTrackProcessor frame counters

[Chromestatus]

Contact emails

agp...@google.com, gui...@google.com

Specification

https://www.w3.org/TR/mediacapture-transform/#track-processor-interface

Summary

Adds discardedFrames and totalFrames attributes to the MediaStreamTrackProcessor interface. These counters allow web developers to monitor the health of their media processing pipelines by tracking the number of frames received and dropped by the processor.

Blink component

Blink>MediaStream

Web Feature ID

insertable-streams

Motivation

No information provided

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: Positive (https://github.com/w3c/mediacapture-transform/pull/125) Spec PR was approved by Mozilla

WebKit: Positive (https://github.com/w3c/mediacapture-transform/pull/125) Spec PR was approved by WebKit

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
third_party/blink/web_tests/wpt_internal/mediacapture-insertable-streams/MediaStreamTrackProcessor-stats.https.html, third_party/blink/web_tests/wpt_internal/mediacapture-insertable-streams/MediaStreamTrackProcessor-stats-transfer.https.html

Flag name on about://flags

No information provided

Finch feature name

MediaStreamTrackProcessorStats

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/513481577

Estimated milestones

Shipping on desktop	150
Shipping on Android	150
Shipping on WebView	150

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6267249280286720?gate=4665260125585408

This intent message was generated by Chrome Platform Status.

[Alex Russell]

LGTM1

[Dan Clark]

LGTM2

[Daniel Bratell]

Looking through the request, while I note that it's a small change there is also quite a few fields not filled in. For instance, no explicit requests for official Mozilla or WebKit standards positions, no TAG review, no web developer position, and more. 

Could we get some motivation for skipping those fields, or if they should not be skipped, well, updated info?

/Daniel

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b38af407-69fb-4d05-b19a-df34c13a76afn%40chromium.org.

[Guido Urdaneta]

On Wed, Jun 3, 2026 at 5:22 PM Daniel Bratell <brat...@gmail.com> wrote:

Looking through the request, while I note that it's a small change there is also quite a few fields not filled in. For instance, no explicit requests for official Mozilla or WebKit standards positions, no TAG review, no web developer position, and more. 

Could we get some motivation for skipping those fields, or if they should not be skipped, well, updated info?

For TAG review: This is a minor addition (with consensus across browsers in a WG) to a spec that already has a TAG review. In the past, this type of small addition to an already reviewed spec was usually exempted from a new TAG review. We can request one if you think it's necessary. This is the TAG review of the original spec: https://github.com/w3ctag/design-reviews/issues/603

For standards positions:

https://github.com/mozilla/standards-positions/issues/1417

https://github.com/WebKit/standards-positions/issues/679

Officially this is "No Signals", since they positions were just requested.  In practice, though, the spec change had the explicit approval of the Mozilla and WebKit representatives. See https://github.com/w3c/mediacapture-transform/pull/125

Regarding developer support: We reported "No Signals," which in this case actually means no public signals since we do not have we can link to.

Internally we are aware of positive signals from developers, but they're not public.

There is one developer comment here, but I'm not sure it meets the threshold for a positive signal. 

Another developer participated in a discussion about an earlier proposal of this feature in the WG and their feedback was incorporated into the final proposal: https://youtu.be/BFxA2GavBnI?t=4798

It does not refer to the finalized version that landed in the spec, but maybe all taken into consideration this amounts to "Positive signals".

Please let us know if there is any other field that requires more information.

 

[Sangwhan Moon]

On Jun 4, 2026, at 5:00, 'Guido Urdaneta' via blink-dev <blin...@chromium.org> wrote:



On Wed, Jun 3, 2026 at 5:22 PM Daniel Bratell <brat...@gmail.com> wrote:

Looking through the request, while I note that it's a small change there is also quite a few fields not filled in. For instance, no explicit requests for official Mozilla or WebKit standards positions, no TAG review, no web developer position, and more. 

Could we get some motivation for skipping those fields, or if they should not be skipped, well, updated info?

For TAG review: This is a minor addition (with consensus across browsers in a WG) to a spec that already has a TAG review. In the past, this type of small addition to an already reviewed spec was usually exempted from a new TAG review. We can request one if you think it's necessary. This is the TAG review of the original spec: https://github.com/w3ctag/design-reviews/issues/603

For standards positions:

https://github.com/mozilla/standards-positions/issues/1417

https://github.com/WebKit/standards-positions/issues/679

Officially this is "No Signals", since they positions were just requested.  In practice, though, the spec change had the explicit approval of the Mozilla and WebKit representatives. See https://github.com/w3c/mediacapture-transform/pull/125

Original TAG reviewer here. It seems like Mozilla is indirectly expressing concerns (I somehow missed this, although the comments did come 3 years after it was closed) on the original review (which I missed), were the details of the concerns brought up in another forum?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BBuZxb2Fn4rx0q3%3D7YXLOtGCgnYLErZdei0Ucy%3DBkjn1BF4Lw%40mail.gmail.com.

[Guido Urdaneta]

On Sat, Jun 6, 2026 at 5:16 AM Sangwhan Moon <s...@chromium.org> wrote:

On Jun 4, 2026, at 5:00, 'Guido Urdaneta' via blink-dev <blin...@chromium.org> wrote:



On Wed, Jun 3, 2026 at 5:22 PM Daniel Bratell <brat...@gmail.com> wrote:

Looking through the request, while I note that it's a small change there is also quite a few fields not filled in. For instance, no explicit requests for official Mozilla or WebKit standards positions, no TAG review, no web developer position, and more. 

Could we get some motivation for skipping those fields, or if they should not be skipped, well, updated info?

For TAG review: This is a minor addition (with consensus across browsers in a WG) to a spec that already has a TAG review. In the past, this type of small addition to an already reviewed spec was usually exempted from a new TAG review. We can request one if you think it's necessary. This is the TAG review of the original spec: https://github.com/w3ctag/design-reviews/issues/603

For standards positions:

https://github.com/mozilla/standards-positions/issues/1417

https://github.com/WebKit/standards-positions/issues/679

Officially this is "No Signals", since they positions were just requested.  In practice, though, the spec change had the explicit approval of the Mozilla and WebKit representatives. See https://github.com/w3c/mediacapture-transform/pull/125

Original TAG reviewer here. It seems like Mozilla is indirectly expressing concerns (I somehow missed this, although the comments did come 3 years after it was closed) on the original review (which I missed), were the details of the concerns brought up in another forum?

Their main concern was exposure on Window. Since this API is closely related to WebCodecs the decision was to align with WebCodecs and ship it on Window too.

See the I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/oo6MQoRbDXk/m/7Kjjfe9NAwAJ

[Yoav Weiss (@Shopify)]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b38af407-69fb-4d05-b19a-df34c13a76afn%40chromium.org.

--
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+unsubscribe@chromium.org.