On Wed, Jan 31, 2018 at 7:03 PM, wm4 <nfx...@googlemail.com> wrote: > On Wed, 31 Jan 2018 11:52:14 +0000 > Mark Thompson <s...@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 https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224787.html Thank's. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
