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

[vmrsss]

Hi Michael,

	Thanks for this email, it really helps!

> You do NOT solve anything by ommiting names, its just that you then  
> have no names.

I suspect we might be talking across purposes, which makes us miss  
each other's point, and in fact we might both partly right (and both  
partly wrong). I understand from you code below:

> a system with names:
>
> (main, left, right, bot)my_overlay=
> "(main, left)picinpic,
>      (right)picinpic,
>        (bot)picinpic"
>
> use of it is the same either way:
> movie=  main.avi
> *movie=  left.avi
> *movie= right.avi
> *movie=bottom.avi , my_overlay


that you are now using a positional binding for parameters (viz the  
name of the parameter is irrelevant for invocation, only relevant  
inside the body). This is much better, not so far from what I meant, I  
have much fewer problems with it, and like its style: very readable.

Now, question: will you allow forms like this?

(main,second)my_overlay =
    (main,main)picinpic;
         (main) picinpic

If the answer is no, then this is just a convenient way to use  
numbered inputs and swaps, and I have no problems with it, good idea,  
I am all for it! (Advantage: more readable; disadvantage: the parser  
has to check the unique occurrence of each parameter in the body.)

If the answer is yes, then we need to ask whether this is good style,  
as it leaves a number of copy/split/kill operations implicit, but I  
agree it looks very natural and readable. More importantly, we need to  
ask: what happens in the following?

	my_overlay * my_overlay

Has this got two input streams (1 copied 6 times, 1 dropped), or four  
input streams (1st and 3rd copied 3 times each, the 2nd and 4th  
dropped)? If parameters can be used more than once in the filter body,  
then both answers are natural.

The point is that both forms should be allowed (with different syntax  
clearly), and my opinion is that if we answer "no" to the first  
question above (and therefore "four" the the second one), the we are  
close to a winner.

Regards to all,
-vmrsss

PS. Michael, would you please stop pinning me down to the nop*swap  
thing? This misrepresents my proposal, as I I have already explained  
twice that those are the elementary filters under the bonnet, the same  
as MOVs and JMPs in an assembly language, and I was not advocating  
their direct use for end users: I thought we agreed a form  
swap=1:2:3... was superior both in readability and to simplify the  
parser.