- From: Amit Hilbuch via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Jan 2019 00:09:00 +0000
- To: public-webrtc-logs@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