From be3ec6f4da22f8cd9dcd8b4227851f6ceba5eaff Mon Sep 17 00:00:00 2001
From: Dominique Hazael-Massieux
- 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 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
-
- 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.
- Methods
-
- Adjusting the receiver's jitter buffer
-
- Modification to existing procedures
- null
.
- {{RTCRtpReceiver}} interface extensions
- partial interface RTCRtpReceiver {
- attribute DOMHighResTimeStamp? jitterBufferTarget;
-};
- Attributes
-
-
-
-
null
.
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. -
-