# [FFmpeg-devel] [PATCH] [2/??] [3/3] Filter graphs - Parser for a graph description

Fri Mar 21 16:28:50 CET 2008

```On 18 Mar 2008, at 23:06, Robert Swain wrote:
>> (tmp0,tmp1,in0)filter1(tmp0,tmp2,out0);
>> (tmp3,tmp2,in1)filter2(tmp3,tmp1,out1)
>>
>> !(swap*nop, !( !filter1 * !filter2, nop*swap*nop, swap,nop,nop))
>
> While this 'final' solution has reasonable notation in the vmrsss
> syntax, it would seem that, for complex filter graphs, linking inputs
> and outputs of filters that have multiple i/o pads may benefit from
> labeling. This is one case where I was able to visualise the graph far
> more easily with Vitor's notation. I'm still working on distilling the
> vmrsss notation from the graph... :)

(though I would not write the swap example like that, but introduce
some high-level abbreviation, eg a combinator !{n1,..,nk} meaning
feedback the i-th output to the ni-th input, which can be easily
expressed using ! and swaps: eg the example above wold be !{1,5,_,
3,2,_}( filter1 * filter 2 ) ).

One has to be careful about the details though. There is no free
lunch. In general, I would like to have a way to put any two filters F
and G next to each other, like in F * G (or F;G in Vitor's notation)
as well as a way to do some non trivial loops from outputs into inputs
of F*G.

How would one do that in the notation with names? One could take F and
G's code and explicitly cut-and-paste (and modify as necessary) in
order to obtain all distinct names if no loops are required, eg:

F' = (x0 y0 z0) filter1 (h0 k0 j0)
G' = (x1 y1 z1) filter2 (h1 k1 j1)

(and  here feel free to imagine that filter1 and filter2 are very
large chunks of code, eg think a big avisynth script) or the right
number of matches in the right position in case they are, eg:

F'' =  (tmp0,tmp1,in0)filter1(tmp0,tmp2,out0)
G'' = (tmp3,tmp2,in1)filter2(tmp3,tmp1,out1)

In my opinion -- and here I know that unfortunately Michael disagrees
-- I should not need to modify nor copy, and not even look at a
filter's body to use it; a filter should be a black box, I should only
need to know its interface, parameters and intended effects (as it
happens eg with C functions). Notice that I am not saying that the
"black box" approach is incompatible with a notation based names! You
can have both, but the current proposal needs some brushing up.