On Sun, Aug 10, 2014 at 2:25 PM, Kieran Kunhya <[email protected]> wrote:
> On 10 August 2014 11:25, Janne Grunau <[email protected]> wrote:
>> On 2014-08-10 04:17:09 +0100, Kieran Kunhya wrote:
>>> The Opus decoder in particular uses optimised float_dsp functions that 
>>> expect 32-byte alignment
>>> ---
>>>  libavcodec/avcodec.h |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>>> index 93aad35..5cbc175 100644
>>> --- a/libavcodec/avcodec.h
>>> +++ b/libavcodec/avcodec.h
>>> @@ -1880,7 +1880,7 @@ typedef struct AVCodecContext {
>>>       * avcodec_default_get_buffer() instead of providing buffers allocated 
>>> by
>>>       * some other means.
>>>       *
>>> -     * AVFrame.data[] should be 32- or 16-byte-aligned unless the CPU 
>>> doesn't
>>> +     * AVFrame.data[] should be 32-byte-aligned unless the CPU doesn't
>>
>> NAK. While this is technical true it is not an improvement. Just making
>> it a little less ambiguous by removing a correct value (16-byte
>> alignment is fine on ARM) makes this documentation good.
>>
>> It should read "should be aligned to the targets CPU SIMD maximal
>> required alignment."
>>
>> I'll add some some examples and will sent a patch later today.
>
> If vector_fmac requires 32-byte alignment (irrespective of cpu) then
> the API/ABI should reflect that.
> If not then vector_fmac should be changed.
>

I would think it only needs 32-byte alignment when it uses AVX,
because I don't see a reason why SSE would ever need 32-byte
alignment.
You could argue that it does then depend on the CPU, if you have one
that supports AVX it needs 32, otherwise only 16.

Regardless, I'm fine to just document it as 32 always.

- Hendrik
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to