Poor bandwidth estimation performance without x-google-max-bitrate

[Peter]

The sender is configured min/max bitrates using webrtc::RtpEncodingParameters (set to 5000 and 16000 respectively).

I measure effective bitrate on the client side and log values recevied in webrtc::VideoEncoder::SetRates -- target_bitrate from webrtc::VideoEncoder::RateControlParameters.

Here is how the graphs look like over 45-sec test run:

The bitrate ramps up over 20 seconds to the maximum, stays there for ~10 seconds and then drops. The pattern repeats.

If I munge SDP offer sent by client by adding "x-google-max-bitrate=16000"  the behavior changes completely:

The client achieves maximum bitrate in ~2sec and continue to maintain it.

Why is this happening? I always thought tweaks like "x-google-max-bitrate" are optional and RtpEncodingParameters takes precedence, but obviously this is not the case.

Thanks,

Journee Technologies GmbH | Chausseesstr. 36 | 10115 Berlin | Germany

Managing Directors: Christian Loclair, Thomas Johann Lorenz

Registration Court: Charlottenburg

Commercial Register: HRB 220868 B

VAT ID: DE334442803

Europe: +49 (0) 30 83794320

United States: +1 (332) 248 1278

---

This email and any files transmitted with it are confidential and are intended solely for the use of the person or organisation to whom they are addressed. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. If you have received this e-mail in error, please notify the sender immediately by e-mail and delete the e-mail from your system; you are advised that disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited.

------

Thank you

[V I]

Nice find. I've run into a similar looking problem with a libwebrtc 115 based sender. I did try b=AS (which changed nothing), but not x-google-max-bitrate - gotta try it as well

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/fe62cf7d-1514-44b3-b4b1-1bd502fd39een%40googlegroups.com.

[Peter]

The only place where I see this ("x-google-max-bitrate") is being checked is inside WebRtcVideoChannel::WebRtcVideoSendStream::CreateVideoEncoderConfig which is then used in multiple places when VideoEncoder needs to be reconfigured -- somewhere down inside VideoEngine/Stream/Channel. This seems to be a different API path from what I use. 

I've been searching through the sources trying to find a way how to provide webrtc::VideoEncoderConfig but can't find it yet. Any pointers/clarifications will be appreciated!

I'm aiming to have sender work as in the second use case (i.e. utilize available bandwidth) without the need to provide x-google-... options in the client.

Thanks,

[Björn Terelius]

I'm not very familiar with "x-google-max-bitrate", but I don't think it should be needed for bandwidth estimation.

Are you doing bandwidth estimation on send side or receive side? In the former case, are you negotiating the transport-wide sequence number extension and associated RTCP feedback message?

Is this issue reproducible in chrome?