Xpra: Ticket #1694: re-add webp codec

It was removed in r14508 as part of a codec cleanup. The main problems with it were that:

After playing with it on Fedora 27 with libwebp 0.6.0, it seems that there are settings we can use that will give us better compression and better performance than png. And we should be able to avoid using it for the cases where it isn't adequate.

We need something better than png to avoid using up all the bandwidth with lossless refresh. (see ticket:999#comment:20 for details)

Tue, 21 Nov 2017 16:37:07 GMT - Antoine Martin: status changed

A very quick and dirty test with glxspheres at 1240x900 with speed=100 and quality=100 shows:

The pillow webp code is much slower (~100ms), but it also compresses better: the size is just 2.5%! So clearly we can do better with this codec, I'm just not sure how yet. Undoing all the configuration we do, the same image takes 2 seconds to compress! (and the gains really aren't worth it: only 6.5% compression ratio)

Here are the settings that we use when trying to go for maximum lossless compression:

webp.compress used config: {'emulate_jpeg_size': 0, 'filter_sharpness': 0, 'thread_level': 1, \
    'autofilter': 1, 'pass': 1, 'alpha_filtering': 0, 'sns_strength': 0, \
    'target_PSNR': 0.0, 'low_memory': 0, 'show_compressed': 0, 'target_size': 0, 'method': 0, \
    'filter_type': 1, 'preprocessing': 0, 'alpha_compression': 0, 'alpha_quality': 0, \
    'partition_limit': 0, 'lossless': 1, 'partitions': 3, 'filter_strength': 0, 'image_hint': 'graph', 'segments': 2}

The only major problem with this is that my xterm window comes out all black. (but the glxspheres window looks fine!)

Sadly, detect webp support.

Wed, 22 Nov 2017 04:26:26 GMT - Antoine Martin:

doh: we were forcing speed=100 when quality=100 (lossless).

Hardcoding the "method" to 0 (fast) and lossless mode (quality=100), we can fine tune the time spent compressing by setting webp's "quality" attribute (which has nothing to do with quality in this case..) - but the resulting output size remains pretty much the same! Setting the method to 1 or higher and the compression becomes too slow (250ms or more), for only 1 percentage point of extra compression! The reason why Pillow was doing better is that it wasn't doing true lossless as the quality value was clamped to 99 in our code!

Wed, 22 Nov 2017 04:26:58 GMT - Antoine Martin: attachment set

re-adds webp and makes it fast!

Wed, 22 Nov 2017 08:45:36 GMT - Antoine Martin: owner, status changed

In debug mode, webp is shown using a pink contour colour as before. All builds should have the correct dependencies added, including macos and win32 builds.

@maxmylyn: mostly a FYI, testing wouldn't hurt but feel free to just close.

Thu, 23 Nov 2017 06:52:16 GMT - Antoine Martin: attachment set

I don't think this is needed as long as pillow doesn't link with libwebp

Fri, 24 Nov 2017 15:33:06 GMT - Antoine Martin:


Interesting thing I spotted during bandwidth tuning for #999, webp can compress the xterm in lossless mode 40 times better than when using lossy compression!

compress:  10.5ms for  499x316  pixels at    0,0    for wid=1     using   webp \
    with ratio  23.0%  (  615KB to   141KB), sequence    74, \
    client_options={'quality': 99, 'speed': 97, 'rgb_format': 'RGBX'}
compress:   2.6ms for  499x316  pixels at    0,0    for wid=1     using   webp \
    with ratio   0.6%  (  615KB to     3KB), sequence    75, \
    client_options={'quality': 100, 'speed': 50, 'rgb_format': 'RGBX'}

Time for some window hints to make better guesses at what compression to use: #1699.

Wed, 29 Nov 2017 07:23:03 GMT - Antoine Martin:

r17541: libwebp 0.6.1

Wed, 29 Nov 2017 18:53:17 GMT - J. Max Mena: status changed; resolution set

Noted. I'll also make a note to myself to add it to the test box.


Sun, 17 Dec 2017 13:34:54 GMT - Antoine Martin:

Found a bug with the non-opengl rendering: the red and blue channels would end up swapped. That's because the webp encoder compresses BGRA (or BGRX) as input, so if it was fed "RGBA" (or "RGBX") then we have to swap the channels when decoding. The correct fix is a bit long but it does make sense: r17688.

Mon, 18 Dec 2017 13:25:10 GMT - Antoine Martin:

r17697 is a more complete end-to-end fix: the client tells the server which RGB modes it can handle for webp.

This fixes the potential problem where the HTML5 client would be asked to decode a swapped-channels-webp image. This could happen if we had a server that fed "RGBX" (or "RGBA") to the encoder instead of "BGRX" (or "BGRA"). ie: maybe on a little endian arch?

Sat, 23 Jan 2021 05:31:16 GMT - migration script:

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