New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
2 participants
@robin-raymond
Contributor

robin-raymond commented Apr 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@aboba

aboba Apr 25, 2016

Contributor

Duplicate: #187

Contributor

aboba commented Apr 25, 2016

Duplicate: #187

@aboba

This comment has been minimized.

Show comment
Hide comment
@aboba

aboba Apr 27, 2016

Contributor

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.

Contributor

aboba commented Apr 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@robin-raymond

robin-raymond Apr 27, 2016

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

Contributor

robin-raymond commented Apr 27, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@aboba

aboba Apr 27, 2016

Contributor

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

Contributor

aboba commented Apr 27, 2016

@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 added a commit that referenced this issue Apr 28, 2016

aboba added a commit that referenced this issue Apr 28, 2016

@robin-raymond

This comment has been minimized.

Show comment
Hide comment
@robin-raymond

robin-raymond Apr 28, 2016

Contributor

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

Contributor

robin-raymond commented Apr 28, 2016

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