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.
These warnings are mostly hints or complete nonsense based on broken parsing. It is easier to disable them than to find a common solution that works on all compilers.
* New translations en-US.ini (Russian)
* New translations en-US.ini (Czech)
* New translations en-US.ini (Italian)
* New translations en-US.ini (Spanish)
* New translations en-US.ini (Polish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (French)
This work-around adds the necessary include directories, as the 'libobs' target does not export any include directories visible without BUILD_INTERFACE evaluating to TRUE. Hopefully the true cause for this problem can be identified and fixed later.
- Use auto in places where code clarity is improved or identical.
- Replace trivial constructors and destructors with default.
- Use true random for random generation.
- Use std::string_view where it is valid to do so.
- Apply const where it is valid to do so.
- Use references where it is valid to do so.
- Manually optimize memory usage with std::move and std::copy.
- Opt for memory efficient containers where the size is known ahead of time.
Signed-off-by: lainon <GermanAizek@yandex.ru>
For unknown reasons this results in an error only when the project is built within git-bash and with cmake. It does not occur with cmake-gui or VS itself.
