[FFmpeg-devel] [PATCH] libavfilter: constify filter list
mfcc64 at gmail.com
Thu Feb 1 20:35:01 EET 2018
On Wed, Jan 31, 2018 at 7:03 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Wed, 31 Jan 2018 11:52:14 +0000
> Mark Thompson <sw at jkqxz.net> wrote:
>> >> On the other side, you get rid of a field in AVFilter and avoid having to put some pointless boilerplate in a lot of places.
>> > The other solution is to initialize next pointer on
>> > avfilter_register_all() as before, add new iterate API, and deprecate
>> > both avfilter_register_all() and avfilter_next().
>> I guess having thought about this further my problem is that you appear to be writing a lot of new infrastructure for creating and updating the next links (with special generation code in configure and extra boilerplate on every filter) when the feature does not have any clear value. Once other functions are properly updated the only place where the next link is used is in avfilter_next(), which is only slowed down a little bit and would never be called in performance-sensitive code anyway. A new iterate API would be welcome but is mostly orthogonal - you aren't going to call that in performance-sensitive code either.
>> So, can we just drop the next links completely?
> Just as a comment on the side: if he changes that, I'd prefer of the
> next links are lazily initialized and only when using the old API. That
> would waste less memory (since writing the next link will trigger copy
> on write and in the worst case waste 4K (a page) per filter.
> (Personally I found the static next links rather neat, but yeah, maybe
> it's too much configure magic.)
I've posted a new patch
More information about the ffmpeg-devel