Intent to Ship: jitterBufferTarget

[Eldar Rello]

Contact emails

eldar...@gmail.com

Explainer

None

Specification

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget

Summary

JitterBufferTarget attribute allows applications to specify a target duration of time in milliseconds of media for the RTCRtpReceiver's jitter buffer to hold. This influences the amount of buffering done by the user agent, which in turn affects retransmissions and packet loss recovery. Altering the target value allows applications to control the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter.

Essentially it is a rename of already shipped playoutDelayHint attribute.

Blink component

Blink>WebRTC

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping

WebKit: No signal

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?

None

Debuggability

None

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

No

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

Yes

https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental&label=master&aligned

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

123

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).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5930772496384000

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 2/12/24 6:36 AM, Eldar Rello wrote:

Contact emails

eldar...@gmail.com

Explainer

None

Specification

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget

Summary

JitterBufferTarget attribute allows applications to specify a target duration of time in milliseconds of media for the RTCRtpReceiver's jitter buffer to hold. This influences the amount of buffering done by the user agent, which in turn affects retransmissions and packet loss recovery. Altering the target value allows applications to control the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter.

Essentially it is a rename of already shipped playoutDelayHint attribute.

Is this purely a rename, or are there changes to the semantics?

And do we have any sense how widely used playoutDelayHint is in the wild? There is some discussion of the bikeshedding in https://lists.w3.org/Archives/Public/public-webrtc/2023Apr/0045.html, but no consideration of existing usage (at least as reflected in the minutes).

Blink component

Blink>WebRTC

TAG review

None

TAG review status

Not applicable

Opening an issue seems useful, but that seems like a heavy tax for a contributor (vs the spec editors...).

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping

Mind providing a link to a bug?

WebKit: No signal

Can we request a permission please? https://github.com/WebKit/standards-positions

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?

None

Debuggability

None

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

No

Which platforms will it be supported on, if not all of them?

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

Yes

https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental&label=master&aligned

Flag name on chrome://flags

None

Finch feature name

None

Can we add a flag? https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md

(Or someone can explain why that's difficult and the risk is low here...).

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

123

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).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5930772496384000

This intent message was generated by Chrome Platform Status.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALvR0FL%2BF95hLfNZWDMK6W6qNGiPf1xqKeZ9pn__2aru4urypw%40mail.gmail.com.

[Mike Taylor]

We also need to flip the various review gates on the chromestatus entry (privacy, security, enterprise... etc.). If you're working with someone at Google on this feature, perhaps they could assist?

[Eldar Rello]

On Monday, February 12, 2024 at 4:53:50 PM UTC+2 mike...@chromium.org wrote:

On 2/12/24 6:36 AM, Eldar Rello wrote:

Contact emails eldar...@gmail.com

Explainer None

Specification https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget

Summary

JitterBufferTarget attribute allows applications to specify a target duration of time in milliseconds of media for the RTCRtpReceiver's jitter buffer to hold. This influences the amount of buffering done by the user agent, which in turn affects retransmissions and packet loss recovery. Altering the target value allows applications to control the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter.

Essentially it is a rename of already shipped playoutDelayHint attribute.

Is this purely a rename, or are there changes to the semantics?

Other than the name change, it throws RangeError when delay parameter is out of range. playoutDelayHint is throwing only if delay is negative. Another difference is that jitterBuffferTarget is in milliseconds unit while playoutDelayHint is using seconds.

And do we have any sense how widely used playoutDelayHint is in the wild? There is some discussion of the bikeshedding in https://lists.w3.org/Archives/Public/public-webrtc/2023Apr/0045.html, but no consideration of existing usage (at least as reflected in the minutes).

I do not have visibility over usage, but playoutDelayHint remains supported to enable smooth adaption.

Blink component Blink>WebRTC

TAG review None

TAG review status Not applicable

Opening an issue seems useful, but that seems like a heavy tax for a contributor (vs the spec editors...).

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping

Mind providing a link to a bug?

 

Added

WebKit: No signal

Can we request a permission please? https://github.com/WebKit/standards-positions

Created ticket there.

 

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?

None

Debuggability

None

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

Which platforms will it be supported on, if not all of them?

 

Fixed. Initially I was unsure, but it should be supported on all platforms where WebRTC is available. 

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

https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental&label=master&aligned

Flag name on chrome://flags None

Finch feature name None

Can we add a flag? https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md

(Or someone can explain why that's difficult and the risk is low here...).

Personally I do not see any value for guarding as like already mentioned exactly same functionality is already exposed by legacy attribute playoutDelayHint. 

[Eldar Rello]

>Can we add a flag? https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md

>(Or someone can explain why that's difficult and the risk is low here...).

I made it as a runtime enabled feature now.

[Mike Taylor]

Thanks! I had intended to reply that it's very simple to add a runtime enabled feature to IDL, but it's been a busy day. :)

[Henrik Boström]

From a code owner and W3C participant's perspective, I'm very happy that we're finally aligning our attribute name with the spec + Firefox' implementation. Thank you Eldar!

(Ultimately we should deprecate and remove the old attribute name, but not until this has been shipped for a long time.)

[Yoav Weiss (@Shopify)]

LGTM1

Thanks for aligning us on an interoperable name!!

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2aa3524-56da-4214-910c-f973f79dda19n%40chromium.org.

[Daniel Bratell]

LGTM3 but don't forget to verify that the chromestatus NAs for security and privacy are eventually confirmed. (I don't see how it could not be, but they are experts)

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-VChDUsWwQC%2BdB%3Dj19NK%3DQj9f27pTbmecxKPcrBiVJ8w%40mail.gmail.com.