W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2018

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

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Fri, 19 Oct 2018 14:57:32 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-431391881-1539961048-sysbot+gh@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:07 UTC