For an int array[8][2] using &array[8][0] (which is an int*
pointing to the element beyond the last element of array)
triggers a "runtime error: index 8 out of bounds for type 'int[8][2]'"
from (Clang-)UBSan in the fate-vsynth(1|2|_lena)-snow tests.
I don't know whether this is really undefined behaviour or does not
actually fall under the "pointer arithmetic with the element beyond
the last element of the array is allowed as long as it is not
accessed" exception". All I know is that the code itself does not
read from beyond the last element of the array.
Nevertheless rewrite the code to a form that UBSan does not complain
about.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Modifying static storage must not happen because of multithreading
(except initialization of course), so add const to the pointed-to type
for pointers that point to static storage.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This code is in a performance critical section. AV_QSORT is
substantially faster due to the inlining of the comparison callback.
Thus, the increase in performance is worth the increase in binary size.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Fixes: asan_heap-oob_394322e_138_cov_4265020547_CVPCMNL1_SVA_C.264
Found-by: Samuel Groß, Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Inline functions declared without extern do not provide an external
definition in standard C99. This code only works because most
compilers do not implement the inline semantics correctly. With a
stricter compiler, linking fails with unresolved references to these
functions.
Declaring the functions extern inline works correctly with some
compilers while some others still fail to create external definitions.
For maximum portability, create a static inline version with an
externally visible wrapper for ff_get_mb_score. ff_epzs_motion_search
is so large that no sane compiler inlines it anyway, so there the
inline keyword can simply be dropped with no effect.
Signed-off-by: Mans Rullgard <mans@mansr.com>
The way this value is used, it should be an unsigned type.
While the numerical value has no meaning, unsigned wraparound
is relied upon.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
motion_est.o is now less than half its previous size.
No speedchange meassureable.
Originally committed as revision 22771 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Carl Eugen Hoyos cehoyos chez ag or at
original thread: [FFmpeg-devel] [PATCH] attribute_unused -> av_unused
date: 05/29/2007 01:23 PM
Originally committed as revision 9155 to svn://svn.ffmpeg.org/ffmpeg/trunk
Date: Mar 30, 2007 9:00 PM
Subject: Re: [Ffmpeg-devel] Motion Estimation in snow.c for Waevelet encoded frames (DWT)
Originally committed as revision 8579 to svn://svn.ffmpeg.org/ffmpeg/trunk
Andreas Rheinhardt
Andreas Rheinhardt
Michael Niedermayer
Marton Balint
Vittorio Giovara
Diego Biurrun
Ganesh Ajjanagadde
Michael Niedermayer
Anton Khirnov
Mans Rullgard
J. Bohl
Stefano Sabatini
Aurelien Jacobs
Carl Eugen Hoyos
Loren Merritt
Guillaume Poirier