review and probe the codec picture size limits

[totaam]

Issue migrated from trac ticket # 948

component: encodings | priority: major | resolution: fixed

2015-08-17 06:32:08: antoine created the issue

---

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.

[totaam]

2015-08-17 07:33:18: antoine changed owner from antoine to afarr

[totaam]

2015-08-17 07:33:18: antoine commented

---

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:

• libvpx v1.4 vp8: 8k x 8k
• libvpx v1.4 vp9: 16k x 8k
• libx264 v146: 16k x 16k

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:

• vp8: 4k x 4k
• vp9: 8k x 8k
• libx264: 4k x 4k

To test and verify that the values are correct:

• ./xpra/codecs/loader.py -v should show you the values used based on the library version checks - the same values which will be used at runtime by the server and which you can then see via "xpra info", ie:

* enc_vpx              : /usr/lib64/python2.7/site-packages/xpra/codecs/vpx/encoder.so
                         vp8, vp9
                         {'libvpx14': True, 'vp8.colorspaces': ['YUV420P'], 'version': u'v1.4.0', 'abi_version': 10, 'encodings': ['vp8', 'vp9'], \
                          'vp8.max-size': (8192, 8192), 'vp9.max-size': (16384, 8192), \
                          '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']}
* enc_x264             : /usr/lib64/python2.7/site-packages/xpra/codecs/enc_x264/encoder.so
                         h264
                         {'max-size': (16384, 16384), 'version': 146, 'buffer_api': 1, 'formats': ['YUV422P', 'RGB', 'BGRX', 'BGR', 'YUV420P', 'BGRA', 'YUV444P']}

• XPRA_CODEC_FULL_SELFTEST=1 ./xpra/codecs/loader.py -v will actually run the full self tests and the values shown will be the ones we have verified by testing each codec. Add XPRA_UTIL_DEBUG=1 for more verbose logging, which will show which sizes worked and which ones did not.

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..)

[totaam]

2015-08-29 11:16:54: antoine commented

---

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.

[totaam]

2015-10-23 18:20:56: maxmylyn commented

---

• Ran XPRA_CODEC_SELFTEST=1 XPRA_UTIL_DEBUG=1 python loader.py -v | grep max from the r10989 trunk code(trimmed the output to just max-size prints)

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?

[totaam]

2015-10-24 03:48:22: antoine changed status from new to closed

[totaam]

2015-10-24 03:48:22: antoine set resolution to fixed

[totaam]

2015-10-24 03:48:22: antoine commented

---

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.

[totaam]

2015-10-24 07:07:17: antoine changed status from closed to reopened

[totaam]

2015-10-24 07:07:17: antoine removed resolution (was fixed)

[totaam]

2015-10-24 07:07:17: antoine commented

---

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

[totaam]

2015-10-27 21:19:28: maxmylyn commented

---

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)

[totaam]

2015-10-28 02:24:50: antoine changed status from reopened to closed

[totaam]

2015-10-28 02:24:50: antoine set resolution to fixed

[totaam]

2015-10-28 02:24:50: antoine commented

---

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.