[webrtc-rtptransport] Not requiring per-packet JS Events (#20)

tonyherre has just created a new issue for https://github.com/w3c/webrtc-rtptransport:

== Not requiring per-packet JS Events ==
We talking before in the Design Discussion meetings about the need for reducing the CPU & power overhead of using RTPTransport APIs. One large source we've seen in Chrome when working with Encoded Frame APIs is that frequent (100s of Hz) JS event scheduling brings a significant amount of overhead due to context switching, thread wakeups, JS event management etc. eg see crbug.com/40942405.

To avoid these issues at the packet level, which is inherently higher frequency than frames, we would need to avoid requiring apps to have JS callbacks execute individually per-packet, for both send, receive and BWE, in order to achieve their usecases.

We've already talked about this a few times in the design discussion meetings, and come to ideas about having APIs to read batches of all available packets etc. The same needs to be considered for BWE feedback signals & mechanisms.

Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/20 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 15 April 2024 09:50:49 UTC