limit video dimensions

[Antoine Martin]

Compressing video can be expensive, especially at high-res, let's provide a way to cap this CPU cost by forcing video the be down-scaled to a size that doesn't place too high a burden on the server.

This will also help maintain a decent framerate with HTML5 clients where the decoding is often CPU-bound.

[Antoine Martin]

Done in r19591:

• the python client will be limiting video resolution to 8k x 8k or the maximum texture size - whichever one is smaller
• the html5 client will set the limit at 1024x768

The server will then choose a scaling value which makes the video smaller than the "video-max-size".

client.window.2.scaling=(1, 2)
client.window.2.supports_video_scaling=True
client.window.2.video-max-size=(1024, 768)

(the scaling values are integer ratios, ie: 1/2, 2/3, etc)

@maxmylyn: this may help with your CPU constraints if you also enable h264 decoding. (#1839)
You may also want to raise min-speed. This will use more bandwidth and less CPU time.

[J. Max Mena]

Running a Fedora 28 trunk r19621 server:

I'm getting this traceback serverside when attaching via an HTML5 client:

2018-06-12 13:03:15,892 listget('video_max_size', (8192, 8192), <type 'int'>, None)
None
2018-06-12 13:03:15,892 expected a list or tuple value for video_max_size but got <type 'int'>

I'm assuming it's related to this ticket since it's printing about video maximum size.

[Antoine Martin]

I'm getting this traceback serverside when attaching via an HTML5 client:

I cannot reproduce. Make sure that the HTML5 client you use is up to date, hit shift+reload if necessary.
If you can still reproduce it, please attach the server's "-d server" log output.

The current version clearly has a pair of ints as value: browser/xpra/trunk/src/html5/js/Client.js.

[Antoine Martin]

Never mind, I hit it (no idea why I didn't before - I still despise Javascript too much to care), fixed in r19624.

See also #1951

[J. Max Mena]

Okay that solved it.

Closing