[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.
andreas.cadhalpun at googlemail.com
Thu Nov 17 21:26:24 EET 2016
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
> 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.
More information about the ffmpeg-devel