On Mon, 02 Jan 2012 13:19:41 +0000, Måns Rullgård <[email protected]> wrote: > 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.
This would make it inconsistent with the av_buffersrc_buffer() function which I've managed to sneak past you just recently. > > 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. Strictly speaking there's also this thing called vsrc_movie, but yeah, pretending it doesn't exist is better. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
