[FFmpeg-devel] [RFC] AVFilter Parser

[Michael Niedermayer]

On Tue, Mar 25, 2008 at 10:57:34PM +0100, Vitor Sessak wrote:
> Michael Niedermayer wrote:
> > On Tue, Mar 25, 2008 at 09:41:14PM +0100, Vitor Sessak wrote:
> > [...]
> >>>> 2- Let the ';' be interpreted like vrmsss's '*'
> >>>> Advantages, Disadvantages: Same as (1)
> >>> I don't think the choice of a symbol is important, it is the syntactic  
> >>> mechanisms to combine streams which are important. I suppose we can  
> >>> take everybody agrees on the key elements for that (functional or  
> >>> sequential composition of filters --meaning outputs of the preceding  
> >>> filter feed into inputs of the following one-- parallel or non- 
> >>> sequential composition, rearrangement of streams via appropriate  
> >>> namings, and feedback or looping). I don't think we are yet reached  
> >>> the perfect way to express these, but we're close.
> >> Maybe having both my ';' and your '*'. My ; is the last symbol in 
> >> precedence, yours is the first. Mine operates in chains with no unlinked 
> >>   pads. Yours operates in chains with one or more.
> > 
> > I think using () to override precedence is more natural than having 2
> > identical operators but with different precedence.
> 
> I agree in general. But in this case, I see this operator as two 
> different things: '*' means parallel processing, ';' means "end of a 
> description block - beginning of an unrelated description block". Note 
> also that if we extends the comma to link an arbitrary number of streams 
> (including 0), it can replace the semi-colon (but I think it would make 
> it more obfuscated).

how do you plan to do parallel processing of filter chains then?

example:
(scale,crop,brightness)*(contrast,rotate,flip)*(gray,scale,rotate,saturation) , picinpic*nop , picinpic

vs.

scale*contract*gray , crop*rotate*scale , brightness*flip*rotate, nop*nop*saturation , picinpic*nop , picinpic

I think its clear which is more readable ...



> 
> > Also maybe see eval.c which contains a expression parser with +-*/^()...
> > Not sure how usefull such a design would be for filters though ...
> 
> I'll have a look. But I made my suggestion based in clarity, not 
> easiness to parse.

to me it rather looks like a hack to cover a limitation of the parser.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080325/6dec4c2e/attachment.pgp>