[FFmpeg-devel] [PATCH] [2/??] [3/3] Filter graphs - Parser for a graph description
Wed Mar 19 16:42:39 CET 2008
On 19 Mar 2008, at 14:16, Michael Niedermayer wrote:
>> Then your term is a filtergraph of type 2 ---> 2 and can be written
>> !!!! (3,4,5,6,1,2) , filter1 * filter2 , (3,5,2,4,1,6)
> Instead of unnecesarily complicating the parser, there should be a
> filter doing the permutation.
> 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
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
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
> So can practically any other syntax. Note also we are discussing the
> 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
> 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,
(*) 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.
More information about the ffmpeg-devel