- From: youennf via GitHub <noreply@w3.org>
- Date: Wed, 18 Jun 2025 06:47:42 +0000
- To: public-webrtc-logs@w3.org
This design was based on the initial version of the spec which was based on exposing readable and writable properties. It also reduces the number of interfaces while allowing to use SFrame outside of RTC (SFrame is bigger than RTC I think). > await readable.pipeThrough(transceiver.sender.transform).pipeTo(writable); // what does this do? This will reject since attaching a transform to a sender is locking the streams. In general, SFrame can be used for transmitting any kind of data, audio, video, data channel data, web socket stuff... Hence why `SFrameTransform` is a generic transform. We could have separate constructs, maybe this is worth it, based on comments from Richard as well. That would mean introducing a `RTCSFrameTransform` in addition to `SFrameTransform`. Benefits I would see with a separate interface (SFrameTransform vs. RTCSFrameTransform): - Clearer meaning (?) - Remove the `role` parameter for `RTCSFrameTransform`. - Remove readable/writable for `RTCSFrameTransform`. - `RTCSFrameTransform` would be window only, `SFrameTransform` could be created in workers as well. Some points to discuss: - More interfaces -> More expensive - Most of the API is shared between the two (mixin could be used to mitigate this) - Spec becomes bigger (we might need to describe twice very similar more processing). - A UA could ship one API but not the other (could be a bonus, since `SFrameTransform` could be shipped before we have SFrame packetization). -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/262#issuecomment-2982900023 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 June 2025 06:47:43 UTC