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

Closed
robin-raymond opened this Issue Apr 7, 2016 · 5 comments

Projects

None yet

2 participants

@robin-raymond
Contributor
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
Contributor
aboba commented Apr 25, 2016

Duplicate: #187

@aboba
Contributor
aboba commented Apr 27, 2016 edited

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
Contributor

@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 aboba added a commit that referenced this issue Apr 27, 2016
@aboba aboba send() / receive() behaviour when RtpParameters has empty sequence of…
… encodings specified

Fix for Issue #461
ad6991c
@aboba aboba added PR exists and removed to-do-next-draft labels Apr 27, 2016
@aboba
Contributor
aboba commented Apr 27, 2016 edited

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

@aboba aboba added a commit that referenced this issue Apr 28, 2016
@aboba aboba Unset encodings in send()
Fix for Issue #461
b023358
@aboba aboba added a commit that referenced this issue Apr 28, 2016
@aboba aboba Unset encodings in send()
Fix for Issue #461
f704472
@robin-raymond
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment