[Ffmpeg-devel] [PATCH]: Too much alignment assumed by H264 decoder

[Loren Merritt]

On Sun, 25 Dec 2005, David S. Miller wrote:
> From: Michael Niedermayer
>
>>> for(y=0; y<4; y++){
>>>   *(uint64_t*)s->current_picture.motion_val[list][b_xy + 0 +
>>>     y*h->b_stride]= *(uint64_t*)h->mv_cache[list][scan8[0]+0 + 8*y];
>>>   *(uint64_t*)s->current_picture.motion_val[list][b_xy + 2 +
>>>     y*h->b_stride]= *(uint64_t*)h->mv_cache[list][scan8[0]+2 + 8*y];
>>> }
>>>
>>> The problematic access is the h->mv_cache[] one, h->mv_cache itself
>>> is 8-byte aligned, but the indexed value here is only 4-byte aligned.
>>>
>>> Is the problem at least a little bit clearer to folks now? :-)
>>
>> no it was always clear, fix b_stride so its a multiple of 2
>
> b_stride is not involved in the indexing of h->mv_cache[],
> and h->mv_cache[] is where the unaligned access is happening.
>
> The accesses to s->current_picture.motion_val[] are just fine.
>
> Any index into h->mv_cache[] which is a multiple of 2, but not
> a multiple of 4, will not be 8-byte aligned.  The first trap
> I get while decoding has us with scan8[0] == 12, so we end up
> indexing 14 + 8*y, which is the problematic index type (a multiple
> of 2 but not a multiple of 4).  The resulting address is 4-byte
> but not 8-byte aligned, and we trap on that.

int16_t mv_cache[2][5*8][2] __align8;

h->mv_cache[i][j] is size 4, so j only needs to be a multiple of 2, which 
it is.

--Loren Merritt