Direct integration of AMD AMF encoder

[Xaymar]

Discussion Thread

https://github.com/Xaymar/obs-StreamFX/discussions/860

Provide a summary of the Improvement

The AMD AMF encoders should be available via StreamFX directly, instead of relying on FFmpeg.

Completion Requirements

• A reasonable amount of documentation should be present in the code.
• Support for Windows and Linux with the available Graphics APIs in libOBS.
• Zero-Copy and Multi-GPU encoding should be supported with the best matching API (if possible on the API).
• Both H.264/AVC and H.265/HEVC should be available for encoding.
• The User Interface should expose all useful UI options in a similar way to the (via FFmpeg) encoders. This includes the Custom Settings field, which allows users to specify settings that override everything shown in the UI.
• All common encoding formats between libOBS and AMF should be supported (NV12) in the bitness available at implementation time.
• Performance should be similar to the already existing (via FFmpeg) AMF encoder, if not better. Memory usage is secondary and can be worse if necessary.

[Xaymar]

@abebeos

I have the feeling that the effort here (and similar within https://github.com/Xaymar/obs-StreamFX/issues/859 https://github.com/Xaymar/obs-StreamFX/issues/857) is beyond a $500 bounty budget.

The budget is based on income via Patreon or Github Sponsors, but all of them together already exceed the available income through those methods. They are intended to be picked up by developers already versed in CMake and with some experience in libOBS, and only require knowing or learning one extra API (NVENC, QSV or AMF). With the minimum knowledge (CMake, libOBS), these are entirely doable within a 20 to 30 hour total time window, thus being at market rate.

requirements/feasibility analysis

This step has already been done ahead of time, which is where the requirements are from. As libOBS 28.0 is not yet out, only support for 27.2 is listed as requirements for now. This is why there is no HDR or 10bit output requirement either.

AMF also provides the necessary interop structures for all three APIs, though the Vulkan interface is by far the fastest way to encode on AMD. Perhaps I should provide a base framework for people to start off from, which will better explain what actually needs to be done.

$500 - refactor code to simplify migration to native encoders $500 - produce a migration layer

Neither of these are necessary, as no migration will take place. They are new encoder options, not replacements for the existing one - if you were to replace the existing ones, it would cause all kinds of hellish issues with older GPUs.

[jarrard]

Yeah I lost the AMD AMF H.265/HEVC option recently (it never worked when it did appear) which is unfortunate because apparently it can now work... Total bummer!

[Xaymar]

would it be possible to update functionality incrementally (e.g. using both, ~StreamFX~ direct AMD AMF and FFmpeg for different functionality) ?

This is the intended path, if it ends up implemented. This is why there should not be any migration code, or updating code. This is purely an "implement this thing and this thing only" feature.

[Xaymar]

Provide an easy-to-reproduce development env

The recommended way to develop for StreamFX is by using a bundled build, and shouldn't require Docker at all. This build type allows for rapid iteration on changes, with almost no work required. In fact, most of the development of StreamFX happens entirely with this build type.

Additionally I can recommend developing cross-platform features on Windows first, as OBS Studio is more feature-complete on Windows than it is on other platforms. While there have been major improvements to this status over the years, it is still significantly more complete on Windows than it is on Linux or MacOS.

I would suggest $500 for this (as I've experienced with such setups, I expect to have this within a week), then I could live with the $500 budget for this issue. And if the AMD issue goes fine, I could most possibly execute the other 2 issues, too.

The attached bounty is already at the limit of what can be spent. Funding is, as already explained, provided through GitHub Sponsors, Patreon and one-time-only PayPal donations. All bounties combined is the income StreamFX generated over 4 years, excluding fees and taxes.

[Xaymar]

If you're not confident with implementing this feature, I recommend opting for one of the other bounties first to get more familiar with libOBS, obs-frontend-api and StreamFX. #846 is the easiest of the bunch by far, and probably has a larger bounty attached than necessary.

[Xaymar]

It's not about confidence, the technical stuff is peanuts. It's about the budget, and the risk to work in the end for $5/hour. There are projects where one can start developing immediately, without losing time in test-system setup. That is what I'm referring to.

You need to realize: I'm trying to help here, beyond the scope of the bounties. It looks like no developer has responded yet - at least provide a ready-to-go dev-system, thus interested parties take at least a look and assess the effort.

While your attempt at help is appreciated, it is wholly misplaced. As I've already explained above, these bounties are for developers who have knowledge in libOBS and enough knowledge in CMake to work with OBS Studio. These developers would most likely already have a "dev-system" capable of building StreamFX from the get-go, and not need to set up anything new.

In fact, if you had knowledge in both the things required to actually complete this task, you wouldn't be asking many of these questions. This is why I'm trying to direct you at simpler tasks instead, but instead you keep attempting to extend the bounty far beyond what it is supposed to be.

As usual with bounties like these, they'll either be picked up by someone who already has the skill, or someone who will be taught along the way and get paid for it. This is not a "you are hired at X$/hr" task.

If you say that setting up the bundled build takes only two or three hours (until one can make and validate a change within your StreamFX code), the I say that it is not necessary to provide a more convenient setup.

Question: would it be possible to make the development headless (without an UI) ?

Since you appear to be new to OBS Studio development, it only takes a few minutes to set up OBS Studio for building. The actual speed depends entirely on your Internet speed, but with the newer automated building system it should be done even faster than before. There is also no headless development - how do you test a User Interface without a User Interface?