Add SFrame packetization handling for SFrameTransform#252
Add SFrame packetization handling for SFrameTransform#252alvestrand merged 3 commits intow3c:mainfrom
Conversation
|
@jan-ivar, @guidou, @dontcallmedom, here is the PR based on yesterday's meeting. |
|
@alvestrand, this also introduces the |
youennf
force-pushed
the
sframe-packetization-integration
branch
from
f580cb7 to
4f74b13
Compare
youennf
force-pushed
the
sframe-packetization-integration
branch
2 times, most recently
from
6226b9a to
17e6cf2
Compare
|
At some point this needs to refer to how SDP negotiation of SFrame connects to it - hopefully that will be simple once the IETF agrees on the SFRAME RTP spec. |
Agreed, plan is to discuss this at next AVTCore meeting, on Tuesday next week. I hope to see you there. |
|
Sorry I approved the wrong PR. |
youennf
force-pushed
the
sframe-packetization-integration
branch
from
17e6cf2 to
c493da4
Compare
| ### Stream creation ### {#stream-creation} | ||
|
|
||
| At construction of each {{RTCRtpTransceiver}}, run the following steps: | ||
| 1. If [=this=] is associated with a media description, initialize [=this=].`[[useSFrame]]` from the media description. If [=this=].`[[useSFrame]]` is true, enable SFrame RTP packetization for [=this=]. |
There was a problem hiding this comment.
How this would apply for the frame/packet encryption? For frame level encryption suggested algorithm looks good.
Could you explain how this would change in the future for packet level sframe?
Since then you won't be able to tell based on sdp if encryption should be frame or packet, and for packet level encryption you want to use media specific packetization.
youennf
force-pushed
the
sframe-packetization-integration
branch
from
c493da4 to
e2eb006
Compare
| 1. Otherwise, run the following steps: | ||
| 1. Question: should we always allow the case of setting back a transform to null? | ||
| 1. If |transceiver|.`[[useSFrame]]` is true, throw a {{InvalidModificationError}} and abort these steps. | ||
| 1. Set |transceiver|.`[[useSFrame]]` to false. |
There was a problem hiding this comment.
@youennf I don't remember what was the outcome of the W3C meeting in which disabling sframe was discussed. It was supposed to be possible to disable a sframe on the transceiver? Or rather if transceiver have once initiated sframe, it must remain in this state?
If the outcome was that we should be able to disable sframe for transceiver, the steps here shouldn't mention that both sender/receiver transforms should be set to null?
Also what would be the way for the RTCRtpTransceiver to disable sframe, which was negotiated via SDP, and doesnt have any transforms attached (both are null).
There was a problem hiding this comment.
This was discussed during https://www.w3.org/2025/10/21-webrtc-minutes#981d
It seems easier to have a strict setup at first, to not have to deal with rollback et al.
When web app creates transceiver, web app has some limited amount of time to select sframe packetization or not.
Applications can create two transceivers, one with sframe and the other without, and switch between the two to send/receive media.
youennf
force-pushed
the
sframe-packetization-integration
branch
from
e2eb006 to
5ceaa3d
Compare
|
This issue was discussed in WebRTC February 2026 meeting – 17 February 2026 (SFrame Update) |
youennf
force-pushed
the
sframe-packetization-integration
branch
from
5ceaa3d to
8e0930a
Compare
Co-authored-by: Jan-Ivar Bruaroey <jan-ivar@users.noreply.github.com>
SHA: 1d0f17e Reason: push, by alvestrand Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
5 participants
Following on last WebRTC WG meeting and this week's chair meeting, here is a draft of how SFrame packetization could be integrated with SFrameTransform and RTCRtpScriptTransform.
Preview | Diff