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.
This fixes two separate issues.
First, with the MSVC _snprintf implementations, the return value
is negative if the buffer wasn't large enough - this would in
the worst case lead to making iBufferUsed negative, writing before
the start of the buffer.
Secondly, when both iBufferUsed and iBufferLeft are accumulated,
one can't do "iBufferLeft -= iBufferUsed;". As an example,
say the buffer is 100 bytes in total and iBufferLeft is 40 and
iBufferUsed is 60. If SNPRINTF then writes 5 more bytes to the
buffer, iBufferUsed would be 65, but if we now do
"iBufferLeft -= iBufferUsed;" then iBufferLeft would end up as
-25 even though there's 35 bytes left in the buffer to use.
Therefore, we use a separate variable to store the return value
from the latest SNPRINTF call. This is checked to make sure it
wasn't negative, and only this amount is added to iBufferUsed
and subtracted from iBufferLeft.
This is the same pattern used in codec/encoder/core/src/utils.cpp.
strftime never returns negative numbers, so those calls don't
need as much checking.
Checking iBufferLeft > iBufferUsed does not make sense, since
this would stop writing into the buffer alredy after the buffer
is half full, when there is less space left than has been used.
The right check is iBufferLeft > 0.
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.
The decoder used WelsMedian while the encoder used WELS_MEDIAN.
The former has two different implementations, WELS_MEDIAN was
identical to the disabled version of WelsMedian.
Settle on using the same implementation for both decoder and
encoder - whichever version of the implementations is faster
should be used for both.
All functions that are assigned to function pointers with this
typedef (WelsHadamardQuant2x2Skip_c and WelsHadamardQuant2x2Skip_mmx)
use int32_t instead of BOOL_T for the return value.
No code exists within the project for building such a trace library.
This also fixes building on OS X with -Wno-deprecated-declarations
removed, since this code contained calls to deprecated functions
within #ifdef MACOS, which now are enabled when building on OS X.
bundleloader.h, which is included if MACOS is defined, defines
inline functions that reference bundle loading system functions,
which requires linking to the core foundation framework.
Avoid requiring linking to extra libraries/frameworks if
NO_DYNAMIC_VP is defined.
Add a struct that matches the C++ interface vtable.
This requires that the C++ interface methods are declared to use
the same calling convention as normal C functions, and that the
C struct exactly matches the layout and ordering of the C++
virtual table - MSVC seemed to reorder methods if there were
overloaded methods.
This is required to make the order in the C++ virtual table
consistent in MSVC - previously the overloaded methods were
ordered differently in the vtable compared to the interface
declaration.
Commit f38111d76b updated these files
manually (based on older versions of them) to something not generated
by the current mktargets.py/sh, losing the compact pattern rules.
Currently this used the _MSC_VER && !WIN64 to enable the inline
assembly, which still tried to use this code on windows on arm.
Using _MSC_VER && _M_IX86 is enough since _M_IX86 is defined only
when targeting 32 bit x86, not for x64.
astyle was only run on .cpp files this time - already in
ff6b66917 where the style cleanup was done initially, not all
.h files seem to have gotten the same styling (rerunning astyle
on .h files at that commit produces a huge diff).
For the first encoded frame, is bEncCurFrmAsIdrFlag true
while bIdrPeriodFlag is false.
Previously, the scene detection code unnecessarily checked for
a scene change in the first encoded frame (where the reference
frame was an uninitialized frame), triggering valgrind warnings
about using uninitialized memory.
The same ifdefs are already used in the corresponding constructors,
so this just avoids a runtime/link time library dependency which
is practically unused in this build setup.
