src/misc/picture.c allocates on 16 byte boundaries

[oviano]

...which causes avcodec to issue this warning:

"plane 0 not aligned, disabling direct rendering"

This is solved by changing the call to vlc_memalign in picture.c to align to 32 bytes instead, as per the patch below.


What does this all mean though?

1. what is direct rendering, in the context of using vmem?
2. are there some benefits in making the above change?
3. are there likely to be some side effects?

- Oliver

Code: Select all

From 22c82f5f70e84f72fb1326d3fe40f2968c4549d9 Mon Sep 17 00:00:00 2001 From: Oliver Collyer <ovcollyer@mac.com> Date: Mon, 7 Nov 2016 09:43:03 +0300 Subject: [PATCH 1/1] align picture buffers on 32-byte boundary --- src/misc/picture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/misc/picture.c b/src/misc/picture.c index 43207ce..f0f2146 100644 --- a/src/misc/picture.c +++ b/src/misc/picture.c @@ -62,7 +62,7 @@ static int AllocatePicture( picture_t *p_pic ) i_bytes += p->i_pitch * p->i_lines; } - uint8_t *p_data = vlc_memalign( 16, i_bytes ); + uint8_t *p_data = vlc_memalign( 32, i_bytes ); if( i_bytes > 0 && p_data == NULL ) { p_pic->i_planes = 0; -- 2.7.4

[Jean-Baptiste Kempf]

Do you see any performance change?

[oviano]

I haven't measured it. I expect any gain is marginal but I didn't like the warning and this gets rid of it so I presume it's not a bad thing.