[FFmpeg-devel] On libavfilter: A Summary of Issues

[Stefano Sabatini]

On date Thursday 2012-10-18 16:22:41 -0600, Roger Pack encoded:
> Sorry late joining to the party...
[...] 
> If the goal is to provide filters that programs like mplayer/VLC/FFmpeg can use,
> that would seem to be a different target than a full fledged
> filter/scripting system, like
> AviSynth is.

Please define what filter/scripting system means. Also I believe that
scripting is beside the objectives of FFmpeg. Scripting layer should
be written on FFmpeg, for example through automatic building of a
filtergraph, given the input features. Note that could be done through
an high-level component (e.g. a smil demuxer which parse the SMIL, and
builds a filtergraph accordingly).

> Is the goal to be as flexible/user friendly as avisynth, or to provide
> filters for other programs?
> 
> I guess the OP is saying that if you try and become like AviSynth, it
> could speed adoption,
> since AviSynth does some "community friendly" things like easier
> scripting (though still basically
> creating a filtergraph) and simplified development.
> 
> At the same time, FFmpeg itself would benefit from some AviSynth like
> abilities, for instance, I
> have no idea how to do the equivalent of something like following in
> one command in FFmpeg:
> 

> a = movie('input', :from => 10:00, :to => 10:30)

movie="input:sp='10:00':t=30" [v1];

(the time option is not yet implemented, or we could implement an
"upto" option)

> b = movie('input2')

movie="input2" [v2];

> c = fade_in(a, b, :seconds => 10, :overlap => 5)

we have no fade in at this point, also I don't know how this really
works, but it could be something like:
[v1][v2] fadein=??? [tmp1];

> d = add_overlay(c, :from => 1:00 => to: 200)

again I don't know what this means, but what we lack in this case is
an enable parameter, which could be:
overlay=...:enable=gte(t,60)*lt(200)

These are easy extensions, but I can't read people's mind, so if there
is a *specific* suggestion, a feature request is welcome (a patch
would be even better).
 
> At the same time, I'd also note that libavfilter *is* getting better,
> for instance, there's actually
> a wiki page about for filters now, and the concat filter was added
> recently, etc.
> 
> So it's improving.  Maybe this discussion will spur improvemenet.
> 
> > So you may ask why libavfilter was conceived and implemented in the
> > first place?
> >
> > Well there are several reasons: one reason was to reduce the
> > dependency on external projects (an ffmpeg which needs to link against
> > avisynth or another framework for cropping or padding would suck
> > hard), we wanted/needed to simplify application code (resampling,
> > padding, rescaling with as few hacks as possible in the ff*
> > tools/application code), we wanted to provide a filtering *and* high
> > level *internal* library (for having a consistent framework, and
> > leverage the cababilities already included in the codebase, e.g. DSP
> > utils).
> 

> So is it just to have a high quality internal library, or does it want
> to become "as useful as AviSynth"?

We never set "as useful as AviSynth" as an objective, let me note that
avisynth was Windows-only until recently (still it is?). Sure we can
add features to lavfi as long as they don't clutter the already
complex framework. I don't see many design flaws in lavfi which make
impossible to implement some of the avisynth features. It has a
different syntax, so people used to avisynth "scripting" won't like
it.

> If it just wants to be a high quality internal library, maybe somebody
> should write an AviSynth plugin that can
> access/use FFmpeg's filters.  Just sayin' :)

Sure that would be welcome.
-- 
FFmpeg = Fast and Faithless Multipurpose Perfectionist Enchanting Gargoyle