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

Received on Tuesday, 21 February 2017 23:17:52 UTC