Re: [webrtc-encoded-transform] Add description of an API for controlling SDP codec negotiation (#186)

Following on yesterday's editor meeting, here are some thoughts related to this proposal.
I would tend to reduce the scope of the API to what is needed now, without precluding any future extension.

AIUI, we seem to get consensus on adding support to:
1. Enable media agnostic RTP payload formats like SFrame.
2. Allow the application to select one of these RTP payload formats as part of a `RTCRtpSender` transform.

For 1, we assume the UA implements the RTP payload format.
`setCodecPreferences` can be used if the UA does not negotiate it by default.

For 2, we could use payload types.
Another approach, potentially more convenient for web developers, is to reuse the name of the payload format directly.
This is similar to manipulating mimeType instead of payloadType.

```
partial interface RTCEncodedAudioFrame {
    attribute DOMString rtpPaylodFormat;
}
partial interface RTCEncodedVideoFrame {
    attribute DOMString rtpPayloadFormat;
}
```
On sender side, the application would set it to `sframe`, to make use of https://www.ietf.org/archive/id/draft-thatcher-avtcore-rtp-sframe-00.html. On receiver side, the application detects the use of `sframe` by checking `rtpPayloadFormat`.

We could also use that API internally to further define the interaction of SFrameTransform with the RTP layers.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/186#issuecomment-1761004339 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 13 October 2023 06:58:17 UTC