[FFmpeg-devel] [PATCH v3] lavfi: add new iteration API

Andreas Rheinhardt andreas.rheinhardt at gmail.com
Thu Apr 16 22:52:50 EEST 2020


Michael Niedermayer:
> On Wed, Apr 15, 2020 at 03:00:32PM -0700, Josh Allmann wrote:
>> On Tue, 14 Apr 2020 at 01:53, Josh de Kock <josh at 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 <josh at itanimul.li> wrote:
>>>>>
>>>>> Signed-off-by: Josh de Kock <josh at 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...)
> 
> I also would be in favor of some out of tree filter support.
> Let me explain why
> Some real ideas i was toying around:
> Some video source to simulate N body gravitational interaction and
> another idea was one to simulate the spread of an epidemic amongth
> points moving around ...
> 
> Iam not sure these things would belong in-tree
> And as things are, if anyone works on anything like such filters which
> are not generic multimedia filters. They run the risk to get their work
> rejected "doesnt belong in FFmpeg" and then that has no reasonable place
> to go.
> For me at least that risk has been a factor in moving some random ideas about
> writing one or another filter down my todo and rather work on something else
> 
> With "out of tree filter" support one would know that filters which are 
> outside the scope of multimedia would have a place to go.
> I think its also in the spirit of open source ...
> 
How would one create these out-of-tree filters without using internal
API and without extending the public API for this (thereby hindering
development generally)? E.g. all those function pointers in AVFilter
(and lots of other similar structures) are internal API and would be
made public in some way to support this.

- Andreas


More information about the ffmpeg-devel mailing list