#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)
Change History (11)
Changed 9 years ago by
| Attachment: | screenshot_1333026482.jpg added |
|---|
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
| Status: | new → accepted |
|---|
please try r648, it disables x264 for OR (aka "transient") windows
Changed 9 years ago by
| Attachment: | screenshot_1333093514.jpg added |
|---|
VirtualBox? showing the problem at the right
comment:3 Changed 9 years ago by
Unfortunately I can reproduce the problem on non-OR windows as well. See attached VirtualBox? screenshot.
comment:4 Changed 9 years ago by
| Owner: | changed from Antoine Martin to ahuillet |
|---|---|
| Status: | accepted → 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.
comment:5 Changed 9 years ago by
I tried *enlarging* the image (w + 1) & 0xFFFE but it doesn't change the issue at all.
comment:6 Changed 9 years ago by
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.
comment:7 Changed 9 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
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:9 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/95
copyleft 2010 - 2021
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.