addTransceiver: 1 sendEncodings vs 0 sendEncodings

[henbos]

I found this note in addTransceiver and I am wondering if it is reflecting legacy behavior.

NOTE Providing a single, default RTCRtpEncodingParameters in sendEncodings allows the application to subsequently set encoding parameters using setParameters, even when simulcast isn't used.

This note makes it sound like there is something special about specifying a single encoding. It doesn't say it, but it seem to imply that if you had not specified a single encoding, setParameters() may not have been usable in singlecast. But that doesn't make sense, because there's no such thing as having 0 sendEncodings. If you don't specify any sendEncodings, you get singlecast by default, so surely setParameters() would work with that single encoding regardless.

A few milestones ago Chromium did treat 0 sendEncodings and 1 sendEncodings subtly differently, but this was patched as a bugfix. But finding this note now, I'm curious as to why it is phrased this way?

Should we clarify that "0 sendEncodings == 1 sendEncodings with default values"?

[henbos]

@jan-ivar Does Firefox treat 0 vs 1 sendEncodings any differently with regards to being able to do get+setParameters()?

[Orphis]

We should not have any senders with 0 encodings. The algorithm to create an RTCRtpSender says:

If sendEncodings is given as input to this algorithm, and is non-empty, set the [[SendEncodings]] slot to sendEncodings. Otherwise, set it to a list containing a single new RTCRtpEncodingParameters dictionary, and if kind is "video", add a scaleResolutionDownBy member with the value 1.0 to that dictionary.

So the comment is probably out of date.

[henbos]

Great, then it's just a strangely formulated note, but no question about what the implementation should do

[henbos]

Editorial label to reflect just re-wording the note