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.
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.
IOSurface locks are only necessary when any processing with the data
contained in the surface is done and an explicit copy of data from GPU
memory back to CPU memory is needed.
Apple Silicon-based Macs have a unified memory architecture, as such
an IOSurface will always be available in memory accessible to the CPU
and GPU (and an off-load of the IOSurface will not take place).
eGPUs are not supported on Apple Silicon-based Macs either, so an
IOSurface lock to ensure data is copied back to CPU memory is not
necessary.
Without invalidating the mach port used for sharing the IOSurface
between OBS and the application displaying the virtual camera output,
IOKit seems to run into the issue of receiving "shared" mach ports,
possibly because of port exhaustion. IOKit requires a "new" port
however and crashes upon that error otherwise.
Co-authored-by: Steven Michaud <smichaud@pobox.com>
Certain programs can start the virtualcam filter, then they may choose
to call `Stop()` on the filter, call `SetFormat()` to change the
resolution, then call `Run()` again to start the filter again. The
Windows virtual camera filter did not account for this, thus if the
resolution was different, it had potential to cause a crash.
To fix this, store the last filter resolution, then check the resolution
every frame, and if it changes, reset the scaling information.
(Author note: This code is unclean. What we need to do with the virtual
camera filter is make it only create the thread on `Run()`, then join
the thread on `Stop()`. It's currently a bit complicated to make it do
that at the moment, so this code is a kind of an annoying stopgap for
now.)
The `cx`/`cy`/`interval` variables specifically specify the
OBS/placeholder resolution/interval. The resolution may not be the same
as the filter's resolution (when scaling is used).
Instead, prefix these variables with `obs_` to improve clarity.
Sending frames on initial pause seems to cause an odd crash on
subsequent frame calls.
(Note by author: I do not know why the crash happened because code
beyond OBS is a proprietary black box. I suspect it's just a bug in
WebRTC or something, but I can't know for sure. This is incredibly
frustrating. But at least this particular crash seems to be fixed.
...for now.)
The callback missing_file_callback will get an empty string when a user
decided to remove the file on the missing file dialog.
Avoid the empty string to be held in files array and remove it.
Also avoid passing an empty file name from the property to internal
functions.
A prior patch made the button to show/hide a VST check the current
status of a loaded VST. This lead to situation where upon first
selection a VST might be loaded but the button's visibility is not
changed.
This change will reevaluate the status of a loaded VST upon selection
in the drop-down menu and trigger button visibility accordingly.
Ask the PA server to kindly not migrate our streams to the default
device unless the user chose the default device for input/output
captures.
Fixes#3211
While the inject-helper tries to hook an application, the source is
set to `active` until the inject-helper reports being unable to hook.
If the graphics thread updates the transformations of every source in
that time frame, the game-capture source will report the width and
height used from the last valid capture, leading to its selection box
flickering in and out of view.
Ensuring that width and height are only reported when the source is not
only made active but is also capturing content fixes the flickering
issue.
