[FFmpeg-devel] [PATCH] [2/??] [3/3] Filter graphs - Parser for a graph description
Wed Mar 19 00:12:36 CET 2008
On Tue, Mar 18, 2008 at 11:13:25PM +0100, Aurelien Jacobs wrote:
> Michael Niedermayer wrote:
> > On Tue, Mar 18, 2008 at 09:29:51AM +0000, vmrsss wrote:
> > [...]
> > > (F) If I understood your examples correctly (which I might have
> > > not)`, there is still one missing ingredient: a feedback
> > > combinator, say !, which takes a filter with at least one input and
> > > at least one output stream and feeds back the first output to the
> > > first input. For instance, let's look at the examples you have been
> > > discussing in this thread:
> > >
> > > (1)
> > > > in --> scale --> crop --> picInPic --> rotate --> split --> out
> > > > ^ |
> > > > | |
> > > > delay<-------------------/
> > >
> > >
> > > becomes: scale,crop, !( picInPic, rotate, split, delay * nop ) --
> > > in fact the duplicated stream from split is fed to delay and
> > > delay's output is then fed back to picInPic (if that was the sense
> > > of the example, of course...)
> > How does the following work in your system?
> > (in0,tmp0,tmp2)filter1(tmp1,out0,tmp2);(in1,tmp1,tmp3)filter2(tmp3,tmp0,out1)
> If I understood correctly, this would look like this:
> !(swap*nop*nop, nop*swap*nop,
> * (swap, !(swap*nop,nop*swap,filter2))
> Well, not very beautiful, but at least, it is possible to describe such
> a filter chain.
interresting, lets add a 3rd one
And i wonder how many users will be able to do that ...
Also what about filters which can take a variable number of inputs/outputs?
> I suppose this would not exactly be a common filter chain, and I also
> suppose that filter1 and filter2 would naturally be designed so that
> their "natural" self-feedback in and out pad would be the first pad.
> This would highly simplify this filter graph. Here is an example of
> the exact same graph, with ideally ordered filters pad:
> !(swap*nop, !( !filter1 * !filter2, nop*swap*nop, swap,nop,nop))
> So IMO, this case just show that "mathematical" description allows
> to represent complex graph as well as the original description.
no, it does not, it shows that you could represent the given graph. Its
not a proof that all graphs can be represented. Though its quite easy
to proof that if you want ...
> But it don't show which one is the most simple/intuitive to
> describe commonly used graph (ie. graph with no feedback or at
> most one feedback).
Filter chains are just filter1,filter2,filter3 in either system.
More complex ones without feedback could look like
i think first wins
With one feedback
And with multiple feedbacks we have seen that the !*, description is
significantly less readable
So IMHO while the * operator might be worth considering, the way feedbacks
are handled is absolutely messy when there is more than 1 feedback.
Also i think ,* is unintuitiv |, might be better but then maybe not i dunno
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel