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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
