xpra icon
Bug tracker and wiki

Opened 2 months ago

Closed 4 weeks ago

#1951 closed enhancement (fixed)

video-scaling should be set to auto

Reported by: Antoine Martin Owned by: J. Max Mena
Priority: major Milestone: 2.4
Component: encodings Version: 2.3.x
Keywords: Cc:


We already have speed and quality settings.
Those alone should be enough to drive the amount of video scaling applied.
We can keep the existing heuristics for when video scaling is set to a value.
We may want to expose this via the system tray menu and html5 advanced connection options.

Change History (4)

comment:1 Changed 2 months ago by Antoine Martin

Status: newassigned

New heuristics mostly done in r20366 - see commit message for details. Updates in r20367 + r20368.

Rather than choosing the downscaling using the old opaque heuristics, the new code will choose the downscaling required to fit within a target budget. This target can come from:

  • the current bandwidth-limit value (#417) if we have one (roughly converted into a number of uncompressed pixels per second), the lower bound used here can be changed using XPRA_SCALING_MIN_PPS=1000000 (ie: 1 megapixels per second), defaults to 240p25: 25*320*240
  • the default target, configurable using XPRA_SCALING_PPS_TARGET=16000000 (ie: 16 megapixels per second) defaults to 1080p25: 25*1920*1080
  • some of the details of the calculations can be shown with "-d scaling"
  • to revert to the old heuristics, just use --video-scaling=VALUE (with VALUE=1) instead of video-scaling=auto.


  • we allow more downscaling for "video" content (by a factor of 2), since we care less about lossy pixel data with video content - we take into account the "video" content-type hint (#1952)
  • we allow less downscaling for shadow servers (by a factor of 2): those sessions are using video encodings because of how we refresh via a timer and not because this is actually video content, a shadow session usually looks garbled with downscaling applied
  • if the quality is above 80 (90 for video), no downscaling is used unless required by the video encoder's size limits
  • higher quality or low speed settings raise the target, low quality or high speed lower it - roughly by a factor of ~4 each (r20369)

Still TODO:

  • take into account fullscreen and maximized flags?
  • UI updates
Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:2 Changed 2 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

Not going to update the UI (we have too many controls already), and not going to use fullscreen or maximized flags (not sure which way they should favour).

@maxmylyn: FYI, the new heuristics should be easier to use (automatic) and will honour the dynamic quality and speed tuning more accurately.

Somewhat related to #1867, see also #1952.

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 8 weeks ago by Antoine Martin

Important fixups in r20520.

comment:4 Changed 4 weeks ago by J. Max Mena

Resolution: fixed
Status: newclosed

Noted and closing.

Note: See TracTickets for help on using tickets.