[FFmpeg-devel] [PATCH] [2/??] [3/3] Filter graphs - Parser for a graph description
Michael Niedermayer
michaelni
Wed Mar 19 18:23:47 CET 2008
On Wed, Mar 19, 2008 at 05:38:29PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 19, 2008 at 03:42:39PM +0000, vmrsss wrote:
> [...]
> > (*) 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.
>
> Ive provided a formal proof of equivalency already. You are trying to
> tell me that you dont understand math ? Because if you did you wouldnt
> argue against a proof ...
>
> Non formally i could again point you to C and say that it doesnt matter what
> arguments to a function are named nor what local variable names are used
> in a function. You do NOT solve anything by ommiting names, its just that
> you then have no names. Which will negativly affect readability.
>
> your system:
>
> my_overlay= "picinpic*nop*nop,picinpic*nop,picinpic"
>
>
> a system with names:
>
> (main, left, right, bot)my_overlay=
> "(main, left)picinpic,
> (right)picinpic,
> (bot)picinpic"
>
> use of it is the same either way:
> movie= main.avi
> *movie= left.avi
> *movie= right.avi
> *movie=bottom.avi , my_overlay
>
> And yes a system without names is surely shorter, and so would be C if one
> ommited variable names and used rules to implicitly select them. This doesnt
> make it a good idea though.
and here is yet another alternative syntax:
my_overlay(main, left, right, bot){
ret= picinpic(main, left)
ret= picinpic(ret, right)
picinpic(ret, bot)
}
my_overlay(movie:main.avi,
movie:left.avi,
movie:right.avi,
movie:bottom.avi)
Thus we have the following syntax classes
1. Chain based
swap, !(nop*picInPic , swap , picInPic , denoise)
or
(tmp)picInPic , (in2)picInPic , denoise(tmp)
2. infix/prefix based
T= denoise ((in1 picInPic T) picInPic in2)
3. function based
T= denoise( picInPic( picInPic(in1,T), in2) )
This also nicely shows how "clear and readable" the nop*swap chain is ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- 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/20080319/765c3bca/attachment.pgp>
More information about the ffmpeg-devel
mailing list