- From: Iñaki Baz Castillo via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Mar 2019 21:24:43 +0000
- To: public-webrtc-logs@w3.org
@alvestrand said: > Short version: CNAME is a feature mentioned in the specs, but a) sending the same CNAME on all RTP streams solves the problem for outgoing, and b) ignoring the CNAME entirely on incoming does no harm. Once the bug has been (mostly) identified, can we please focus on whether knowing the CNAME (in advance via SDP or in runtime upon reception of RTCP SDES) is useful or not for synchronizing incoming tracks from the same source? * AFAIU RTP `timestamp` are the same for SSRC streams originated by the same source, so for example the mic and webcam tracks share both CNAME and RTP timestamps (more or less). * The receiver can then synchronize both audio and video tracks by "waiting" a bit for rendering audio if the video stream is being received with some delay. That's the only CNAME use-case coming to my mind, and that can not be achieved via MID because MID values do not tell anything about who the source is. Said that, what I said above regarding "RTP `timestamp` are the same for SSRC streams originated by the same source" may be completely wrong and, if so, the rest of this comment does not make any sense. **In summary:** Does libwebrtc use CNAME value for something in the receiver side? -- GitHub Notification of comment by ibc Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2114#issuecomment-470282667 using your GitHub account
Received on Wednesday, 6 March 2019 21:24:44 UTC