This fixes warnings like the following:
codec/decoder/core/src/mv_pred.cpp: In function ‘void WelsDec::PredPSkipMvFromNeighbor(WelsDec::PDqLayer, int16_t*)’:
codec/decoder/core/src/mv_pred.cpp:158:51: warning: ‘iLeftTopXy’ may be used uninitialized in this function [-Wmaybe-uninitialized]
codec/processing/src/backgrounddetection/BackgroundDetection.cpp: In member function ‘void WelsVP::CBackgroundDetection::ForegroundDilation(WelsVP::SBackgroundOU*, WelsVP::SBackgroundOU**, WelsVP::CBackgroundDetection::vBGDParam*, int32_t)’:
codec/processing/src/backgrounddetection/BackgroundDetection.cpp:281:63: warning: suggest parentheses around operand of ‘!’ or change ‘|’ to ‘||’ or ‘!’ to ‘~’ [-Wparentheses]
For the possibly uninitialized variables, this is similar to earlier
commits 8be8fe17 and af2666fd.
Avoid X86_ASM ifdef.
Ideally, we may want to update all routines to average vertically
first, which would make this unnecessary. In the interim, this
enables the tests to run successfully on x86 without SSSE3 support
again.
X86 SIMD downsampling routines may, for convenience, read slightly beyond
the input data and into the alignment padding area beyond each line. This
causes valgrind to warn about uninitialized values even if these values
only affect lanes of a SIMD vector that are effectively never used.
Avoid these false positives by zero-initializing the padding area beyond
each line of the source buffer used for downsampling.
This fixes building for android differently than in f5e483ce.
On android, <cassert> isn't available in the normal include path,
only when the STL headers are available.
We intentionally avoid using STL within the main libopenh264.so, to
simplify dependency chains for users of the library (which otherwise
could run into conflicts if the surrounding app would want to use
a different STL implementation).
The previous fix only provided headers, not actually linking
against STL, so at this point it's not a real issue yet, but it's
still a very slippery slope towards accidentally starting relying on
STL within the core library.
Instead explicitly avoid using STL within the core library, by not
even providing the include path.
AFAICT, it is sufficient that the sample buffer has space for half
the source width/height. With the current sample buffer size, this
enables its use for resolutions up to 3840x2176.
Average vertically before horizontally; horizontal averaging is more
worksome. Doing the vertical averaging first reduces the number of
horizontal averages by half.
Use pmaddubsw and pavgw to do the horizontal averaging for a slight
performance improvement.
Minor tweaks.
Improve the SSSE3 dyadic downsample routines and drop the SSE4 routines.
The non-temporal loads used in the SSE4 routines do nothing for cache-
backed memory AFAIK.
Adjust tests because averaging vertically first gives slightly different
output.
~2.39x speedup for the widthx32 routine on Haswell when not memory-bound.
~2.20x speedup for the widthx16 routine on Haswell when not memory-bound.
Note that the widthx16 routine can be unrolled for further speedup.
Assume that data can be written into the padding area following each
line. This enables the use of faster routines for more cases.
Align downsample buffer stride to a multiple of 32.
With this all strides used should be a multiple of 16, which means
that use of narrower downsample routines can be dropped altogether.
Keep track of relative pixel offsets and utilize pshufb to efficiently
extract relevant pixels for horizontal scaling ratios <= 8. Because
pshufb does not cross 128-bit lanes, the overhead of address
calculations and loads is relatively greater as compared with an
SSSE3/SSE4.1 implementation.
Fall back to a generic approach for ratios > 8.
The implementation assumes that data beyond the end of each line,
before the next line begins, can be dirtied; which AFAICT is safe with
the current usage of these routines.
Speedup is ~8.52x/~6.89x (32-bit/64-bit) for horizontal ratios <= 2,
~7.81x/~6.13x for ratios within (2, 4], ~5.81x/~4.52x for ratios
within (4, 8], and ~5.06x/~4.09x for ratios > 8 when not memory-bound
on Haswell as compared with the current SSE2 implementation.
Keep track of relative pixel offsets and utilize pshufb to efficiently
extract relevant pixels for horizontal scaling ratios <= 8. Because
pshufb does not cross 128-bit lanes, the overhead of address
calculations and loads is relatively greater as compared with an
SSSE3 implementation.
Fall back to a generic approach for ratios > 8.
The implementation assumes that data beyond the end of each line,
before the next line begins, can be dirtied; which AFAICT is safe with
the current usage of these routines.
Speedup is ~10.42x/~5.23x (32-bit/64-bit) for horizontal ratios <= 2,
~9.49x/~4.64x for ratios within (2, 4], ~6.43x/~3.18x for ratios
within (4, 8], and ~5.42x/~2.50x for ratios > 8 when not memory-bound
on Haswell as compared with the current SSE2 implementation.
Keep track of relative pixel offsets and utilize pshufb to efficiently
extract relevant pixels for horizontal scaling ratios <= 4.
Fall back to a generic approach for ratios > 4.
The use of blendps makes this require SSE4.1. The pshufb path can be
backported to SSSE3 and the generic path to SSE2 for a minor reduction
in performance by replacing blendps and preceding instructions with an
equivalent sequence.
The implementation assumes that data beyond the end of each line,
before the next line begins, can be dirtied; which AFAICT is safe with
the current usage of these routines.
Speedup is ~5.32x/~4.25x (32-bit/64-bit) for horizontal ratios <= 2,
~5.06x/~3.97x for ratios within (2, 4], and ~3.93x/~3.13x for ratios
> 4 when not memory-bound on Haswell as compared with the current SSE2
implementation.
Keep track of relative pixel offsets and utilize pshufb to efficiently
extract relevant pixels for horizontal scaling ratios <= 4.
Fall back to a generic approach for ratios > 4. Note that the generic
approach can be backported to SSE2.
The implementation assumes that data beyond the end of each line,
before the next line begins, can be dirtied; which AFAICT is safe with
the current usage of these routines.
Speedup is ~6.67x/~3.26x (32-bit/64-bit) for horizontal ratios <= 2,
~6.24x/~3.00x for ratios within (2, 4], and ~4.89x/~2.17x for ratios
> 4 when not memory-bound on Haswell as compared with the current SSE2
implementation.
Use a combination of table lookups and pshufb to convert coefficients
to zero run/level format. Two 16-entry lookup tables are used for a
total of 192 bytes worth of tables. (The existing SSE2 version uses a
table of size 2048 bytes.)
Speedup is ~1.5x-3x as compared with the SSE2 version on Haswell (the
speedup is greater for input with many trailing zeros).
The use of popcnt makes it require SSE4.2. This can be replaced with
a small LUT and accumulation which would reduce the requirement to
SSSE3.
WelsQuantFour4x4Max_avx2 (~2.06x speedup over SSE2)
WelsQuantFour4x4_avx2 (~2.32x speedup over SSE2)
WelsQuant4x4Dc_avx2 (~1.49x speedup over SSE2)
WelsQuant4x4_avx2 (~1.42x speedup over SSE2)
Process 8 lines at a time rather than 16 lines at a time because
this appears to give more reliable memory subsystem performance on
Haswell.
Speedup is > 2x as compared to SSE2 when not memory-bound on Haswell.
On my Haswell MBP, VAACalcSadSsdBgd is about ~3x faster when uncached,
which appears to be related to processing 8 lines at a time as opposed
to 16 lines at a time. The other routines are also faster as compared
to the SSE2 routines in this case but to a lesser extent.
At lower bitrates, it is overall faster to conditionally do one block
at a time with SSE2 on Haswell and likely other common architectures.
At higher bitrates, it is faster to use the wider routine that IDCTs
four blocks at a time. To avoid potential performance regressions
as compared to MMX, stick with single-block IDCTs with SSE2. There
is still a performance advantage as compared to MMX because the
single-block SSE2 routine is faster than the corresponding MMX
routine.
Stick with four blocks at a time with AVX2 for which that appears
to be consistently faster on Haswell.
Move asm routines to common. Delete obsolete decoder routines.
Use wider routines where applicable.
~1.07x overall faster decode on a quick 720p30 4Mbps test on Haswell.
WelsSampleSatd16x16_avx2 (~2.31x speedup over SSE4.1 on Haswell).
WelsSampleSatd16x8_avx2 (~2.19x speedup over SSE4.1 on Haswell).
WelsSampleSatd8x16_avx2 (~1.68x speedup over SSE4.1 on Haswell).
WelsSampleSatd8x8_avx2 (~1.53x speedup over SSE4.1 on Haswell).
In 9cb4f4e8e21af, the error code returned from CheckIntraNxNPredMode
was changed - therefore, these return value checks, that look
for a specific error code, need to be updated accordingly.
This fixes crashes in DecodeCrashTestAPI.DecoderCrashTest
with some seeds.
Prior to 7bcb3ba4f4abf18a,
pCurLayer->sLayerInfo.pSliceInLayer[uiSliceIdx].iCountMbNumInSlice
was read after setting pCurLayer->sLayerInfo.pSliceInLayer to
the newly allocated, larger array. After this commit, it is read
before the array has been switched, and thus is read from the
old array (which only holds elements up to iMaxSliceNumOld, not
up to iMaxSliceNum).
This fixes reads out of bounds, and crashes in the test suite.
The "Video signal type present" information is written to the output
video file when it is created, and later is used by the decoder to
properly decode the compressed video data. The saved attributes
are:
- format type (PAL, NTSC, etc.)
- color primaries (BT709, SMPTE170M, etc.)
- transfer characteristics (BT709, SMPTE170M, etc.)
- color matrix ((BT709, SMPTE170M, etc.)
These modifications allow the client to specify these attributes
and, if specified, makes sure they are written to the output file.
The "Video signal type present" information is written to the output
video file when it is created, and later is used by the decoder to
properly decode the compressed video data. The saved attributes
are:
- format type (PAL, NTSC, etc.)
- color primaries (BT709, SMPTE170M, etc.)
- transfer characteristics (BT709, SMPTE170M, etc.)
- color matrix ((BT709, SMPTE170M, etc.)
These modifications allow the client to specify these attributes
and, if specified, makes sure they are written to the output file.
The "Video signal type present" information is written to the output
video file when it is created, and later is used by the decoder to
properly decode the compressed video data. The saved attributes
are:
- format type (PAL, NTSC, etc.)
- color primaries (BT709, SMPTE170M, etc.)
- transfer characteristics (BT709, SMPTE170M, etc.)
- color matrix ((BT709, SMPTE170M, etc.)
These modifications allow the client to specify these attributes
and, if specified, makes sure they are written to the output file.
We do four blocks at a time when possible, but need to handle
single blocks at a time for intra prediction.
~3.15x speedup over MMX for the DCT on Haswell.
~2.94x speedup over MMX for the IDCT on Haswell.
Returns diminish with increasing vector length because a larger
proportion of the time is spent on load/store/shuffling.
We do four blocks at a time when possible, but need to handle
single blocks at a time for intra prediction.
~2.31x speedup over MMX for the DCT on Haswell.
~1.92x speedup over MMX for the IDCT on Haswell.
Do some shuffling in load/store unpack/pack to save some
work in horizontal DCTs.
Use a few 128-bit broadcasts to compact data vectors a bit.
~1.04x speedup for the DCT case on Haswell.
~1.12x speedup for the IDCT case on Haswell.
Use a combination of instruction types that distributes more
evenly across execution ports on common architectures.
Do the horizontal IDCT without transposing back and forth.
Minor tweaks.
~1.14x faster on Haswell. Should be faster on other architectures
as well.
Use a combination of instruction types that distributes more
evenly across execution ports on common architectures.
Do the horizontal DCT without transposing back and forth.
Minor tweaks.
~1.54x faster on Haswell. Should be faster on other architectures
as well.
IDCT input is defined in such a way that the intermediate values
cannot legally overflow an int16_t. The use of random values
as input causes such overflows. This results in implementation-
dependent output depending on which type is used to hold
intermediate results. Use a template for the test reference
implementation to test implementations with different
intermediate representation.
Initialize input arrays with different random values.
Otherwise, the input to the DCT routines is effectively
all zero values after taking the difference.
Reduce duplication.
In dc2cbe4, the previous test for GetOption that succeeds when the
decoder is initialized was removed. Add a GetOption call for a different
option, now that DECODER_OPTION_DATAFORMAT is removed.
Before dc2cbe4, the DecoderConfigParam function returned early
since DecoderSetCsp signaled a failure, which is why the uninitialized
parameters weren't read before.
This fixes valgrind warnings about conditional jumps depending on
uninitialized values.
Use int32_t for a parameter that is always 0 or 1, because it is
negated. This fixes "warning C4146: unary minus operator applied
to unsigned type, result still unsigned" in MSVC.
Also add casts to silence MSVC warnings about "conversion from
'WelsEnc::cabac_low_t' to 'uint8_t', possible loss of data".
The generated code still is identical to before, on both gcc
and clang.
~2.4x speedup (time attributed to all CABAC-related fuctions) on x86
(Ivy Bridge) with GCC version 4.9.2 (Debian 4.9.2-10).
~1.3x overall faster encode on a quick 720p30 6Mbps test.
Reviewed at https://rbcommons.com/s/OpenH264/r/1347/
This reverts an unrelated part of e7e3b4f37f0.
Since the function still is declared as taking an int32_t parameter
in the header, changing the function implementation makes it end
up as a different function.
Currently the emscripten JavaScript environment for C/C++ programs
cannot do multithreading, and doesn't have a sysctl implementation
to get hardware CPU count. Hardcode to 1.
Using the Linux OS settings works, so not adding a platform file.
To build with emscripten (tested 1.30.0):
emmake make OS=emscripten ARCH=asmjs
The resulting libopenh264.so is LLVM bitcode which can be further
linked into an emscripten project for final JavaScript output.
When running "make install" the destination of pkgconfig/openh264.pc and
lib/libopenh264.a was hard coded to "lib". When building packages it
might be required to change the install location of those files to
the systems default library location (like lib64 or lib/x86_64-linux-gnu
for example).
This commit adds an additional make variable "LIBDIR_NAME" that allows
it to change the destination directory for those files.
Without setting LIBDIR_NAME the installation location is the same as before
(lib).
This adds some spacing to the version struct, so that astyle won't
need to change the file.
This was changed in 02354832cf8, both in the earlier codec_ver.h
and in the script that generates it, but a recent change manually
overwrote the spacing.
- Generate version header in the build tree
- Generate .res file in the build tree on Windows
- Add the $(SRC_PATH) prefix to the .def files on Windows
These values are read as two separate 16 bit integers from an
array in the FeatureSearchOne function, therefore we should
also store them in a well-defined order.
This fixes encoding of screen content on big endian; now the
full testsuite passes on big endian.
Since these spaces aren't at the start of lines, astyle doesn't
change it when fixing indentation.
The spacing and alignment is manually fixed up in a few places.
The function actually was correct for big-endian use already
(and the changes in 239e22d0 actually broke normal decoding tests),
it was only the test function itself that needed fixing for big-endian.
The astyle configuration makes sure normal code is indented consistently
with 2 spaces, but astyle doesn't seem to touch the indentation in
these multi-line macros.
This does the same cleanup as was done in 4fc27714bd on new occurrances
in the code base.
This fixes building with MSVC 2015 (which is still only a release
candidate).
This is for building code in the "app" mode (for Windows
Store apps/RT/metro/modern UI/appcontainer), which restricts API
usage and uses the Windows Runtime APIs for threading instead of the
old Win32 functions that aren't available for such apps.
This is similar to building for Windows Phone, but without the phone
specific libraries.
The common parts are abstracted to a common include makefile, that
both the targets "msvc-app" and "msvc-wp" use.
This makes them consistent with the rest of the assembly source
files. Prior to f2314151e8, all the assembly files had consistent
indentation, but after that, this file had been made different.
Add Intra 8x8 support
Add no_deblocking support inside T8x8
Add CABAC parse support
Add static data sheet for dequant
Fix bugs and clean/astyle the code
Remove build warnings
Modify the UT cases
Fix the ParseNalHeader bug
Keep support for the ENABLE64BIT flag (as a flag for choosing between
32 and 64 bit, if the current arch happens to be x86) but avoid using
it in code that wants to know the exact architecture used.
This makes the platform build files more straightforward and
consistent.
This is the same dirs as used as output dir by the msvc project files.
This makes sure that the project files can pick up the output files
directly instead of having to manually copy them around.
Instead of repeating everything hardcoded with platform ifdefs,
use a common define BUILD_UT_EXE to define whether we should build
an executable or a library of the unit test suite. Later factorize
all other platform differences into smaller and simpler ifdefs.
This makes sure the code is at least somewhat tested. Ideally those
assembly functions should be upgraded to work in 64 bit mode as well,
but until then it's better to actually use them in the configurations
where they can be built.
The apple assembler for arm can handle the gnu binutils style
macros just fine these days, so there is no need to duplicate all
of these macros in two syntaxes, when the new one works fine in all cases.
We already require a new enough assembler to support the gnu binutils
style features since we use the .rept directive in a few places.
The apple assembler for arm64 can handle the gnu binutils style
macros just fine, so there is no need to duplicate all of these
macros in two syntaxes, when the new one works fine in all cases.
We already require a new enough assembler to support the gnu binutils
style features since we use the .rept directive in a few places.
This makes for a chroma plane of 2x2. The SIMD versionf of generic
downscalers assume that the width and height is at least 2, since
it does an unconditional loop for the body of the image, and a
separate step for the last pixel and last row. The SIMD versions
assume that (width-1) and (height-1) are larger than zero.
This is the same fix as in e8cdbd2ea7, but making sure it applies
to both dimensions, that commit only fixed it for one of the
dimensions.
This fixes spurious crashes in EncodeDecodeTestAPI.SimulcastSVC.
Previously this used unofficial, apple specific syntax (with fallback
macros for gnu binutils), since Xcode 5.x didn't support the official
syntax of these instructions. Since Xcode 6 has been out for quite a
number of months already, it should be safe to require this (for
building 64 bit binaries for iOS, armv7 builds can still be built
with older Xcode versions).
This clarifies the code by avoiding apple specific syntax in the
assembler instructions.
If DESTDIR is set, it needs to include a trailing slash now.
This fixes "make install" on msys (i.e. on windows), where a path
starting with // is interpreted as a special network path.
This makes for a chroma plane of 2x2. The SIMD versionf of generic
downscalers assume that the width and height is at least 2, since
it does an unconditional loop for the body of the image, and a
separate step for the last pixel and last row. The SIMD versions
assume that (width-1) and (height-1) are larger than zero.
This fixes spurious crashes in EncodeDecodeTestAPI.SetOptionEncParamExt.
The individual tests shouldn't reseed the random number generator
(other than for local debugging).
Hardcoding a specific random seed here leads to this test (and
all subsequent tests) not testing things randomly as intended, but
always testing the same parameters.
When calculating what resolution to actually downscale to,
it can end up smaller than what the caller set. When scaling
down to resolutions close to the limit of allowed values,
this can end up setting values lower than the limit.
Previously, e.g. a downscale from 2266x8 to 566x2 will end
up as 566x1 after this calculation. When scaling to a
566x1, the chroma plane gets a height of 0, which doesn't
make sense, and which breaks e.g. the SSE2 scaler. Therefore,
make sure none of the dimensions end up set below 2.
Normally, the DownsamplePadding skips scaling if the target
size is the same as the source size, assuming that the caller
will use the source data pointer in that case. This is true
for the base layer (the first call to DownsamplePadding in
SingleLayerPreprocess), but when downsampling the other layers,
there is no special handling for the case when the target
is the same size as the source.
Previously, the encoding of such spatial layers will use
completely uninitialized data, encoding complete garbage.
Instead force DownsamplePadding to make a copy if no scaling
is required, for the dependency layers. The base layer still
avoids a copy unless scaling of that layer is required.
Whether it actually makes sense to have lower spatial layers
the same size as the original one is a different question
though - currently the code allows it, and
EncodeDecodeTestAPI.SetOptionEncParamExt will try to use it.
If the calling test hasn't set m_iPicResSize, it is set to the
maximum frame size, which takes much longer to initialize than the
current actual frame size.
This reduces the runtime of EncoderInterfaceTest.SkipFrameCheck
in valgrind from 229 seconds to 8 seconds, and the total runtime
of all the test cases in EncoderInterfaceTest from 405 seconds
to 89 seconds.
They are still used slightly differently in the encoder and decoder;
the decoder uses plain functions while the encoder uses one object
keeping track of the number of allocated bytes, and keeping track
of the requested alignment.
When generating a new version of the header, that includes the
actual git hash, don't overwrite the file that is tracked by git.
Instead create a new file, and include this only if the build system
indicates that it exists (by setting a define). This allows the
untouched source tree to be built from within an IDE even if make
has not been run.
This reduces the hassle with a file that needs to be ignored in the
git configuration.
The downside is that the generated file isn't used if building
from within an IDE, if the header has been updated by calling make
before (since the IDE configuration doesn't know whether the user
actually has run make). Since users of the IDE might not build via
make in the command line at all (in the same source checkout at least),
this should not be an issue in practice. The previous way things worked,
the version hash (generated by make) when used in an IDE could actually
be outdated and misleading.
This function actually zero-initializes the allocated memory, thus
make this clear in the function name.
This makes the function name match the same behaviour in the encoder.
the decoder did not produce valid output, call DrainComplete in Drain
and FlushComplete in Flush. Without these, the caller of the GMP may
end up waiting forever on a requested operation to complete.
Use the decoder versions of the functions (which are capable
of handling widths 4/8/16 for luma, not only 16 as in the
encoder). By using the more generic versions, there may be a small
performance loss since the functions need to check the width
in every call. Actual measurements show that the actual change is
very small (and the shared routines turn out to actually be faster
than the existing ones in ARM NEON setups).
Even if there actually is no SIMD optimized version of the
width==2 cases, luma function for SIMD still needs to handle
it by calling McCopyWidthEq2_c for these cases.
This simplifies the UT code a little, and makes sure that
those codepaths are tested properly.
This speeds up the compile time from 21.3 to 2.6 seconds
for the MC test files.
This makes it slightly harder to see exactly which test
failed on a quick glance, but it makes the overall structure of
the unit test output more manageable and readable, by reducing
the number of tests from 1300 to 430.
This test seems to have been added to the git tree in commit
9a602cac (which does much more than what the commit message
tells), and finally merged into git master in 2c99f581.
Since WELS_CLIP3 is a macro, using it will cause the arguments
to be evalated multiple times, which means that the clip will
not work as intended. If using a rand() argument, always use
WelsClip3 instead, which is an inline function.
Since cropping is disabled (prepareParam does
memset (pParam, 0, sizeof (SEncParamExt)); which clears the
cropping flag), we need to make sure that the number of
macroblocks differ, not only the number of pixels.
Previously, this test picked a width at random until it found
a width that had been used before, meaning that all tests were
made with the same single width.
This makes all compiler warnings to be treated as errors.
This allows catching warnings that are introduced, that may only be
visible with some compilers.
This option is only added within travis unit tests, not during normal
builds, so there is no risk of unnecessarily breaking builds on
new/untested systems.
This is similar to how it is done in release mode already.
The fact that this behaviour differed between release and debug
can be traced back to commit cf92e8d6.
The GetVersionEx function has been deprecated since Windows 8.1.
VerifyVersionInfo exists at least since Windows 2000.
This fixes warnings about use of deprecated functions in MSVC.
There is no problem in using the "insecure" CRT functions, as long as
they are used correctly - especially not within the test suite where
they are only are exposed to the test suite input data.
Within the library, these are used via the library internal wrappers
in codec/common/src/crt_util_safe_x.cpp, but we'd rather not use them
in the test suite - just use the normal standard C functions here.
The existing cast didn't make much sense. The expression itself is
already int, there's little point in casting it to int, especially
when assigning to a float.
This fixes warnings with MSVC.
This disables armasm warning A4509, "This form of conditional
instruction is deprecated".
The conditional instructions (such as movcs, addcs, subscs)
have been deprecated in ARMv8, in favor of conditional branches.
This isn't something that we need to take immediate action about,
though, therefore silence the warning.
These fields were originally int64_t. Even though long long is
the same size as int64_t in all setups, some compilers treat
it as a different type than long long (in 64 bit environments,
int64_t is a long, not a long long, even if they are the same
size).
%"PRId64" is used for printing int64_t, while %lld is used
for printing long long.
This fixes build warnings with gcc.
valgrind thinks xmm2 is uninitialized - in fact it is, but
its value here doesn't really matter. Instead set it to a known value
before using it in SUMW_HORIZON.
Previously, the variable itself wasn't const (which meant that
it could be set to point to another const string instead).
By declaring it as const, gcc doesn't warn about it being unused,
and we can get rid of a workaround.
This function doesn't return a struct, but fills in a struct via
a provided pointer.
The ABI of returning a struct is different between MSVC and mingw.
This allows using the same function from mingw, even though the DLL
has been built with MSVC.
If only a static library is installed, the user of the library may
not know that only a static version of this particular library is
available (and doesn't know that --static should be added to the
pkg-config call). Therefore, one common practice is to include private
dependencies in the public Libs line if a static-only library is
installed.
When the header is used from C instead of C++, an empty parameter
list means that it can take any number of parameters, and can cause
warnings like "function declaration isn’t a prototype" with some
C compilers. Clarify this by explicitly adding void to this function.
If the codec library is loaded dynamically, it may be necessary that
the loaded library actually matches the version that was used when
it was built, to avoid issues due to ABI differences. Therefore add
a public function to allow getting the version of the currently
loaded library.
The ForceIntraFrame test will fail (giving up after 100 skipped
frames) if the bitrate is not set high enough.
Set the minimum bitrate to w*h/50, which is a very low value,
but which still should allow getting a non-skipped frame within
a few attempts.
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.
Previously, the encoder logging was done in InitEncoder(),
which is called from the constructor. Therefore, it was impossible
to override the log level, to silence this message.
This makes sure both "make libopenh264.so" and "make libopenh264.so.0"
work as intended.
Use the versionless name as dependency for the install rule,
to make sure both (if possible) are created.
This feels more straightforward - some file systems/environments
(such as MSys) implement symlinks as plain file copies, where
distinguishing whether a file is a link might be hard.
Prior to 3f69873c99, there already was a mechanism for installing
the import library, used for the MSVC builds. Use that for mingw
as well, instead of adding more hardcoded rules.
In WelsEncoderParamAdjust it is already clipped in the
same way, but here we should probably rather error out
than to silently clip it to the right range.
@ -4,12 +4,13 @@ OpenH264 is a codec library which supports H.264 encoding and decoding. It is su
Encoder Features
----------------
- Constrained Baseline Profile up to Level 5.2 (4096x2304)
- Constrained Baseline Profile up to Level 5.2 (Max frame size is 36864 macro-blocks)
- Arbitrary resolution, not constrained to multiples of 16x16
- Rate control with adaptive quantization, or constant quantization
- Slice options: 1 slice per frame, N slices per frame, N macroblocks per slice, or N bytes per slice
- Multiple threads automatically used for multiple slices
- Temporal scalability up to 4 layers in a dyadic hierarchy
- Simulcast AVC up to 4 resolutions from a single input
- Spatial simulcast up to 4 resolutions from a single input
- Long Term Reference (LTR) frames
- Memory Management Control Operation (MMCO)
@ -23,7 +24,7 @@ Encoder Features
Decoder Features
----------------
- Constrained Baseline Profile up to Level 5.2 (4096x2304)
- Constrained Baseline Profile up to Level 5.2 (Max frame size is 36864 macro-blocks)
- Arbitrary resolution, not constrained to multiples of 16x16
- Single thread for all slices
- Long Term Reference (LTR) frames
@ -38,55 +39,57 @@ OS Support
- Windows 64-bit and 32-bit
- Mac OS X 64-bit and 32-bit
- Linux 64-bit and 32-bit
- Android 32-bit
- Android 64-bit and 32-bit
- iOS 64-bit and 32-bit
- Windows Phone 32-bit
Processor Support
-----------------
- Intel x86 optionally with MMX/SSE (no AVX yet, help is welcome)
- ARMv7 optionally with NEON
- ARMv7 optionally with NEON, AArch64 optionally with NEON
- Any architecture using C/C++ fallback functions
Building the Library
--------------------
NASM needed to be installed for assembly code: workable version 2.07 or above, nasm can downloaded from http://www.nasm.us/
NASM needed to be installed for assembly code: workable version 2.10.06 or above, nasm can downloaded from http://www.nasm.us/
For Mac OSX 64-bit NASM needed to be below version 2.11.08 as nasm 2.11.08 will introduce error when using RIP-relative addresses in Mac OSX 64-bit
To build the arm assembly for Windows Phone, gas-preprocessor is required. It can be downloaded from git://git.libav.org/gas-preprocessor.git
For Android Builds
------------------
To build for android platform, You need to install android sdk and ndk. You also need to export **ANDROID_SDK**/tools to PATH. On Linux, this can be done by
To build for android platform, You need to install android sdk and ndk. You also need to export `**ANDROID_SDK**/tools` to PATH. On Linux, this can be done by
make OS=android NDKROOT=**ANDROID_NDK** TARGET=**ANDROID_TARGET**
Valid **ANDROID_TARGET** can be found in **ANDROID_SDK**/platforms, such as android-12.
You can also set ARCH, NDKLEVEL according to your device and NDK version.
ARCH specifies the architecture of android device. Currently only arm and x86 are supported, the default is arm.
NDKLEVEL specifies android api level, the api level can be 12-19, the default is 12.
Valid `**ANDROID_TARGET**` can be found in `**ANDROID_SDK**/platforms`, such as `android-12`.
You can also set `ARCH`, `NDKLEVEL` according to your device and NDK version.
`ARCH` specifies the architecture of android device. Currently `arm`, `arm64`, `x86` and `x86_64` are supported, the default is `arm`. (`mips` and `mips64` can also be used, but there's no specific optimization for those architectures.)
`NDKLEVEL` specifies android api level, the default is 12. Available possibilities can be found in `**ANDROID_NDK**/platforms`, such as `android-21` (strip away the `android-` prefix).
By default these commands build for the armeabi-v7a ABI. To build for the other android
ABIs, add "ARCH=arm64", "ARCH=x86", "ARCH=x86_64", "ARCH=mips" or "ARCH=mips64".
To build for the older armeabi ABI (which has armv5te as baseline), add "APP_ABI=armeabi" (ARCH=arm is implicit).
By default these commands build for the `armeabi-v7a` ABI. To build for the other android
ABIs, add `ARCH=arm64`, `ARCH=x86`, `ARCH=x86_64`, `ARCH=mips` or `ARCH=mips64`.
To build for the older `armeabi` ABI (which has armv5te as baseline), add `APP_ABI=armeabi` (`ARCH=arm` is implicit).
To build for 64-bit ABI, such as `arm64`, explicitly set `NDKLEVEL` to 21 or higher.
For iOS Builds
--------------
You can build the libraries and demo applications using xcode project files
located in codec/build/iOS/dec and codec/build/iOS/enc.
located in `codec/build/iOS/dec` and `codec/build/iOS/enc`.
You can also build the libraries (but not the demo applications) using the
make based build system from the command line. Build with
'make OS=ios ARCH=**ARCH**'
make OS=ios ARCH=**ARCH**
Valid values for **ARCH** are the normal iOS architecture names such as
armv7, armv7s, arm64, and i386 and x86_64 for the simulator. Additionally,
one might need to add 'SDK=X.Y' to the make command line in case the default
SDK version isn't available. Another settable iOS specific parameter
is SDK_MIN, specifying the minimum deployment target for the built library.
Valid values for `**ARCH**` are the normal iOS architecture names such as
`armv7`, `armv7s`, `arm64`, and `i386` and `x86_64` for the simulator.
Another settable iOS specific parameter
is `SDK_MIN`, specifying the minimum deployment target for the built library.
For other details on building using make on the command line, see
'For All Platforms' below.
@ -95,40 +98,54 @@ For Windows Builds
Our Windows builds use MinGW which can be found here - http://www.mingw.org/
To build with gcc, add the MinGW bin directory (e.g. /c/MinGW/bin) to your path and follow the 'For All Platforms' instructions below.
To build with gcc, add the MinGW bin directory (e.g. `/c/MinGW/bin`) to your path and follow the 'For All Platforms' instructions below.
To build with Visual Studio you will need to set up your path to run cl.exe. The easiest way is to start MSYS from a developer command line session - http://msdn.microsoft.com/en-us/library/ms229859(v=vs.110).aspx If you need to do it by hand here is an example from a Windows 64bit install of VS2012:
export PATH="$PATH:/c/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin:/c/Program Files (x86)/Microsoft Visual Studio 11.0/Common7/IDE"
export PATH="$PATH:/c/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin:/c/Program Files (x86)/Microsoft Visual Studio 11.0/Common7/IDE"
You will also need to set your INCLUDE and LIB paths to point to your VS and SDK installs. Something like this, again from Win64 with VS2012 (note the use of Windows-style paths here).
export LIB="C:\Program Files (x86)\Windows Kits\8.0\Lib\Win8\um\x86;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib"
Then add 'OS=msvc' to the make line of the 'For All Platforms' instructions.
Then add `OS=msvc` to the make line of the 'For All Platforms' instructions.
For Windows Phone builds
------------------------
Follow the instructions above for normal Windows builds, but use `OS=msvc-wp`
instead of `OS=msvc`. You will also need gas-preprocessor (as mentioned below
"Building the Library").
If building for Windows Phone with MSVC 2013, there's no included bat file that sets the lib paths to the Windows Phone kit, but that can be done with a command like this:
export LIB="c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\store\arm;c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\arm;c:\Program Files (x86)\Windows Phone Kits\8.1\lib\arm"
This is only necessary for building the DLL; the static library can be built without setting this.
For All Platforms
-------------------
From the main project directory:
'make' for automatically detecting 32/64bit and building accordingly
'make ENABLE64BIT=No' for 32bit builds
'make ENABLE64BIT=Yes' for 64bit builds
'make V=No' for a silent build (not showing the actual compiler commands)
- `make` for automatically detecting architecture and building accordingly
- `make ARCH=i386` for x86 32bit builds
- `make ARCH=x86_64` for x86 64bit builds
- `make V=No` for a silent build (not showing the actual compiler commands)
- `make DEBUGSYMBOLS=True` for two libraries, one is normal libraries, another one is removed the debugging symbol table entries (those created by the -g option )
The command line programs h264enc and h264dec will appear in the main project directory.
The command line programs `h264enc` and `h264dec` will appear in the main project directory.
A shell script to run the command-line apps is in testbin/CmdLineExample.sh
A shell script to run the command-line apps is in `testbin/CmdLineExample.sh`
Usage information can be found in testbin/CmdLineReadMe
Usage information can be found in `testbin/CmdLineReadMe`
- Added support of video signal type present information
- Added support of encoder load-balancing
- Improved encoder multi-threads, rate control and down-sampling
- Fixed the frame size constraint in encoder
- Bug fixes for rate control, multi-threading, simulcasting in encoder
- Bug fixes for interface call, return value check, memory leak in decoder
- Bug fixes for UT and statistic information
- Bug fixes for assembly code
- Remove the unused and redundant code
- Improvements on UT, memory allocation failed protection, error-protection in decoder, input parameters checking in encoder, assembly for AVX2 support, assembly code performance, logging and documentation
- Correct some typos in source code and documents
v1.5.3
------
- Bug fixes for GMP Plugin
v1.5.2
------
- Fix GMP Plugin causing the Browser crash on Android
v1.5.1
------
- Bug fixes for GMP Plugin
v1.5.0
------
- Correct a typo in codec return value (github issue#2046, cmUnkonwReason -> cmUnknownReason)
- Added Codec demo and auto build script for WP8
- Decoder support of 'Constrained High Profile' of H.264
- Encoder support of CABAC of H.264
- Encoder support of input frame rate 60
- Improved syntax of gaps_in_frame_num_value_allowed_flag in encoder
- Improved memory usage for multi-threading in encoder
- Added VUI info for base layer in encoder
- Added encoder interface to get external setting of iMaxQp and iMinQp for rate control
- Bug fixes for Rate Control, multi-threading and simulcasting in encoder
- Bug fixes for NoDelay API, ParseOnly functions, error-concealment off functiond and error-detection in decoder
- Bug fixes for UT
- Fixes to avoid valgrind warnings, potential crash and calculation overflow
- Merged files for decoder/encoder and remove unused files
- Improvements on build scripts, UT, error-protection in decoder, input param checking in encoder, assembly for 64bit support, downsampling, logging and documentation
Note:
'Constrained High Profile' = 'Constrained Baseline Profile' plus:
- CABAC
- Intra 8x8 mode support
- 8x8 transform
- QP scaling matrices
- QP per chroma component
- Mono 4:0:0 (experimental)
- Weighted prediction
v1.4.0
------
- Decoder new interface of DecodeFrameNoDelay
- Added new encoder and decoder statistics
- Added option for generating pdb in windows builds
- Added new rate control mode (RC_TIMESTAMP_MODE) for inconstant frame rate input
- Added new Sps/Pps strategies for real-time video
— Added support for simulcast avc
- Improvements in code structure, assembly, input parameter checking, logging, UT and comments
- In gmp-openh264, return decoder error correctly and other fixes
- Decoder bug fixes when for Error Concealment disabled
- Bug fixes for ParseOnly functions
- Bug fixes for encoding large frame size (>32767MBs)
- Fixes to avoid valgrind warnings, potential crash and calculation overflow
-----------
v1.3.1
------
- Fixed and enhanced protection to avoid crash when reading lossy bitstreams
- Adjust the default mode of Error Concealment used by gmp-openh264
-----------
v1.3.0
------
- Removed manual API document, now using wiki: https://github.com/cisco/openh264/wiki (0af48e5 for v1.3.0)
- Added API version in API header files
- Added pkg-config file
- Added decoder support of parsing only (bParseOnly) for only parsing bit stream but not decoding
- Added timestamp and max nal size in gmp-openh264.cpp when calling encoding
- Added timestamp info in decoder input and return structure
- Added support of level 9 in decoder
- Added total length of the encoded frame in encoder return structure
- Added SetOption(ENCODER_OPTION_SVC_ENCODE_PARAM_BASE,&base) for encoder
- Set constraint set 0 and 1 flags for non-scalable
- Improved error concealment algorithms and provide more modes of error-concealment
- Improved rate control algorithms and reference selection algorithms for screen content encoding
- Added encoder and decoder statistics interface
- Improved input parameter checking and logging
- Bug fixes, warning reductions, and test improvements
-----------
v1.2.0
------
@ -26,6 +124,58 @@ Binaries
These binary releases are distributed under this license:
rem if "%vArcType%" =="arm" set PATH=C:\MinGW\bin;C:\MinGW\msys\1.0\bin;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin;C:\Program Files (x86)\Git\bin;%PATH%
if"%vArcType%"=="i386"call"%VCPATH%\vcvarsall.bat" x86
*//for Decoding only, pData can be used for render.
*if(sDstBufInfo.iBufferStatus==1){
*outputpData[0],pData[1],pData[2];
*}
*//for Parsing only, sDstParseInfo can be used for, e.g., HW decoding
*if(sDstBufInfo.iBufferStatus==1){
*if(sDstBufInfo.iNalNum >0){
*HardwaredecodingsDstParseInfo;
*}
*//no-delay decoding can be realized by directly calling decoder again with NULL input, as in the following. In this case, decoder would immediately reconstruct the input data. This can also be used similarly for Parsing only. Consequent decoding error and output indication should also be considered as above.
*//no-delay decoding can be realized by directly calling DecodeFrameNoDelay(), which is the recommended usage.
*//no-delay decoding can also be realized by directly calling DecodeFrame2() again with NULL input, as in the following. In this case, decoder would immediately reconstruct the input data. This can also be used similarly for Parsing only. Consequent decoding error and output indication should also be considered as above.
DECODER_OPTION_TRACE_CALLBACK,///< a void (*)(void* context, int level, const char* message) function which receives log messages
DECODER_OPTION_TRACE_CALLBACK_CONTEXT,///< context info of trace callbac
@ -239,29 +253,6 @@ typedef struct {
intiLTRRefNum;///< TODO: not supported to set it arbitrary yet
}SLTRConfig;
/**
*@briefStructureforsliceargument
*/
typedefstruct{
unsignedint
uiSliceMbNum[MAX_SLICES_NUM_TMP];///< only used when uiSliceMode=2;here we use a tmp fixed value since MAX_SLICES_NUM is not defined here and its definition may be changed;
unsignedintuiSliceNum;///< only used when uiSliceMode=1
unsignedintuiSliceSizeConstraint;///< only used when uiSliceMode=4
}SSliceArgument;///< not all the elements in this argument will be used, how it will be used depends on uiSliceMode; please refer to SliceModeEnum
/**
*@briefEnumeratethetypeofslicemode
*/
typedefenum{
SM_SINGLE_SLICE=0,///< | SliceNum==1
SM_FIXEDSLCNUM_SLICE=1,///< | according to SliceNum | enabled dynamic slicing for multi-thread
SM_RASTER_SLICE=2,///< | according to SlicesAssign | need input of MB numbers each slice. In addition, if other constraint in SSliceArgument is presented, need to follow the constraints. Typically if MB num and slice size are both constrained, re-encoding may be involved.
SM_ROWMB_SLICE=3,///< | according to PictureMBHeight | typical of single row of mbs each slice + slice size constraint which including re-encoding
SM_DYN_SLICE=4,///< | according to SliceSize | dynamic slicing (have no idea about slice_nums until encoding current frame)
SM_AUTO_SLICE=5,///< | according to thread number
SM_RESERVED=6
}SliceModeEnum;
/**
*@briefEnumeratethetypeofratecontrolmode
*/
@ -269,7 +260,9 @@ typedef enum {
RC_QUALITY_MODE=0,///< quality mode
RC_BITRATE_MODE=1,///< bitrate mode
RC_BUFFERBASED_MODE=2,///< no bitrate control,only using buffer status,adjust the video quality
RC_OFF_MODE=-1///< rate control off mode
RC_TIMESTAMP_MODE=3,//rate control based timestamp
RC_BITRATE_MODE_POST_SKIP=4,///< this is in-building RC MODE, WILL BE DELETED after algorithm tuning!
RC_OFF_MODE=-1,///< rate control off mode
}RC_MODES;
/**
@ -277,17 +270,17 @@ typedef enum {
*/
typedefenum{
PRO_UNKNOWN=0,
PRO_BASELINE=66,
PRO_MAIN=77,
PRO_EXTENDED=88,
PRO_HIGH=100,
PRO_HIGH10=110,
PRO_HIGH422=122,
PRO_BASELINE=66,
PRO_MAIN=77,
PRO_EXTENDED=88,
PRO_HIGH=100,
PRO_HIGH10=110,
PRO_HIGH422=122,
PRO_HIGH444=144,
PRO_CAVLC444=244,
PRO_CAVLC444=244,
PRO_SCALABLE_BASELINE=83,
PRO_SCALABLE_HIGH=86
PRO_SCALABLE_BASELINE=83,
PRO_SCALABLE_HIGH=86
}EProfileIdc;
/**
@ -326,38 +319,136 @@ enum {
WELS_LOG_DETAIL=1<<4,///< per packet/frame log
WELS_LOG_RESV=1<<5,///< resversed log iLevel
WELS_LOG_LEVEL_COUNT=6,
WELS_LOG_DEFAULT=WELS_LOG_DEBUG ///< default log iLevel in Wels codec
WELS_LOG_DEFAULT=WELS_LOG_WARNING ///< default log iLevel in Wels codec
};
/**
*@briefStructureforsliceconfiguration
*/
*@briefEnumeratethetypeofslicemode
*/
typedefenum{
SM_SINGLE_SLICE=0,///< | SliceNum==1
SM_FIXEDSLCNUM_SLICE=1,///< | according to SliceNum | enabled dynamic slicing for multi-thread
SM_RASTER_SLICE=2,///< | according to SlicesAssign | need input of MB numbers each slice. In addition, if other constraint in SSliceArgument is presented, need to follow the constraints. Typically if MB num and slice size are both constrained, re-encoding may be involved.
SM_SIZELIMITED_SLICE=3,///< | according to SliceSize | slicing according to size, the slicing will be dynamic(have no idea about slice_nums until encoding current frame)
SM_RESERVED=4
}SliceModeEnum;
/**
*@briefStructureforsliceargument
*/
typedefstruct{
SliceModeEnumuiSliceMode;///< by default, uiSliceMode will be SM_SINGLE_SLICE
SSliceArgumentsSliceArgument;
}SSliceConfig;
unsignedintuiSliceNum;///< only used when uiSliceMode=1, when uiSliceNum=0 means auto design it with cpu core number
unsignedintuiSliceMbNum[MAX_SLICES_NUM_TMP];///< only used when uiSliceMode=2; when =0 means setting one MB row a slice
unsignedintuiSliceSizeConstraint;///< now only used when uiSliceMode=4
}SSliceArgument;
/**
*@briefEnumeratethetypeofvideoformat
*/
typedefenum{
VF_COMPONENT,
VF_PAL,
VF_NTSC,
VF_SECAM,
VF_MAC,
VF_UNDEF,
VF_NUM_ENUM
}EVideoFormatSPS;// EVideoFormat is already defined/used elsewhere!
/**
*@briefEnumeratethetypeofcolorprimaries
*/
typedefenum{
CP_RESERVED0,
CP_BT709,
CP_UNDEF,
CP_RESERVED3,
CP_BT470M,
CP_BT470BG,
CP_SMPTE170M,
CP_SMPTE240M,
CP_FILM,
CP_BT2020,
CP_NUM_ENUM
}EColorPrimaries;
/**
*@briefEnumeratethetypeoftransfercharacteristics
*/
typedefenum{
TRC_RESERVED0,
TRC_BT709,
TRC_UNDEF,
TRC_RESERVED3,
TRC_BT470M,
TRC_BT470BG,
TRC_SMPTE170M,
TRC_SMPTE240M,
TRC_LINEAR,
TRC_LOG100,
TRC_LOG316,
TRC_IEC61966_2_4,
TRC_BT1361E,
TRC_IEC61966_2_1,
TRC_BT2020_10,
TRC_BT2020_12,
TRC_NUM_ENUM
}ETransferCharacteristics;
/**
*@briefEnumeratethetypeofcolormatrix
*/
typedefenum{
CM_GBR,
CM_BT709,
CM_UNDEF,
CM_RESERVED3,
CM_FCC,
CM_BT470BG,
CM_SMPTE170M,
CM_SMPTE240M,
CM_YCGCO,
CM_BT2020NC,
CM_BT2020C,
CM_NUM_ENUM
}EColorMatrix;
/**
*@briefStructureforspatiallayerconfiguration
*/
typedefstruct{
intiVideoWidth;///< width of picture in luminance samples of a layer
intiVideoHeight;///< height of picture in luminance samples of a layer
floatfFrameRate;///< frame rate specified for a layer
intiSpatialBitrate;///< target bitrate for a spatial layer
intiMaxSpatialBitrate;///< maximum bitrate for a spatial layer
intiVideoWidth;///< width of picture in luminance samples of a layer
intiVideoHeight;///< height of picture in luminance samples of a layer
floatfFrameRate;///< frame rate specified for a layer
intiSpatialBitrate;///< target bitrate for a spatial layer, in unit of bps
intiMaxSpatialBitrate;///< maximum bitrate for a spatial layer, in unit of bps
EProfileIdcuiProfileIdc;///< value of profile IDC (PRO_UNKNOWN for auto-detection)
ELevelIdcuiLevelIdc;///< value of profile IDC (0 for auto-detection)
intiDLayerQp;///< value of level IDC (0 for auto-detection)
SSliceConfigsSliceCfg;///< slice configuration for a layer
SSliceArgumentsSliceArgument;
// Note: members bVideoSignalTypePresent through uiColorMatrix below are also defined in SWelsSPS in parameter_sets.h.
boolbVideoSignalTypePresent;// false => do not write any of the following information to the header
iMultipleThreadIdc;///< 1 # 0: auto(dynamic imp. internal encoder); 1: multiple threads imp. disabled; lager than 1: count number of threads;
boolbUseLoadBalancing;///< only used when uiSliceMode=1 or 3, will change slicing of a picture during the run-time of multi-thread encoding, so the result of each run may be different
/* Deblocking loop filter */
intiLoopFilterDisableIdc;///< 0: on, 1: off, 2: on except for slice boundaries
intiLoopFilterAlphaC0Offset;///< AlphaOffset: valid range [-6, 6], default 0
intiLoopFilterBetaOffset;///< BetaOffset: valid range [-6, 6], default 0
intiLoopFilterBetaOffset;///< BetaOffset: valid range [-6, 6], default 0
/*pre-processing feature*/
boolbEnableDenoise;///< denoise control
boolbEnableBackgroundDetection;///< background detection control //VAA_BACKGROUND_DETECTION //BGD cmd
char*pFileNameRestructed;///< file name of reconstructed frame used for PSNR calculation based debug
char*pFileNameRestructed;///< file name of reconstructed frame used for PSNR calculation based debug
EVideoFormatTypeeOutputColorFormat;///< color space format to be outputed, EVideoFormatType specified in codec_def.h
unsignedintuiCpuLoad;///< CPU load
unsignedcharuiTargetDqLayer;///< setting target dq layer id
unsignedintuiCpuLoad;///< CPU load
unsignedcharuiTargetDqLayer;///< setting target dq layer id
ERROR_CON_IDCeEcActiveIdc;///< whether active error concealment feature in decoder
boolbParseOnly;///< decoder for parse only, no reconstruction. When it is true, SPS/PPS size should not exceed SPS_PPS_BS_SIZE (128). Otherwise, it will return error info
floatfAverageFrameRate;///< the average frame rate in, calculate since encoding starts, supposed that the input timestamp is in unit of ms
floatfLatestFrameRate;///< the frame rate in, in the last second, supposed that the input timestamp is in unit of ms (? useful for checking BR, but is it easy to calculate?
unsignedintuiBitRate;///< sendrate in Bits per second, calculated within the set time-window
unsignedintuiAverageFrameQP;///< the average QP of last encoded frame
unsignedintuiInputFrameCount;///< number of frames
unsignedintuiSkippedFrameCount;///< number of frames
cat ../../openh264.rc.template | sed "s/\$MAJOR/$major/g"| sed "s/\$MINOR/$minor/g"| sed "s/\$REVISION/$revnr/g"| sed "s/\$RESERVED/$resnr/g" > openh264.rc.tmp
<comment>Controls the Language and ensures that the font for all elements in the RootFrame aligns with the app's language. Set to the language code of this resource file's language.</comment>
SlicesAssign0 960 # count number of MBs in slice #0
SlicesAssign1 0 # count number of MBs in slice #1
SlicesAssign2 0 # count number of MBs in slice #2
SlicesAssign3 0 # count number of MBs in slice #3 -- seting here is for better testing
SlicesAssign4 0 # count number of MBs in slice #4
SlicesAssign5 0 # count number of MBs in slice #5
SlicesAssign6 0 # count number of MBs in slice #6
SlicesAssign7 0 # count number of MBs in slice #7
### DESIGN OF SLICE MODE ####
# 0 SM_SINGLE_SLICE | SliceNum==1
# 1 SM_FIXEDSLCNUM_SLICE | according to SliceNum | Enabled dynamic slicing for multi-thread
# 2 SM_RASTER_SLICE | according to SlicesAssign | Need input of MB numbers each slice. In addition, if other constraint in slice_argument is presented, need to follow the constraints. Typically if MB num and slice size are both constrained, re-encoding may be involved.
# 3 SM_ROWMB_SLICE | according to PictureMBHeight | Typical of single row of mbs each slice?+ slice size constraint which including re-encoding
# 4 SM_DYN_SLICE | according to SliceSize | Dynamic slicing (have no idea about slice_nums until encoding current frame)
# 5 SM_AUTO_SLICE | according to thread number | the number of slices is decided by the number of threads,SliceNum is ignored
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.