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

[Andreas Cadhalpun]

On 17.11.2016 17:27, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Andreas Cadhalpun a écrit :
>> API changes in libavfilter are less of a problem, since not that many
>> programs use it. For example, the codecpar change has orders of magnitude
>> more impact.
> 
> I mostly agree. If people are ok with a sudden API change in lavfi, then
> I can rework my patch for that. But I want confirmation beforehand.

I don't think a sudden API change would be good.

> A scheduled API change would be better, but I do not want to wait for it
> to apply the patch, so you would have to accept a temporary solution.

I understand that and think a temporary solution would be OK if it's clear
that it will be removed in say 2 years.

>> However, ideally any incompatible API change should be coordinated with Libav.
> 
> I have been spurned in the past in my attempts to coordinate lavfi
> evolution with libav, I will not make efforts again for that.

That's sad. Maybe someone who uses the libavfilter API from both forks can
help and mediate in this matter?


On 17.11.2016 17:47, Nicolas George wrote:
> Here are three ideas to further reduce the drawbacks of my proposal.
> 
> All these are an alternative to the other suggestion of making
> AVFilterLink suddenly opaque.
> 
> 1. Filter the public headers before installing them, in order to
>    completely remove the internal fields. That way, the installed
>    headers are clean and not confusing for the users.
> 
> 2. In the public view of the structure, instead of just removing the
>    internal fields, replace them with "char reserved[0xE000];". That
>    would completely close the risk of overflow for applications that
>    incorrectly allocate the structure themselves (which I do not think
>    exist, actually).
> 
> 3. For compilers where we know that works, replace that 0xE000 with
>    SIZE_MAX*7/16, making the structure impossible to allocate, thus
>    forbidding the invalid uses of the API.

These are good ideas for mitigating the problems with your temporary
solution.

> Now, I realize that a lot of people will find these suggestions ugly.
> They are, there is no doubt about it. But this is irrelevant: the
> question is not "are they ugly?" but "are they uglier than the
> alternative?", and your opinion on the matter can only be relevant if
> you actually gave a solid amount of thought to the alternative.

Sure this is somewhat "ugly", but as long as it's only a temporary
solution I find that is not really a problem.

Best regards,
Andreas