xpra icon
Bug tracker and wiki

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


Changes between Initial Version and Version 1 of Ticket #1135


Ignore:
Timestamp:
02/24/16 09:35:15 (5 years ago)
Author:
Antoine Martin
Comment:
  • 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?

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1135

    • Property Owner changed from Antoine Martin to alas

  • Ticket #1135 – Description

    initial v1  
    55
    66Other things we could / should be doing:
    7 * 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 85 to 100 depending on the size of the area to encode)
     7* 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)
    88* 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
    99* 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