Xpra trac archive

Xpra: Ticket #1423: native jpeg encoder and decoder

This will speed things up as we can use zero copy upload to the opengl backend directly as YUV data. The Python Pillow module just doesn't give us YUV...


Fri, 27 Jan 2017 06:11:02 GMT - Antoine Martin: attachment set

decode jpeg to RGB24

Fri, 27 Jan 2017 11:33:02 GMT - Antoine Martin: status, summary changed

Decoder added in r14863 + r14864, including build file updates and packaging. It paints directly using YUV if the opengl backend is present (otherwise it is unused). The new module should build out of the box on Fedora and centos. (opensuse will need a specfile update). It builds and runs fine on win32 as mingw-w64 already included everything we need. OSX has the libturbojpeg.dylib but not the matching pkgconfig file. I've created one by hand, it builds with warnings (probably an older version of libjpeg-turbo that we should update) - but the packaging step forgets it?

The encoder shouldn't be too difficult to add. I don't think we want to go through the pain of hooking our own CSC module so we'll use the built-in libjpeg-turbo version, which is probably plenty fast already. We should be getting zero-copy transfers from the XSHM, and we will be able to choose the subsampling based on the speed setting (which pillow did not do for us).

Mon, 30 Jan 2017 07:49:17 GMT - Antoine Martin: owner, status changed

Lots of fixes and related changes:

Also found a big bug in opengl backend: r14898 (not sure why it didn't bite before..)

Somewhat related:

Ready for testing: the jpeg decoder and encoder should now be faster. BUT, we were previously always using YUV420P with the pillow based encoder whereas now we choose the pixel subsampling based on the quality setting. So this may actually be slower at higher quality settings. (the opengl backend should paint more quickly as it paints using YUV directly, this may also affect the html5 client.. we may want to lower / adjust the jpeg quality settings for it)

Sat, 04 Feb 2017 08:33:37 GMT - Antoine Martin: attachment set

wiki rendered using the jpeg encoder

Sat, 04 Feb 2017 08:34:08 GMT - Antoine Martin: owner, status changed

Found some visual artifacts as part of testing for #1426: the xpra wiki loses its background colour: wiki rendered using the jpeg encoder.

Sat, 04 Feb 2017 12:12:20 GMT - Antoine Martin:

I suspect that the YUV output uses a different range than what we are used to with the avcodec and vpx output, so r14974 disables the YUV jpeg decoder until I can figure this out.

Mon, 06 Feb 2017 15:55:10 GMT - Antoine Martin:

This new codec help uncover 2 very serious issues, fixed in r14990 + r14991. Also needed r14989 to close the context and avoid a memory leak. Minor improvements in r15000, r15001 (opengl paint debugging)

Tue, 14 Feb 2017 13:48:07 GMT - Antoine Martin: owner, status changed

I give up on decoding to YUV: moved to #1438.

As of r15061 + r15062, we use this new decoder to RGB with both opengl and pixmap backings.

@afarr: this is mostly a FYI. This new codec is faster, that is all. You can see the compression performance server side with "-d compress", client side with: 

XPRA_JPEG_LOG_PERF=1 xpra attach --encodings=jpeg -d jpeg

I get: 

decompress_to_rgb: size=694x244, subsampling=444, colorspace=YCbCr
decompress jpeg to BGRX:  869 MB/s (   677344 bytes in 0.7ms)
decompress_to_rgb: size=694x244, subsampling=444, colorspace=YCbCr
decompress jpeg to BGRX:  461 MB/s (   677344 bytes in 1.4ms)

~400 to 900 MB/s is quite impressive.

Tue, 20 Jun 2017 20:01:42 GMT - J. Max Mena: status changed; resolution set

Noted that it's speedier and closing.

Sat, 08 Jul 2017 13:29:56 GMT - Antoine Martin:

r16228 fixes the python3 / cairo rendering which was broken by this change (jpeg decoder code should have been added to the superclass)

Sat, 23 Jan 2021 05:23:55 GMT - migration script:

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