Implement |setCodecPreferences| in RTCRtpTransceiver
Categories
(Core :: WebRTC: Signaling, enhancement, P2)
Tracking
()
People
(Reporter: bwc, Assigned: dbaker)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
(4 keywords)
Attachments
(1 file)
Updated•8 years ago
|
Comment 1•8 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•1 year ago
|
Assignee | ||
Comment 4•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Comment 5•1 year ago
|
||
We will want to target landing this at the start of the 128 Nightly to ensure this has enough time to bake in. Given that this feature required adjustments to our codec negotiation logic we want to ensure no obvious issues arise from it. The main concern is with sites possibly doing feature detection for setCodecPreferences and using a new code path not previously used by Firefox.
Comment 8•1 year ago
|
||
bugherder |
Assignee | ||
Comment 11•1 year ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: This allows for WebRTC services to easily manipulate what codecs it wishes to receive and the preferred order.
[Affects Firefox for Android]: Yes
[Suggested wording]: The setCodecPreferences method allows applications to disable the negotiation of specific codecs (including RTX/RED/FEC). It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.
[Links (documentation, blog post, etc)]: https://www.w3.org/TR/webrtc/#dom-rtcrtptransceiver-setcodecpreferences, https://blog.mozilla.org/webrtc/ (blog should be coming)
Comment 13•11 months ago
|
||
FF128 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/33981
Updated•11 months ago
|
Updated•8 months ago
|
Description
•