On Thu, 24 Jan 2019, Michael Niedermayer wrote:
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 <c...@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
change
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
interlaced_search.
So yes, the size parameter is still optimized as a constant in the touched
functions.
i guess its ok then
Thanks, applied.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
