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

[Michael Niedermayer]

On Wed, Mar 19, 2008 at 10:32:49AM +0000, vmrsss wrote:
> 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).

what you argue for is that
function(int, float){
    +=
    swap
    *=
    return 
}

is better and avoids problems with the names while

function(int a, float b){
    a+=b;
    b*=a;
    return b;
}

does not, this is obviously not true


[...]
> 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)

You are inventing some syntax and then complain about it, there is nothing
in the code nor in any mails from vitor suggesting anything like above.


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

swap-nop is a nightmare and very unintuitiv, if you need to swap more than 2.

a simple reorder filter like

swap=1:2:3:0 

is vastly more readable than

swap*nop*nop,nop*swap*nop,nop*nop*swap

and this is not an obscure case which wont occur in practice


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080319/2eaf3316/attachment.pgp>