- From: Richard Barnes via GitHub <noreply@w3.org>
- Date: Wed, 18 Jun 2025 14:22:37 +0000
- To: public-webrtc-logs@w3.org
I agree that SFrame is bigger than RTC. For example, [MoQ is looking at SFrame](https://datatracker.ietf.org/doc/draft-jennings-moq-secure-objects/) for protecting media objects. But it does seem worthwhile to me to separate the RTC case from the more general use case. As has been discussed, in the RTC context, SFrameTransform does more than just apply SFrame encryption. It also changes the packetization, whether that's by swapping the media-aware packetizer for a generic one (`mode=frame`) or updating the MTU (`mode=packet`). The generic transform shouldn't have to be bothered by that. On the discussion points: I think most of the duplication can be avoided in exactly the way you suggest. Your last point about shipping SFrameTransform ahead of WebRTC seems like a positive to me -- you could basically ship this today. -- GitHub Notification of comment by bifurcation Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/262#issuecomment-2984426708 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 14:22:38 UTC