Many platforms (and/or kernels) don't zero memory before it is acquired, resulting in uninitialized memory being used to store critical content. This made the threadpool assume it had an infinite number of threads to work with, despite actually having spawned none.
Fixes#1017
This should fix the case where comparing '0.12.0b164' with '0.12.0a169' results in it claiming the former is newer. Also should fix the case where stable releases would always be treated as older.
Fixes#1015
The rendering code here was one of the older code bases, which was riddled with bugs and leaks. The new code doesn't look pretty, but it works for the time being until a better solution is found or made. It should be able to handle HDR inputs now, but it may not be completely correct yet. This also fixes the double-free bug.
As an additional improvement, I've moved the allocation of the effect to a shared class which should reduce the memory usage slightly when multiple effects are in play. And now selecting nothing selects the filter target itself without infinitely adding references to the filter. Good enough in my eyes.
Fixes#819
While this had no actual effect due to the immediate ID3D11DeviceContext being tied to the ID3D11Device itself, it shouldn't have occured at all. With this there should now only be a single Release() call for every AddRef() call.
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.
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
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.
- 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.
To ensure better stability of future releases, we need to adopt multiple stages in the release cycle. As we already label Alpha, Beta, Candidate and Stable differently, simply adopting this classification system already does everything for us. This also allows us to maintain compatibility with the existing system, while offering something new entirely.
As the recursion checking code is somewhat broken in libOBS, we need something to prevent accidental recursion from occurring. While the alternative fix is to simply make all of libOBS support recursion, unfortunately that endeavor would be too large for a single person to take on.
In some rare cases, a bug is observed where some sources end up missing despite being visible in the OBS Studio UI. This is most likely related to us actually missing the events due to plugin load order. We can fix this by explicitly enumerating sources in the constructor.
Additionally in order to reduce the human error factor, we should avoid explicit initialize() and finalize() calls for our singleton. Instead the get() function should do all of the heavy lifting, including thread safety, so that the human writing the code will have next to no chances to break it.
The build breaks if compiling against a newer version of ffmpeg which does not define the FF_API_NEXT macro and has fully removed the av_codec_next() API.
Replaces some very specific code with generic support for FFmpeg, which should last us much longer than the old way. Also improves the migration of settings, which wasn't quite working with the previous way.
When FFmpeg Encoders was originally written, FFmpeg 4.2 was still new and OBS Studio did not seem to want to update to anything newer for a while. This led to code being fine-tuned for FFmpeg 4.2, which stops working the moment OBS Studio upgrades FFmpeg. This removes the dependency on FFmpeg 4.2 hopefully, and allows using newer FFmpeg versions - or perhaps even older versions.
Additionally the nonsensical behavior of the Target Quality slider was fixed. It is now from 0 to 51, instead of from 0 to 100, and as such matches FFmpeg exactly.
As contributors and translators always increase in number and never decrease, it was getting difficult to thank everyone properly with every update. So instead of manually writing each entry we should take advantage of the power of automation and use APIs to gather this information properly. As long as the user is not actively hiding their profile, they will be thanked properly.
This also includes a potential fix for the problem with multi-lingual text in the About StreamFX window.
With increasing complexity in video encoders, we end up with complex priority and drop priority structures. While the fields are currently ignored by the default libOBSs output plugins, in the future this might no longer be the case. In any case, the increase in complexity requires us to adjust to it.
Implements File, Source and Enumeration type for Texture shader inputs, completing the initial Shader implementation.
Related: #5
Co-authored-by: Michael Fabian 'Xaymar' Dirks <info@xaymar.com>
