- From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Apr 2019 22:19:53 +0000
- To: public-webrtc-logs@w3.org
@jan-ivar I believe the text in the note is actually incorrect. When receiving simulcast, the `RtpReceiver` *does* need to combine two distinct RTP streams into a single track. This is non-trivial because re-ordering can cause the streams to be co-mingled, so that the `RtpReceiver` will need to maintain two jitter buffers and figure out when to switch between streams so that it can feed material to the decoder in a coherent way. This is not required when `sender.replaceTrack()` is called - the `RtpReceiver` only sees a single RTP stream, so it doesn't actually need to do anything special. Saying that the `RtpReceiver` "stiches together" is wrong here - as wrong as saying that the `RtpReceiver` has to do anything when an SFU (which receives simulcast) switches between incoming RTP streams and provides the receiver with a single RTP stream. -- GitHub Notification of comment by aboba Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2171#issuecomment-486449403 using your GitHub account
Received on Wednesday, 24 April 2019 22:19:54 UTC