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

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180714/c5cbff96/attachment.sig>