Let receiver have a [[ReceiveCodecs]]
internal slot, representing a list of RTCRtpCodecParameters
Let receiver have a [[LastStableStateReceiveCodecs]] internal slot and @@ -10213,7 +10213,7 @@
WebIDL[Exposed=Window] +WebIDL[Exposed=Window] interfaceRTCRtpReceiver{ readonly attribute MediaStreamTracktrack; readonly attributeRTCDtlsTransport?transport; @@ -10249,7 +10249,7 @@
- transportof type, readonly, nullableRTCDtlsTransport+ The
attribute is the transport over which media for the receiver'stransportis received in diff --git a/webrtc.html b/webrtc.html index 846b7981a..cc1ffeb64 100644 --- a/webrtc.html +++ b/webrtc.html @@ -10217,7 +10217,7 @@trackinternal slot and initialize it to an empty list. -
+ - Let receiver have a [[\ReceiveCodecs]] internal slot, representing a list of [=tuple=]s, each containing a {{RTCRtpCodecParameters}} @@ -10226,13 +10226,19 @@
set in an implementation defined manner.
+ + Let receiver have a [[\LastStableStateReceiveCodecs]] internal slot and initialize it to an empty list.
+ + Let receiver have a [[\JitterBufferTarget]] + internal slot initialized to
+null. +Return receiver. @@ -10240,7 +10246,7 @@
-[Exposed=Window] +[Exposed=Window] interface RTCRtpReceiver { readonly attribute MediaStreamTrack track; readonly attribute RTCDtlsTransport? transport; @@ -10249,6 +10255,7 @@sequence<RTCRtpContributingSource> getContributingSources(); sequence<RTCRtpSynchronizationSource> getSynchronizationSources(); Promise<RTCStatsReport> getStats(); + attribute DOMHighResTimeStamp? jitterBufferTarget; };
@@ -10278,7 +10285,7 @@
transport of type {{RTCDtlsTransport}}, readonly, nullable -
+ + The {{transport}} attribute is the transport over which media for the receiver's {{RTCRtpReceiver/track}} is received in @@ -10293,6 +10300,112 @@
{{RTCRtpReceiver/[[ReceiverTransport]]}} slot.
jitterBufferTarget of type {{DOMHighResTimeStamp}}, nullable + + 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. +
+