Skip to main content

Low bitrate even when exporting with High quality on 720p display

Feature Request

Hello. Even when exporting at high quality, the final video’s bitrate seems to be low.

Hosaka recording:

vs. OBS output (directly uploaded OBS mkv to YouTube):

I know youtube does some video processing too but even when viewing the exported video locally, it has artifacts. My display resolution is 1366×768. Attached logs as well.

screen.txt

70.8 KB• Text

There’s this log in particular about the app using CPU encoding:

10:45:47.410 WARNING hosaka.core.ffmpeg:190 - VAAPI runtime probe failed. AMD GPU detected - ensure 'mesa-va-drivers' is installed. Falling back to CPU encoding.


Might that be causing the issue, or is it ffmpeg settings? I did try fixing it yesterday but couldn’t find a way.

Posted by Sujal Gurung ·
Status: Completed7 comments

Log in to comment and vote

Comments7

  • Hugo Baldwin changed status to Completed
    Team•

    Mar 18

    Pinned

    @Sujal Gurung A fix for this has gone in to v0.1.121. Please let me know if you encounter further issues or if this (or the other solutions in my comment) doesn’t improve the exported video for you.

  • Hugo Baldwin

    Team•

    Mar 18

    Thanks for the detailed report, you hit a real bug.

    The root cause: your system is falling back to CPU encoding with libopenh264 (because VAAPI isn't available and libx264 isn't installed). Unlike libx264, libopenh264 doesn't support CRF quality mode and was silently ignoring the quality preset, encoding at a very low default bitrate. A fix is in the next release that forces the target bitrate when libopenh264 is used.


    A couple of things that would give you noticeably better results in the meantime:

    • Fix VAAPI. mesa on Arch already includes the AMD VA-API driver (libva-mesa-driver), so if VAAPI isn't working the missing piece is likely libva: sudo pacman -S libva libva-utils. You can confirm it's working with vainfo. If it lists your AMD GPU's encode/decode profiles, the app will use hardware encoding automatically.

    • Install x264. If you'd rather stay on CPU encoding, libx264 supports proper CRF mode and will respect the quality preset correctly: sudo pacman -S x264.

    • Sujal Gurung

      •

      Mar 18

      Thanks. x264 actually improved the quality. Or it might have been the update.

      For va-aapi, I’ve been trying for a while but couldn’t find a fix. After a lot of back and forth, Gemini Pro concluded that my setup is correct and the issue probably lies with Hosaka itself. Thought I’d share what I tried.

      I already had libva installed before but still got the errors. All the LLMs I tried said that system level libva isn’t accessible to flatpak so I’d have to install things within flatpak. Some models hallucinate and tell me to install something like org.freedesktop.Platform.VAAPI.AMD using flatpak, which actually doesn't exist?

      Gemini Pro says the correct packages are org.freedesktop.Platform.GL.default//24.08, flathub org.freedesktop.Platform.GL.default//24.08-extra, and org.freedesktop.Platform.ffmpeg-full//24.08.

      Note: it recommends using these exact version numbers, and flatpak update may updated these to newer versions, which it says can cause issue?

      I had all these installed but was still getting the error, at which point Gemini concluded it’s probably an issue with the app itself. Here’s the summary it gave

      Bug: VA-API probe fails with Error -22 on AMD GPUs (Mesa)
When launching Hosaka Studio via Flatpak on an AMD GPU, the VA-API runtime probe fails. The logs show [vf#0:0] Terminating thread with return code -22 and [vost#0:0/h264_vaapi] Task finished with error code: -22.

The Flatpak environment has the correct org.freedesktop.Platform.GL.default//24.08-extra extensions installed and mounted. Since the vf (video filter) thread is throwing the Invalid Argument error, it appears the ffmpeg probe command in hosaka.core.ffmpeg is missing the format=nv12,hwupload filter, or is passing a resolution/parameter that AMD's radeonsi driver strictly rejects. Intel/Nvidia might accept it, but AMD requires strict NV12 formatting and even-numbered dimensions for VA-API encoding.


      I’ve also collected output for different approaches / fixes that Gemini suggested here, all with no success:

      https://gist.github.com/gursuj/332921a1a5a4ad6a0c940d2da9e918c5

      • Hugo Baldwin

        Team•

        Mar 19

        Thanks for the detailed report!

        I found a bug where the export dialog also wasn't applying the quality preset correctly on open, and the default config had the wrong values (8 Mbps instead of 20 Mbps) This has been fixed in v0.1.124.

        The VA-API -22 error is a separate issue - it's Flatpak's sandbox blocking direct access to the DRI render node (/dev/dri), which VA-API needs. You may be able to work around it with:

        flatpak override --user --device=dri io.hosaka.studio


        That should expose the GPU to the app. I'll look into including this in the Flatpak manifest by default so it works out of the box. Ultimately I think the long-term fix for this and other issues it to just set up an Arch repo although testing this on all the various distros adds up.

        • Sujal Gurung

          •

          Mar 19

          Hmm I had tried using —device=dri before, albeit with com.hosaka.studio. When using `io.hosaka.studio, I still get same errors. 

          09:26:52.619 DEBUG hosaka.core.ffmpeg:176 - Running VAAPI runtime probe...
09:26:52.630 DEBUG hosaka.ui.recording_modal:1105 - Audio warmup complete - all recorders ready
09:26:53.211 DEBUG hosaka.core.ffmpeg:124 - VAAPI runtime probe failed (exit 234): id argument)
[vost#0:0/h264_vaapi @ 0x561fc3656a00] Could not open encoder before EOF
[vost#0:0/h264_vaapi @ 0x561fc3656a00] Task finished with error code: -22 (Invalid argument)
[vost#0:0/h264_vaapi @ 0x561fc3656a00] Terminating thread with return code -22 (Invalid argument)
[out#0/null @ 0x561fc34e3400] Nothing was written into output file, because at least one of its streams received no packets.
frame=    0 fps=0.0 q=0.0 Lsize=       0KiB time=N/A bitrate=N/A speed=N/A
Conversion failed!

09:26:53.212 WARNING hosaka.core.ffmpeg:190 - VAAPI runtime probe failed. AMD GPU detected - ensure 'mesa-va-drivers' is installed. Falling back to CPU encoding.
09:26:53.213 DEBUG hosaka.pipeline.encoder:99 - Codec libx264 not in available codecs
09:26:53.213 WARNING hosaka.pipeline.encoder:186 - No encoders available, defaulting to CPU


          CPU encoding is good enough for me for now. Maybe building an AppImage might be more convenient than having a separate build for arch / other distros? Probably not worth catering to specific distros unless you get large userbases from them? I won’t be able to immediately buy the app after the trial cause of financial circumstances, but I would like to do so in the future.

          I don’t really understand linux packaging but Gemini says the AppImage could help solve these issues. [These guys](https://github.com/pkgforge/) have a discord server if you wanna talk to people experienced with linux packaging.

          • Hugo Baldwin

            Team•

            Mar 19

            I actually originally built AppImages but switched to Flatpak believing it would be better in order to provide users with automatic updates.

            Dealing with all the various Flatpak permissions issues is a nuisance though (this is actually why I started building Fedora packages) so I think it’s actually simpler to go with deb/rpm/arch support since that already covers the vast majority of popular Linux distros.

            Some of the outstanding Wayland compositor issues (an unreleased xdph bug fixed in #366 for example) when combined with Flatpak distribution simply prevent the necessary combination of screen capture without cursor + cursor coordinate capture from working properly.

            I’ve emailed you a license key for Hosaka Studio because I’m grateful for the bug reports you’ve provided.

            • Sujal Gurung

              •

              Mar 19

              Super grateful for the license key! Thank you for your kindness.

              There's actually some tools to auto update appimages like you'd do with package managers, and even package managers for appimages. Could you check this blog:

              https://raghukamath.com/automatically-updating-nightly-builds-of-krita-on-linux/

              I use that approach and have a single shell script that runs update commands for pacman, yay and appimages. It does require you to sign the appimage with update info or something like that. Could recommend users to do that?