For simple image and video editing, LUTs (Look-Up Tables) are vastly superior to running the entire editing operation on each pixel - especially if all the processing can be done inside a single shader.
Due to the post-processing requirements for our LUTs, we are limited to 8 bits per channel - though clever use of the unused Alpha channel may result in additional space. For our purposes however, this is definitely enough.
A complete redesign of the component and dependency system is necessary in order to support additional platforms, such as MacOS and other Linux platforms. Additionally it results in a much cleaner code base, which is less confusing overall.
Eventually it might be necessary to push components of StreamFX into their own CMake projects, as it is getting kind of complex now. Especially with the push for a proper plugin manager, things get dicey for big plugins like StreamFX.
The majority of users should have already switched or upgraded to Ubuntu 20.04 at this point, so there is no point in building further Ubuntu 18.04 versions. This saves us some CI slots, and also reduces the number of target systems to actually support.
* New translations en-US.ini (Turkish)
* New translations en-US.ini (Sinhala)
* New translations en-US.ini (Spanish)
* New translations en-US.ini (Czech)
* New translations en-US.ini (Serbo-Croatian)
Ignoring the data parameter during initialization results in duplication and some third party plugins not working as expected, so it's better to not ignore it.
Fixes#315
Adds support for the AMD Advanced Media Framework H.264 and H.265 encoders via FFmpeg. The majority of settings are supported, and the UI/UX experience mimics that of the NVENC implementation. Various settings are left out due to their complexity and should be controlled via the custom parameters field.
Using the obs_module_file and obs_module_config_path macros works okay, but it comes with a slight overhead as well as additional requirements when passing it to C++ functions that expect certain rules to be fulfilled. By instead wrapping the actual functionality into our own functions and using those we can avoid most of the issues that come with the old approach.
Related: #359
The MODULE_EXPORT and EXPORT macros in libOBS do not correctly mark a function or type as visible on GCC, which results in the newly added flag hiding everything from view, instead of just what should be hidden.
