I discovered while testing that the first split would always be one GOP
too long (e.g. 1m2s instead of 1m) due to the fact that b-frames and
negative start DTSes were not accounted for.
This is now fixed by setting the start_time to the nonzero negative DTS
produced for the first packet. Additionally, a small tolerance of 1 ms
was also added to account for rounding issues present in the first GOP.
Originally, before file splitting was introduced, I made the choice to
simply ignore the last frame in the packet queue of the muxer, because
frame N+1 is required to properly determine the duration and I figured
nobody would notice if their recording is one frame short.
However, when using frame splitting this would result in the last frame
before the split being dropped. To fix this, we can simply reuse the
previous sample's duration for the final sample in a file. Since OBS
only does CFR, they should all be identical anyway.
The recording audio bitrate was hardcoded to 192 kbps regardless of
channel layout. For a 5.1 mix this yields ~32 kbps per channel which is
very low quality. Scale proportionally from the stereo reference (192
kbps) using the active channel count, snapping to the closest bitrate
supported by the selected encoder (AAC or Opus).
Stereo recordings are unchanged (192 * 2 / 2 = 192 kbps).
The frontend UI assumes transitions are always available and crashes if
none are present. Resolving the crashes resulted in a completely broken
UI, so it's safe to assume that transitions are a core requirement for a
working OBS.
Crash reports indicate that obs-transitions is failing to load for some
users, so we should handle the case where no transitions load and abort
with an error instead of crashing.
This process mitigation flag is inherited by child processes and applies
to load-time DLL resolution, pushing the application's own directory
below the system directories. If there are system-installed copies of
dependent DLLs such as FFmpeg, those get loaded when OBS is updated as
the updater and subsequent relaunch of OBS inherit the mitigation.
As we use SetDefaultDllDirectories, this mitigation is less important,
the proper fix would be to use /DEPENDENTLOADFLAG to protect load-time
import resolution.
Qt 6.11 only supports macOS 13+. It does not support macOS 12, and OBS
Studio will fail to launch on macOS 12 as a result. We should reflect
that with our deployment target.
https://doc.qt.io/qt-6.11/supported-platforms.html
We suspect users hit errors updating the system-wide hook files even if
the file is not in use, but without logging we have no way to know for
sure. This commit adds additional logs. Not logging source paths
anywhere is intentional to avoid wide char to utf-8 issues making this
more complicated than it needs to be - the source will always be the OBS
install dir regardless.
The previous increase from 1 to 3 deltas has an acceptable time cost on
CI. Further increase it from 3 to 5.
This should somewhat improve the update experience on macOS for users
not on the most recent previous version of OBS Studio.
Notable Changes:
* deps.qt: Backport fix for QTBUG-146665
Fix a bug that causes right-click to not work for disabled items in the
source list. This is fixed on the Qt 6.11 branch and in 6.12.0-beta1,
but we've backported the patch for now.
More useless "security" software to try to prevent screenshots that
installs global hooks and kernel drivers. Crash reports indicate that
their hook attaches to and subsequently crashes OBS.
derrod