Hi, On Wed, Jul 27, 2016 at 7:20 AM, Michael Niedermayer <mich...@niedermayer.cc > wrote:
> On Tue, Jul 26, 2016 at 07:30:14PM +0000, Davinder Singh wrote: > > hi > > > > On Mon, Jul 25, 2016 at 9:55 PM Ronald S. Bultje <rsbul...@gmail.com> > wrote: > > > > > Hi, > > > > > > On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer > > > <mich...@niedermayer.cc > > > > wrote: > > > > > > > On Mon, Jul 25, 2016 at 04:05:54AM +0000, Davinder Singh wrote: > > > > > https://github.com/dsmudhar/FFmpeg/commits/dev > > > > > > > > > So, correct me if I'm wrong, but it seems the complete ME code > currently > > > lives inside the filter. I wonder if that is the best way forward. I > > > thought the idea was to split out the ME code into its own module and > share > > > it between various filters and the relevant encoders without a strict > > > dependency on avfilter/avcodec, or more specifically, AVCodecContext or > > > anything like that? > > > > > > Ronald > > > _______________________________________________ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > The code is almost ready to be shared, I just didn't move that yet. That > > makes changes difficult. mInterpolate will use those functions (which are > > currently in mEstimate) to find true motion. My plan is to move that code > > out of mEstimate to say, libavfilter/motion_estimation.c and can be > shared > > between multiple filters. Since that is general ME, I think it can be > used > > with encoding (with some changes). So, should I move it to libavutil > > instead? > > one thing thats important, > independant of where its moved, the interface between libs is part > of the public ABI of that lib and thus cannot be changed once it is > added. That is new functions can be added but they > cannot be removed nor their interface changed once added until the > next major version bump (which might occur once a year) > > its important to keep this in mind when designing inter lib interfaces You could - to address this - design it as if it lived in libavutil, but (until it actually is used in libavcodec) keep it in libavfilter with a ff_ function prefix to ensure functions are not exported from the lib. Once libavcodec uses it, move it to libavutil and change ff_ to av(priv?)_ prefix so it's exported. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel