- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Sun, 24 Mar 2019 09:45:57 +0000
- To: public-webrtc-logs@w3.org
A possible solution would be to add the following attributes to the `sendEncodings`: - `minBitrate` : bellow this threshold the encoding/layer will be dropped (i.e. will not be sent until there is enough bandwidth to start sending it again). Default: `0` - `weight` : weight of this encoding compared to the other encodings of this sender. Default: `1/scaleResolutionBy` - `dropOrder` : In case two (or more) encodings cannot be sent because there is not enough bandwidth which one should be dropped first. Default: `array index of the encoding` So, when the total bandwidth is assigned to the sender/track (this could be up to the implementators), the total weight of the encodings should be calculated and assigned each the bandwidth according to the weight ratio. If any of the encodings does not meet the `minBitrate` the one with lower `dropOrder` will be removed and the total weight will be calculated and the bandwidth split again until either all encodings are dropped or they match the minimum bandwidth constrains. We should also add events for layer drop/activation due to this process. -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2141#issuecomment-475943396 using your GitHub account
Received on Sunday, 24 March 2019 09:45:59 UTC