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

vmrsss vmrsss
Wed Mar 19 16:01:41 CET 2008

Hi Michael,

On 19 Mar 2008, at 14:00, Michael Niedermayer wrote:
> 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

I see your point, and concerning the "better" I agree with you that it  
is to a matter of taste; more precisely my function would be

function(int, float){
    return 2;

which is not as bad as yours. However, I accept you might not like it.  
I suppose my point remains that  filter chain is a *dataflow*  
computation, you don't really need to refer explicitly to the streams  
by *name* as you do in a C function (and in fact in the current  
vfilters or in mplayer's vf you don't), you only need to connect the  
corresponding pads suitably,

However, concerning "avoid problems" part, I think I showed you what  
the problems are, don't think it's a matter of opinions, just a matter  
of sitting down and looking at it.

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

Hmm, I might not have made myself clear: sure you haven't suggested  
anything like the above, I am arguing (and made a specific example in  
support) that you **have** to if you want to reuse filters.

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

Agreed, and that's exactly the suggestion I made in my previous email!  
(Has it reached?) The point worth mentioning is that this is not an ad  
hoc filter, it's a short-hand for a number of swap and nops; it is a  
nice fact that all arises from only two very elementary filters. Given  
that, we don't need to use swaps and nops at all


More information about the ffmpeg-devel mailing list