[FFmpeg-devel] [PATCH 2/3] Add section describing the filtergraph.

Mike Scheutzow mike.scheutzow
Fri Nov 12 21:14:15 CET 2010


Michael Niedermayer wrote:
> On Fri, Nov 12, 2010 at 01:32:55AM +0100, Stefano Sabatini wrote:
>> ---
>>  doc/filters.texi |   86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 86 insertions(+), 0 deletions(-)
> 
> This needs the attention of a english speaker
> 
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 4750d32..d1ae815 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -1,3 +1,89 @@
>> + at chapter Filtergraph description
>> + at c man begin FILTERGRAPH DESCRIPTION
>> +
>> +A filtergraph is a graph of connected filters.
>> +
>> +Each filter instance has a variable number of inputs and output pads,
>> +which are used to connect it with other filters. A filter with no
>> +input pads is called "source", a filter with no output pads is called
>> +a "sink". A connection between an output pad and an input pad of a
>> +filter is called a "link".
>> +
>> + at section Filtergraph syntax
>> +
>> +A filtergraph can be represented using a textual representation, which
>> +is recognized by the @code{-vf} and @code{-af} options of the ff*
>> +tools, and by the @code{av_parse_graph()} function defined in
>> + at file{libavfilter/avfiltergraph}.
>> +
>> +A filtergraph is represented by a list of ";"-separated filterchain
>> +descriptions. Each filterchain represents a sequence of connected
>> +filterchain node filters (each one called "filternode").
> 
> you define filter instances and then use undefined terms like 
> filterchain node filters and filternode instead
> ive not reviewed further, this IMHO needs more work
> 
> [...]

Stefano:

Why do you want to have two such similar concepts: a FILTERCHAIN and a 
FILTERGRAPH? Having both adds complexity and will increase user 
confusion. I don't understand the benefit this gives us.

It seems to me that requiring users to provide labels for any situation 
that is not a simple single-output-pad -> single-input-pad situation 
would be a good thing.


Mike Scheutzow




More information about the ffmpeg-devel mailing list