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

[Måns Rullgård]

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?

-- 
M?ns Rullg?rd
mans at mansr.com