Xpra: Ticket #568: colors off with H.264 encoding on Ubuntu 12.04 server with swscale csc module

OSX Xpra client, Ubuntu Xpra server and calibre application.

My app shows different colors when using the H.264 encoding.

Attached are X_1 and X_2, screenshots of the app's main window and a dialog as exported to an X server. For encodings other than H.264, the Xpra colors match.

Also attached are H264_1 and H264_2, screenshots of the same windows using Xpra and H.264 encoding. The dialog window only changes after I move the mouse over a button or text field or I give focus to another window. It may have something to do with focus and/or highlighting.



Thu, 08 May 2014 14:08:03 GMT - Troy Cauble: attachment set

Main window via X server.


Thu, 08 May 2014 14:08:24 GMT - Troy Cauble: attachment set

Dialog via X server.


Thu, 08 May 2014 14:08:53 GMT - Troy Cauble: attachment set

Main window via Xpra H.264 encoding


Thu, 08 May 2014 14:09:32 GMT - Troy Cauble: attachment set

Dialog via H.264 encoding


Thu, 08 May 2014 14:11:06 GMT - Troy Cauble: component changed


Thu, 08 May 2014 14:13:12 GMT - Antoine Martin:

Oh, that's odd. Looks like a wiki/CSC bug.

Which CSC module are you using / are available? (output of xpra info | grep ".csc=") Does it help if you use a different csc module on the server? or on the client? (--csc-module option) Do you get the same thing with vp8? What is the exact version on the server? (inc full package version, and full distro version, arch, etc)


Thu, 08 May 2014 14:25:58 GMT - Troy Cauble:

On the server side:

window[2].encoding.pipeline_option[0].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[1].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[2].csc=None
window[2].encoding.pipeline_option[3].csc=None
window[2].encoding.pipeline_option[4].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[5].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[6].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[7].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[8].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[9].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[10].csc=codec_spec(cython)
window[2].encoding.pipeline_option[11].csc=codec_spec(cython)

VP8 and the other encodings look OK colorwise. (VP8 is slow to resolve text but that's probably just the way it is.)

If you need me to try different modules, please let me know the '--csc-modules' settings you want to see on each side.


Thu, 08 May 2014 14:31:55 GMT - Troy Cauble:

Ubuntu 12.04 xpra --version says xpra v0.12.4 package manager says 0.12.4-1 I see 0.12.5-1 available, will try.


Thu, 08 May 2014 14:36:34 GMT - Antoine Martin:

OK, so it isn't using CSC at all, or you would have seen something like this too:

window[2].csc=swscale

So there is not much point trying with --csc-module=cython on the server for example.


Hmmm, now I am thinking that it may well be the outdated x264 encoder in Ubuntu 12.04. We have plans to make statically linked versions of xpra for Ubuntu to workaround all the issues caused by the outdated codec libraries. Until I make a static beta build, I'm not too sure what to suggest. If I have time, I will try to reproduce in a VM. Unless afarr can beat me to it? There are beta builds for ubuntu already, but those are not statically linked yet.


Thu, 08 May 2014 14:40:37 GMT - Antoine Martin:

Just remembered, are you still using --opengl=no as per ticket:563#comment:9? Does it make any difference if you enable opengl?


Thu, 08 May 2014 14:50:58 GMT - Troy Cauble:

Crap. I must have missed it with my cut and paste.

window[2].csc=swscale
window[2].encoding.pipeline_option[0].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[1].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[2].csc=None
window[2].encoding.pipeline_option[3].csc=None
window[2].encoding.pipeline_option[4].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[5].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[6].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[7].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[8].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[9].csc=codec_spec(swscale)
window[2].encoding.pipeline_option[10].csc=codec_spec(cython)
window[2].encoding.pipeline_option[11].csc=codec_spec(cython)

Upgraded both sides to 0.12.5 and it still happens. Tried without --opengl=no and it still happens.

Are there really known issues with the codecs on Ubuntu 12.04? That's still an LTS release. It doesn't get new features, but nothing should be broken.


Thu, 08 May 2014 15:06:30 GMT - Antoine Martin:

Sorry, I should have told you that 0.12.5 is unlikely to fix this - there was almost no change in that release.

xpra --csc-module=cython on the server side is worth a try, but again, I believe vp8 would have used swscale too, so I can't see how that would make any difference.

We are making progress though: if the problem still occurs with opengl enabled client side, then the problem is almost certainly server side. The fact that no-one else has reported this, plus my frequent encounters with Ubuntu codec library issues... all point in the same direction. If you have access to a Windows or Linux client, you could try connecting with those to confirm. I will try to make this static Ubuntu beta build as soon as I can.


Thu, 08 May 2014 15:24:24 GMT - Troy Cauble:

xpra --csc-module=cython on the server side fixes the H.264 color problem!

But, I noticed

$ xpra info | grep ".csc="
window[2].encoding.pipeline_option[0].csc=None
window[2].encoding.pipeline_option[1].csc=None
window[2].encoding.pipeline_option[2].csc=codec_spec(cython)
window[2].encoding.pipeline_option[3].csc=codec_spec(cython)
window[3].encoding.pipeline_option[0].csc=None
window[3].encoding.pipeline_option[1].csc=None
window[3].encoding.pipeline_option[2].csc=codec_spec(cython)
window[3].encoding.pipeline_option[3].csc=codec_spec(cython)

Is that right? No window[2].csc= this time? Same results for --opengl=no and not.


Thu, 08 May 2014 15:35:49 GMT - Antoine Martin:

Ah. Interesting. What happens is that by specifying --csc-module=cython, we discard swscale which is faster, and so the winning option ends up being no csc (no match window[x].csc in grep - pipeline_option[0].csc=None) rather than cython. The server decides that no csc is better than slow csc.. which is right.

The only way to ensure that the csc module does get used in this case would be to start the server with:

XPRA_FORCE_CSC_MODE=YUV420P xpra start --csc-module=cython ...

Which would be very useful to test, because:


FYI: another option to force csc is to force picture downscaling:

XPRA_SCALING_HARDCODED=2:3 xpra start --csc-module=cython

The results won't be pretty!


Thu, 08 May 2014 22:39:14 GMT - Troy Cauble:

XPRA_FORCE_CSC_MODE=YUV420P xpra start --csc-module=cython ... worked with no color issues and

$ xpra info | grep ".csc="
window[2].csc=cython
window[2].encoding.pipeline_option[0].csc=codec_spec(cython)
window[2].encoding.pipeline_option[1].csc=codec_spec(cython)

Fri, 09 May 2014 05:30:54 GMT - Antoine Martin:

OK, so the issue is pretty much confirmed as a libav swscale bug in Ubuntu 12.04

Options are: disable swscale in those builds or make static builds. Either way, the changes to the debian build system are painful.


Fri, 09 May 2014 05:32:52 GMT - Antoine Martin: owner, status, summary changed

editing bug title


Fri, 09 May 2014 07:43:16 GMT - Antoine Martin: attachment set

shows the bug connecting to an Ubuntu 12.04 server by using the RGB test app


Fri, 09 May 2014 07:45:19 GMT - Antoine Martin:

As can be seen here: shows the bug connecting to an Ubuntu 12.04 server by using the RGB test app

The colors are swapped!:

Connecting to a Fedora 20 server instead and things work as they should. Using Ubuntu 12.04 as client, we detect the buggy version of libav and refuse to enable dec_avcodec (printing a big warning message instead), therefore preventing the use of video encodings.


Fri, 09 May 2014 08:42:57 GMT - Antoine Martin:

Workaround applied in r6415 (+ r6416, r6417 and r6418 fixing the buggy commit as I cannot test locally on my dev box..)

We detect the buggy version of libswscale (anything older than 2.1.1) and refuse to use it. This is a blunt instrument, especially as different versions of Debian / Ubuntu ship fixed versions of the library but with the same version number... oh dear:

DistroVersionswscale versionNotes
Ubuntu12.042.1.0buggy and now blocked - as we already do for avcodec...
Ubuntu12.102.1.0OK
Ubuntu13.102.1.0OK
Ubuntu14.042.1.1OK
DebianWheezy2.1.0OK
DebianJessie2.1.1OK
DebianSid2.1.1OK

Which means that this version detection blacklisting penalizes Debian Wheezy unfairly (and also Ubuntu 12.10 and 13.10, but those are so near their end-of-life that it doesn't matter).

I guess I could also add a platform test, and assume that only Ubuntu is buggy. In all fairness, I have ample empirical evidence to back this up!


Fri, 09 May 2014 10:36:27 GMT - Antoine Martin:

Added Ubuntu detection in r6423 to avoid degrading Debian Wheezy unnecessarily.

Tested OK on Ubuntu 12.04 and Debian Wheezy.

Will backport, all of it...


Fri, 09 May 2014 10:41:56 GMT - Antoine Martin: status changed; resolution set

Backported in r6425, will be included in 0.13.0 and 0.12.6 when released.

Closing this ticket, feel free to re-open if I have missed anything.


Sat, 23 Jan 2021 04:59:37 GMT - migration script:

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