- From: Seth Hampson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Aug 2018 17:00:03 +0000
- To: public-webrtc-logs@w3.org
> If both a priority "low" and a priority "high" stream is available, and neither can fit within the bandwidth set by congestion control, one is supposed to send 4 bytes from the "high" priority stream for every byte sent from the "low" priority Currently this is done above the minimum of each stream. So after the minimum amount for a stream is satisfied, the bandwidth is allocated proportionally. But this is specific to streams (RtpSenders), not for simulcast layers. As far as dropping a stream/layer I don't think it makes sense necessarily to drop the stream with a priority of low. As Taylor pointed out in [issue 1625](https://github.com/w3c/webrtc-pc/issues/1625), the _priority_ is different than the [networkPriority](https://w3c.github.io/webrtc-dscp-exp/#networkPriority). The common case here would be that you want to keep the low quality layer and drop higher quality layers first. For streams this is dropping audio before video, but for layers maybe this might mean keeping a thumbnail while dropping your HD layer. For [3] I don't think maxBitrate should affect how layers are dropped or how bandwidth is allocated. Shouldn't they be dropped based on (a hidden) minimum configured bitrate? Doesn't the proportional allocation happen with the priority? -- GitHub Notification of comment by shampson Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1964#issuecomment-413263555 using your GitHub account
Received on Wednesday, 15 August 2018 17:00:04 UTC