If the android test projects hasn't been built yet, the "make clean"
command will stop at "ant clean" (which fails since build.xml doesn't
exist yet). If this happens, one still would want to run the "make
clean" command to the end, cleaning up any possible intermediate object
files (e.g. from a build for a different platform).
This makes it easier for platform specific makefiles to add
things to some of them. (build/platform-android.mk already does this
for a few submodules, e.g. GTEST_INCLUDES and CODEC_UNITTEST_INCLUDES
already use +=.)
Most of the default parameters still are overwritten with hardcoded
values in FillSpecificParameters though, but this makes sure that
defaults are applied for any new fields at least.
These are never overridden by any assembler optimized versions.
(The assembler optimized intra predictor functions may use such
optimized code internally anyway.)
This avoids global writable data.
Make the tables const and keep a copy of the table in the
SWelsFuncPtrList struct instead, where any modifications to
the table only touch that individual instance of the codec.
This makes sure we don't accidentally return the same sequence
of random numbers multiple times within one test (which would
be very non-random).
Every time srand(time()) is called, the pseudo random number
generator is initialized to the same value (as long as time()
returned the same value).
By initializing the random number generator once and for all
before starting to run the unit tests, we are sure we don't
need to reinitialize it within all the tests and all the
functions that use random numbers.
This fixes occasional errors in MotionEstimateTest.
MotionEstimateTest was designed to allow the test to occasionally
not succeed - if it didn't succeed, it tried again, up to 100 times.
However, since the YUVPixelDataGenerator function reset the random
seed to time(), every attempt actually ran with the same random
data (as long as all 100 attempts ran within 1 second) - thus if
one attempt in MotionEstimateTest failed, all 100 of them would
fail. If the utility functions don't touch the random seed,
this is not an issue.
On 64 bit kernels, /proc/cpuinfo doesn't list the same old features
as on 32 bit kernels, since most of them are mandatory on 64 bit arm
systems, see [1] for details.
If running a 32 bit arm binary on such a kernel, we need to detect
the features slightly differently, either by using other names
listed in the Features field on these devices, by checking the
"CPU architecture" field and always enabling these if the architecture
is >= 8, or by parsing /proc/self/auxv or using the getauxval function.
[1] http://marc.info/?l=linux-arm-kernel&m=139087240101974
