RetroSearch Browse

Thu Jan 4 12:24:31 CET 2007 · https://ffmpeg.org/pipermail/ffmpeg-devel/2007-January/027006.html

Hi,

On 1/3/07, Luca Abeni <lucabe72 at email.it> wrote:

> Filters can be "internal" (implemented in libavfilter itself) or
> external (implemented through wrappers to other libraries).

Here are a few more thoughts and concerns about the libavfilter design.

#1: it has to support filter chaining (i.e filter_a then filter_b
isn't the same than filter_b then filter_a). One should create an
empty filter chain where you can append/prepend filters. I don't know
if inserting filter at a defined position of the chain makes much
sense, seems overkill.

#2: one must be able to enable/disable filters at runtime.

#3: one must be able to append/prepend filters at runtime (think about
post-proc, deinterlacing or simply MPlayer's OSD menu).
Thus, it's a matter of:

av_filter_chain_apply() {
  ...
  while (filter->next)
    if (filter->state == enabled)
      av_filter_apply (filter);
  ...
}

#4 the filter registering API should be public. It will allows loading
external av filters through .so via dlopen(). Consider that some media
app require some av filter of their own to work or interact with the
player. If the filter is not (yet or for any reason) part of ffmpeg,
the player should be able to still register it. Otherwise, considering
it won't be shipped with the distro players, the media app will have
to shipp it's program with a customized version of the  player and
ffmpeg which is a not recommended nor desired.

Ben

-- 
"My life, and by extension everyone else's is meaningless."
Bender, Futurama

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://ffmpeg.org/pipermail/ffmpeg-devel/2007-January/027006.html below:

[Ffmpeg-devel] New/extended filter API discussion