[FFmpeg-devel] [GSoC] Motion Interpolation

[Michael Niedermayer]

On Wed, Jul 27, 2016 at 08:41:28AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Jul 27, 2016 at 7:20 AM, Michael Niedermayer <michael at 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 <rsbultje at gmail.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer
> > > > <michael at 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 at 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.

i like this idea alot!

thanks!

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160727/e872f94b/attachment.sig>