Re: [webrtc-pc] Add setTargetJitterBufferDelay method to RTCRtpReceiver (#2139)

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.)

-- 
GitHub Notification of comment by alvestrand
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2139#issuecomment-475905072 using your GitHub account

Received on Saturday, 23 March 2019 21:11:19 UTC