On 4/16/20, Josh Allmann <joshua.allm...@gmail.com> wrote: > On Tue, 14 Apr 2020 at 01:53, Josh de Kock <j...@itanimul.li> wrote: >> >> Hi, >> >> On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote: >> > Hi, >> > >> > On Sat, 24 Mar 2018 at 14:40, Josh de Kock <j...@itanimul.li> wrote: >> > > >> > > Signed-off-by: Josh de Kock <j...@itanimul.li> >> > > --- >> > > configure | 29 +- >> > > doc/APIchanges | 4 + >> > > doc/writing_filters.txt | 6 +- >> > > libavfilter/allfilters.c | 823 >> > > +++++++++++++++++++++++++---------------------- >> > > libavfilter/avfilter.c | 50 +-- >> > > libavfilter/avfilter.h | 29 +- >> > > libavfilter/version.h | 3 + >> > > 7 files changed, 489 insertions(+), 455 deletions(-) >> > > >> > >> > This is a couple years too late, but wanted to drop a note that this >> > particular API change was breaking : it made avfilter_register a >> > no-op. The consequence is that it's much more difficult to maintain >> > filters out-of-tree; preserving the old behavior without changes to >> > user code requires a special build of ffmpeg that has the filter >> > configured/compiled in. The recommended workaround of using >> > avfilter_graph_alloc_filter requires more effort to wire the filter in >> > explicitly. It also doesn't allow for conveniences such as using >> > avfilter_graph_parse, since there doesn't seem to be a way to make >> > filters accessible via avfilter_get_by_name outside of ffmpeg compile >> > time. >> > >> > If there is another workaround that I'm missing, please let me know, >> > or if there's some deeper rationale for the decision to disable this >> > feature. >> >> This was actually an intentional change, there was some trouble with how >> external codecs/filters/etc should be handled. >> >> Since this was an unsupported use-case which was quite sensitive to ABI >> the >> change was there to explicitly prevent people (ab)using the API like this. >> It >> was also to prepare for potentially a new API to implement this in a >> proper >> fashion (but as you can see this was never completed). >> >> I did begin working on this again a little while back but due to an >> unfortunate >> data-loss I will have to start from scratch to continue working on it >> (yes, yes >> 'where's your backup?' I know). It's likely to be something I will be >> working >> on in the future since I will be doing FFmpeg stuff again soon. >> >> There is also the discussion of 'do we want this?' from a more ideological >> perspective which we will have to re-discuss, maybe something like >> gstreamer is >> more suited for the majority of the use-cases (?). >> > > Thanks for the explanation Josh. For what it's worth, count me as > being at least one API user for which out-of-tree filter capability > would be very helpful. (And to preempt some other reactions, "use > gstreamer" is not really helpful for us either...) >
You must know that out of tree filters will never be supported. > Josh > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
