Allow max-quality setting

[TijZwa]

Is your feature request related to a problem? Please describe.
When using Xpra as VDI solution over a very fast and reliable link, sometimes we get frames/pictures that are encoded with a quality that is too high for the purpose. Ie: When using webp a quality of 70% is very decent quality.
But a frame with 95%+ encoding makes a running video stutter because it's too big/takes longer to encode/takes longer to decode.

Describe the solution you'd like
It would be nice to be able to set a max-quality param.

Describe alternatives you've considered
Tuning speed and refresh is also a solution, but max-quality would be a bit more convenient.

[totaam]

Did you figure out why you're getting this webp frame whilst playing video? Was it an auto-refresh or just a non-video area?
The auto-refresh can be slowed down or even turned off.
This varies depending on the code path taken, but generally non-video areas get a quality boost: we assume that the video quality matters less than the framerate but that areas outside the video are unlikely to be refreshed regularly and therefore need a higher quality.

@TijZwa Was your video also encoded with 70% quality? Can you provide a brief -d compress log sample to use as reference?

There are a number of things that this may interfere with, which is why I haven't implemented it yet:

• auto-refresh: this one should not honour any max-quality option, but it can be turned off if needed so this is not a big problem
• batch delay calculations: a lower quality currently implies performance issues
• other heuristics also use the quality value as a percentage - should they continue to use it directly or use the range min-quality - max-quality instead? (ie: setting a low max-quality would end up always enabling video scaling)

[TijZwa]

@totaam Yes, I've only rgb + png + webp enabled, as webp offers me the best balance between speed and quality.
The 70% quality is fixed (--quality=70)

I would like xpra to choose between two fixed numbers, like min-quality=50 & max-quality=80.
I can see the interference with other options, so this might not be the way to go.

[totaam]

I've only rgb + png + webp enabled, as webp offers me the best balance between speed and quality

Beyond a certain size, webp is too slow, you should keep jpeg enabled for that reason.

I can see the interference with other options, so this might not be the way to go.

Perhaps we can avoid this costly frame without limiting the quality to an arbitrary value.
If this was a non-video area, by reducing the boost for non-video.
If this was an auto-refresh, perhaps delaying it further.
But first, you have to know why this was happening before deciding how to deal with it.

Just as important, we want to know if the pixel data is compressed with the alpha channel or not. (same issue as #3410)
What browser are you running server side?

[totaam]

The commit above makes it easier to play with max-quality and max-speed:

• using server environment variables, ie: XPRA_ENCODING_MAX_QUALITY=50
• using client encoding properties encoding.max-quality and encoding.max-speed

---

Playing with these new knobs I am quite concerned that they are going to be misused and lead people to believe that this is the official or correct way of sacrificing quality for bandwidth or framerate when it is not.
This could end up being just as counter productive as allowing users to choose --encodings= (which they invariably do not understand the implications of - causing harm).
In particular, with many applications I am seeing that setting a low max-quality causes a lot of unnecessary screen updates (once at a low quality then later on with an auto-refresh at 100%).
Forgoing the auto-refresh is also not a good idea in this case.

@TijZwa please see the questions in the comment above.
We should let the server engine figure out how best to deal with these situations, tweaking the heuristics if needed, rather than second guessing it. The encoding engine can make thousands of data driven decisions per second, users cannot.

[TijZwa]

@totaam Nice! I will test this soon.
To answer the question; I'm using Chrome/Chromium 99% of the time on the backend.

[totaam]

@TijZwa I meant getting the -d compress log of the problematic screen updates (with a little bit before and after) so that we can see if they are justified or not. (ie: was it an auto-refresh, a video area detected, etc..)