- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Aug 2023 13:36:01 +0000
- To: public-webrtc@w3.org
alvestrand has just created a new issue for https://github.com/w3c/webrtc-encoded-transform: == SDP mangling: control encoding or control packetization? == (Unusual usage of bug tracker: asking for input on a feature of an outstanding PR) While pondering #186 , I wonder if I should redesign. The purpose of having a packetizer field in the codec description is to control the packetizer/depacketizer once the codec has been negotiated. But putting it in the SDP description kind of mixes the SDP negotiation (outside of transport) with the transport control. This came to a head when considering how to set the outgoing codec, given that we have a new API for setting it using SetParameters. New suggestion: - Drop the packetizer from the negotiation. The two parties have to agree that they are willing to understand what this codec name represent, that's *all* the SDP module should care about. - Use SetParameters() to get the encoder to encode the type that the transform expects as input. This already exists. - Add a new call - RtpSender.SetPacketizer(PT, DOMString) - where the MIME type has a predefined effect, others may be added. - Similarly, RtpReceiver.SetDepacketizer(PT, DOMString) - If no packetizer /depacketizer is registered for a PT when a frame/packet is sent for packetization/depacketization, drop it. It seems cleaner. @jan-ivar @youennf @orphis @henbos - WDYT? Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/199 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 31 August 2023 13:36:03 UTC