Re: [webrtc-encoded-transform] Receiver transform depacketizer requirements (#109)

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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Friday, 20 August 2021 12:35:06 UTC