Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
RTPReceiver encoding parameters are useless #445
Correct me if I am wrong.
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:
As usual, am I missing anything?
The "RTP matching rules" section is a bit special in the sense that it is not intended for API users, but for ORTC implementors (browser vendors). It helps anyhow but it does not provide complete guidelines for the implementor.
Agreed. Also note that the SSRC for received RTX payloads should also be unique (not sure why, but in the real world it is unique). So I would add a
added a commit
Apr 1, 2016
@aboba I believe it is what was needed. Anything further requires a proposed redesign which is beyond the scope of this bug and the original statement about encodings being useless in the title of the bug is inaccurate.
I filed a separate bug to clarify when encodings are not specified to describe exactly the behaviour expected. As far as I'm concerned, this bug is closed.