Xpra: Ticket #948: review and probe the codec picture size limits

swscale can handle pictures bigger than 4k, we now detect this in r10314. we should do the same for the other csc modules and video codecs, or if it is too slow to probe, at least have some code that allows us to figure it out and have better defaults - probably per encoding.



Mon, 17 Aug 2015 06:33:18 GMT - Antoine Martin: owner changed

Done in r10319, r10322, r10323, see commit messages for details.

In the future, we may also want to be more clever about how we check against the maximum picture size and allow a maximum number of pixels rather than just width and height. (vp9 and x264 supports width OR height much higher than 8k.. at least 16k!)

@afarr: I cannot test all the different versions of libvpx and x264, so the new hardcoded size limits I have added in this commit are only enabled with the latest versions available in the repositories:

If you have older versions available or even in use, and you find that they also support higher resolutions than the hardcoded defaults, then we can make the version checking less stringent. The defaults for older versions are:

To test and verify that the values are correct:

Warning: the self tests can consume a lot of memory, and they do not run under gdb and trigger the OOM killer instead.. A single frame of 16kx16k RGBX data uses up 1GB of memory... we will need much faster computers before we can handle that! (but it is coming) The tests just stop there rather than wasting memory: we probably don't handle windows bigger than 16k anyway.

I don't think this should be backported to older branches. If you want windows bigger than 4k, upgrade. Note: the opencl limits are figured out at runtime based on which CPU / GPU is selected. (I get a surprisingly low 8k limit on a high end GTX 970..)


Sat, 29 Aug 2015 10:16:53 GMT - Antoine Martin:

r10483 prevents us from hitting the OOM killer whilst probing the vpx maximum encoder dimensions - it will also fail the build if the hard-coded limits are bigger than they should be.


Fri, 23 Oct 2015 17:20:55 GMT - J. Max Mena:

Got the following output:

[root@localhost codecs]# XPRA_CODEC_SELFTEST=1 XPRA_UTIL_DEBUG=1 python loader.py -v | grep max
 x264 xpra.codecs.enc_x264.encoder.<built-in function get_info>={'max-size': (4096, 4096), 'version': 142, 'buffer_api': 1, 'formats': ['YUV422P', 'RGB', 'BGRX', 'BGR', 'YUV420P', 'BGRA', 'YUV444P']}
 swscale xpra.codecs.csc_swscale.colorspace_converter.<built-in function get_info>={'max-size': (16384, 16384), 'version': (3, 1, 101), 'buffer_api': 1, 'formats': ['RGB', 'BGR', 'XRGB', 'BGRX', 'YUV420P', 'YUV422P', 'YUV444P', 'GBRP']}
 vpx xpra.codecs.vpx.encoder.<built-in function get_info>={'libvpx14': True, 'vp9.max-size': (8192, 4096), 'vp8.colorspaces': ['YUV420P'], 'version': u'v1.4.0', 'abi_version': 10, 'encodings': ['vp8', 'vp9'], 'vp8.max-size': (4096, 4096), 'build_config': '--prefix=/usr --libdir=/usr/lib64/xpra --enable-pic --disable-install-docs --disable-install-bins --enable-shared --enable-vp8 --enable-vp9 --enable-realtime-only --enable-runtime-cpu-detect', 'buffer_api': 1, 'vp9.colorspaces': ['YUV420P', 'YUV444P']}
                         {'max-size': (16384, 16384), 'version': (3, 1, 101), 'buffer_api': 1, 'formats': ['RGB', 'BGR', 'XRGB', 'BGRX', 'YUV420P', 'YUV422P', 'YUV444P', 'GBRP']}
                         {'libvpx14': True, 'vp9.max-size': (8192, 4096), 'vp8.colorspaces': ['YUV420P'], 'version': u'v1.4.0', 'abi_version': 10, 'encodings': ['vp8', 'vp9'], 'vp8.max-size': (4096, 4096), 'build_config': '--prefix=/usr --libdir=/usr/lib64/xpra --enable-pic --disable-install-docs --disable-install-bins --enable-shared --enable-vp8 --enable-vp9 --enable-realtime-only --enable-runtime-cpu-detect', 'buffer_api': 1, 'vp9.colorspaces': ['YUV420P', 'YUV444P']}
                         {'max-size': (4096, 4096), 'version': 142, 'buffer_api': 1, 'formats': ['YUV422P', 'RGB', 'BGRX', 'BGR', 'YUV420P', 'BGRA', 'YUV444P']}

Granted I have all the latest encoding packages, and Smo should as well. The output looks fine to me (at least from what I understand). Unless there's anything specific you'd like for us to test?


Sat, 24 Oct 2015 02:48:21 GMT - Antoine Martin: status changed; resolution set

I think this will do for now, we have bigger problems at high resolutions and scaling should take care of at least some of those.


Sat, 24 Oct 2015 06:07:17 GMT - Antoine Martin: status changed; resolution deleted

Actually, this needs full testing: XPRA_CODEC_FULL_SELFTEST=1, see comment:1 XPRA_CODEC_SELFTEST=1 is the default already.


Tue, 27 Oct 2015 21:19:28 GMT - J. Max Mena:

Re-ran on a hardware machine: (i7(?) and nvidia 745)

[root@scheeschuhe-spikes-qa codecs]# XPRA_CODEC_SELFTEST=1 XPRA_CODEC_FULL_SELFTEST=1 python loader.py -v | grep max
<module 'xpra.codecs.enc_x264.encoder' from '/usr/lib64/python2.7/site-packages/xpra/codecs/enc_x264/encoder.so'> max dimensions: 8192x4096
 x264 xpra.codecs.enc_x264.encoder.<built-in function get_info>={'max-size': (8192, 4096), 'version': 146, 'buffer_api': 1, 'formats': ['YUV422P', 'RGB', 'BGRX', 'BGR', 'YUV420P', 'BGRA', 'YUV444P']}
 swscale xpra.codecs.csc_swscale.colorspace_converter.<built-in function get_info>={'max-size': (16384, 16384), 'version': (3, 1, 101), 'buffer_api': 1, 'formats': ['RGB', 'BGR', 'XRGB', 'BGRX', 'YUV420P', 'YUV422P', 'YUV444P', 'GBRP']}
 vpx xpra.codecs.vpx.encoder.<built-in function get_info>={'libvpx14': True, 'vp9.max-size': (8192, 4096), 'vp8.colorspaces': ['YUV420P'], 'version': u'v1.4.0', 'abi_version': 10, 'encodings': ['vp8', 'vp9'], 'vp8.max-size': (8192, 4096), 'build_config': '--prefix=/usr --libdir=/usr/lib64/xpra --enable-pic --disable-install-docs --disable-install-bins --enable-shared --enable-vp8 --enable-vp9 --enable-realtime-only --enable-runtime-cpu-detect', 'buffer_api': 1, 'vp9.colorspaces': ['YUV420P', 'YUV444P']}
                         max-size = (16384, 16384)
                         vp8.max-size = (8192, 4096)
                         vp9.max-size = (8192, 4096)
                         max-size = (8192, 4096)

Is this acceptable? Everything looks fine to me....then again to me it looks like it actually ran the self-tests when I ran it without Grep. (due to having ~7GBs free memory)


Wed, 28 Oct 2015 02:24:49 GMT - Antoine Martin: status changed; resolution set

Those limits are the same as the predicted ones we hardcode.

We'll just have to hope that older versions of x264 and libvpx don't have lower limits.

Closing at last.


Sat, 23 Jan 2021 05:10:36 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/948