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 <michae...@gmx.at> > wrote: > > > From: Michael Niedermayer <mich...@niedermayer.cc> > > > > This is needed for vf_mcfps, no codec related structs are part of the > > public interface > > > > Signed-off-by: Michael Niedermayer <mich...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
