[FFmpeg-devel] [PATCH] [2/??] [3/3] Filter graphs - Parser for a graph description
Vitor Sessak
vitor1001
Tue Apr 1 22:49:39 CEST 2008
Hi
Michael Niedermayer wrote:
> On Sun, Mar 30, 2008 at 01:50:51PM +0200, Vitor Sessak wrote:
(...)
>> static int query_formats(AVFilterGraph *graph)
>> {
>
> Now i dont think this belongs in the parser code ...
> There should be IMHO
> A. code for a filter graph (a single flat filter graph that is a filter graph
> is not a filter) If we ever see the need for having filter graphs be
> filters this can be added later as a filter easily. Not weirdly
> intermingled with everything else.
> B. the parser
This function is _not_ passed as a callback to AVFilter.query_formats
(but it was some svn revs ago). It is called by the code
(avfilter_graph_config_formats()) that tries to set a agreed upon filter
format for all filters.
The only thing that can be split is the general graph code
(avfilter_graph_add_filter(), avfilter_destroy_graph(),
avfilter_graph_config_formats(), etc) from the parser. If you think it
is a good idea, I'm not against it.
>
>
> [...]
>> char tmp[20];
>>
>> snprintf(tmp, 20, "%d", index);
> ^^
> sizeof
Agreed. But are you ok with the instance name/instance lookup logic here?
>
>
>> if(!(filterdef = avfilter_get_by_name(name)) ||
>> !(filt = avfilter_open(filterdef, tmp))) {
>> av_log(&log_ctx, AV_LOG_ERROR,
>> "error creating filter '%s'\n", name);
>
> The purpose of the context is so the user can associate it with some
> specific instance of something. using a global context defeats this.
Yes. Any suggestion?
>
>
> [...]
I'll look at the rest later this week.
-Vitor
More information about the ffmpeg-devel
mailing list