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

Robert Swain robert.swain
Fri Mar 21 18:03:40 CET 2008


On 21/03/2008, vmrsss <vmrsss at gmail.com> wrote:
> On 19 Mar 2008, at 15:36, Michael Niedermayer wrote:
>  >> 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".
>
>
> Sorry, I don't understand that: how you can fail to see the added
>  value for something like libavfilter --- hopefully meant to be used in
>  as many applications as libavcodec --- of a modular filter-combination
>  language (think of C without functions, if you dare), but what do I
>  know?
>
>  Perhaps I've got the wrong picture in mind here, when I think of
>  libavfilter I don't think of the elementary crop,scale,aspect
>  sequence, but rather of large avisynth-like scripts, of collections of
>  user-contributed application-specific filters, etc: I think the same
>  way several users today share ffmpeg parameters to encode for, say,
>  ipod or psp without really understanding the details, they will
>  tomorrow share potentially complex libavfilter's filtergraphs.

I think being able to code filters which are filter graphs themselves
in a similar way (at a conceptually high level) to how people do
things in avisynth is a good thing. Using filters coded as part of
libavfi and essentially scripting other pseudo-filters on top.

However, I don't see the problem with using Vitor's syntax to do this
so I don't understand what you're arguing about.

Rob




More information about the ffmpeg-devel mailing list