The bandwidth-limit is used to raise the batch delay (variable refresh rate) so that we stay within budget (and that in turns has an effect on quality and speed), but we should pass the information down to the video encoders so that they can be tuned adequately earlier.
This bitrate constraint overrules the speed and quality settings so this should only be applied when the bandwidth-limit is relatively low.
Done in r20399 for x264 and vpx. We only use the bandwidth-limit value when speed and quality are on "auto" and when min-quality is lower than 50%.
The change also improves the amount of x264 encoder configuration details shown in xpra info, so we can see which "rc-method" is in use, ie trimmed:
client.window.2.encoder=x264 client.window.2.encoder.b-frames=1 client.window.2.encoder.bandwidth-limit=2000000 client.window.2.encoder.content-type=video client.window.2.encoder.fps=159 client.window.2.encoder.ms_per_frame=3 client.window.2.encoder.params.rc.bitrate=1953 client.window.2.encoder.params.rc.rc-method=ABR client.window.2.encoder.params.rc.vbv_buffer_init=1.0 client.window.2.encoder.params.rc.vbv_buffer_size=1953 client.window.2.encoder.params.rc.vbv_max_bitrate=3906 client.window.2.encoder.preset=fast client.window.2.encoder.profile=high10 client.window.2.encoder.tune=film
Regression introduced by r20399 is fixed: ticket:2087#comment:4
Summary: this new code should allow the video encoders to be better tuned for the amount of bandwidth available, lowering the picture quality (sometimes drastically - see #2087 for what a 2Mbps limit does) but allowing for a higher refresh rate and a better quality for the non-video areas around it.
Not heard back.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1957