- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Mar 2016 21:56:56 +0000
- To: public-ortc@w3.org
murillo128 has just created a new issue for https://github.com/openpeer/ortc: == RTPReceiver encoding parameters are useless == 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: ```javscript dictionary RTCRtpReceivingParameters { DOMString muxId = ""; sequence<RTCRtpCodecParameters> codecs; sequence<RTCRtpHeaderExtensionParameters> headerExtensions; unsigned long ssrc; unsigned long fecSsrc; RTCRtcpParameters rtcp; }; ``` As usual, am I missing anything? Please view or discuss this issue at https://github.com/openpeer/ortc/issues/445 using your GitHub account
Received on Thursday, 31 March 2016 21:56:58 UTC