[Preview] Advanced WebRTC Bandwidth Estimation (Auto Quality Switching)

[getroot]

I am excited to finally share this feature with you. I would also like to express my gratitude to everyone who has provided valuable feedback and waited for this update.

I have developed and uploaded an initial version of the Advanced Bandwidth Estimation (BWE) logic. Since this is currently a draft version, I have pushed it to a separate feature branch.

In the context of WebRTC, there is no single "correct answer" for BWE. This is especially true for 1:N streaming scenarios, unlike P2P, making the implementation extremely challenging. I believe that continuous tuning and refinement are the only ways to make this feature truly valuable.

While the core logic is implemented, it requires further tuning. In particular, it has not yet been fully tested under high concurrency environments with many connected sessions. Although it performed reasonably well in my test environment, please note that the current implementation may behave unexpectedly in different network conditions.

You can check out the initial version in the branch below:
https://github.com/AirenSoft/OvenMediaEngine/tree/feature/advanced-bwe

Additionally, an option has been added to the <WebRTC> configuration in Server.xml to select the BWE mechanism. In my test environment, TransportCC showed better results compared to REMB.

Configuration Example:

<WebRTC>
    <Timeout>10000</Timeout>
    <Rtx>false</Rtx>
    <Ulpfec>false</Ulpfec>
    <JitterBuffer>false</JitterBuffer>

    <BandwidthEstimation>TransportCC</BandwidthEstimation> <!-- REMB -->
</WebRTC>

I am eager to merge this feature into the main branch as soon as possible. To achieve this, I kindly ask for your active testing, feedback, and contributions.

[naanlizard]

For someone that doesn't have any idea what bandwidth estimation is used for, can you provide an example use case for this feature?

[naanlizard]

Thank you, unfortunately not something I can help test haha, we only have the source bitrate for any given stream

[nums]

Many thanks for this feature @getroot I'll test it very soon ;)

[nums]

I've been testing TransportCC for a few minutes and it works perfectly!
Still images don't cause any changes at low bitrates.

Great works 🚀

I'm using NetLimiter to play with BW, I have got this kind of logs :

[2025-12-15 14:40:36.961] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:344  | Bandwidth OverUse detected. But there is no lower rendition or changing state.
[2025-12-15 14:41:01.085] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:340  | Bandwidth OverUse detected. Requested to lower the rendition.
[2025-12-15 14:41:13.835] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:355  | Bandwidth UnderUse detected. Requested to higher the rendition.
[2025-12-15 14:41:40.461] W [SW-WebRTC:367] WebRTC Publisher | rtc_bandwidth_estimator.cpp:173  | Cannot find RTP history for wide_seq_no(65535)
[2025-12-15 14:41:41.211] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:340  | Bandwidth OverUse detected. Requested to lower the rendition.
[2025-12-15 14:41:51.399] E [SW-WebRTC:367] RTCP | transport_cc.cpp:183  | Even though parsing transport-cc was completed, the payload is not fully parsed
[2025-12-15 14:42:57.961] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:340  | Bandwidth OverUse detected. Requested to lower the rendition.
[2025-12-15 14:43:10.024] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:355  | Bandwidth UnderUse detected. Requested to higher the rendition.
[2025-12-15 14:45:32.901] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:340  | Bandwidth OverUse detected. Requested to lower the rendition.
[2025-12-15 14:45:45.026] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:355  | Bandwidth UnderUse detected. Requested to higher the rendition.
[2025-12-15 14:46:50.091] W [SW-WebRTC:367] WebRTC Publisher | rtc_bandwidth_estimator.cpp:173  | Cannot find RTP history for wide_seq_no(65535)
[2025-12-15 14:47:59.654] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:340  | Bandwidth OverUse detected. Requested to lower the rendition.
[2025-12-15 14:48:11.716] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:355  | Bandwidth UnderUse detected. Requested to higher the rendition.
[2025-12-15 14:48:33.907] E [SW-WebRTC:367] RTCP | transport_cc.cpp:183  | Even though parsing transport-cc was completed, the payload is not fully parsed
[2025-12-15 14:48:39.528] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:340  | Bandwidth OverUse detected. Requested to lower the rendition.
[2025-12-15 14:48:51.591] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:355  | Bandwidth UnderUse detected. Requested to higher the rendition.
[2025-12-15 14:49:43.716] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:340  | Bandwidth OverUse detected. Requested to lower the rendition.
[2025-12-15 14:49:55.841] I [SW-WebRTC:367] WebRTC Publisher | rtc_session.cpp:355  | Bandwidth UnderUse detected. Requested to higher the rendition.
`

[nums]

I logged the information from rtc_bandwidth_estimator.cpp. Sometimes the bandwidth estimate doesn't match what I'm specifying with NetLimiter, even though the switch to a lower rendering resolution is working correctly.
I may also have detected a problem when transitioning from a static image to a very "animated" video sequence.

I'll investigate further and provide more logs.

[getroot]

The bandwidth estimate expressed in that number is output for debugging purposes and is not actually used to determine under-use/over-use. Calculating the actual bandwidth estimate using TransportCC is subject to significant errors due to jitter (the lower the track's bitrate). Therefore, this value is for reference only and can be ignored.