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

Vitor Sessak vitor1001
Wed Mar 19 19:48:04 CET 2008


Hi Michael, Vmrsss

Michael Niedermayer wrote:
> On Wed, Mar 19, 2008 at 03:01:41PM +0000, vmrsss wrote:
>> Hi Michael,
>>
>> On 19 Mar 2008, at 14:00, Michael Niedermayer wrote:
> [...]
>>> [...]
>>>> As for the extra operator, you are right. However, I claim that in
>>>> order to allow reusable libraries of graphs in your syntax you will
>>>> have to provide a renaming operator, eg:
>>>>
>>>>  	{tmp1/in} (in)overlay(out) {tmp2/out}  = (tmp1) overlay (tmp2)
>>> You are inventing some syntax and then complain about it, there is  
>>> nothing
>>> in the code nor in any mails from vitor suggesting anything like  
>>> above.
>> Hmm, I might not have made myself clear: sure you haven't suggested  
>> anything like the above, I am arguing (and made a specific example in  
>> support) that you **have** to if you want to reuse filters.
> 
> Look, as there is nothing specified about "reuseable libraries" any
> system/syntax could be used, this clearly would allow to use "your syntax"
> as well thus this is a proper proof that it cannot be worse than "your
> syntax".

One problem about libraries of filter chains is that ideally they should 
be more flexible than just some graph hunk. Citing an example of what 
I'd like to be possible:

AVFilter avfilter_vf_rotate =
{
     .name = "rotate";
     .init = init;

     {some magic to make it a pseudofilter}
}

static void init(char *args, AVFilter *ctx) {
     int ang= atoi(args);
     switch (ang) {
     case 90:
         ctx->actual_filter = "transpose,vflip";
         break;
     case 180:
         ctx->actual_filter = "hflip,vflip";
         break;
     case 270:
         ctx->actual_filter = "vflip,transpose";
         break;
     else
         snprintf(ctx->actual_filter, "rotate_slow=%d", ang);
         break;
     }
}

But for doing this it would have to be a real filter, not something that 
pasted some code while parsing the chain.

It would allow all the flexibility you want, irrespective of the 
grammar. With this, your idea of graph library could be very easily 
done: a pseudo-filter that read a graph from a file (the library) and 
filter its input according to it (you could even specify as a second 
parameter which filter from the lib to use). Something like

(in) vflip, filterlib=myfile.txt:filter1, negate (out)

and in myfile.txt:
----------------
[filter1]
(in) split(T),rotate=40, (T2)picinPic(out); (T) scale=10:10 (T2);
----------------

The downside of all this is that I don't know a good way to implement 
it. Maybe using the code in avfiltergraph.c? (but I'm not happy either 
with the extra complexity of it...)

-Vitor




More information about the ffmpeg-devel mailing list