send() / receive() behaviour when RtpParameters has empty sequence of encodings specified

[robin-raymond]

9.4.1 Dictionary RTCRtpParameters Members

encodings of type sequence<RTCRtpEncodingParameters>
The "encodings" or "layers" to be used for things like simulcast, Scalable Video Coding, RTX, FEC, etc. When unset, send() behaves as described in Section 5.3.3, and receive() as described in Section 6.3.3.

and in 5.3.3.:

5.3.3 Methods
send
Media to be sent is controlled by parameters. If send() is called with invalid parameters, throw an InvalidParameters exception. If rtcpTransport is not set and send(parameters) is called with parameters.rtcp.mux set to "false", throw an InvalidParameters exception. For each value of i from 0 to the number of codecs, check that each value of parameters.codecs[i].name not equal to "red", "rtx" or a forward error correction codec is included in

This does not correctly describe the behaviour when there are no encodings specified at all for a sender. I same issue exists on the receiver but that is somewhat covered by the matching rules (but those need revamping anyway).

[aboba]

Duplicate: #187

[aboba]

Proposal:

When unset in a call to send(), the browser behaves as though a single encodings[0] entry was provided, with encodings[0].ssrc set to a browser-determined value, encodings[0].active set to "true" encodings[0].codecPayloadType set to codecs[j].payloadType where j is the index of the first codec that is not "cn", "dtmf", "red", "rtx" or a forward error correction codec, and all the other parameters.encodings[0] attributes (e.g. fec, rtx, priority, maxBitrate, resolutionScale, etc.) unset.

When unset in a call to receive(), the browser behaves as though a single encodings[0] entry was provided, with encodings[0].ssrc unset, encodings[0].active set to "true", encodings[0].codecPayloadType set to codecs[j].payloadType where j is the index of the first codec that is not "cn", "dtmf", "red", "rtx" or a forward error correction codec, and all the other parameters.encodings[0] attributes (e.g. fec, rtx, priority, maxBitrate, resolutionScale, etc.) unset.

[robin-raymond]

@aboba I agree with send() but not with receive();

I think receive without any encodings has a different meaning than 1 encoding. Specifically, it allows latching by codec for simulcasting scenarios and this is something we discussed previously allowing. Will add more on this later...

[aboba]

@robin-raymond

We should be clear when encoding parameters are needed on a receiver. To receive simulcast or MRST SVC there is a need to associate layers with specific SSRCs. However, I am not clear that these scenarios need to be in scope for ORTC. WebRTC 1.0 only supports sending of simulcast, not receiving it and with respect to MRST SVC, there is only an implementation for a specific codec (Edge's H.264UC). AFAIK, there are no plans to implement MRST SVC generally in any browser - VP8, VP9 and AV1 are all SRST.

For codecs like VP8, VP9, AV1, etc. there should be no need to specify encoding parameters on the receiver, even if the sender is encoding SRST SVC. The decoder can decode anything that the encoder can send, so it shouldn't matter what the layer structure is.

[robin-raymond]

Looks good. We have another issue outstanding already about matching rules so this one is okay now.