[FFmpeg-devel] [RFC] AVFilter Parser
Vitor Sessak
vitor1001
Fri Mar 28 18:28:14 CET 2008
Hi
vmrsss wrote:
> On 26 Mar 2008, at 18:55, Vitor Sessak wrote:
>> I really can't see what is so special about feedback. It could be
>> written like
>>
>> (tmp in1 tmp4) filter0 (tmp out1 tmp2);
>> (tmp2 in2 tmp5) filter1 (tmp4 out2 tmp5);
>>
>> or using your syntax
>>
>> (a b), (<tmp a tmp4>, filter0, (tmp out1 tmp2)) *
>> (<tmp2 b tmp5>, filter1, (tmp4 out2 tmp5)), <out1 out2>
>>
>> Why is the extra complexity of the '[]' needed?
>
> Very good, thanks for this question, in fact that is where I started
> from. I then arrived to [ ... ] for the following reasons:
>
> The construct (x) is a binder (that is, a scoping construct like a
> function definition in C), so that in (x)F the name x is invisible
> outside F. (This is important, so other occurrences of x are not mixed-
> up accidentally.) But then, (tmp ... ) would make tmp invisible to the
> <tmp ... > construct outside its scope... In other words, (tmp ...)
> binds to the right, while we'd rather need it to bind to the left.
>
> Since I am unhappy about using the same symbol with two diametrically
> different meanings (it will always lead to confusion -- if you can't
> unify the notions (concepts), then keep the notations separated too),
> I conceived [ ... ], which is similar to ( ... ), but binds in the
> other direction. (In this sense, it is similar to the T>1 and T<1
> proposed by Michael.) So I started to play with forms like:
>
> (filter0 * filter1)[1 _ 4 3 _ 6]
>
> meaning: feed the 1st output back to the 1st input, let the 2nd pass
> through, feed the 3rd back to the 4th input, then the 4th back to the
> 3rd, let the 5th output pass through, and finally the 6th back to the
> 6th input. I find this quite readable, compositional and flexible; it
> doesn't need to be postfix -- of course! -- but that's not necessarily
> a bad choice, because it acts on the outputs to twist them backwards.
> I really like this: neat, simple, quick, essential, irredundant.
>
> But then, since the discussion on the list had manifested a clear
> preference for (explicit) names over (implicit) numbering, I
> translated the [ ... ] above into a named form of the exact same
> intended meaning (though necessarily more verbose and not as crisp):
>
> ( < a x b > filter0 * < c y d > filter1 ) [ a _ c b _ d ]
>
> this has two outputs (corresponding to the two _) and two free
> variables (x and y), because a, b, c and d are bound (from the right)
> by the [ ... ] construct. Finally, by pre-pending ( x y ) I bind the
> variables x and y to be respectively the 1st and 2nd input to the
> entire filter.
Ok, I understand. In my syntax it'll be
((a:1 b:3) filter0 * (c:1 d:3) filter1) (a:1 c:3 b:4 d:5)
or
((a x b) filter0 * (c y d) filter1) (a z c b w d)
(with 4 free variables, that should be set elsewhere)
Does in your syntax something like
<a> filter0, filter1 [a]
is invalid and should be written as
(<a> filter0, filter1) [a] ?
About the underscore, I find it interesting. Its only drawback is that
you can't use it to swap outputs...
> Now, frankly, the only reason to say that this is more complex or
> confusing than your proposed form at the start of this message is that
> you're used to yours. What my proposal does is mainly to give
> different notations to different concepts (input ( ... ), output
> < ... > and feeback [ ... ]), in a way that is full compositional (ie
> it doesn't run into syntactic non-sense nor unexpected ambiguities)
> under very simple formal rules.
>
> On 26 Mar 2008, at 19:44, Michael Niedermayer wrote:
>> seconded, i like vitors syntax a lot more than this artificial
>> seperation
>> into forward and feedback.
>
>
> Well, it was actually you who introduced forward/backwards (you called
> left and right then); I thought it was quite a good idea and took it
> up. Anyway, I think the separation of inputs/outputs/feedback is not
> artificial, is there also in Vitor's proposal (in for inputs, out for
> outputs, ...) for a good reason. Vitor prefers a in/out "reserved-id
> rule"; I don't care very much for it (among other things, it reminds
> of old times Fortran IV 50 years back :-)
It depends of the usage. I find
vitor at vitor$ ffmpeg -i file1.avi -i file2.avi -i file3.avi -vfilters '[a
b c] (a)(b) picInPic, (c) picInPic(d) [d]' file4.avi
and
vitor at vitor$ ffmpeg -i file1.avi,"a" -i file2.avi,"b" -i file3.avi,"c"
-vfilters '(a)(b) picInPic, (c) picInPic(d)' file4.avi,"d"
both too much verbose to my taste. I prefer
vitor at vitor$ ffmpeg -i file1.avi -i file2.avi -i file3.avi -vfilters
'(in1)(in2) picInPic, (in3) picInPic(out1)' file4.avi
On the other hand, I agree that
myfilter1 := "(in1) (in2) picInPic, (in3) picInPic (out1)"
is a bit fortranish, I'm not against something like
(a b c) myfilter1 (d) := "(a) (b) picInPic, (c) picInPic (d)"
and I have to admit that I have not thought a lot about the syntax for
defining user-defined filters (but I care to choose a syntax to the
command line that goes well with it).
> and prefer explicit import/
> export lists -- ie ( x y ) / < u v >.
>
>> the main difference between
>> the syntax and mine is that yours is stream based (and you link
>> streams)
>> and mine is filter based (and I define links between the filters).
>> In my
>> syntax "(in1),(out1)" or "(in1) (out1)" is a syntax error, filter
>> missing.
>
> No, hopefully I have clarified that in my previous email. I think the
> proposals are very similar. The main difference is ( ... ) and its
> interplay with < ... > that cannot be mimicked easily with only one
> operator -- viz. "< u >, F" can be seen as "naming" u the input of F,
> which is emphatically *not* the same as "(x)F" (a legal term with
> different semantics). Dually, "F, (x)..." can as "naming" x the output
> of F, not the same as "F, <x>" (which most of the times will be an
> illegal term).
Ok, now I think I understand your syntax. So now there are only two
things that differs between my syntax and yours:
1- To use or not different (and/or directional) labels for input/output
of individual filters
2- To use (a _ b) or (a:1 b:3)
Or is something missing??
> Summing up, my objective in this discussion is to make sure one can
> capture (I mean "get a handle to") inputs and outputs in any given
> filter (whether an atomic filter from avfilter, or a user-defined
> filter) in order to rearrange them when composing filters in complex
> graphs (using semicolon/star, comma and feedback, and no specific
> knowledge of the inner working of the filter). I think this is the one
> point that can be perfected in your current proposal, and there is a
> good case to experiment in your syntax with forms analogous to < ... >
> and ( ... ).
Well, this I don't understand. I was seeing the differences between the
two syntaxes more of a matter of taste. Can you give an example of
something that is particularly clumsy with my syntax and not with yours?
> Anyway, I think I have given this my best shot, which sadly appears
> not to be good enough for ffmpeg. So perhaps I should stop holding you
> people up, and try to find other ways to help the project.
Well, it's practically impossible to get to a consensus with a single
shot. :-)
Your opinions are useful. We've already got a consensus about several
things (including having a star operator) and the syntax proposals
(both, in my opinion) are getting each time better (and closer) with the
discussion.
> Cheers,
> -vmrsss
>
>
> PS. When I say the proposal are similar, that is modulo my current
> understanding --which I am aware might not be full-- of the follow
> issue: the scope of the intermediate labels tmp... in terms like:
>
>> (tmp in1 tmp4) filter0 (tmp out1 tmp2);
>> (tmp2 in2 tmp5) filter1 (tmp4 out2 tmp5);
>
>
> My understanding is that they are confined to the term they appear in.
> That is, if I have
>
> F1 = (in1 tmp) filter2 (tmp out1) and F2 = (in1 tmp) filter2 (tmp out1)
>
> then by writing F1 ; F2 I am not mixing up the two different loops
> represented by the same variable tmp. Right?
Yes.
-Vitor
More information about the ffmpeg-devel
mailing list