- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2023 16:30:59 +0000
- To: public-webrtc-logs@w3.org
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-extensions: == Should we clarify playoutDelay value is jitter buffer depth? == https://github.com/w3c/webrtc-extensions/issues/46#issuecomment-661779681 and https://github.com/w3c/webrtc-extensions/issues/12 suggest a shared understanding that `playoutDelay` controls the user agent's jitter buffer depth, and little else. They stress the importance of JS being able to read the UA's current value, both for tests and correct API use. This depth is JS-observable through `receiver.getStats()`, as experiments in https://github.com/w3c/webrtc-extensions/issues/12#issuecomment-1497681908 show. But [current spec language](https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-playoutdelay) instead ties it to _"time between network reception of media and playout."_ i.e. jitter buffer depth + implementation-defined playout path delay. Ironically, I think this stems from early concerns over web compatibility (including mine): Naively it seemed better to me if the same value in two browsers produced the same net total playout delay (the "result"). But hindsight, that "result" isn't just total playout delay, but more or less jitter! I think applications using this API ultimately wish to set the jitter buffer depth directly. While, the spec already alludes to this in notes, "[notes in this specification are non-normative](https://w3c.github.io/webrtc-extensions/#conformance)": <img width="760" alt="image" src="https://user-images.githubusercontent.com/3136226/230143859-45326524-2e9b-435c-92aa-c3b4803d9d59.png"> We should update the normative language to clarify that the value is the jitter buffer depth and nothing else. Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/156 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 16:31:01 UTC