video-scaling should be set to auto

[totaam]

Issue migrated from trac ticket # 1951

component: encodings | priority: major | resolution: fixed

2018-09-09 03:36:41: antoine created the issue

---

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.

[totaam]

2018-09-09 17:25:53: antoine changed status from new to assigned

[totaam]

2018-09-09 17:25:53: antoine commented

---

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 (re-implement bandwidth constraint option #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: 25320240
• the default target, configurable using XPRA_SCALING_PPS_TARGET=16000000 (ie: 16 megapixels per second) defaults to 1080p25: 2519201080
• 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.

Tweaks:

• 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 (use content-type hint for better encoding selection and tuning #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

[totaam]

2018-09-11 16:16:47: antoine changed status from assigned to new

[totaam]

2018-09-11 16:16:47: antoine changed owner from antoine to maxmylyn

[totaam]

2018-09-11 16:16:47: antoine commented

---

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.

[totaam]

2018-09-24 11:39:57: antoine commented

---

Important fixups in r20520.

[totaam]

2018-10-18 17:42:16: maxmylyn changed status from new to closed

[totaam]

2018-10-18 17:42:16: maxmylyn set resolution to fixed

[totaam]

2018-10-18 17:42:16: maxmylyn commented

---

Noted and closing.