This code checked whether one function pointer was non-null,
but the went on to call a different function pointer. Check
for the one that actually was called.
According to the calling convention, the registers q4-q7 should be
preserved by functions. The caller (generated by the compiler) could
be using those registers anywhere for any intermediate data.
Functions that use more than 12 of the qX registers must push
the clobbered registers on the stack in order to be able to restore them
afterwards.
In functions that don't use all 16 registers, but clobber some of
the callee saved registers q4-q7, one or more of them are remapped
to reduce the number of registers that have to be saved/restored.
This incurs a very small (around 0.5%) slowdown in the decoder and
encoder.
According to the calling convention, the registers q4-q7 should be
preserved by functions. The caller (generated by the compiler) could
be using those registers anywhere for any intermediate data.
Functions that use 12 or less of the qX registers can avoid
violating the calling convention by simply using other registers instead
of the callee saved registers q4-q7.
This change only remaps the registers used within functions - therefore
this does not affect performance at all. E.g. in functions using
registers q0-q7, we now use q0-q3 and q8-q11 instead.
Now calling WelsThreadJoin is enough to finish and clean up
the thread on all platforms.
This unifies the thread cleanup code between windows and unix.
Now all of the threading code should use the exact same codepaths
between windows and unix.
This avoids using a separate thread for handling pUpdateMbListEvent
events, and later allowing using the encode exit event on unix instead
of pthread cancellation.
This allows using the same codepath for both unix and windows
for distributing new slices to code to threads.
This also improves the performance on unix - instead of waiting
for all the current threads to finish their current slice
before handing out a new slice to each of them (where the threads
that finish first will just wait instead of immediately getting
a new slice to work on), we now use the same logic as on windows.
In one setup, it improves the performance of encoding from ~920 fps
to ~950 fps, and in another setup it goes from ~390 fps to ~660 fps.
(These tests were done with the SM_ROWMB_SLICE mode, which
heavily exercises the code for distributing new slices to the
worker threads.)
The extra WelsEventSignal call on windows where it isn't strictly
necessary doesn't incur any measurable slowdown, so it is kept
without any extra ifdefs to keep the code more readable and unified.
All users of the function passed the value corresponding to
"infinite", and the (currently unused) unix implementation of it
only supported infinite wait as well.
This unifies the event creation interface, even if the event
name itself is unused on windows, allowing use the exact same
code to initialize events regardless of the actual platform.
Some ifdefs still remain in the event initialization code, since
some events are only used on windows.
There is no point in doing a timed wait here - there's no work
that we can do if the wait timed out, and sleeping for 1 ms
inbetween doesn't help, it only adds potential extra latency
to reacting to threads that need more work to do.
Typedeffing WELS_EVENT as sem_t* makes the typedef behave similarly
to the windows version (typedeffed as HANDLE), unifying the code
that allocates and uses these event objects (getting rid of
most of the need for separate codepaths and ifdefs).
The caller of the function should not need to know exactly which
implementation of it is being used.
For the variants that don't support detecting the number of cores,
the pNumberOfLogicProcessors parameter can be left untouched
and the caller will use a higher level API for finding it out.
This simplifies all the calling code, and simplifies adding
more implementations of cpu feature detection.
The two different variants of the threadlib basically are
win32 and unix - use _WIN32 to check for this consistently,
instead of occasionally using __GNUC__ to enable the unix
codepath. (__GNUC__ is also defined on mingw, which still is
a windows platform and should use the _WIN32 code.)
The iFrameWidth/iFrameHeight fields are already aligned by the
SetActualPicResolution() function. Previously when iFrameWidth was
aligned directly in ParamBaseTranscode, this aligned value was used
to set iActualWidth/iActualHeight - losing the original, cropped
size.
This makes sure the output bitstream from the test of encoding
res/Static_152_100.yuv actually is cropped as it should.
On processors without HTT, WelsCPUFeatureDetect can't return
a number of cores but might still return a nonzero set of
CPU feature flags. Previously the nonzero cpu feature flag
indicated that cpuid worked and the encoder wouldn't use the
higher level API for getting the number of cores, even though the
number of cores was left at 1.
Previously the loop filter was unconditionally enabled
regardless of what encoder parameter was set. If using
SEncParamBase instead, the loop filter was always disabled.
Previously, these fields kept whatever value was set by
FillDefault. The corresponding fields were set properly within
sSpatialLayers, but the fields within the main struct were left
with the default values.
This doesn't change the hashes in the unit test, since these
fields don't seem to be used in the produced bitstream at all.
TRUE/FALSE has intentionally been left in use for the few
platform specific APIs that define these constants themselves
and expect them to be used, for consistency.
Instead of byteswapping a 32 bit word and writing it out as a
whole (which could even possibly lead to crashes due to
incorrect alignment on some platforms), write it out explicitly
in the intended byte order.
This avoids having to set a define indicating the endianness.
The code interprets an array of 4 uint8_t values as one uint32_t
and does shifts on the value. The same optimization can be
kept in big endian as well, but the shift has to be done in the
other direction.
This code could be made truly independent of endianness, but
that could cause some minimal performance degradaion, at least
in theory.
This makes "make test" pass on big endian, assuming that
WORDS_BIGENDIAN is defined while building.
This makes the code work properly on big endian.
The MC case is similar to how it's done in the encoder.
Neither of these should have any significant performance
impact.
This simplifies the code and makes the buffer size checks
more consistent. Additionally, the previous version wrote
the extra space character without checking if it actually fit
into the buffer.
strlen is not dangerous if the string is known to be null
terminated (and MSVC does not warn about its use either).
For the cases in the decoder welsCodecTrace.cpp, the string
passed to all WriteString instances is produced by WelsVsnprintf
which always null terminates the buffer nowadays.
Additionally, as the string was passed to OutputDebugStringA
without any length specifier before, it was already assumed to
be null terminated.
The file name parameter passed to DumpDependencyRec and
DumpRecFrame in encoder.cpp is always null terminated,
which was already assumed as it is passed to WelsFopen as is.
As for the encoder utils.cpp, the strings returned by GetLogPath
are string constants that are null terminated.
As long as WelsFileHandle* is equal to FILE* this doesn't matter,
but for consistency use the WelsF* functions for all handles
opened by WelsFopen, and use WelsFileHandle* as type for it
instead of FILE*.
Both encoder and decoder versions were functionally equivalent,
but I picked the decoder version (but added the static inline
keywords to it) since the encoder one was quite messy with a lot
of commented out code.
Instead of using "defined(MSC_VER) || defined(__MINGW32__)" to
indicate the windows platform, just check for the _WIN32 define
instead.
Also remove an unused codepath - the removed codepath would
only be used under the condition
"(defined(MSC_VER) || defined(__MINGW32__)) && !defined(_WIN32)",
and I'm not aware of any environment with MSVC or MinGW that
doesn't define _WIN32, thus this codepath never was used.
The following pattern is unsafe on all platforms:
n = SNPRINTF(buf, ...);
buf[n] = '\0';
On windows, the _snprintf variants return a negative number
if the buffer was too small, thus buf[n] would be outside
of (before the start of) the buffer.
On other platforms, the C99 snprintf function returns the
total number of characters which would have been written if
the buffer had been large enough, which can be larger than
the buffer size itself, and thus buf[n] would be beyond the
end of the buffer.
The C99 snprintf function always null terminate the buffer.
These invocations of SNPRINTF are within !WIN32, so we can
be sure that the SNPRINTF call itself already null terminated
the buffer.
