This loader model should have wider compatibility, as it relies on defined C++ behavior instead of undefined preprocessor behavior. We may even be able to implement a simple dependency system that automatically sorts components into the correct order.
When a QCefWidget is alone and all by itself, no layout updates are performed on the "window". This causes a problem where it just stays in place, instead of moving with the rest of the elements. The fix to this appears to be to just add a different Qt widget into the layout.
Looks stupid, is stupid, but works anyway. Qt is weird.
Allows us to pass an obs_module_t into util::library::load() for cleaner code. This requires an additional flag so we don't unload a module that is still in use by libOBS.
Fixes several files incorrectly stated a different license from the actual project, as well as the copyright headers included in all files. This change has no effect on the licensing terms, it should clear up a bit of confusion by contributors. Plus the files get a bit smaller, and we have less duplicated information across the entire project.
Overall the project is GPLv2 if not built with Qt, and GPLv3 if it is built with Qt. There are no parts licensed under a different license, all have been adapted from other compatible licenses into GPLv2 or GPLv3.
This functionality broke at some point in the past without anyone noticing, resulting in most dropdowns that rely on this functionality being blank.
Fixes#1025
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
