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

Taylor said:

“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.

[BA]  That makes sense to me.  In ORTC getCapabilities works that way:  codecs that support multiple clock rates have distinct capability entries for each clock rate and H.264/AVC with packetization-mode 0 is a distinct entry from packetization-mode 1.

To make this more clear, do we need a table showing which attributes in RTCRtpCodecParameters can be modified via setCodecPreferences?  Are there any attributes that are modifiable other than the sdpFmtpLine dictionary?  channels perhaps?


Taylor said:

“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?”

[BA] If some RTCRtpCodecParameters attributes are going to be modifiable via setCodecPreferences() then I think additional attributes will be needed in RTCRtpCodecCapability to articulate the valid combinations.  That would include attributes such as clockRate (since there are codecs that support multiple clockRates) and sdpFmtpLine (so as to permit distinct entries for different values of packetization-mode).  Not sure we’d need numChannels (e.g. since we typically do not have distinct entries for Opus mono and stereo).

On Tue, Feb 21, 2017 at 12:37 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto: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?