Hi,

2011/7/10 Måns Rullgård <m...@mansr.com>:
> "Ronald S. Bultje" <rsbul...@gmail.com> writes:
>
>> From: Anton Mitrofanov <bugmas...@narod.ru>
>>
>> ptrdiff_t can be 4 bytes, which leads to the next element being 4-byte
>> aligned and thus at a different offset than intended. Using a fixed 8-byte
>> element for uv_off_px/byte fixes that.
>>
>> Signed-off-by: Ronald S. Bultje <rsbul...@gmail.com>
>> ---
>>  libswscale/swscale_internal.h |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
>> index b602541..7166667 100644
>> --- a/libswscale/swscale_internal.h
>> +++ b/libswscale/swscale_internal.h
>> @@ -345,8 +345,8 @@ typedef struct SwsContext {
>>      DECLARE_ALIGNED(8, uint64_t, v_temp);
>>      DECLARE_ALIGNED(8, uint64_t, y_temp);
>>      int32_t  alpMmxFilter[4*MAX_FILTER_SIZE];
>> -    DECLARE_ALIGNED(8, ptrdiff_t, uv_off_px);   ///< offset (in pixels) 
>> between u and v planes
>> -    DECLARE_ALIGNED(8, ptrdiff_t, uv_off_byte); ///< offset (in bytes) 
>> between u and v planes
>> +    DECLARE_ALIGNED(8, int64_t, uv_off_px);   ///< offset (in pixels) 
>> between u and v planes
>> +    DECLARE_ALIGNED(8, int64_t, uv_off_byte); ///< offset (in bytes) 
>> between u and v planes
>>      uint16_t dither16[8];
>>      uint32_t dither32[8];
>>
>> --
>
> What is this supposed to fix, and why are those things declared with
> extra alignment at all?  It makes no sense.

It fixes ptrdiff_t being 4 bytes on x86-32, and then dither16 being at
a different address. We hardcode the offset from dither16 somewhere
for use in assembly.

It could be argued that that is a bug, and I agree, but I haven't
gotten to fix that yet.

As for the alignment of int64_t, it may be a bug, but other pieces of
sws use that also so I just adhered to a common style.

Again, it could be argued that that is a bug, and I agree, but I
haven't gotten to fix that yet.

Ronald
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to