Skip to content

RTPReceiver encoding parameters are useless #445

@murillo128

Description

@murillo128

Correct me if I am wrong.

On chapter 8.3 RTP matching rules the rtp packets are routed to the correct RTPReceiver based on the following parameters:

  • parameters.muxId
  • parameters.encodings[i].ssrc
  • parameters.encodings[i].fec.ssrc
  • parameters.encodings[i].fec.ssrc
  • parameters.codecs[j].payloadType
  • parameters.encodings[i].rtx.payloadType

First weird case, we check the payloadType on the codecs, but the rtx payloadType on the encodings (???). Luckily this will be solved by #444

We only use encodings for looking for the ssrc, but we then don't do anything with it (is it relevant at all that a packet is received by a particular encoding? i don't think so, we know the ssrc and the codec already).

So my question is what are encodings really used for in receving side? We just need a sequence of <ssrc,fecssrc> at most.

Moreover, as discussed in #439, if we just allow one incoming stream for simulcast, we just need one ssrc and one fecssrc, don't we?

So if we do #440 we could simplify to:

dictionary RTCRtpReceivingParameters {
             DOMString                                 muxId = "";
             sequence<RTCRtpCodecParameters>           codecs;
             sequence<RTCRtpHeaderExtensionParameters> headerExtensions;
             unsigned long                             ssrc;
             unsigned long                             fecSsrc;
             RTCRtcpParameters                         rtcp;
};

As usual, am I missing anything?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions