Make sure that pOptions is initialized to the parameters that
the codec actually uses, not the ones that we initially tried
to set.
When calling SetOption to update the codec parameters, this may
cause a reset of the whole codec if e.g. the number of threads
differs from what is set within the codec itself.
If the number of threads was changed by the codec internally
when inited (e.g. changed from 0 to 1), WelsEncoderParamAdjust
may think the whole codec needs to be reset.
This fixes running EncoderInterfaceTest.TemporalLayerSettingTest
on machines where the detected number of cores is 1.
Previously, this test used whatever size was set in m_iWidth
and m_iHeight before, which depended on the order that the tests
were executed. When this test was the first one executed in the
EncoderInterfaceTest, the width and height were set to the max.
Instead of having the test behaviour depend on the test order,
set a specific size, just as InitializeParamExt and MemoryCheckTest
do.
This reduces the runtime of TemporalLayerSettingTest from 86 seconds
to 26 seconds, when run in valgrind.
There's little point in running the same test over and over for
a huge number of frames if it doesn't test much different things.
This reduces the runtime of EncoderInterfaceTest.* from 322 seconds
to 140 seconds, when running in valgrind.
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.
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.
