The location for System-wide and User-only installation depend on Windows-managed locations, which means that they will never require a user to select the correct location. Therefore it is best to hide the page in all modes except for Portable, which should still offer a path to extract to.
While the previous approach of a static thread pool worked, it was sub-optimal in its resource usage. Many of the threads would never see a single task, and simply permanently sleep. This seems like a good idea, except that sleeping threads still end up in the scheduler, and thus waste a tiny amount of resources.
It is better to instead dynamically spawn threads when needed and only keeping the bare minimum around all the time. These dynamically spawned threads are also explicitly set to background priority which further reduces scheduling overhead. Finally optimizing the memory layout to prevent unwanted false sharing should also keep sporadic wake ups at a minimum.
This new model should be able to handle many more tasks than ever before, but is still not as optimal as it could be.
Thanks to the PR by @abcdw (https://github.com/obsproject/obs-studio/pull/4067) we can support 'local user' installations. These will allow end users to install StreamFX without requiring Administrator rights, or learning how to use OBS Studio in portable mode.
With OBS Studio 0.15.0 came a better location for plugins to install to, which solves many of the current issues. While this location still requires Administrator rights to write to, it is a much safer location than writing directly into the OBS Studio installation directory.
It seems to be possible to encode with a different framerate than what libOBS is configured for. While technically any framerate appears to be possible, it is currently limited to integer fractions only in order to make the implementation much easier. Integer fractions only require skipping N frames and multiplying the denominator by N, where N is the configured integer. For sanity reasons, the limit of N is currently 10.
This allows power users to split their streaming and recording framerates with relative ease, and opt for things such as:
- 30 FPS (1/4) streaming with 120 FPS (1/1) recording.
- 30 FPS (1/10) streaming with 300 FPS (1/1) recording.
- 30 FPS (1/10) streaming with 100 FPS (1/3) recording.
- and so on.
While some of these combinations are just stupid, they are now available to power users.
While this may break some unusual encoders that require additional frames for extra data or sei data to be present, it fixes the problem where encoders would never record at all. May need to look into a different solution in the future.
Fixes#911
Nlohmann-json is used in the about dialog, yet wasn't required when building the front-end, leading to failing compilation. This ensures that it is correctly required.
With OBS Studio 28.0 comes another restriction: Per-User Plugins. This is currently only enforced on ARM64, but may soon be enforced on all architectures. Adjusting the Packages installer to generate the correct files is relatively easy.
Unfortunately the MacOS Package Installer has some problems figuring out if it should show the user the correct step or not, and may even ignore our settings entirely. This bug has been first reported in 2010, and has since then been re-reported in 2016, 2017, 2018, 2019, and 2020 where it was finally turned into a community wiki on StackOverflow.
With OBS Studio 28.0.0 a new requirement was added to MacOS plugin: Loadable Bundles. These bundles are similar to Application Bundles, and have many of the same features, but are designed to be loaded by Applications instead of being the Application. This allows for almost all of the advantages to persist, with some minimal drawbacks.
The compiler will choose the optimal way automatically, and forcing std::move here actually results in two objects existing side by side, before being "moved" into one.
