Implement bitrate controller in vpx and h264 codecs and use REMB RTCP messages to set bitrate naively #467
Conversation
Codecov ReportBase: 58.21% // Head: 58.41% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #467 +/- ##
==========================================
+ Coverage 58.21% 58.41% +0.19%
==========================================
Files 62 62
Lines 3683 3715 +32
==========================================
+ Hits 2144 2170 +26
- Misses 1412 1415 +3
- Partials 127 130 +3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
Hi, thank you for your PR, it looks awesome ! While automatic bitrate adjustment is a great feature, it should probably be configurable. We should be able to at least disable it by default and chose the percentage of the detected maximum bandwidth. Perhaps you could split this PR, letting us merge your bitrate controllers and discuss about how to implement the automatic bitrate adjustment in a dedicated PR ? |
|
Thanks for the suggestions @EmrysMyrddin. I rolled back this PR to just include the bit-rate encoder controllers. I'm thinking the place to implement the option for auto bit-rate control is in the RTPCodec struct at the beginning of codec.go, and then maybe allow setting the percentage bandwidth used per stream by passing the percentage as a mediaStreamConstraint in getUserMedia(). Does that seem good, or might there be a better way to do it? |
| @@ -78,6 +79,22 @@ Encoder *enc_new(x264_param_t param, char *preset, int *rc) { | |||
| return NULL; | |||
| } | |||
|
|
|||
| #define RC_MARGIN 10000 /* 1kilobits / second*/ | |||
Description
This sets every track to use roughly all (hardcoded to 93%) the estimated available bandwidth.
Currently it doesn't compensate for when other tracks or data channels are transmitting over the same bandwidth.
I couldn't find an easy way to detect what other tracks & datachannels were in use over the same peer connection, so doing bit rate control in a smarter way is still an open problem (see rtcpReadLoop in track.go).