Filter codecs preferences on transceiver direction #3018
Conversation
amendments.json
Outdated
| "webrtc/RTCRtpTransceiver-setCodecPreferences-direction.html" | ||
| ], | ||
| "testUpdates": [ | ||
| "web-platform-tests/wpt#1234" |
There was a problem hiding this comment.
Needs updating to a real test and WPT PR, just put in a dummy value for the time being
webrtc.html
Outdated
| remote peer. The local peer MUST be prepared to receive any | ||
| codec that has been negotiated, even ones not first in the | ||
| list. |
There was a problem hiding this comment.
We should avoid competing normative language with JSEP. One way might be to put explanations in non-normative notes.
There was a problem hiding this comment.
I changed these to notes and tried to be more clear
webrtc.html
Outdated
| remote peer. The local peer MUST be prepared to receive any | ||
| codec that has been negotiated, even ones not first in the | ||
| list. |
There was a problem hiding this comment.
I changed these to notes and tried to be more clear
|
@jan-ivar Have I addressed your feedback? If you could take a look before the editor's meeting |
| An RTCRtpSender defaults to sending what the remote endpoint | ||
| indicated that it prefers to receive, but the application can | ||
| change which codec to send amongst negotiated codecs in | ||
| setParameters() at any time. An RTCRtpReceiver is prepared to |
There was a problem hiding this comment.
Link to "codec" specifically
| they have any. | ||
| </p> | ||
| <p class="note"> | ||
| An RTCRtpSender defaults to sending what the remote endpoint |
There was a problem hiding this comment.
Use curly bracket links here and elsewhere
| <p> | ||
| The {{setCodecPreferences}} method overrides the default | ||
| receive codec preferences used by the <a>user agent</a>. When | ||
| codec preferences used by the <a>user agent</a>. When |
There was a problem hiding this comment.
user agent "...as input to negotiation"
| If the m= section is used for receiving, the order of the | ||
| codecs in the SDP (both the offer and the answer) tells the | ||
| remote endpoint which codec the local endpoint prefers to | ||
| receive. The answerer defaults to using the order in the SDP |
There was a problem hiding this comment.
Even if the m= section is not used for receiving,
| ], | ||
| "testUpdates": [ | ||
| "web-platform-tests/wpt#44318" | ||
| "web-platform-tests/wpt#1234" |
There was a problem hiding this comment.
Add real test before landing!
There was a problem hiding this comment.
Chromium issue for adding WPTs: https://crbug.com/379551577
There was a problem hiding this comment.
quoting @henbos
Add real test before landing!
(marking this as requesting changes to make sure this doesn't get overlooked)
| description =]'s [= associated =] transceiver, | ||
| <var>transceiver</var>, is said to be the value of | ||
| <var>filteredCodecs</var> if non-empty and said to | ||
| be unset otherwise. |
There was a problem hiding this comment.
Note to self there is also a reference to preferred codecs internal slots in setParameters that should be filtered on sending
Fixes #3006.
As decided by the WG, this PR implements Proposal A at TPAC, i.e:
This is supported via filtering based on RTCRtpTransceiver.direction. In addition, the case where filtering results in an empty codec preferences this is treated as "no preference" as per Proposal A at Virtual Interim.
Preview | Diff