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

[vmrsss]

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... :)

Yes I agree entirely, names are typically more readable than threading  
(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.

-vmrsss