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.
All the tests of the line search (unoptimized and optimized)
use the exact same copypasted structure. Instead factorize this
into a test function which uses the provided function.
A 16x16 pixel block is copied to the destination pointed out by the
target motion vector. Since the motion vector is relative to the
center of the buffer, the upper bound of the range is size/2-16.
Previously we never used negative motion vectors, but there is no
reason not to test that direction. Therefore, the possible range
would be [-size/2,size/2-16]. Additionally pad this range with
INTPEL_NEEDED_MARGIN.
The block size is chosen randomly; if the block size is 16,
LineFullSearch_c will read a block with 16 pixels from kiMaxPos;
thus kiMaxPos cannot be larger than height-16, otherwise the calls
end up with reads out of bounds.
Previously, the same variable 'i' was sometimes declared within a for
loop and sometimes outside of the loop, all within the same function.
This avoids spurious warnings in MSVC 2005.
Add asm level functions
Add asm code for ME
Modify format
Add unit test for asm code.
Modify function name and format.
Remove unuse comment
Modify targets file
Add Macro protect for SSE41 funtion test
Modify according to review request.
