The resolution and aspect ration should be added to the description of
the format even if there are no available frame rates.
The code is restructured a bit to avoid having to call `dstr_free()`
before each `continue`.
Fixes: 4cfcfc8c35 ("linux-pipewire: Make camera framerate non-mandatory")
The HDR support is removed from the full blur FX but kept for Background
Blur and Greenscreen FX.
The Blur FX is SDR only but for Background Blur it can be tolerated
since the foreground is not touched.
Signed-off-by: pkv <pkv@obsproject.com>
We were giving images to the Blur effect in linear color space.
This caused a darkening of colors with banding effects.
This fixes the issue.
For Background Blur FX, we composite the original texture with the
blurred one using the mask provided by AI Greenscreen.
This means the non blurred area will look the same whether the filter is
applied or not, irrespective of OBS settings and the nature of the
source. For both HDR & SDR this preserves the colours in non blurred
zones.
Signed-off-by: pkv <pkv@obsproject.com>
Chapters take their timestamp from the total video frame time. With
file splitting enabled in recording settings, the time offset since
the start of the current split was made needs to be considered before
submitting chapters to the muxer.
Change to subtract start_time of the current output from the chapter
timestamp.
The enum members being getting the bitwise or here are from different
enums, and bitwise operations on members from different enums are
deprecated in C++20. kAudioFormatFlagsNativeFloatPacked is the
equivalent value (see its defintion), but removes the manual bitwise or.
std::find is used in enumerate_frame_rates already, so the equality
operator is needed there. Until C++17 this is defined implicitly, but
since C++20 it's needed explicitly.
efca325 already increased the default bitrate for various encoders.
However, some were missed and this commit fills the gap:
* Mac-VT
* OpenH264
* Texture AMF
* VAAPI
For 'pulse_output_capture', calls are added when devices are either
changed, started or removed.
The calls trigger a check against the monitoring device.
Signed-off-by: pkv <pkv@obsproject.com>
For 'coreaudio_output_capture', calls are added when devices are either
changed, started or removed.
The calls trigger a check against the monitoring device.
Signed-off-by: pkv <pkv@obsproject.com>
For 'wasapi output capture', calls are added when devices are either
changed, started or removed.
The calls trigger checks against the monitoring device.
Signed-off-by: pkv <pkv@obsproject.com>
The default of 2500 kbps was chosen 10 years ago and times have changed.
Logs and forums posts show that many users of OBS for recording don't
change their bitrate and end up with a 2.5 mbps recording which looks
terrible.
Now that service bitrate enforcement exists, this will be automatically
capped to the maximum bitrate for streaming services, so the only time
this should result in a problem is if the user's upload speed is the
limiting factor, hopefully rarer these days with increasing internet
speeds.
These usages should be removed! On Clang or GCC this would throw a
warning now, but unfortunately on MSVC (the only compiler this plugin is
built with) PRAGMA_WARN_DEPRECATION disables the warning completely.
The only reason the usages here are tolerated is that removing them is
not completely trivial and I cannot test it.