W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

Re: [webrtc-pc] Do simulcast offers need to contain RIDs of all streams in both directions? (#2053)

From: Amit Hilbuch via GitHub <sysbot+gh@w3.org>
Date: Tue, 15 Jan 2019 00:09:00 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-454212153-1547510939-sysbot+gh@w3.org>
The browser is the symmetric equivalent of the sender, we should assume that they might also be sending simulcast layers to the server.
The server should pick a single layer and transmit that to the browser (client). This layer can change based on network requirements, app logic (ex. conference calls), or other signalling.
The server negotiates that traffic independently to the client, and can:
1. rewrite the RID to match what the client expects (regardless of which stream is transmitted).
2. drop the rid altogether (because mid is sufficient).
3. negotiate an SSRC because the client does not support RIDs and transmit the chosen stream on the SSRC without any MID/RID extensions.

In all of these options, it seems to me that the client and server can agree to change the relayed stream, without changing the rtp stream it is transferred on. 
As an example, if i click on your video during a conference call, i can signal to the server to send me your video in high quality, but it should be sent over the same RTP stream (with the same MID, RID, SSRC) and this is application logic that is hidden from the WebRTC logic.

This assumes that the video encoder will be able to handle changing resolutions. i'm no expert on that.

-- 
GitHub Notification of comment by amithilbuch
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2053#issuecomment-454212153 using your GitHub account
Received on Tuesday, 15 January 2019 00:09:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:15:00 UTC