Adds links to release functions for "new/incremented reference".
Extra info on signal handler.
Parameter description on `obs_property_list_add_*` functions, since
their parameter `name` can be confusing and it is unclear which value
is stored in obs_data_t.
Adds clarifications on calldata_ptr.
Erroring out of NVENC init early if the Max B-frames setting was higher
than the encoder's capability causes an encoder failure on NVIDIA Pascal
(10-series) and earlier GPUs due to an unfortunate interaction between
Simple Output Mode, HEVC, and our default B-frames setting of 2. Since
we already check the Max B-frames capability of the encoder, cap at that
value instead of erroring out.
Fixes#7698.
Checks to make sure that the bframe count is equal to or below the
maximum number of bframes that the encoder for the codec supports.
Fixes a bug where setting bframes higher than what the encoder supports
would cause the encoder to not start up properly.
The old NVENC preset "Default", labeled in OBS as "Performance", maps to
the new P3 preset when not using multipass. Since we previously only
enabled multipass/two-pass on "Max Quality", we can map this to P3 in
all cases.
This commit also modifies UI.
8dda8d3500 added a few functions to get the last
recording/replay/screenshot path, but it should return allocations
because it's possible for the data to be modified at a later point.
Ubuntu 20.04 and 22.04 both have the same FFmpeg versions, but FFmpeg on
20.04 was built with version 9 of NVENC headers, whereas 22.04 was built
with 11.
Unfortunately, that means we have to revert back to the old presets when
Ubuntu 20.04 is detected. The way this detection is done is a bit hacky,
but it's the only way to preserve startup performance. Otherwise we'd
have to write yet another startup subprocess test program to detect
whether the FFmpeg being used was built with older or newer NVENC, which
is both slow to start up and annoying to write. So instead, just get the
distro name/version strings and detect Ubuntu 20.04 that way.
An upward compressor increases levels below a threshold, instead of
decreasing levels above it. This is closely related to an expander; the
upward compressor can be seen as an expander with ratio in the [0,1]
range. This can be used for example when the game audio is lowered
against a voice track but that one still wants to be able to hear very
low game sounds.
For more use cases:
https://www.izotope.com/en/learn/4-tips-for-using-upwards-compression-in-neutron.html
Signed-off-by: pkv <pkv@obsproject.com>
Things were a bit unoptimal and were squished together, making the code
much more difficult to work with. Instead, separate the code for
processing individual samples into its own function.
