[FFmpeg-devel] [PATCH] dsputil: add bswap16_buf()

[Jason Garrett-Glaser]

2010/6/17 M?ns Rullg?rd <mans at mansr.com>:
> Michael Niedermayer <michaelni at gmx.at> writes:
>
>> On Thu, Jun 17, 2010 at 06:34:04PM +0100, M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>
>>> > On Thu, Jun 17, 2010 at 11:43:44AM +0100, M?ns Rullg?rd wrote:
>>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>>> >>
>>> >> > On Thu, Jun 17, 2010 at 11:24:11AM +0100, M?ns Rullg?rd wrote:
>>> >> >> Mans Rullgard <mans at mansr.com> writes:
>>> >> >>
>>> >> >> > ---
>>> >> >> > ?libavcodec/dsputil.c | ? ?7 +++++++
>>> >> >> > ?libavcodec/dsputil.h | ? ?1 +
>>> >> >> > ?2 files changed, 8 insertions(+), 0 deletions(-)
>>> >> >>
>>> >> >> Is anyone fundamentally opposed to this? ?If not, can we please just
>>> >> >> apply it and figure out the required alignment later?
>>> >> >
>>> >> > without the alignment being documented its not possible to implement it
>>> >> > efficiently, thus useless
>>> >>
>>> >> No more useless than having a dozen copies of that loop scattered
>>> >> about the code.
>>> >
>>> > Sorry but you cant block badly needed changes without any constructive
>>> > comment on what is wrong with them so they could be fixed.
>>>
>>> You're the one doing the blocking here.
>>
>> you have done great work on arm optimizations and also the build system
>> but theres a limit to the amount of trolling attacks and fillibustering
>> that ill swallow
>>
>> its you blocking the code and everyone can just read
>> Re: [FFmpeg-devel] [PATCH] lavfi test for 1-1 filters pixel format output
>> to see that himself
>
> That's not blocking anyone but me. ?It works on native builds, which
> is what everybody else is doing.
>
>>> > And then on the other hand expect me to accept half digested new API
>>> > that due to lacking of 1 line of text cannot be implemented.
>>> >
>>> > please send code that is remotely close to the quality you expect from
>>> > people working on your scripts.
>>>
>>> The patch has exactly the same quality as the various loops it intends
>>> to replace. ?I'm tired of you imposing impossible perfection
>>> requirements on changes that may not be perfect, but still a huge step
>>> in the right direction. ?Why don't you (or others) help find all the
>>> places doing 16-bit block byteswaps instead?
>>
>> why dont you just add a 16byte alignmnet requirement to all arguments?
>> we will then find out once someone tries to use it at a point where
>> this cannot be met. And we wont block implementations in the meantime
>
> What if we find that this requirement can't always be met? ?What if
> optimised versions have been written by then?

We add a bswap_buf_unaligned version, obviously.

There's no such thing as too many function pointers.

Dark Shikari