xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 5 years ago

Last modified 4 months ago

#1135 closed enhancement

degrading video quality more than the rest — at Version 1

Reported by: Antoine Martin Owned by: alas
Priority: critical Milestone: 1.0
Component: encodings Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

Similar and related to #1130 and #967: we want to ensure that when we need to make sacrifices to cope with the amount of pixels that need to be encoded we sacrifice the video area picture quality (if there is video), before we degrade the rest of the window.
And also make sure that we only use a video encoder when it is the right choice for the content.

We already have hooks for this: WindowVideoSource get_speed / get_quality: the non-video areas get a huge speed and quality boost.

Other things we could / should be doing:

  • maybe the boost code above should be replaced by more aggressive speed and quality mappings in the video codecs themselves? Changing the tuning code to give higher values for quality and speed by default and/or use non-video lossless at a lower threshold (currently between 75 to 100 depending on the size of the area to encode)
  • more aggressively switch to YUV420P: if we are using a video encoder, we are very likely to be sending the data losslessly already (unless the quality is set to 100), so using a subsampled colourspace probably does not matter much and will save a lot of CPU / bandwidth which we can use for other things - can be tested using XPRA_FORCE_CSC_MODE=YUV420P xpra start ... - I believe newer versions already do this
  • automatic video scaling: this is probably OK as it is (we have a command line switch to control how aggressive it is: #692), can easily be tested and verified
  • more stringent video detection: only using video if we are absolutely certain that we are dealing with a video area (see ticket:967#comment:11)
  • when the picture compression ratio is very high (#967 pages that repaint for no reason: successive frames are identical), we should automatically raise the quality

Change History (1)

comment:1 Changed 5 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to alas
  • r12028 tries to make the video region detection more strict, which may help
  • r12029 lowers the threshold for lossless updates (both for the case where we have video on screen and when we don't)
  • r12030 fixes a bug (oops) - backport makes me a bit nervous since no-one noticed this until now: this fix could make things worse
  • r12031 takes the compression ratio into account to update the quality setting (ie: better compression ratios should make us increase the quality, worse -> decrease)

You can see the server quality settings getting updated with -d stats by looking for update_quality in the output, or with:

xpra info | grep "encoding.quality"

The "backlog_factor" is new and takes the form: backlog_factor=(PACKETS, PIXELS, TARGET_QUALITY). When the recent compression ratio is better than average, the delta should increase the target quality. (and conversely, it should show a negative delta value to lower the quality when the recent is worse than average)

There are some new environment variables which can be used to tune the video region detection code (maybe this can be tuned better so as to exclude problematic cases like #967):

  • XPRA_VIDEO_DETECT_MAX_TIME - how far back we look for screen updates, defaults to 5 (in seconds)
  • XPRA_VIDEO_DETECT_MIN_EVENTS - within this timeframe, how many events we require to start looking for a video region, defaults to 20

@afarr: do you have reliable test cases to verify that this improves the corner cases we want to deal with?

Last edited 5 years ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.