Re: [webrtc-pc] Using codecPayloadType with addTransceiver()

It seems to me that "codecPayloadType" refers to "parameters.codecs[i].payloadType", i.e. from getParameters(). It is referring to sender parameters that don't exist yet, because the sender has not been created yet. Even if it had, there has been no negotiation yet.

If codec payload types are the same for the entire session, and not different depending on m= section, then we could allow setting a payload type that was retrieved from a _different sender_. The spec says what to do if the "codecPayloadType" is not accepted by negotiation (fallback to default), so it's fine if we end up not using this codec. The API makes sense if we can use it as a preference. But this is bad design. Why can't I say "I want to use VP9"? Why do I have to use the specific codecPayloadType?

Would it make more sense if codecPayloadType is read-only, and to select codec we instead set a "preferredCodec" of type RTCRtpCodecCapability? This is something we can obtain from getCapabilities() without having to do a negotiation.

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2008#issuecomment-431391881 using your GitHub account

Received on Friday, 19 October 2018 14:57:37 UTC