[FFmpeg-devel] [PATCH] [2/??] [3/3] Filter graphs - Parser for a graph description
Robert Swain
robert.swain
Fri Mar 21 18:07:55 CET 2008
On 21/03/2008, vmrsss <vmrsss at gmail.com> wrote:
>
> 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.
What needs brushing up? I see no problem with the current pad naming
suggested syntax nor any obvious difference between this style and
variable names for arguments of functions in their definitions.
Imagine the outputs to be members of a struct that is the return of
the function in question, maybe.
I hope I'm not missing something obvious...
Rob
More information about the ffmpeg-devel
mailing list