Xpra: Ticket #95: x264 encoding displays strange data in OpenOffice menus

Hello,

See attached screenshot. I suspect that this might be a bug tied to a window not being even-sized.

Thu, 29 Mar 2012 13:09:52 GMT - ahuillet: attachment set

attachment set to screenshot_1333026482.jpg

Thu, 29 Mar 2012 13:53:35 GMT - ahuillet:

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.

Thu, 29 Mar 2012 16:28:57 GMT - Antoine Martin: status changed

status changed from new to accepted

please try r648, it disables x264 for OR (aka "transient") windows

Fri, 30 Mar 2012 07:47:18 GMT - ahuillet: attachment set

attachment set to screenshot_1333093514.jpg

VirtualBox? showing the problem at the right

Fri, 30 Mar 2012 07:47:49 GMT - ahuillet:

Unfortunately I can reproduce the problem on non-OR windows as well. See attached VirtualBox? screenshot.

Tue, 03 Apr 2012 10:30:00 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to ahuillet
status changed from accepted to assigned

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.

Tue, 03 Apr 2012 14:38:51 GMT - ahuillet:

I tried *enlarging* the image (w + 1) & 0xFFFE but it doesn't change the issue at all.

Tue, 03 Apr 2012 16:12:48 GMT - ahuillet:

I've dumped the data at various points:

the input to compress_image is not corrupted
after colorspace conversion to YUV, the data isn't corrupted
the compressed stream replays fine with mplayer (no corruption)
the compressed stream as dumped by decompress_image isn't corrupted
after decompression, the image isn't corrupted

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.

Wed, 04 Apr 2012 13:54:48 GMT - ahuillet: status changed; resolution set

status changed from assigned to closed
resolution set to fixed

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

Fri, 04 May 2012 10:00:58 GMT - Antoine Martin: milestone deleted

milestone current deleted

Milestone current deleted

Sat, 23 Jan 2021 04:45:24 GMT - migration script:

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