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

[Michael Niedermayer]

On Mon, Feb 25, 2008 at 08:22:47PM -0500, Bobby Bingham wrote:
> 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.

yes
also this is VERY easy to do for the application, for example
myfilter="crop=123:345,scale=333:555"
-vf mirror,myfilter

could be supported by the app by nothing more than a simple string search and
replace

and even more complex things could relativly easily been done:

[tmp]myfilter="crop=123:345,scale=333:555,[tmp]picInPic"
-vf mirror,[anotherin]myfilter


The difference is working with strings instead of complicated graphs.
Also a bug in messing at the string level will be caught during filter
graph building, a bug in code which directly messes with the graphs will
likely lead to more fatal results.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080226/1d16eaca/attachment.pgp>