When #5169 implemented deferred encoder updates, it did not account for
the case when the encoder hadn't started yet. This means the encoder would
start and then immediately call update with the same settings it was
started with, which in the case of some hardware encoders would trigger
a reconfiguration request to the driver.
Reset frame_rate_divisor_counter to 0 on encoder shutdown.
After starting and stopping a GPU encoder session, obs_encoder_shutdown
would set frame_rate_divisor_counter to 1. When the next GPU encoder
session was started, in libobs/obs-video-gpu-encode.c, gpu_encode_thread
would set skip to this value (1), and increment
frame_rate_divisor_counter to 2. This causes the next check to fail, as
frame_rate_divisor is 1 by default (2 == 1 is false), so
frame_rate_divisor_counter retains its value. Since skip is non-zero,
the next check, if(skip), passes, and skip to the next loop iteration.
This will continue forever, because frame_rate_divisor_counter will
continue to increment, so it will never hold the same value as
frame_rate_divisor. This means that send_off_encoder_packet is never
called, so the muxer never receives encoded packets.
To the end-user, this manifests as their second encoder session being
impossible to stop. They then have to force quit OBS and the
obs-ffmpeg-mux process. This change prevents that from occurring and
allows multiple back-to-back GPU encoder sessions to be completed.
To avoid passing `struct darray *` type, which cannot hold the type
information, this commit defines array types and uses that types on the
function parameters.
To avoid passing `struct darray *` type, which cannot hold the type
information of the array element, use defined array types on the
function parameter lists.
Passing DARRAY with an operator such as dereference (`*`) sometimes
caused a compile error. To avoid the error, introduced parentheses
inside the macros.
Allows rescaling resolution for GPU encoders and allows moving
rescaling for CPU encoders from CPU to GPU
Rescaling is implemented via core video mixes; encoders create
their own core mix with matching width/height/format/colorspace/
range when gpu scaling is enabled and no matching core video
mix exists
This software seems to be pre-installed on many Lenovo systems and has a
"Network Boost" feature that restricts data usage of background apps,
causing throughput issues when streaming with OBS.
Creation of Info.plist files through Xcode is more canonical and
future-proof, as it will automatically pick up changes/updates
introduced by Apple. Non-standard keys can still be added via a
template file, which will then be extended by Xcode with the default
keys.
clang expects an empty prototype to explicitly use `void`.
Also silences the warning in `libobs-opengl`, `obsglad`, `caption`,
`mac-syphon` and `obs-x264-test`.
Initialize arrays to 0, as otherwise these can get initialized with
garbage data or potentially Visual Studio's default debug marker,
which is a problem if they're being checked against `NULL` later.
Effectively reverting parts of d314d47, this commit removes the new
functions that got added to remove the flags parameter. Instead, it just
marks the parameter as unused and documents this. Having what is
effectively an API break just to remove a parameter is a bit overkill.
The other parts of d314d47 which cleaned up the usage of the flags
parameter are untouched here.
MinGW comes with it's own intrinsics macros as regular MSVC does.
On MinGW the inclusion of SIMDe would cause multiple definitions
of the same macro names.
Since sse-intrin.h leaks into the public header space this
will cause 3rd party plugins build with MinGW tool-chains emit
redeclaration warnings when including obs-module.h.
Switching to a static library that contains version information as
const char strings has multiple benefits:
* The version information provided externally via compiler definitions
will fail compilation early if malformed
* An updated version string (which will happen with every commit) will
not invalidate existing compilation units, because only the static
library is affected by the change
* An update of the version change just requires a recompilation of the
static library and a linker update
* An update of the version will _not_ infect the rest of the codebase
(as it does currently, because everything includes obsconfig.h one
way or another)
* Other modules which used the macro definition directly have been
updated as much as possible to use the proper getter method from
`libobs` instead (some Windows-specific modules use preprocessor
string composition, the value has been added as a compiler definition
directly in those cases)
* Because the impact of a version change due to a commit hash change
is limited to the static library, ccache hit rates should be
improved considerably
#8873 accidentally used `log_flag_encoded()` instead of `flag_encoded()` in `obs_output_begin_data_capture()`, which was causing a warning to be logged when it shouldn't.
This deprecates the following functions, replacing them with new
versions:
- `obs_output_can_begin_data_capture()` - now `*capture2()`
- `obs_output_initialize_encoders()` - now `*encoders2()`
- `obs_output_begin_data_capture()` - now `*capture2()`
The flags parameter was initially designed to support audio-only or
video-only operation of an output which had the `OBS_OUTPUT_AV` flag,
however, full support for that was never implemented, and there are
likely fundamental issues with an implementation, mainly that most
outputs are programmed assuming that there will always be at least one
audio and one video track. This requires new flags specifying support
for optional audio/video, among other things.
An implementation to allow audio/video to be optional is best done
using the flag technique above, with audio/video enablement specified
by whether media (raw, `video_t/audio_t`) or encoder (`obs_encoder_t`)
objects are specified.
Since every implementation I could find always specifies `flags` as 0,
I was able to safely conclude that immediately removing the parameter's
functionality is safe to do.