On Tue, 12 Sep 2017 11:40:55 +0200 Nicolas George <geo...@nsup.org> wrote:
> Signed-off-by: Nicolas George <geo...@nsup.org> > --- > doc/APIchanges | 3 +++ > libavfilter/buffersink.c | 10 ++++++++++ > libavfilter/buffersink.h | 12 ++++++++---- > 3 files changed, 21 insertions(+), 4 deletions(-) jamrial asked to clarify this, so here's some reasoning why I'm against it: The alternative would be using AVOptions, but AVOptions are clunky. Especially when setting things like lists of allowed formats or channel layouts. I don't like AVOption APis in general, but with those lists it gets seriously error-prone on the API user side. On the source filter side, AVBufferSrcParameters was recently introduced, so that alone is an indicator that a dedicated params struct makes sense, and that we shouldn't remove it. I would argue that there should be a av_abuffersink_parameters_set function, instead of using the really unsafe opaque init parameter. I'd also respect if we were to merge AVABufferSinkParams into AVBufferSinkParams, or if this were preparation for adding a similar but more general mechanism for both FFmpeg/Libav (non-AVOption of course), but I haven't noticed such plans. All in all, just deprecating/removing this would be a step backwards, and would force current users of this API to use more awkward API instead. There was also no good (or any) reason given _for_ removing the API. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
