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

[mypopy at gmail.com]

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?
Thanks.