Add setTargetJitterBufferDelay method to RTCRtpReceiver

[kuddai]

Following discussion here, can we add a new method to the RTCRtpReceiver, called setTargetJitterBufferDelay. It would allow to provide a preference for the user agent for the target jitter buffer delay, but depending on the congestion control and network condition actual delay may differ.

The justification is essentially the same as in previous issue. This extensions would open a room for quality improvements for both audio and video media sourced by an RTCPeerConnection as you will have additional time until the media rendered. For example, in the case of network issues you will have more video samples to play and recover. Or if the packets are lost then you will have more time for packets retransmission.

[kuddai]

@jan-ivar, can you please take a look?

[alvestrand]

I actuallly prefer the latency-on-track format. It allows us to specify a parameter reasonably consistent with the value for sending tracks, and allows the full expression power of constraints ("not less than this" and "no more than this", with "preference for something like this" all expressible), rather than just saying "this is the value you have to aim for".

It also gives us a well defined span over which to measure the latency ("from incoming packet to final destination") which can be different for different tracks sourced from the same remote source, and indeed may have to be implemented differently for different destinations (playback to screen needs to have a minimum of decode time + a minimal jitter buffer; sending a remote stream to a recorder may be able to live without any jitter buffer whatsoever, but might want to have a max wait time to allow for recovery of packet loss via NACK, while sending it to an outgoing remote stream may require a third limitation set).

Having a single number attached to a receiver destroys all of this flexibility in implementation.

(I know Jan-Ivar and I do not agree on this point. That's OK; we're searching for WG consensus here.)

[jan-ivar]

("not less than this" and "no more than this", with "preference for something like this"

How would latency: {min: 0.5, ideal: 0.7, max: 0.9} differ from latency: 0.7?

How would it differ from latency: {min: 0.2, ideal: 0.7, max: 1.2}?

Having a single number attached to a receiver destroys all of this flexibility in implementation.

"flexibility in implementation" != standard. We'd have to specify this.

I also commented in #2138 (comment) but we should move here.

[henbos]

This will be moved to an extension spec, closing. See also #2149.