[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