Support RTCRtpReceiver. jitterBufferTarget (formerly playoutDelay)
Categories
(Core :: WebRTC: Signaling, enhancement, P4)
Tracking
()
People
(Reporter: bwc, Assigned: dbaker)
References
(Blocks 1 open bug, )
Details
Attachments
(5 files)
Bug 1592988 - Enable wpt tests and renamed from playoutDelayHint to playoutDelay to match spec.r?jib
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
Maybe needs some spec discussion first.
Hi all,
Chromium implemented this starting in M79. It would be a great addition to FF.
For some more details, please see the following:
https://github.com/w3ctag/design-reviews/issues/441
https://discourse.wicg.io/t/hint-attribute-in-webrtc-to-influence-underlying-audio-video-buffering/4038
Also see the following example jsfiddle:
https://jsfiddle.net/75cnfojy/
Below, I've pasted the "Objective" and "Use Cases" sections from the discourse link above:
Objective:
We want to provide means for javascript applications to set their preferences on how fast they want to render audio or video data. As fast as possible might be beneficial for applications which concentrates on real time experience. For others additional data buffering may provide smother experience in case of network issues.
Use cases
Cloud gaming is a good example where application requires a very high level of interactivity. 60 FPS corresponds to 16.6 milliseconds delay and we would like to provide User Agent a hint to render media as fast as possible without hurting the user experience. On the other hand, for live streaming additional 500~1500 milliseconds probably won’t hurt live experience but it would allow smoother playback because when small network issues happen you would still have some data to play.
Comment 2•3 years ago
|
||
This is now called playoutDelay
in the spec.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Depends on D174700
Assignee | ||
Comment 6•2 years ago
|
||
Depends on D174701
Assignee | ||
Comment 7•2 years ago
|
||
Depends on D174702
Comment 8•2 years ago
|
||
Waiting on a libwebrtc change which we'll cherry pick or roll in from a regular update.
Assignee | ||
Comment 9•1 year ago
|
||
Depends on D176450
Updated•1 year ago
|
Updated•1 year ago
|
Comment 10•1 year ago
|
||
Comment 12•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/17b11131ae66
https://hg.mozilla.org/mozilla-central/rev/32e7e07d957c
https://hg.mozilla.org/mozilla-central/rev/11d59d8a50fc
https://hg.mozilla.org/mozilla-central/rev/9fa26b09323b
https://hg.mozilla.org/mozilla-central/rev/38320c197609
Assignee | ||
Comment 14•1 year ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: We will be one of the first browsers to ship jitterBufferTarget. The feature allows an application to modify the jitter buffer which can improve quality for users experiencing network issues such as packet loss.
[Affects Firefox for Android]: Yes
[Suggested wording]: WebRTC application developers can now specify a target in milliseconds of media for the jitter buffer to hold. 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.
[Links (documentation, blog post, etc)]: https://w3c.github.io/webrtc-extensions/#rtcrtpreceiver-jitterbuffertarget-attributes
Comment 15•1 year ago
|
||
Thanks, added the note to the Nightly release notes. Keeping the relnote? flag open to keep it on the radar for inclusion in our final release notes.
Updated•1 year ago
|
Description
•