See attached screenshot. I suspect that this might be a bug tied to a window not being even-sized.
I can reproduce the issue with Libreoffice writer's main window. It appears that the few rightmost columns are corrupted with an odd width, but if you resize it to be even, the last block of pixels is actually corrupted as well (but only sometimes).
As a result: I believe we have a bug that isn't merely tied to odd width windows, since it's more than just the rightmost column that is affected but apparently a 3-or-so-wide block of pixels.
please try r648, it disables x264 for OR (aka "transient") windows
VirtualBox? showing the problem at the right
Unfortunately I can reproduce the problem on non-OR windows as well. See attached VirtualBox? screenshot.
Maybe this is because the rowstride is bigger than the picture width and it is not padded with zeroes? (should be easy to add C code to zero-out the "invisible" data - and we may not need to pad all of it, maybe only just up to the size used by x264's regions encoder? or is it first used by swscale?)
Testing the exact same setup with vpx may give us clues too.
I tried *enlarging* the image (w + 1) & 0xFFFE but it doesn't change the issue at all.
I've dumped the data at various points:
So the problem is in the final YUV420 -> RGB colorspace conversion.
Note: the corrupted zone seems to be exactly 4 pixels wide - actually it seems to be tied to modulo 16. If the width is divisible by 16, no corruption appears.
Apparently one has to use SWS_ACCURATE_RND to get swscale to do proper colorspace conversion without mangling the data. I'm a bit surprised but am starting to think that it might be interesting to merge our own (taken from another GPL source) CSC conversion code.
Fixed in r703
Milestone current deleted
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/95