- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Jul 2020 08:57:52 +0000
- To: public-webrtc-logs@w3.org
I don't think the intent of this API was ever that you would be that fine of a control knob. Generally speaking, the internal engine should be in the best position to know how to adjust the delay as to minimize poor quality and is the one in control of the jitter buffer. The problem is that the assumption was previously always that we wan to play out received media as soon as possible because that optimizes interactiveness, even if a shorter buffering necessarily entails a risk of reducing the quality when packets are dropped or don't arrive on time. The intent of the playoutDelay was to give the application the power to say "you don't need to push the playout delay to below this point, because the interactiveness of my application's use case can loosen up these constraints... even if conditions are pretty good, I don't mind a bit of extra delay if that increases the odds of better quality". -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/46#issuecomment-663426623 using your GitHub account
Received on Friday, 24 July 2020 08:57:57 UTC