[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Nicolas George]

Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
> Why do you always only accept or consider replies and arguments from other
> people when they exclusively fit the narrative you expect them to be? You're
> literally telling me what i said is worth nothing because it wasn't, or you
> assumed it wasn't, exactly what you wanted.

Your goal is to convince me, is it not? Well, I am telling you what kind
of argument is, I expect, necessary to do so. Is it not better that I
tell you instead of just arguing and letting you figure it by yourself?

It is not specific to me: if you want to convince anyone that A is
better than B, you have to address the reasons they have to think that B
is better than A. Otherwise, you just show them that you do not
understand the issue as well as them. The only thing about me is that I
am more conscious of these phenomenons than others, having spent so much
of my youth bikeshedding trivial matters on NNTP forums.

> I very much rather stick with a clean, longstanding and proven to work method
> that doesn't fill the public headers with ifdeffery, doesn't require extra care
> to avoid including a new special kind of volatile header that should only be
> used in a specific way, and that doesn't make future merges more a pain in the
> ass than they already are.

It is the second time you invoke the "longstanding and proven to work"
argument. Do you have any reason to think that my proposal does not
work? If not, withdraw this argument, because it only amounts to FUD.

For the merges, it has been a long time since merges on the lavfi
framework were mostly impossible. The fork has the scheduling in lavfi
completely broken.

> One indirection is not going to make a difference, even if we catalog it as a
> considerable disadvantage for the sake of this discussion. It's not enough of
> an argument in favor or replacing it with your design when you weight it with
> the above.
> 
> And "Aesthetics comes second" many times ends up in spaghetti and nigh
> unreadable and maintainable code, so lets try to not go that route if possible.
> Ask Ronald about his libswr simd refactor work if you want anecdotal evidence,
> or refer to avutil/common.h

As I said to Clément a few minutes ago, I remembered that my reasons for
choosing this solution were mostly readability. The extra efficiency is
just a bonus.

You seem to consider consistency in the code to be a goal by itself. It
is not, it is only a means to an end, the end being simplicity,
readability, maintenability.

The version with the private structure and an indirection leads to more
complex, less readable code. I say we throw consistency away, we go for
the simpler and more readable code, as it happens it is more efficient
too. And when everybody is convinced that it is satisfactory, we bring
back consistency the other way around, porting other parts of the code
to that new, better pattern.

I can explain why the indirection gives more complex code, but not right
now because the time I have is elapsed.

Regards,

-- 
  Nicolas George