[FFmpeg-devel] [GSoC] Motion Interpolation

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/92bd57f6/attachment.sig>