[FFmpeg-devel] [PATCH 1/2] avcodec: Add interface to motion estimation

Michael Niedermayer michael at niedermayer.cc
Mon Aug 31 04:02:45 CEST 2015

On Sun, Aug 30, 2015 at 08:53:37PM -0400, Ronald S. Bultje wrote:
> Hi,
> On Sat, Aug 29, 2015 at 10:23 PM, Michael Niedermayer <michaelni at gmx.at>
> wrote:
> > From: Michael Niedermayer <michael at niedermayer.cc>
> >
> > This is needed for vf_mcfps, no codec related structs are part of the
> > public interface
> >
> > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > ---
> >  libavcodec/Makefile   |    2 +-
> >  libavcodec/avme.c     |  138
> > +++++++++++++++++++++++++++++++++++++++++++++++++
> >  libavcodec/avme.h     |   30 +++++++++++
> >  libavcodec/internal.h |    2 +
> >  libavcodec/snow.c     |   30 +++++++++++
> >  libavcodec/version.h  |    2 +-
> >  6 files changed, 202 insertions(+), 2 deletions(-)
> >  create mode 100644 libavcodec/avme.c
> >  create mode 100644 libavcodec/avme.h
> This is just wrapper code. It may fix an interface issue, but not the
> implementation issue. Can you make ME available without depending on snow?

the currently used ME code is part of snow, its a integral part of snow

> I can't imagine this is hard, don't we have an mpeg encoder, doesn't that
> use ME also?

snow has iterative OBMC based motion estimation, mpeg does neither
have iterative nor OBMC based ME

If someone extracts that out of snow then by the time mcfps maybe
will use its own motion estimation independant of libavcodec. Or
maybe it wont i dont know. but if anything then the ME code
used is not good enough, and the mpeg code is worse. Also the code
has different goals, libavcodec ME code tries to find good matches
for compression, it doesnt really truly matter if that matches the
actual motion but for frame interpolation a single wrong motion
vector can cause severe artifacts even if the block from it matches
pixel wise very well
so iam a bit reluctant to do API and implementation work around
the ME interface ATM, my time would be better spend in improving and
testing mcfps IMO

what seems the most pressing need to me is to make it easier for other
developers to test and work on the code. Putting it in the main
development branch aka git master would achive that. Which is why
iam suggesting to do that.
Do you agree ?

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- 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/20150831/7c79349f/attachment.sig>

More information about the ffmpeg-devel mailing list