[FFmpeg-devel] [PATCH 2/2] lavfi/avfilter: add avfilter_graph_get_filters_by_name() function
george at nsup.org
Fri Apr 25 09:58:02 CEST 2014
Le sextidi 6 floréal, an CCXXII, Lukasz Marek a écrit :
> TODO: update doc/APIChanges and bump minor.
> Allows to search for filters when instance name is not known.
> Signed-off-by: Lukasz Marek <lukasz.m.luki2 at gmail.com>
> libavfilter/avfilter.h | 12 ++++++++++++
> libavfilter/avfiltergraph.c | 20 ++++++++++++++++++++
> 2 files changed, 32 insertions(+)
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 0cc5274..c9428b1 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -1276,6 +1276,18 @@ AVFilterContext *avfilter_graph_alloc_filter(AVFilterGraph *graph,
> AVFilterContext *avfilter_graph_get_filter(AVFilterGraph *graph, const char *name);
> + * Get filter instances identified by filter name from graph.
> + *
> + * Returned array must be freed with av_free().
> + *
> + * @param graph filter graph to search through.
> + * @param name filter name (not unique in the graph).
> + * @param[out] count number of found filters. May be NULL.
> + * @return array of found filters or NULL on failure.
How is the caller suppose to distinguish between failure because of external
conditions (ENOMEM) and simply 0 filters being found?
And more generally, what is the use case? AFAICS, the function only uses
public fields. And most of the function's complexity comes from "useless"
bookkeeping and checks code. The actual work is done by just two simple
> + for (i = 0; i < graph->nb_filters; i++)
> + if (!strcmp(name, graph->filters[i]->filter->name))
I must say, as an application programmer, I prefer to write those two lines
in my code than calling a function for that. Just handling the failure case
and freeing the returned array takes more code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel