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

I'd think that only the "fmtp" parameters that *don't* "identify a media
format configuration" could be modified. For example, for H.264,
"profile-level-id" and "packetization-interval" are described as
identifying the media format configuration.

So, continuing that example, getCapabilities should return every
combination of "profile-level-id" and "packetization-mode" that's
supported, and setCodecPreferences can reorder them. But
setCodecPreferences can't include a codec dictionary with a combination
that wasn't present in getCapabilities.

Something I'm just noticing, though, is that RTCRtpCodecCapability only has
a "mimeType" field. I don't see how this is sufficient, even for basic
reordering use cases; how can an application say it prefers a codec with a
specific number of channels, or clock rate, or "profile-level-id" as in the
above example? Or is that just something we decided not to support?

On Tue, Feb 21, 2017 at 12:37 PM, Bernard Aboba <Bernard.Aboba@microsoft.com
> wrote:

> Taylor said:
>
>
>
> *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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcs.chromium.org%2Fchromium%2Fsrc%2Fremoting%2Fprotocol%2Fwebrtc_transport.cc%3Ftype%3Dcs%26q%3Dwebrtc_transport%26l%3D83&data=02%7C01%7CBernard.Aboba%40microsoft.com%7Cb7e8aaec6d7e4de22dcd08d45a7f5038%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636232950239875295&sdata=W8O4HK8Pm7iM29sxZ0QrnvA6p68hsPHKBkQ9%2FIi3Xxg%3D&reserved=0>
> .
>
>
>
> 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).
>
>
>
> [BA] What attributes in the RTCRtpCodecParameters dictionary would become
> writeable via setCodecPreferences (e.g. payLoadType, mimeType, clockRate,
> channels, sdpFmtpLine)?   Within an sdpFmtpLine dictionary, would only some
> entries be writeable?
>