Export fails on AMD GPUs since NV12 fast path (v0.1.142)
Hello. I’m currently on a new system (MX Linux, though don’t think the distro is the problem here) and wanted to do a quick recording. Installed using the install script and all went well. Authenticated youtube and when trying to upload, it fails. I’ve attached the log file found in ~/.local/state/hosaka/
hosaka.log
188.7 KB
Log in to comment and vote
Hugo Baldwin
Mar 26
Hi Sujal I’ve included a fix for this in v0.1.147 (along with the new track for changing the recording layout)
It turns out AMD devices are more pedantic about which flags are provided to FFmpeg when encoding than Intel and that’s why the issue wasn’t caught earlier. In your logs there was a compatibility probe which passed and then the encoding itself failed after a few frames. To prevent it occurring again I’ve added test coverage to ensure the args used in the compatibility check and encoding always match. I’ll also see if I can pickup a AMD laptop for testing
Let me know if that fixes the issue for you
Sujal Gurung
Mar 27
Thanks! I had a separate issue with the stop systray icon crashing the app that got fixed by this, though this error still persists.
Some background info: I'm running MX linux off a usb on the same laptop i used to report arch issues before. Haven't updated and tested on arch but I am getting the previously attached errors on MX. Also updated all packages. Here's the latest logs
Sujal Gurung
Mar 27
You can get mx linux here if you wanna test (issue confirmed on both xfce and kde variants:
https://mxlinux.org/download-links/
Also, here's Gemini's take on it. It also gave me a python command to force the app to use the cpu but that just made my laptop freeze
Gemini:
This is definitively an issue with the app itself, not a missing dependency on your new system. You can pass this exact explanation back to the developer—they made a tiny oversight in the app's export pipeline regarding AMD hardware compatibility. Here is exactly what is happening: The Problem: B-Frames and AMD Vega GPUs Your new system is running an AMD Radeon Vega 3 GPU on Debian 13. The hardware video encoder on this specific generation of AMD chips (Raven/VCN 1.0) does not support B-frames for H.264 encoding. The developer actually handled this perfectly during the recording phase, but forgot to apply the same fix to the export phase.
The Recording Phase (Success) If you look at the FFmpeg command the app generates to record your screen, it includes a specific flag:
That -bf 0 explicitly tells FFmpeg to disable B-frames. Because of this, the AMD driver accepts it, and the recording succeeds perfectly. 2. The Export Phase (Failure) When you stop recording and the app tries to export/render the final file, it generates a slightly different FFmpeg command:
Notice that -bf 0 is missing. Because it's missing, FFmpeg falls back to its default behavior (which tries to use B-frames). The AMD hardware driver instantly rejects this because it physically can't do it, resulting in the errors you see:
Task finished with error code: -22 (Invalid argument) (The AMD driver rejecting the encoder settings)
Terminating thread with return code -38 (Function not implemented) (The video filter failing because the encoder crashed) How the Dev can fix it Tell the developer that they need to ensure the -bf 0 flag (or any hardware-specific compatibility flags they are using for the live capture) is also being passed to the FFmpeg builder during the export pipeline for AMD VA-API users. Right now, their app checks the hardware capability for the capture stream but seemingly uses a hardcoded preset for the export stream that breaks on older AMD APUs.
Hugo Baldwin
Mar 27
Can you test again with the latest release? And yes, Gemini's analysis was spot-on. Hopefully this sorts it. TBH because of issues like this I'm glad I haven't done heavy marketing until I'm confident there's reasonably broad device/architecture compatibility.
Sujal Gurung
Mar 28
Hmm still getting those errors. Couldn't upload the lofg file from my phone so here's a google drive link: https://drive.google.com/file/d/1EfZGQ440oFXv12TMVW0GvPJPMeRt8g7V/view?usp=drivesdk
I was trying out a bunch of distros a while back so I guess I should've tested Hosaka on them more. If you do want to test on different distros, using ventoy might be more convenient than spinning up virtual machines.
Hugo Baldwin
Mar 28
Hi Sujal sorry for the trouble, and thank you again for being patient through multiple rounds of AMD-related fixes (it’s definitely an AMD thing, changing distro at the same time was simply a coincidence).
The root cause stems from when I added a direct GPU → encoder NV12 path to speed up export in v0.1.142.
The performance gain is real on most hardware, but AMD's VAAPI driver has a quirk where its hwupload filter advertises RGBA surfaces instead of NV12, causing FFmpeg to silently convert the frames to the wrong format before encoding - the encoder then rejects them with the "Function not implemented" error seen in your logs.
The recording path was unaffected because it goes through a software scale step first, which happens to sidestep the issue. Only export broke.
I’ve deployed a fix in v0.1.149 to probe whether the fast NV12 path works at startup. If it doesn't - as on your system - it falls back to a path that should still work on AMD, while still using hardware (VAAPI) encoding. So you should still get GPU-accelerated exports, just without the NV12 shortcut.
Let me know if you're still seeing issues once it's out.
Sujal Gurung
Mar 30
No worries. Sorry I didn’t get notified of this. Tested and I’m still getting the same issue (on both MX Linux as well as Arch on the same device.
Here’s logs for MX:
hosaka.log
46.2 KB
And for Arch:
hosaka-arch.log
38.8 KB
Hugo Baldwin
Mar 31
I picked up an old Lenovo with AMD CPU/GPU today to squash this bug for good - I’ll push changes up once I’ve tested them myself on AMD