Need to define what to do on very low bitrates

[alvestrand]

If bitrate is so low that it's unreasonable (doesn't allow sending a frame in a reasonable time), is the implementation allowed to emit a frame at all, is it allowed to exceed the bitrate over a short interval, or should it reject the parameter?

[fippo]

and what if the bitrate is reasonable for the track currently attached to the sender (says 320x240@15fps) and then that track is replaced with a 4k@30fps screenshare?

[murillo128]

This situation is no different than setting the bitrate to a reasonable value end then getting a BWE with a very low bitrate.

IMO, the implementation should never be allowed to send more bitrate than the specified on the parameters or the value provided by the BWE.

In this case the implementation could either decide to not send media at all, or try to send it a very low fps (one frame each several seconds).

[alvestrand]

Agree that the configured bitrate (and the bitrate from BWE) should never be exceeded when averaged over a long enough period. (But what's long enough?)
When sending a single frame, it makes sense to me to send it as fast as possible within the constraints given by BWE, no matter what the maxBitrate value says - but then it may take a long time until we send the next one.

[shampson]

A relevant webrtc bug:
https://bugs.chromium.org/p/webrtc/issues/detail?id=9141

[Orphis]

Regarding this issue, should we treat maxBitrate == 0 the same as maxFramerate == 0 for consistency?
Both could be equivalent to setting active to false.