When using a macro, the macro parameters get evaluated
multiple times, which means that the rand() value compared
actually isn't the same that is used as return value.
This makes sure that clipping works as intended for the
random tests.
1, ref_list_mgr_svc.cpp, Ln314: fix a wrong DeleteLTRFromLongList which should not be used under screen strategy
2, ref_list_mgr_svc.cpp, Ln910: remove the frame which is furthest in distance to the current frame in ref list
3, wels_preprocess.cpp: use scene LTR ref list when the current frame is scene LTR
-, ref_list_mgr_svc.cpp, Ln811: add DEBUG trace
reviewed at: https://rbcommons.com/s/OpenH264/r/870/
Interpreting data of one type via a pointer of a different type is an
aliasing violating. This means that a compiler optimizer's analyzer
can assume that data loaded into an array as uint32_t isn't related
to data read out from the same array as uint64_t, and e.g. reorder
loads/stores.
Since these structs are intentionally used to load data via pointers
of a wrong size, tell the compiler that these accesses may alias
other reads.
This fixes the GetIntraPredictorTest tests of WelsI4x4LumaPredV_c
and WelsI4x4LumaPredH_c. (The compiler optimizer did the wrong thing
as long as WelsFillingPred8to16_c or WelsFillingPred8x2to16_c were
inlined into the calling function.)
We don't use the ftime function on unix for filling SWelsTime anyway,
we fill the time and millitm fields manually.
On android, the sys/timeb.h header has been removed in the next
platform version (currently available in NDK r10 in the "L preview"
release), since this header and the ftime function have been removed
from the POSIX 2008 specification.
This fixes compilation when targeting the Android "L preview" release,
even when targeting the 32 bit ABIs.
This header is included by crt_util_safe_x.h whenever necessary (it's
all hidden in the SWelsTime struct) - code which does not explicitly
use things from sys/timeb.h shouldn't include it.
The logging level is checked in welsCodecTrace anyway.
Previously, error logging wasn't ever shown if the trace
level was set to WELS_LOG_ERROR (as it was by default),
since welsStderrLevelTrace required the message level to
be strictly lower than the trace level.
