- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Apr 2023 08:39:00 +0000
- To: public-webrtc-logs@w3.org
After some chats, my understanding is that... - On the audio side, the playoutDelayHint is affecting the target jitter buffer, so we can measure the effect on the jitter buffer delay. And when the target changes we accelerate/decelerate samples. This is what we want. - On the video side, the playoutDelayHint is not affecting the jitter buffer directly, but rather the [render timestamp being clamped within the min/max delay](https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/webrtc/modules/video_coding/timing/timing.cc;l=210;drc=9329f990b89052f1e7f82e0a1a4b298b72359263). This implicitly achieves a playout delay based on the render pipeline, something which I don't think we can measure in getStats() at the moment. My gut reaction is we probably want to make the spec's notes normative and we want to update the video delay to also affect the jitter buffer rather than render timestamp -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/12#issuecomment-1504886248 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 April 2023 08:39:02 UTC