- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Nov 2019 11:50:22 +0000
- To: public-webrtc-logs@w3.org
When I started this issue I wasn't even thinking about payload type mapping, but if a payload assignment is on offer and is then rolled back, using that payload type to map to any codec should be fair game. This is JSEP territory. As for preferred codecs (i.e. which codecs are included in the list and what the order of that list is), these also need to be rolled back. The outcome of #2332 is that we need to explicitly list all the steps to perform in webrtc-pc land for "rollback". So it makes sense that one of the internal slots we'll need to revert is [[ReceiveCodecs]]. > I think removing PT74 in this case would break stuff, so we shouldn't do it. > Note - I think this is JSEP-land. But it's tangential to the rollback question Separate from the "rollback" issue addressed here, but if the following is illegal due to JSEP rules then we have a bug in webrtc-pc: ``` setCodecPreferences(VP8, VP9); O/A exchange setCodecPreference(VP8); O/A exchange ``` This should work. Whether this continues to list the VP9 payload type in the SDP or not I don't know, but this should generate SDP where VP9 cannot be chosen. That is, the VP9 payload type must not be listed in the "m=video [...] <list of payload types>" line. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2368#issuecomment-558594371 using your GitHub account
Received on Tuesday, 26 November 2019 11:50:23 UTC