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.
Main window via X server.
Dialog via X server.
Main window via Xpra H.264 encoding
Dialog via H.264 encoding
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)
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.
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.
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.
Just remembered, are you still using --opengl=no
as per ticket:563#comment:9? Does it make any difference if you enable opengl?
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.
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.
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.
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:
swscale
or in the x264
encoder when processing the output of the csc step
cython
csc, and the problem might come back then.
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!
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)
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.
editing bug title
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.
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:
Distro | Version | swscale version | Notes |
---|---|---|---|
Ubuntu | 12.04 | 2.1.0 | buggy and now blocked - as we already do for avcodec ...
|
Ubuntu | 12.10 | 2.1.0 | OK |
Ubuntu | 13.10 | 2.1.0 | OK |
Ubuntu | 14.04 | 2.1.1 | OK |
Debian | Wheezy | 2.1.0 | OK |
Debian | Jessie | 2.1.1 | OK |
Debian | Sid | 2.1.1 | OK |
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!
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...
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/568