Anton Khirnov <[email protected]> writes: > On Mon, 02 Jan 2012 11:03:59 +0000, Måns Rullgård <[email protected]> wrote: >> Anton Khirnov <[email protected]> writes: >> >> > It's the same as av_vsrc_buffer_add_frame(), except it doesn't take pts >> > or pixel_aspect parameters. Those are read from AVFrame. >> > >> > Deprecate av_vsrc_buffer_add_frame(). >> > --- >> > avconv.c | 5 ++--- >> > doc/APIchanges | 5 +++++ >> > libavfilter/buffersrc.h | 9 +++++++++ >> > libavfilter/version.h | 11 ++++++++++- >> > libavfilter/vsrc_buffer.c | 17 +++++++++++++++-- >> > libavfilter/vsrc_buffer.h | 3 +++ >> > 6 files changed, 44 insertions(+), 6 deletions(-) >> >> [...] >> >> > +/** >> > + * Add a frame to the filtergraph s. >> > + * >> > + * @param frame frame to be added. >> > + * @warning frame data will be memcpy()ed, which may be a big performance >> > + * issue. Use av_buffersrc_buffer() to avoid copying the data. >> > + */ >> > +int av_buffersrc_add_frame(AVFilterContext *s, AVFrame *frame); >> >> Why does this name not have an avfilter_ prefix? >> > > avfilter_buffersrc_* is > a) a bit long
Can't argue with that, but it's not the only option. For example, dropping the buffersrc part (rendering avfilter_add_frame()) would make sense. The whole notion of exposing this as a filter to the caller is a bit weird since it is the only way of feeding data into the system. > b) the buffersrc part already specifies the namespace, no need to add > avfilter. We do the same in lavu and lavc (e.g. avfft.h). Those are different. Whereas the FFT functions have nothing to do with codecs, this function is an integral part of libavfilter. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
