- 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>
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.
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.
This bug predates the merge into StreamFX and was present in the original release as a separate plugin. libOBS has never sampled Chroma at Center as far as I can look back into its history.
Fixes#676
As people appear to be far too willing to mess with settings they have absolutely no reason to mess with, removing these seems like the best option. Both of these can still be set if you know where to look, and aren't actually required for operation at all.
While the long descriptions were useful, keeping the updated and translated is pretty much impossible. Technology moves fast and not everyone that translates the project knows a lot about technology.
Therefore the long descriptions have now been replaced with a button that opens the wiki page for the feature instead. This should drastically reduce the number of help cases, and improve the translation coverage at the same time.
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.
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.
Improves the previous logic and makes it compatible with the new additions in 26.x, such as sRGB. This was previously broken as the focus was on existing features which could be tested without requiring a compiler to be installed.
Incorrect understanding of how sRGB works with RGB and YCC/YUV formats also caused sRGB to be treated as RGB when I444 was selected. This should also now be fixed, hopefully permanently.
Fixes#331
Removes the NVENC entry on systems without an NVIDIA GPU by checking if the library for it can be loaded. If it can't be loaded, it's likely that the user does not have a system with NVENC capabilities - and guaranteed that they can't use the encoder as FFmpeg relies on these libraries.
