swscale memalign

[totaam]

Issue migrated from trac ticket # 159

component: core | priority: minor | resolution: wontfix

2012-07-05 01:05:01: antoine created the issue

---

We still get this warning on both server and client:

[swscaler @ 0x2f4c200] Warning: data is not aligned! This can lead to a speedloss

• on the client, this can be solved by using GL client rendering (GL acceleration for client rendering #147) which will simply skip colourspace conversion

• on the server, we could use the patch attached to copy the buffer to a memaligned address before use but this would be quite expensive (copying a lot of data for every frame - let's try to get some numbers using the automated tests to compare) and duplicates what pixbuf is already doing in get_rgb_rawdata:

pixbuf.get_from_drawable(pixmap, pixmap.get_colormap(), x, y, 0, 0, width, height)

So here, the best solution is probably to just bypass gtk's pixmap/pixbuf and use the raw X11 drawable, hopefully this will be aligned... and if not, we can copy it just once.

[totaam]

2012-07-05 01:05:50: antoine uploaded file xpra-264-server-memalign.patch (2.0 KiB)

memcopy the pixel data so it is memaligned before we do the colourspace conversion

[totaam]

2012-07-05 01:06:47: antoine changed status from new to accepted

[totaam]

2012-07-05 01:06:47: antoine edited the issue description

[totaam]

2012-07-06 11:27:25: antoine commented

---

For the client, it looks like there is another solution, at least when we build ffmpeg ourselves (osx, static centos builds - and maybe even win32 if we wanted to, although this one is likely to be tedious and time consuming: ffmpeg win32 tutorial):

./configure --enable-memalign-hack (...)

Note, the docs apparently say (from this cvslog message):

docs: Don't recommend adding --enable-memalign-hack

But this does not seem to work IMO, otherwise, we are we getting all those warnings still?

[totaam]

2012-07-23 18:21:02: antoine commented

---

See also #168

[totaam]

2012-09-18 06:51:24: antoine commented

---

Another solution for the non-GL rendering case is to use ffmpeg's CODEC_CAP_DR1 feature:
''
with overridden get/release_buffer() (needs CODEC_CAP_DR1) the user decides into what buffer the decoder decodes and the decoder tells the user once it does not need the data anymore, the user app can at this point free/reuse/keep the memory as it sees fit
''
Then we can use our xmemalign to do the memory allocation in:

int (*get_buffer)(struct AVCodecContext *c, AVFrame *pic);
void (*release_buffer)(struct AVCodecContext *c, AVFrame *pic);

[totaam]

2012-09-19 09:10:27: antoine changed status from accepted to closed

[totaam]

2012-09-19 09:10:27: antoine changed resolution from ** to wontfix

[totaam]

2012-09-19 09:10:27: antoine commented

---

I've looked at the code and ffmpeg allocates memory aligned to 8 bytes and swscale wants it aligned to 16... dumb really. And duplicating all the code in the default get_buffer implementation just to change this alignment would be overkill/bug-prone.

Let's ignore it and rely on accelerated yuv rendering instead.

[totaam]

2013-06-22 07:30:15: antoine commented

---

More info: although the buffer stuff will get solved (at least for the client side, when going from the video decoder to the csc) by #345, this won't solve our problems because this warning comes from the rowstride... which is dictated to us by the X11 server when we create the XImage...