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.
This reimplements the reconnect logic in mpegts muxer.
Taking cues from the WHIP output, a start and stop thread is used,
controlled by a mutex, ensuring the start and stop pipelines can never
be run concurrently.
Fixes bugs #11885, #11721, #11620, #11062, #12133.
For better readibility, this commits also breaks the big set_config
function into smaller units.
Signed-off-by: pkv <pkv@obsproject.com>
This is the first part of a fix for reconnection issues with SRT
protocol.
This part implements the logic on the side of the protocol.
The fixes are as follows:
- a cleanup of return values of the various functions used. The main
libsrt_open function returns OBS_OUTPUT_XXX enum members. But the other
functions return now only AVERROR(xxx).
- an explicit check of the socket state before returning
OBS_OUTPUT_SUCCESS. This fixes an issue due to relying on socket
non-blocking mode; in caller mode, the srt_connect function will return
a success even before a connection has succeeded since it relies on
notifications by srt_epoll_wait. This would prompt obs UI to display a
successful reconnection in spite of a failure.
Signed-off-by: pkv <pkv@obsproject.com>
The do_log function defined for the muxer expects that the struct is
named stream rather than output. So rename output to stream.
This also avoids confusion with stream->output which is an obs_output_t
pointer.
Signed-off-by: pkv <pkv@obsproject.com>
