clapper
clapper copied to clipboard
Rafostar
Low H.265 and AV1 playback performance
Trying to play H.265/HEVC encoded videos is very hit or miss. It seems to depend on bitrate or something. Same with AV1. I can play some AV1 and H.265 content without issue, but others will not play at all, or will run so badly it is completely unwatchable. I cannot upload the video files, but I'm mostly encountering this issue with my high bitrate movie backups.
Steps to reproduce:
It's hard to say for sure, very dependent on the media type and encoding. Usually, these are AV1 and H.265 streams in high bitrate using the matroska container. If you are able to download and convert something like 4K big buck bunny and re-encode it to a 10-bit H.265 and AV1 stream, it may not perform well.
What GPU are you using for decoding (Intel/AMD/Nvidia)?
System specifications:
Clapper 0.5.2 (Flathub)
Operating system: Fedora Linux 38 (Workstation Edition)
Desktop: GNOME 44/Latest, Wayland
CPU: AMD Ryzen 7 5800X3D x16
GPU: AMD Radeon RX 5700XT
Parhaps adding a per-codec software encoding option would be best? In Kodi, I've noticed the software H.265 and AV1 encoders tend to have better performance, compatibility, and stability. Maybe a settings section like this would be welcome and could work around this:
AMD Radeon RX 5700XT
For this Clapper currently defaults to new implementation (but might still have some bugs/issues) called VA. You can force the usage of old/legacy VAAPI implementation in preferences. You can also force usage of software decoders there (like libav_h265).
You can alter what you use (like you mentioned) in prefs dialog if you go to tweaks -> plugin ranking section. Check the name of the video decoder in popover next to progress bar during playback. Default for you should be vah265dec (for h265). Go to prefs, plugin ranking, va and set vah265dec rank override to zero. Next time you restart player vaapidecodebin should be used. If problem still persists, try software decoder by giving it higher value for this particular codec (set libav -> avdec_h265 to 300).
Indeed, this really made a huge difference. vah265dec may not be optimized on AMDGPU. Also, the AV1 decoder in question is av1dec.
Okay, so I found the av1dec under AOM. Disabling this results in no video playback, indicating there is no fallback. I'm not sure if much can be done to improve the AV1 decoder, though I am aware of multiple AV1 encoders, all of which perform differently. In particular, libsvtav1 performed the best to my understanding. Just using the plain AV1 encoder in ffmpeg was so slow, it was unusable. Perhaps the decoder can be configured differently, too?
may not be optimized on AMDGPU
It is designed for modern AMD/Intel GPUs + Wayland. Just fairly new, and AFAIK some of the issues are from GStreamer and some from Mesa driver stack. So, yeah, I am certain it will improve over time (it already works great for me for h264 which development started earliest), but all issues with it should be taken to upstream as its not Clapper fault.
AV1 decoder in question is av1dec
Yes, this AOM one is known to be worse in performance software decoder. Your GPU is unfortunately too old to support HW accelerated AV1, so you need software decoder there. A much faster one (dav1d) is part of GStreamer plugins implemented in Rust, but the problem is those are not yet shipped in Flatpak, see: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1502
@Rafostar Went ahead and asked for this decoder in the issue you mentioned. One developers' reply stated that is would be possible to include the codec in the application manually. I hope you will consider adding a better software-based AV1 decoder, as only very recent GPUs have hardware decoding and av1dec just won't cut it!! AV1 is also just, a great codec for quality and bandwidth sake...
It is my understanding that the AV1 codec is libre, so licensing shouldn't matter, right?
It is my understanding that the AV1 codec is libre, so licensing shouldn't matter, right?
Yes, this is not a problem with licensing. Since they were considering having it as part of base Flatpak runtime, I hoped it will make it for 23.08 and then all Flatpak applications would benefit from it without any changes. That would be the ideal solution, but if this did not happen in time, then the only option to have it in Flatpak is to build said GStreamer plugin that uses it by myself for my own app.
The problem with compiling this plugin is... its in Rust and we do not use Rust for anything else here at all. Adding the Rust dependencies to runtime and then using them for building GStreamer Rust plugins will not only increases package size but fundamentally breaks our CI on aarch64, because it takes many, many hours to compile (more then GitHub allows a single job to run).
In fact for x64 nightly Flatpak builds on git it was included for testing purposes, but these builds are currently broken. They will be back, but probably after other recent work on major changes to Clapper guts finishes. Right now it is questionable/debatable (I am open to discussion) if we need to also put it in stable releases. Mostly due to reasons above (and chances are SDK will include it at some point), but also not everyone needs it (still majority uses h264/h265 nowadays) and also because we already include HW decoders for it for both VAAPI and NVDEC, so modern hardware have an even better hardware decoder to use here and remaining users who really need it will be able to try nightly Flatpaks that include it on x64 at least.
Fair enough. Sounds like it could be more work than it's worth. I actually just upgraded to an AMD Radeon 7900XTX today, and I can confirm that the AV1 hardware decoder works VERY well. It had no trouble at all with decoding the video which was unplayable just the other day. H.265 and Vp9 also seem to be performing much better now, too. I previously had nearly unusable performance and compatibility, now the decoder handles anything I throw at it! That is, not with VAAPI, but the newer VA decoder. If only you could check for GPU features and selectively use the right decoder, or fallback to software.
Were the problematic videos subtitled?
The performance issues might have been https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3171, expected to be fixed in the upcoming GStreamer 1.24.0.
