You are aggresive in your input and you know it. Stop being you-know-what about it. Stop wasting more time, go get your proof.
Still waiting for your side of the proof. Doesnt even exist of course, but ill wait anyway. Just too entertain the idea. Pretty sure you wish it existed. But it doesnt.
You are incorrect about vaapi or you havenât clearly communicated what specific aspect youâre talking about:
There is no need for the disrespect @GreenMinusBlue . Cooler heads will prevailâŚ
5 Likes
And youâre not? 
I donât know why Iâm doing this but apparently you canât do it on your own.
4K 120fps VAAPI AV1 @ CQP 20
YouTube (still processing because YouTube)
Original File
OBS Logfile (36.6 KB)
Iâm sure youâre gonna find it in you to âoh this is not AAAâ, to which I say a) it is and b) I. Donât. Care.
Your issue was with the encoder not the game. My GPU is maxed out and the encoder is holding up just fine.
But again: How about proof of your (LLMs) claims?
3 Likes
Thanks for being patient with this person.
I almost wonder if they have a flatpack or snap version of OBS without realizing that version has been broken. If thatâs whatâs going on here, this is a perfect microcosm of why original projects get so irate with packages packaging (badly) their projects.
5 Likes
I donât know the status of the Snap these days but the Flatpak is packaged by the the OBS project (one of the few that push externally to Flathub actually). The Flatpak does have AV1 encoding by now, that was in one of the last runtime updates.
I donât have the Flatpak installed right now, but excerpt from a random log on the Discord:
OBS 32.0.4 log file uploaded at 2026-03-01, 03:37:23 PM
15:37:14.476: Platform: Wayland
15:37:14.476: CPU Name: AMD RYZEN AI MAX+ 395 w/ Radeon 8060S
15:37:14.476: CPU Speed: 1989.428MHz
15:37:14.477: Physical Cores: 16, Logical Cores: 32
15:37:14.477: Physical Memory: 63566MB Total, 49256MB Free
15:37:14.477: Kernel Version: Linux 6.17.7-ba25.fc43.x86_64
15:37:14.477: Flatpak Branch: stable
15:37:14.477: Flatpak Arch: x86_64
15:37:14.477: Flatpak Commit: 57c369da69c71c12b64543910ee525966ea39f3f5fd3990ea2e206ff707ea733
15:37:14.477: Flatpak Runtime: runtime/org.kde.Platform/x86_64/6.8
15:37:14.477: App Extensions:
âŚ
15:37:15.012: Available Encoders:
15:37:15.012: Video Encoders:
15:37:15.012: - ffmpeg_svt_av1 (SVT-AV1)
15:37:15.012: - ffmpeg_aom_av1 (AOM AV1)
15:37:15.012: - ffmpeg_vaapi_tex (FFmpeg VAAPI H.264)
15:37:15.012: - av1_ffmpeg_vaapi_tex (FFmpeg VAAPI AV1)
15:37:15.012: - hevc_ffmpeg_vaapi_tex (FFmpeg VAAPI HEVC)
15:37:15.012: - obs_x264 (x264)
âŚ
The _tex encoders are the zero-copy encoders by the way.
It is true that until a couple years ago there was a performance penalty with VAAPI because the frames were being copied off the GPU and back, but that hasnât been true for a long time and the post was implying it still is.
4 Likes
Yes absolutely.
I never claimed this (or any) percentage.
No and I never claimed it is. My issue with your post is that you didnât even bother verifying the most basic things.
And another issue is the premise of the post to begin with.
Your assumption is that AMF is required in any way, which it isnât. And so because you asked the LLM what the AMF implementation looks like it tells you (mostly accurately one might add) that there isnât much to be found.
But again: AMF is not required to begin with so you go down the path of fallacy that what the LLM says must be true even though it has no context of it not being required to begin with.
You asked it to write a paragraph about a missing implementation that isnât required in the first place. It strings words together, it doesnât know anything. If it knew anything it would have told you that AMF is not required (and possibly about to be obsoleted by AMD), and that VAAPI is the option to use - like I did.
The VAAPI/AV1 mistake I pointed out is entirely separate from AMF and easily verifiable by just opening up OBS and checking the settings.
What boggles me however is that instead of saying âmy bad about the VAAPI thingâ you insist that itâs either not present or has performance issues and call me retarded. That is what I have an issue with, your attitude that the LLM canât be wrong.
8 Likes
Well at least you do claim that AMF isnt needed and that VAAPI gpu acceleration is somewhat of an NVENC equivalent? Which it isnt. (Still isnt, too this very day)
Also VAAPI used too be only a plugin for OBS, (Back in the day) Which you also claim it never was right?? That has changed since i last checked OBS for recording / streaming. Its now baked in, i verified this myself. I also verified that you cant crank up every setting, as is it simply crashes obs-studio. (Like i thought) Full support, means FULL support. Its not there as both you and wendell claim. In-correct, and im the one that gets the ban?? lolâŚ
Yes i was in-correct about VAAPI acceleration working, (It barely worked for years) So i thought they didnt update it since then and simplescreenrecorder with its extreme x264 encoder preset, was a better experience back then. (Years ago) I thought as OBS didnt care back then, they wouldnt do much, if anything too improve the situation.
MY BAD DUDE, but VAAPI is still not an NVENC equivalent and therefore a real alternative too either NVENC or AMF. You claim this as a fallacy, which it isnt either. The only fallacy being taking in VAAPI acceleration as real and full amd gpu support.
Because it is.
Wrong.
The implementation in OBS predates the vaapi-plugin by a whole 4 years.
Or 1 year for the deprecated plugin:
So you managed to open up OBS? 
This depends on the specific card, what ffmpeg, and what Mesa supports. There are no checks as to what you enter there because OBS (just like any other VAAPI consumer) has no way of knowing the capabilities beyond what is reported by the driver.
And âI thoughtâ is the basis for a post like this? Really? Are we serious here?
The only ones that can change that are AMD by contributing to Mesa and/or ffmpeg. OBS has no part in this.
The whole point of VAAPI is that consuming projects donât need specific implementations for every vendor. Itâs one generic API for everyone. But obviously that assumes and requires proper support from the vendors.
Nvidia wanting to be special and not having a VAAPI implementation doesnât make this better, but they at least contributed for the NVENC implementation.
AMD is years behind when it comes to supporting the software ecosystem.
Thereâs also this tiny and definitely not relevant issue that AMD doesnât even provide proper libraries to implement AMF in the first place. See the PR I linked in my third post. And while youâre at it Iâd also suggest you read the release notes from AMD that are linked in that PR.
1 Like
Its not. No need too create more laughter for the FOSS community. You are already funny enough as is.
That what it looks like now true, but it didnt back then. Which is also true, at least use wayback-machine too provide proper proof, instead of betting everything on the provided up-to-date links. The internet is engineered for link providers like yourself, think about that before posting links.
So youre clapping for an implementation that doesnt provide full support? Good job, keep going.
That was back in the day, no need too create more scenes here. As you only do it too soak up more likes for your âi cant use wayback-machine crowdâ Oh the link doesnt exist anymore? Oh well guess my totally up-to-date links provide any and all truth about the matter lmao.
Please do tell how the Video Acceleration API that is specifically designed to be an API to accelerate video de- and encoding with GPUs (FOSS by the way, shocker), is not GPU acceleration for video.
âŚ
You realise that is a commit⌠from 2018⌠right? If youâre so tuned in to âthe FOSS communityâ, you should at least have a basic understanding of how Git works before you want to shittalk someone who does.
Hereâs a hint: This is not the up-to-date code.
But hey, maybe you should have checked that before typing this up because spoiler: This is exactly the same as in the oldest copy on the Waybackmachine.
And before you make a joke of yourself: I hope you realise Archive.org doesnât archive every single page and even less so right when they are published. The oldest archive.org link does not equal the publish date.
Yeah well, I thought about it, which is why I linked that specific commit from 2018. That commit doesnât change even if you open it 20 years from now.
The hell are you on about? Those links go exactly to where theyâre supposed to go WTF.
2 Likes
I didnt say it cant provide gpu acceleration. It clearly can, but is not on-par with NVENC. Also it never will be, having hope in this issue is just making more room for desktop-embarrasment.
So page 404, no need too make the sentence longer than it needs too be.
Then you can of course also provide all the âcommitsâ that were never taken in right? Also do that please before talking more about how things work and their commits. The internet is a much more chaotic place, than what you and your âlinksâ make it look like.
Again page 404. I dont feel a need too type longer too make my input seem more impactful.
Thatâs a commit on the master branch. It was âtaken inâ, as you put it, by definition; it wouldnât exist on the master branch if it hadnât been merged.
4 Likes
I would love to have more choices in OBS Studio. What am I missing out on on AMDâs stack?
That seems to be the whole point of the thread, but Iâm not seeing what I should be mad at.
Wonder how many commits were dismissed, probably many more than people think. Anyway back to the topic.
Its not that obs-studio doesnt offer the options themselves they are there. They just dont work. At least with the GUI as i tried them myself. Thankfully there is gpu-screen-recorder so i dont have too go through the hassle of obs-studio through the terminal.
And your reason for that isâŚ? âI thinkâ again?
Is the current VAAPI implementation perfect? Absolutely not, and I never claimed it to be.
But isnât it in the FOSS spirit to make things better instead of looking for alternatives? And regarding that I said it above and Iâll say it again: Much of that is down to AMD themselves, because noone knows the hardware like they do (well, hopefully anyway). They have been working on it recently (and with ârecentâ I mean maybe 4-5 years), but they still have a long ways to go and a lot of things are missing in Mesa. But that is their primary focus now. If you donât believe me (which Iâm sure will be the case), read their release notes I mentioned earlier as well.
So you havenât even clicked them, got it.
None of the links I provided 404.
And even if they were, the links are irrelevant. Just clone the repo and look at the commit. GitHub links are nothing more than a convenient way to look at them, they hold nothing of value.
Why would I spend the time on this, youâre the one making a scene here. Iâm not interested in what wasnât merged, Iâm interested in what was. If youâre so convinced there are so many commits that were never merged for this, go look for them yourself.
I provided what was implemented, and what works.
They very much do, but the options expect you to know what youâre doing, which⌠yâknow, going by this thread 
OBS doesnât even have configuration on the command line lol.
PS: You know whatâs the funniest part about your entire FOSS tirade here? I thought it would dawn on you at some point, but apparently that day isnât coming:
You realise you are advocating for the implementation of a closed source and proprietary framework/API instead of furthering the support of the free and open source API that we already have, right? Very FOSS of you
2 Likes