- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Aug 2021 12:35:04 +0000
- To: public-webrtc-logs@w3.org
This turns out to be unexpectedly problematic for the receiver side. The internal logic of frame processing leaves the reordering as late as possible, just before the decoding step, which occurs on a relatively high priority thread so that lost and retransmitted packets have the maximum time available for catching up and filling gaps. But if we insert JS processing at that point, it means that: a) it tightens the delay budget for the transform considerably; any jitter in processing time will be directly reflected in jitter in display b) if one desired to write one's own jitter buffer in WASM, waiting for out-of-order frames *before* the WASM processing would defeat the whole purpose of that function. So I'm reopening the issue; let's discuss more. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/109#issuecomment-902660007 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 20 August 2021 12:35:06 UTC