Re: [webrtc-pc] Order of RTCRtpSendParameters.encodings is not described

> This seems to indicate that the spec-writers were thinking in terms of "highest resolution first, lowest resolution last". But this is never written down as a rule anywhere. Neither is the idea that order stays consistent between calls.

I think we can start by saying "the order stays consistent", since JSEP says that for subsequent offers, "any "a=simulcast" line MUST stay the same."

And "highest resolution first" is written down as a rule... sort of. draft-ietf-mmusic-sdp-simulcast also does "highest resolution first" in its examples, and says:

> The order of the listed simulcast streams in the "send" direction suggests a proposed order of preference, in decreasing order: the rid-id listed first is the most preferred and subsequent streams have progressively lower preference.

Later it also talks about congestion control, saying:

> What simulcast streams to prioritize when allocating available bitrate among the simulcast streams in such adaptation SHOULD be taken from the simulcast stream order on the "a=simulcast" line

Which actually seems backwards, since we want to drop the high quality encoding first... Unless this is meant to imply "prioritize the last stream"? I'm going to ask the authors if they can clarify.

Regardless, the point is that the order in the simulcast attribute _does_ matter.

However, a wrinkle is that JSEP doesn't explicitly say "the order of the RIDS in `sendEncodings` MUST match the order of the RIDs in the simulcast attribute"; it just says "the m= section for the RtpSender will include an "a=simulcast" attribute ...  with a "send" simulcast stream description that **lists each desired encoding**"

@juberti: Can you clarify whether or not JSEP was intended to preserve the ordering? For example, if I use the reverse of the order in the example:

pc.addTransceiver(track, {
  direction: 'sendonly',
  sendEncodings: [
    {rid: 'q', scaleResolutionDownBy: 4.0},
    {rid: 'h', scaleResolutionDownBy: 2.0},
    {rid: 'f'}

Should the generated SDP be "a=simulcast:send q;h;f", and should the implementation actually pause the low-resolution encoding first when congestion occurs, contrary to how you'd normally want things to work?

GitHub Notification of comment by taylor-b
Please view or discuss this issue at using your GitHub account

Received on Monday, 18 June 2018 19:02:06 UTC