- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 29 Sep 2023 06:53:16 +0000
- To: public-webrtc-logs@w3.org
As discussed during yesterday editor's call, here is some feedback for this issue. As expressed in https://github.com/w3c/webrtc-encoded-transform/pull/201#issuecomment-1740387694, WebRTC encoded transform is a very specific tool. It does not seem to be the most appropriate tool for 3.2.2 webrtc nv use cases. Given alternative APIs have been proposed for this use case, we should take the time to evaluate them and pick the best one. Also 3.2.2 use case definition is being refined in https://github.com/w3c/webrtc-nv-use-cases/pull/123, the target seems to be ultra low latency. For 3.2.2 ultra low latency use case, doing processing at packet level (both for forwarding from first to second link and for processing the second link feedback) would probably be more appropriate, like what SFUs are doing. WebRTC encoded transform is only handling frames, not packets, which is one example of the potential mismatch. Another mismatch is that WebRTC encoded transform does not deal with packet loss. When some additional latency is ok, which seems to be the use case behind this PR, using RTCPeerConnection for the first link (limited bandwidth) and data channel for the second link (corporate network) is already feasible and should provide good results. I would be interested in understanding the end user benefits of the proposed new approach with this already feasible implementation strategy. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/202#issuecomment-1740393811 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 29 September 2023 06:53:17 UTC