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 Initial Version

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


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 85 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 (0)

Note: See TracTickets for help on using tickets.