-
Notifications
You must be signed in to change notification settings - Fork 26
Tell SDP negotiation to negotiate support for non-standard codecs #172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
enhancement
New feature or request
Comments
see also w3c/webrtc-extensions#100 - even though I think your scope is intentionally more limited |
A proposal is in the slide deck for March |
This issue was discussed in the minutes of WebRTC March 2023 meeting – 21 March 2023 (WebRTC Encoded Transform: Negotiating Custom Codecs) |
This issue was discussed in WebRTC June 2023 meeting – 27 June 2023 (Encoded Transform Codec Negotiation) |
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of support for encrypted media, the RTP packetizer and depacketizer of senders and receivers have to be able to:
a) know that it's pointless to try to look inside the packet for codec-dependent data
b) know what rules to apply when packetizing and depacketizing the frames
The architecturally cleanest solution would be to ask the SDP negotiation machinery to negotiate a PT value to use with the encrypted and packetized frames, and have the ability to retrieve the resulting PT value so that when enqueueing a frame, the processor can set a payload type that elicits the expected behavior.
The text was updated successfully, but these errors were encountered: