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/
The .align directive takes an argument in number of bits, i.e. the
actual alignment is 2^n. Previously building with binutils failed,
since 16 isn't a valid parameter to .align, the maximum is 15.
Thus, this makes the code try to align to 16 bytes, instead of aligning
to 65536 bytes.
This fixes building for android.
This also clears up the same mistake in the aarch64 code, even though
that one built just fine.
This file is built on its own from within the xcode projects,
even though it isn't necessary. Previously its contents was just
empty, but now a .syntax unified was added, which failed the build
when building for arm64.
Make this file a no-op, just like the other arm assembly source files,
unless HAVE_NEON is defined.
This is the default when building with the clang built-in assembler,
but not if using the external assembler - thus always specify it,
for clarity.
Also use the three-operand for of a sub instruction in BS_NZC_CHECK.
The same is already done in the gnu version of the macro.
This fixes building most of the arm assembly with Apple's external
assembler. While this isn't a necessary goal in itself, there's no
harm in doing this either.
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.
Since Xcode 5.1, the apple tools actually support using the
official, correct syntax for the ext instructions. This syntax
is already used in a number of places already - use it consistently,
and get rid of the compatibility hacks.
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
The pFeatureC pointer is an uint32_t pointer, therefore only
load 32 bits into ecx.
This avoids loading potentially uninitialized data into the upper
half of the rcx register, fixing valgrind warnings in some build
setups (depending on how the compiler chooses to layout the stack
in the calling function).
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.
Previously the assembly sources had mixed indentation consisting
of both spaces and tabs, making it quite hard to read unless
the right tab size was used in the editor.
Tabs have been interpreted as 4 spaces in most cases, matching
the surrounding code.
