xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Opened 9 years ago

Closed 9 years ago

Last modified 6 months ago

#95 closed defect (fixed)

x264 encoding displays strange data in OpenOffice menus

Reported by: ahuillet Owned by: ahuillet
Priority: major Milestone:
Component: core Version:
Keywords: Cc:

Description

Hello,

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

Attachments (2)

screenshot_1333026482.jpg (143.4 KB) - added by ahuillet 9 years ago.
screenshot_1333093514.jpg (109.9 KB) - added by ahuillet 9 years ago.
VirtualBox? showing the problem at the right

Download all attachments as: .zip

Change History (11)

Changed 9 years ago by ahuillet

Attachment: screenshot_1333026482.jpg added

comment:1 Changed 9 years ago by 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.

comment:2 Changed 9 years ago by Antoine Martin

Status: newaccepted

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

Changed 9 years ago by ahuillet

Attachment: screenshot_1333093514.jpg added

VirtualBox? showing the problem at the right

comment:3 Changed 9 years ago by ahuillet

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

comment:4 Changed 9 years ago by Antoine Martin

Owner: changed from Antoine Martin to ahuillet
Status: acceptedassigned

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.

comment:5 Changed 9 years ago by ahuillet

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

comment:6 Changed 9 years ago by 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.

Last edited 9 years ago by ahuillet (previous) (diff)

comment:7 Changed 9 years ago by ahuillet

Resolution: fixed
Status: assignedclosed

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

comment:8 Changed 9 years ago by Antoine Martin

Milestone: current

Milestone current deleted

comment:9 Changed 6 months ago by migration script

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

Note: See TracTickets for help on using tickets.