>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.) On Tuesday, February 13, 2024 at 11:29:09 PM UTC+1 Mike Taylor wrote: > 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. :) > On 2/13/24 3:57 PM, Eldar Rello wrote: > > >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. > > On Monday, February 12, 2024 at 10:50:18 PM UTC+2 Eldar Rello wrote: > >> 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 >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC> >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? 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. >> >> >> 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 >> <https://chromestatus.com/>. >> >> -- >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALvR0FL%2BF95hLfNZWDMK6W6qNGiPf1xqKeZ9pn__2aru4urypw%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/cce2e9bb-d14a-4707-a1f0-559519503e82n%40chromium.org.
