Re: Issue 1021: get/setParameters does not have a parameter for packetization interval

>
> *a.    **Do we need setCodecPreferences() to be able to modify
> codec-specific parameters?*


I'd say yes. Just the example of the opus "stereo" parameter is compelling
enough to me. Chrome currently doesn't offer "stereo=1" by default, but it
would be completely reasonable for applications to want it. This issue was
brought to my attention just recently with Chrome Remote Desktop
<https://cs.chromium.org/chromium/src/remoting/protocol/webrtc_transport.cc?type=cs&q=webrtc_transport&l=83>
.

If we go this route, I'd highly prefer changing sdpFmtpLine to a dictionary
if we can be certain that all parameters are (and will be) key/value pairs.
If we don't do this, then we're back to SDP munging (albeit, very contained
SDP munging).

On Mon, Feb 20, 2017 at 11:23 PM, Bernard Aboba <Bernard.Aboba@microsoft.com
> wrote:

> Issue: https://github.com/w3c/webrtc-pc/issues/1021
>
>
>
> Related Issues: https://github.com/w3c/webrtc-pc/issues/1022
>
> https://github.com/w3c/webrtc-pc/issues/1024
>
>
>
> Issue 1021 as well as related Issues 1022 and 1024 are on the agenda for
> the March 1 Virtual Interim.  Since these issues are related,  it seemed
> like a good idea to get some discussion going prior to the meeting.
>
>
>
> Brief summary:
>
>
>
> Varun:  “We have a few parameters for video and simulcast, would like to
> have one for packetization interval. Currently, I cannot find a way to
> change it without messing with the SDP.”
>
> Taylor: “Currently, you'd have to read "sdpFmtpParameters" and parse the
> "key=value; key=value;" structure. I'd propose changing this to a
> Dictionary, like in ORTC, assuming all codecs use the "key=value"
> structure.”
>
> Varun: “What about setting the packetization interval on setParameters?”
>
> Taylor: “Well, I thought codecs can only be reordered, not modified, so
> that wouldn't be supported. Though RTCRtpParameters.codecs isn't marked
> read-only; is that just an oversight?”
>
>
>
> [BA] In PR https://github.com/w3c/webrtc-pc/pull/1025 which is a fix for
> Issue 1024, Taylor has proposes a clarification saying that setParameters()
> cannot be used to add a new codec to the codecs[] sequence, or modify the
> RTCRtpCodecParameters dictionary entries (which includes payLoadType,
> mimeType, clockRate and channels as well as the sdpFmtpLine attribute).  As
> part of the discussion of Issue 1022, it would appear that for a sender the
> sdpFmtpLine attribute is obtained from the remote peer’s SDP, so this
> effectively says that once a remote description is applied the fmtp
> parameters determined from the negotiation cannot be modified by
> setParameters().
>
>
>
> Example 1:  For H.264/AVC, the remote peer’s profile-level-id is included
> within RTCRtpSender.getParameters.codecs[].sdpFmtpLine and cannot be
> modified by setParameters().  To modify what is being encoded, use
> encodings[].maxBitrate, .maxFramerate, etc.
>
>
>
> PR 1025 also provides a clarification to setCodecPreferences, stating that
> codecs in the codecs[] sequence need to be among those returned by
> RTCRtpReceiver.getCapabilities(kind).codecs[] or
> RTCRtpSender.getCapabilities(kind).codecs[], and also that
> RTCRtpCodecParameters dictionary entries cannot be modified.  Therefore
> this PR would preclude use of setCodecPreferences to modify the
> codec-specific parameters included in the SDP provided createOffer() or
> createAnswer().
>
>
>
> Example 2: An application is using Opus to provide audio support in a situation where stereo is not necessary.  Since stereo is supported by both the local and remote peer implementations, RTCRtpSender/RTCRtpReceiver.getCapabilities().codecs[].numChannels returns 2 for Opus, and the sdpFmtpLine attribute for either the RTCRtpSender or RTCRtpReceiver would contain “stereo=1”.Rather than using setCodecPreferences() to modify sdpFmtpLine so as to contain “stereo=0” prior to calling createOffer(), the SDP signaled by the remote peer is modified to change “stereo=1” to “stereo=0” prior to calling setRemoteDescription().
>
>
>
> In Issue 1022, Taylor raises the question of what the sdpFmtpLine
> attribute contains.  This includes whether it actually contains “a=fmtp:”
> and the payload type values, or just the list of parameters.  If it is just
> the list of parameters, the question is raised as to whether it would
> better be expressed as a dictionary (which would perhaps make it easier to
> modify individual values with setCodecPreferences() if in fact that is
> allowable).   There is also the question of what the sdpFmtpLine attribute
> contains, both in RTCRtpReceiver.getParameters().codecs[].sdpFmtpLine
> (here it is presumably the contents of the fmtp parameters of the local
> peer) and in RTCRtpSender.getParameters().codecs[].sdpFmtpLine (here it
> is presumably the contents of the fmtp parameters of the remote peer).
>
>
>
> Some questions for the WEBRTC WG:
>
>
>
> *a.    **Do we need setCodecPreferences() to be able to modify
> codec-specific parameters?*
>
> *b.    **Do we need to be able to set the ptime value without modifying
> SDP?*
>
> *c.     **Is it necessary to be able to discover the maxptime value
> without parsing SDP?*
>