[FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.

[mypopy at gmail.com]

On Mon, Jul 23, 2018 at 2:33 AM Marton Balint <cus at passwd.hu> wrote:
>
>
>
> On Tue, 17 Jul 2018, mypopy at gmail.com wrote:
>
> > On Sun, Jul 15, 2018 at 1:03 AM Michael Niedermayer
> > <michael at niedermayer.cc> wrote:
> >>
> >> On Sat, Jul
> >> 14, 2018 at 12:04:46PM +0200, Marton Balint wrote:
> >> >
> >> >
> >> > On Sat, 14 Jul 2018, Michael Niedermayer wrote:
> >> >
> >> > >On Fri, Jul 13, 2018 at 10:51:00AM +0200, Marton Balint wrote:
> >> > >>
> >> > >>
> >> > >>On Thu, 12 Jul 2018, mypopy at gmail.com wrote:
> >> > >>
> >> > >>>On Thu, Jul 12, 2018 at 12:43 AM Marton Balint <cus at passwd.hu> wrote:
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>On Wed, 11 Jul 2018, Jun Zhao wrote:
> >> > >>>>
> >> > >>>>>use pixelutils API for sad in motion estimation.
> >> > >>>>
> >> > >>>>Does it make sense to improve this code? I thought a superior and faster
> >> > >>>>approach was a result of 2017 GSOC task:
> >> > >>>>
> >> > >>>>https://docs.google.com/document/d/1Hyh_rxP1KGsVkg7i7yU8Bcv92z0LIL4r-axpoKfvMFk/edit
> >> > >>>>
> >> > >>>>Maybe that code should be merged back, and any further optimalization
> >> > >>>>should be done based on that code, no?
> >> > >>>>
> >> > >>>>Thanks,
> >> > >>>>Marton
> >> > >>>>
> >> > >>>Hi, Marton:
> >> > >>>
> >> > >>>Yes, now I try to improve the
> >> minterpolate, and after use perf
> >> > >>>profiing the commands:
> >> > >>>
> >>
> >> > >>>./ffmpeg -i a.ts -filter_complex
> >> > >>>"minterpolate=mi_mode=mci:mc_mode=aobmc:vsbmc=1" -f null /dev/null
> >> > >>>I found the hotspot is:
> >> > >>>- get_sbad_ob
> >> > >>>- get_sbad
> >> > >>>- get_sad_ob
> >> > >>>- bilateral_obmc
> >> > >>>- set_frame_data
> >> > >>>
> >> > >>>So, as my plan, I will try to use sse2/avx2
> >> > >>>Scatter/Gather, optimized
> >> > >>>sad function (use pixelutils API)
> >> > >>>in  get_sbad_ob /  get_sbad /  get_sad_ob first, for  set_frame_data
> >> > >>>case, maybe need to use Scatter/Gather SIMD instruction.
> >> > >>
> >> > >>That is great, all I am saying we should avoid diverging the two brances
> >> > >>(FFmpeg branch, and GSOC 2017 branch), and try to merge back GSOC2017 if it
> >> > >>can be done with reasonable amount of work before optimizing code, otherwise
> >> > >>the GSOC2017 branch will rot and we will lose the result of the GSOC task.
> >> > >>
> >> > >>>
> >> > >>>But if some guys have done some improve task in this case, I think
> >> > >>>based on the pre-existing work is the better way.
> >> > >>
> >> > >>Michael was the mentor, maybe he can chip in on what should be done here.
> >> > >
> >> > >talk with the author/student who wrote the code, not me :)
> >> >
> >> > Well, his not active here,
> >>
> >> yes but last i heared from him, he was interrested in continuing this project
> >> i think ive not heared much from him after that but i  now see that there is a
> >> small commit in his repo from 2018 so he is not completely inactive.
> >> I think you should talk with him
> >>
> >>
> >> > and the question is if his work is ready for
> >> > mainline inclusion or not, and if he has done enough valuable work during
> >> > GSOC that its worth working on mainlining it.
> >>
> >> He certainly did valuable work. Looking now at the ML, it seems the more or
> >> less last thing on the ML was the RFC/Discussion thread about libmotion.
> >> In that everyone wanted to dictate the design, and all that was contradicting
> >> each other.
> >> If you want to work on unifying this entangled bikeshed ball of conflicting
> >> oppinions, that surely is very welcome. Important is that it ends in something
> >> that is practical and high quality.
> >> Personally i think the author should be given more authority in the design.
> >> But again, please talk with the author of this code
> >> I dont remember everything in as much detail about this ...
> >>
> >> also ive added him to the CC
> >>
> >> Thanks
> >>
> >>
> > Now the minterpolate/libmotion auther didn't give a feedback or
> > sugesstion, so I will update patch 1/2  (just add SSE2/AVX2 sad_32x32)
> > with some perf data and hold on the patch 3 about minterpolate, any
> > other comments?
>
> I checked the "libmotion" series, and it seems they are in
> debug/development state and the commits are not clean, so some heavy
> refactoring is needed before applying them anyway.
>
> Do what you prefer, snow codec based motion compenstaion is an additional
> algorithm to the existing code anyway as far as I see.
>
As my point, I prefer  improve current minterpolate filter first, then
we can try to refactor the  "libmotion" series, Done Is Better Than
Perfect, any other comments or suggestion?