- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2023 15:27:03 +0000
- To: public-webrtc-logs@w3.org
[@fippo](https://github.com/fippo)'s tests are 404 for me. But here's a basic fiddle I wrote https://jsfiddle.net/jib1/hgx4otpL/ — it has a checkbox controlling null/non-null and a slider for value when non-null We're trying to reverse-engineer Chrome's behavior of `playoutDelayHint` [SIC] since the spec is a bit vague. When I run it in Chrome I see Chrome defaulting to 22-27 ms jitter buffer delay, and seems somewhat stable at times, but I also see it sometimes grows on its own? Because of that I'm going to document what I tried, without claiming reproducibility. I tried a couple of things: - If I set value to 0.5 and check the box then I saw the stat grow to 50 over 10-20 seconds, great! - If I then uncheck the box, it drops to 27 ms in about 2 seconds, also great - Starting over, if I drag the slider to 0 and then check the box, it doesn't seem to react and stays at 22-27ms - I suppose the spec is flexible enough with its "minimum allowed delay and a maximum allowed delay" to say that the libwebrtc implementation is within bounds of the spec here. Does this match your experience? > Such as measuring jitterBufferDelay / jitterBufferEmittedCount and ensuring the value is >= the hint is achieved, etc. Let's write WPTs and, if anything needs to be clarified or reworded in the spec to ensure the test is interoperable with the spec definition, we do that too. I'm wondering, since jitter buffer stats is JS-observable through getStats, if it would be better to define the value to be == instead of >=. I'll open a new issue on that. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/12#issuecomment-1497681908 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 April 2023 15:27:04 UTC