- From: Tony Herre via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jun 2024 13:09:34 +0000
- To: public-webrtc-logs@w3.org
They do provide a nice handle to return from RTCRtpSender.replaceSendStreams() / RTCRtpReceiver.replaceReceiveStreams() which naturally associates calls to sendRtp() with the right sender etc. I like that part. Performance-wise, I wouldn't expect much of a difference between N calls to synchronous methods vs one call that returns the union of all results. JS ergonomics-wise, I'd think being able to split separate receivers into their own instances of a MyReceiver class would be a nice architectural option? Potentially an app could even run them concurrently from separate workers? Oh actually, talking of workers, as it stands the RtpXStreams are the Transferable things, and RtpTransport stays on the main thread with the PeerConnection itself - and I think it might always have to stay there to synchronously interact with the PC. We'd need to find a solution for transferring some other intermediate object. -- GitHub Notification of comment by tonyherre Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/47#issuecomment-2149846977 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 June 2024 13:09:35 UTC