- The {{RTCRtpReceiver}} - interface is defined in [[WEBRTC]]. This document extends that interface - by adding an additional attribute to adjust the receiver's jitter buffer. -
-
- Let {{RTCRtpReceiver}} objects have a [[\JitterBufferTarget]] internal slot initially
- initialized to null.
-
partial interface RTCRtpReceiver {
- attribute DOMHighResTimeStamp? jitterBufferTarget;
-};
- This attribute allows the application 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. - -
The user agent MUST have a minimum allowed target and a - maximum allowed target reflecting what the user agent is - able or willing to provide based on network conditions and memory - constraints, which can change at any time.
-This is a target value. The resulting change in delay can be gradually - observed over time. The receiver's average jitter buffer delay can be - measured as the delta - {{RTCInboundRtpStreamStats/jitterBufferDelay}} divided by the delta - {{RTCInboundRtpStreamStats/jitterBufferEmittedCount}}. -
-- An average delay is expected even if DTX is used. For example, if - DTX is used and packets start flowing after silence, larger targets can - influence the user agent to buffer these packets rather than - playing them out. -
-On getting, this attribute MUST return the value of the - {{RTCRtpReceiver/[[JitterBufferTarget]]}} internal slot.
-On setting, the user agent MUST run the following steps:
-Let receiver be the - {{RTCRtpReceiver}} object on which the setter is - invoked.
-Let target be the argument to the setter.
-If target is negative or larger than 4000 milliseconds, then - [=exception/throw=] a {{RangeError}}.
-Set receiver's {{RTCRtpReceiver/[[JitterBufferTarget]]}} - to target.
-Let track be receiver's - {{RTCRtpReceiver/[[ReceiverTrack]]}}.
-In parallel, begin executing the following steps:
-Update the underlying system about the new target,
- or that there is no application preference if target is
- null.
- If track is synchronized with another - {{RTCRtpReceiver}}'s track for - audio/video synchronization, - then the user agent SHOULD use the larger of the two receivers' - {{RTCRtpReceiver/[[JitterBufferTarget]]}} for both receivers. -
-- When the underlying system is applying a jitter buffer target, it will - continuously make sure that the actual jitter buffer target is clamped - within the minimum allowed target and maximum allowed - target. -
- If the user agent ends up using a target different from the - requested one (e.g. due to network conditions or physical memory - constraints), this is not reflected in the - {{RTCRtpReceiver/[[JitterBufferTarget]]}} internal slot. -
- -Modifying the jitter buffer target of the underlying system SHOULD - affect the internal audio or video buffering gradually in order not - to hurt user experience. Audio samples or video frames SHOULD - be accelerated or decelerated before playout, similarly to how - it is done for - - audio/video synchronization or in response to congestion - control.
-The acceleration or deceleration rate may vary depending on - network conditions or the type of audio received (e.g. speech - or background noise). It MAY take several seconds to achieve 1 - second of buffering but SHOULD not take more than 30 seconds - assuming packets are being received. The speed MAY be - different for audio and video.
-- For audio, acceleration and deceleration can be measured - with {{RTCInboundRtpStreamStats/insertedSamplesForDeceleration}} - and {{RTCInboundRtpStreamStats/removedSamplesForAcceleration}}. - For video, this may result in the same frame being rendered - multiple times or frames may be dropped. -
-