[FFmpeg-devel] [PATCH] [2/??] [2/3] Filter graphs - Basic infrastructure

[Bobby Bingham]

On Tue, 26 Feb 2008 01:33:34 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Mon, Feb 25, 2008 at 01:11:02PM -0500, Bobby Bingham wrote:
> > On Sun, 24 Feb 2008 12:58:20 +0100
> > Vitor Sessak <vitor1001 at gmail.com> wrote:
> > 
> > > Hi
> > > 
> > > Michael Niedermayer wrote:
> > > > On Sat, Feb 16, 2008 at 12:44:04PM +0100, Vitor Sessak wrote:
> > > >> See $subj.
> > > >>
> > > > 
> > > >> /*
> > > >>  * filter graphs
> > > >>  * copyright (c) 2007 Bobby Bingham
> > > >>  *
> > > > [...]
> > > >> #include "avfilter.h"
> > > >> #include "avfiltergraph.h"
> > > >>
> > > > 
> > > >> extern AVFilter avfilter_vf_scale;
> > > >> extern AVFilter avfilter_vf_graph;
> > > >> extern AVFilter avfilter_vf_graphdesc;
> > > > 
> > > > this belongs in some header
> > > > 
> > > > 
> > > >> typedef struct AVFilterGraph {
> > > >>     unsigned filter_count;
> > > >>     AVFilterContext **filters;
> > > >>
> > > >>     /** fake filters to handle links to internal filters */
> > > >>     AVFilterContext *link_filter_in;
> > > >>     AVFilterContext *link_filter_out;
> > > >> } GraphContext;
> > > >>
> > > >> typedef struct {
> > > >>     AVFilterContext *graph;
> > > >> } GraphLinkContext;
> > > >>
> > > >> static int link_init(AVFilterContext *ctx, const char *args,
> > > >> void *opaque) {
> > > >>     GraphLinkContext *linkctx = ctx->priv;
> > > >>     linkctx->graph = opaque;
> > > >>     return !opaque;
> > > >> }
> > > >>
> > > >> /**
> > > >>  * Given the link between the dummy filter and an internal
> > > >> filter whose input
> > > >>  * is being exported outside the graph, this returns the
> > > >> externally visible
> > > >>  * link.
> > > >>  */
> > > >> static inline AVFilterLink *get_extern_input_link(AVFilterLink
> > > >> *link) {
> > > >>     GraphLinkContext *lctx = link->src->priv;
> > > >>     return lctx->graph->inputs[link->srcpad];
> > > >> }
> > > > 
> > > > Why are all the dummy filters needed? This looks kinda messy ...
> > > > Cant a filter graph just be a filter graph where the filters
> > > > directly link to the outside? If dummy filters really are
> > > > needed (i need a clear explanation for this first) then they
> > > > should at least be in their seperate vf_ files.
> > > 
> > > I think dummy filters were introduced to make a filter graph a
> > > filter like any other. This make all the rest of the filter
> > > framework simpler (no need to add graph handling code to
> > > avfilter_draw_slice(), etc). I'm cc'ing this to Bobby, this is
> > > the kind of design decision I think he can explain better than
> > > myself.
> > > 
> > 
> > Yes, this was the reason.
> > I agree that the dummy filters are ugly, but I thought it was worth
> > it to let them be treated as a sort of black box filter and not
> > complicate the api or applications too much to deal with them.
> 
> Could you or vitor summarize what exactly would become more complex
> without the dummy filters? Other filter systems like mplayers dont
> need such dummy filters.
> 
> Also an application which doesnt want to interface directly with a
> filter graph could always insert a fifo or whatever filter in between.
> 
> And if the goal is to somehow allow one graph to be inserted as
> filter into another then i plain dont understand what this is good
> for.
> 
> [...]

That was actually the goal. I was thinking about some applications
(video editors perhaps) where a user may build up a library of complex
filter graphs which each do some specific thing out of smaller filters.
By allowing a filter graph to be used inside another like any other
filter, it becomes trivial to chain them together, or even use them to
build larger filter graphs for their library.

Though in thinking about it now that you brought it up, maybe a filter
like that belongs more to the application which requires that use,
rather than in libavfilter itself.

-- 
Bobby Bingham
Never trust atoms.  Or anything made of atoms.
??????????????????????