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

[vmrsss]

Hi Vitor and everybody

On 18 Mar 2008, at 17:45, Vitor Sessak wrote:
> Maybe in my messages I wasn't clear, but in my syntax it is well  
> defined
> also (examples follow).

I didn't mean your syntax is intrinsically ill-defined (hope you  
didn't take offence). I meant is incompletely defined: (that is, it  
needs more "rules" and "conventions") when you name an input you don't  
know which one it is. You have to make a convention (say it's the  
first available), which can then be rather clumsy to keep up with. For  
instance:

> This may be irrelevant for overlay, but certainly it
>> is for other filters, eg picInPic. With the syntax I propose, the two
>> versions would be:
>>
>> 	nop*(movie_src=test.avi, vflip), picInPic
>
> Which in my syntax is
>
> movie_src=test.avi, vflip, (in)overlay(out)

here (in) refers to overlay's 2nd pad, just because of the context it  
is used in. If I take the same term T=(in)overlay(out) in other  
context (in) may refer to a different pad: eg, if I consider T in  
isolation, (in) refers to the 1st input. But if I write (tmp)T, then  
again it refers to the 2nd.

This mixed implicit/explicit naming can become confusing and error- 
prone, and requires a lot of house-keeping. **Most*importantly**, if  
you use explicit names (aka labels, tags, ...) you are making it more  
difficult for yourself to use "libraries" of pre-defined graphs (it is  
more or less as though in order to invoke a C function from a library  
you needed to use exactly the names --not the types-- of the formal  
parameters the original coder used).

> But there is one difference. If we consider that a filter has a "main"
> input (the one who get input from a long filter chain) and a "main"
> output, in my syntax:

I don't think the idea of a designed main input or output is very  
elegant (though there are in the literature some examples); in  
particular I think it is not flexible enough if you want to empower  
your users to write libraries of reusable, complex graphs.


> Well, for me it is not yet clear which syntax is the best. For me, the
> strong points of your syntax is that it is elegant and need no labels.
> It's drawbacks are, in my opinion, that the syntax of the '!' is a bit
> ugly, it need one more operator more than the other syntax ('()*,!'
> against '(),;') and may be a little harder to learn.

The syntax of ! is of course not imposed upon us. (Incidentally,  one  
would normally use * instead  --reminiscent of Kleene's star operator,  
which is a form of feedback-- and use some form of x (times) or ||  
(parallel) for parallel composition (ie putting graphs next to each  
other)

As for the extra operator, you are right. However, I claim that in  
order to allow reusable libraries of graphs in your syntax you will  
have to provide a renaming operator, eg:

  	{tmp1/in} (in)overlay(out) {tmp2/out}  = (tmp1) overlay (tmp2)

to allow some flexibility, and so there you are, number of operators  
matched. In my view, the place where "my syntax" is clumsy the use of  
"swap" to put inputs and outputs in the right order for the next  
filter: this can be done more flexibly with names but -- as I have  
tried to argue in my message -- the price to pay is very high; on the  
other hand, swap is conceptually simple, brings no overheads in terms  
of house-keeping, and is fool-proof.

Sorry for the delayed answer -- I am travelling, and stumbled into  
hotels with very poor internet connectivity. I will reply to all other  
messages in this thread as soon as I can.

Regards.