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

Michael Niedermayer michaelni
Wed Mar 19 15:16:53 CET 2008


On Wed, Mar 19, 2008 at 12:11:12PM +0000, vmrsss wrote:
> On 18 Mar 2008, at 20:53, Michael Niedermayer wrote:
> > How does the following work in your system?
> >
> > (in0,tmp0,tmp2)filter1(tmp1,out0,tmp2); 
> > (in1,tmp1,tmp3)filter2(tmp3,tmp0,out1)
[...]
> So in our case, I would suggest we have a special syntax for  
> permutations (nothing more than filtergraphs in a predefined library).  
> Let's suppose we use (3,1,2) to express the permutation above -- in  
> general (k1, k2, ..., kn) would have in the 1st place the final  
> position of 1 (say k1); in the 2nd place the final position of 2 (say  
> k2); ... in the nth place the final position of n (say kn)). --- 
> Notice: there alternative and better ways to represent permutations;  
> this is just an example, it's not the right time to argue which one is  
> the most convenient for our application.---
> 
> 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


> 
> 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.

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/9d51b94b/attachment.pgp>



More information about the ffmpeg-devel mailing list