- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 May 2017 22:58:57 +0000
- To: public-webrtc@w3.org
taylor-b has just created a new issue for https://github.com/w3c/webrtc-pc: == Setting a remote description may cause discontinuity due to codec switching. == If an application is using `sender.setParameters` to select the sent codec, this gets wiped out when `setRemoteDescription` is called: > The effect of reordering or removing codecs lasts until the codecs are renegotiated. After the codecs are renegotiated, they are set to the value negotiated, and setParameters needs to be called again to re-apply codec preferences. It's a little inconvenient from an API perspective to need to call `setParameters` every time `setRemoteDescription`'s promise resolves. But the bigger issue is that one frame might end up encoded with an unintended codec before the application has a chance to switch. And it wouldn't be surprising if this causes a blip on the receive side. Is there any reason we can't use [`codecPayloadType`](http://draft.ortc.org/#dom-rtcrtpencodingparameters-codecpayloadtype) like ORTC has, and say that once set, it doesn't change? Neither Chrome nor Firefox have implemented the `setParameters` codec reordering yet, so I don't think there are backwards compatibility concerns. Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1207 using your GitHub account
Received on Thursday, 11 May 2017 22:59:03 UTC