- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Nov 2023 12:55:36 +0000
- To: public-webrtc-logs@w3.org
Some thoughts: > * In case SFrameTransform is set on sender side, the SFrame packetization format would be automatically selected. What should happen on receiver side though? It does not make real sense for me to have the SFrameTransform process packets that are not supposed to be encrypted. I would tend to vote for the transform to be a pass-through as a first step. This allows the same receiver to successfully receive encrypted or unencrypted content. > * How should a sending script transform that implements SFrame encryption itself select the SFrame packetization? How should the script transform provide the necessary data to the SFrame packetizer? There is a need to tell UA that SFrame packetiser is to be used. This can be at transform creation time or at the time a frame gets enqueued, the latter being closer to SFrameTransform being a pass-through some times. There is also a need for the SFrame packetiser to know the media payload type. The script transform should ideally not need to do anything special there. > * How should SFrame depacketized data be presented to a receiving script transform? On receiver side, it seems useful to expose to the script transform that the SFrame depacketiser was used for that frame and what the underlying media PT is. Currently, we only have [payloadType ](https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframemetadata-payloadtype) which cannot be used for both. Ideally, the receiving and sending APIs would be made symmetric. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/214#issuecomment-1822721378 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 November 2023 12:55:38 UTC