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

Reply via email to