[FFmpeg-devel] [GSoC] Motion Interpolation

[Robert Krüger]

On Tue, Aug 30, 2016 at 3:13 AM, Davinder Singh <ds.mudhar at gmail.com> wrote:

> On Sat, Aug 27, 2016 at 6:15 PM Robert Krüger <krueger at lesspain.software>
> wrote:
>
> > [...]
> > what is the way to best contribute with test cases? I have two samples
> that
> > I use for testing, so far the results look very, very promising but there
> > are still a few artefact problems, so these could maybe serve as a good
> > test case. In some cases the artefacts almost certainly look like there
> is
> > a bug in motion vector calculation as a very large area suddenly begins
> to
> > move in which really only a small part is/should be moving.
> >
> > How do I make this available to you or other devs at this stage? Just
> trac
> > tickets or is it too early for that and you would like to work on this
> > differently? After all it is always a grey area, when this can be
> > considered solved, as it is a process of gradual improvements, so maybe
> > it's not well-suited for a ticket.
> >
> > Let me know. Happy to contribute samples and some testing time here and
> > there.
> >
>
> I'm currently testing support for unrestricted search area which can be
> used with EPZS, which has improved the quality.
> Once I send the patch you can test if it actually reduces the artifacts or
> doesn't make it worse.
>
>
OK, great. I'll test the patch when it's there.

Have you looked at the example with the moving wall? This really looks a
bit like a bug in motion vectors and I also had the impression that this
wasn't there when I was testing with earlier version from your branch but
cannot be 100% sure.


> For smaller details newer recursive algorithms should perform better. Like
> this one, https://www.osapublishing.org/jdt/abstract.cfm?uri=jdt-11-7-580
> which uses Modified 3D recursive search iteratively.
> So, at this point before any new algorithm is implemented, best way to test
> is to verify the experiments I do improves the quality for most of the
> samples or not.
>
>
Makes sense.


> One would like to compare PSNR, as it's hard compare each frame visually.
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193067.html (for
> better
> results, original sample should be 60fps, subsampled to 30)
> for visual testing, I used to transcode interpolate sample to images and
> compared them to original ones.
>
> Thanks for testing.
>
> Thanks for building this great filter.

Robert