[FFmpeg-devel] [PATCH] avcodec/motion_est: remove duplicate function
michael at niedermayer.cc
Fri Jan 25 00:49:20 EET 2019
On Thu, Jan 24, 2019 at 10:23:33PM +0100, Marton Balint wrote:
> On Sun, 20 Jan 2019, Michael Niedermayer wrote:
> >On Sun, Jan 20, 2019 at 07:35:18PM +0100, Marton Balint wrote:
> >>On Sun, 20 Jan 2019, Michael Niedermayer wrote:
> >>>On Sat, Jan 19, 2019 at 11:48:39PM +0100, Marton Balint wrote:
> >>>>Signed-off-by: Marton Balint <cus at passwd.hu>
> >>>>libavcodec/motion_est.c | 4 +--
> >>>>libavcodec/motion_est_template.c | 62 +---------------------------------------
> >>>>2 files changed, 3 insertions(+), 63 deletions(-)
> >>>please check if the compiler optimizes the size constant out after this
> >>The compiler inlines the function before and after the change as well. I
> >>can't see notable changes in the disassembly of interlaced_search and
> >>h263_mv4_search. Is this enough, or something else should be checked? I am
> >>not sure how...
> >If the inlined code is used with only one size value then its probably ok.
> >you could also put some marker with asm() in the code where size is used
> >and then look at the .s file generated if the size is optimized out or
> >still read as a variable
> I checked the .s file and a constant is pushed to the stack as the size
> parameter when funny_diamond_search is called in h263_mv4_search and
> So yes, the size parameter is still optimized as a constant in the touched
i guess its ok then
thanks for checking
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel