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

[vmrsss]

On 19 Mar 2008, at 14:16, Michael Niedermayer wrote:
>> Then your term is a filtergraph of type 2 ---> 2 and can be written  
>> as:
>>
>>   !!!! (3,4,5,6,1,2) , filter1 * filter2 , (3,5,2,4,1,6)
>
> Instead of unnecesarily complicating the parser, there should be a  
> seperate
> filter doing the permutation.
> swap=3:4:5:6:1:2
> being what i suggested in another mail.
> The same being true for split of course.
> split=3:1 might split the first input into 3 and pass the 2nd  
> unchanged

Precisely! That's exactly it: I used (3,4,5,6,1,2), you used  
swap=3:4:5:6:1:2, same stuff. And in fact strictly speaking you don't  
even need split, just duplicate numbers you want to copy:

	swap=1:2:1 has two stream input, outputs three streams: 1st, 2nd, and  
1st again

Only, you have to make sure the syntax is such you don't get confused  
as to how many inputs are there, otherwise you won't be able to check  
the well-formedness of the filter graph.

>> again, if I understood what you meant. My entire point is that this
>> syntax is modular, you can always define complex graphs  
>> incrementally.
>
> So can practically any other syntax. Note also we are discussing the  
> parser
> syntax ATM and quite a few things said in these mails, like swap,  
> split, perm
> filters have nothing to do with the parser and thus your arguments  
> involving
> their supperiority relative to a parser syntax without them are a  
> little off.


Look, I am only trying to compare the syntax you proposed with another  
one, I don't think I said anything at all about a parser, I am talking  
about languages. What I said is that your proposed syntax makes  
reusing filtergraphs (you have not written yourself) impossible  
without a (relatively complex) renaming operation, and that is a fact  
(*). That it makes binding for a particular (input) name dependent of  
the context of use, and that is another (bad) fact.

The thing left to say is that my only intention is to help make ffmpeg  
better. In my experience, the issues I mentioned above are serious  
difficulties, which one can avoid altogether. If however people don't  
like what I say, e.g. don't like a variable-less style and prefer to  
stick to a syntax involving explicit naming of pads, I am happy to try  
and help to get it right. (Which at the moment is not.)

Regards to all,
-vmrsss

(*) this should be clear from what I wrote previously, just in case  
I'll repeat it: the problem is that you cannot put together two  
previously defined graphs which happen to use a common name for their  
input pads, because you'll get confused as to which is which. You can  
of course modify one of the graphs by hands, don't think is  
particularly user friendly, then you'll have to provide a programmatic  
way to do so. It can be done of course, but it's not pretty, and it's  
not easy to explain to end users.