AMD Ryzen 5 3400G not transcoding HEVC on linux with HWA

Hi Guys,

I’m hoping if someone can shed some light on this.

I am a new Jellyfin user and I quite like it.

My server has an AMD Ryzen 5 3400G APU. On linux(Ubuntu server 20.04), I can turn Hardware Acceleration(HWA) on, using VAAPI, and it works fine for the most part, but when I turn it on for HEVC, the videos play black, which means HWA does not work on linux for HEVC files.

Just to test it out, I installed WIndows 10 on my server, with the latest proprietary AMD drivers, and Jellyfin(ffmpeg) uses HWA fine for HEVC files, which means the APU can do it, but not on Linux, for some reason.

AMD does not have proprietary drivers for this specific APU for Linux, so I am using whatever comes installed with Ubuntu server 20.04.

Can anyone please help? Is this purely because ffmpeg(Jellyfin’s version) does not support HWA for AMD GPUs/APUs?(or even my specfic APU) Or is there something else I am missing?

Jellyfin version: 10.6.4
Installation: both Docker and on metal

Cheers

Anyone please? Just need confirmation if there’s something on my side to get Hardware Acceleration on my AMD APU on Linux, or if it’s simply unsupported.

Cheers

Sadly I only have an AMD CPU, not an APU. The only thing that comes to mind is making sure you have the Mesa 20.4(?) or newer driver installed.

Thanks so much for the reply.

I have two questions.

  1. How do I check the Mesa driver version?
  2. Per what you’re saying, does it mean hardware acceleration on a normal AMD GPU should just work fine on all situations on Linux?

EDIT: Because I am using Ubuntu server 20.04, without a GUI, might I be missing something because of that?

Cheers

3400G(VCN1.0) supports up to HEVC 10bit and VP9 10bit decoding and HEVC 8bit encoding.

  1. sudo apt list --installed | grep mesa-va-drivers to check Mesa driver.
  2. sudo apt install vainfo -y && vainfo to show amdgpu capabilities.
  3. For transcoding HEVC on amdgpu, Mesa >= 20.1 is required.
  4. For transcoding multiple videos simultaneously on amdgpu with VCN engine(Raven, Picasso, Renoir, Navi), kernel >= 5.8 is required.

Hi nyanmisaka,

Thanks a lot for the info, super useful.

So I have installed the very latest drivers using the paa:oibaf/graphics-drivers repository(before I started this thread). Not sure this is the correct repository I should use, but I do have 20.3 version, it seems. I did this a few weeks ago, and from what I can find, I remember reading somewhere that Ubuntu server 20.04 only comes with 20.0, but I might be wrong. When I run 1. I get:

mesa-va-drivers/now 20.3~git2009030730.98e866~oibaf~f amd64 [installed,upgradable to: 20.3~git2009050730.57fba8~oibaf~f]

When I run vainfo, I get:

error: can't connect to X server!
libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Mesa Gallium driver 20.3.0-devel for AMD RAVEN (DRM 3.39.0, 5.4.0-45-generic, LLVM 10.0.1)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

Error in the first line is because I have no Desktop Environment installed, it’s pure ubuntu server.

So here we can see it can transcode HEVC, right?

Also, it says Mesa Gallium driver 20.3.0-devel for AMD RAVEN, but this 3400G is a Picasso. Not sure if this is an issue.

When I run uname -a I get:

Linux myserver 5.4.0-45-generic #49-Ubuntu SMP Wed Aug 26 13:38:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Kernel 5.4 -> Would this support HEVC transcoding on AMD GPUs/APUs?

Thanks a lot for the help again.

Transcoding HEVC videos should work on the host with Mesa 20.3-dev.

VAAPI is still available when running in headless mode.

Picasso is nearly identical to Raven, so it is not an issue.

There is an issue in kernel < 5.8, which will reset the gfx driver when transcoding multiple videos.

You can try to transcode HEVC videos in yuv420p/yuv420p10le pixel format using jellyfin and feedback the ffmpeg log if the problem persists.

Thanks for the reply nyanmisaka.

I digged a bit more into this.

I completely removed mesa drivers 20.3 and the repo I mentioned above, and I re-added the same repo and re-installed latest mesa drivers (still 20.3), and now it does say it’s a Radeon Vega 11 GPU when running vainfo, which is correct.

Now is when the weirdness starts to happen. So far, I only tried HEVC videos recorded with my go pro Hero 7 black, and a few from here: http://www.jell.yfish.us/ and none of the HEVC ever transcode with hardware acceleration(even on Mesa drivers 20.3). So I remembered to try an HEVC video recorded with my iPhone, and that one does use Hardware Acceleration fine, but only on a few “modes”. For example, if when the video is playing, in the cogwheel for the transcode quality I choose 1080p – 30 Mbps, it transcodes fine, but almost all other quality options like the 720p ones, or 480p ones, and even some of the 1080p ones, never work. But at least we are getting somewhere. Could this be because different cameras use different “settings” to record with HEVC, and for some reason my ubuntu server setup does not like those other videos? I want to stress that on Windows, this all worked fine.

Is it worth updating the kernel and see what I get? It’s ok for me to do that as I am still setting this server up and it’s not in production yet, so if anything gets messed up with the OS, I can just re-install.

Cheers

Can I have the ffmpeg log with errors?

If there are scenarios where two or more videos are transcoded at the same time, please update the kernel 5.8. Otherwise it will definitely cause a crash.

Hi,

Sorry I completely forgot about the logs.

This one is a log that is created when a transcode fails, the ffmpeg_transcode_*****.txt: https://pastebin.com/ADgvWsWv

There is a .log file which I assume is a general log. I’ve noticed that when a transcode works well, an ffmpeg_transcode_******.txt file does not get created. I can’t find a way to share that one as it’s big and pastebin won’t take it as it is bigger than 512Kb. Let me know if you really need it.

I also want to say that I am never trying to transcode more than one video at the same time.

Thanks a lot for the help

Seems that you are using jellyfin in docker instead of on the host. Therefore you need to install Mesa >= 20.1 in docker.

This is a log of the same video not transcoding in the host with mesa 20.3: https://pastebin.com/2nQi3mcZ

Does this help?

Cheers

No VA display found for device /dev/dri/renderD128. Device creation failed: -22. Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Invalid argument

ls /dev/dri will show you all possible gfx cards.
Vega 11 may at renderD129 drm node if you also have a discrete gfx card installed.
Change it in Jellyfin->Dashboard->Playback.

btw jellyfin-ffmpeg 4.3.1-1 is recommanded for better performance.

I don’t have a discreet GPU, only this APU. When I run: os -ltr /dev/dri I get:

user@myserver:~$ ls -ltr /dev/dri
total 0
crw-rw---- 1 root video  226,   0 Sep 10 13:03 card0
crw-rw---- 1 root render 226, 128 Sep 10 13:03 renderD128
drwxr-xr-x 2 root root         80 Sep 10 13:03 by-path

So my device really is /dev/dri/renderD128 and that’s what I have set in Jellyfin.
I also tried card0 in Jellyfin but it gives me the same results.

I quickly googled for this error and some people said this was because Jellyfin didn’t have permission to access that device, but when I set this all up I have added my user and jellyfin to the render and video groups. Am I missing something here?

Regarding the ffmpeg version you’re recommending, I am literally just using the one that comes with jellyfin when you install it, be it using docker or the host.

Anything you can recommend?

Thanks a lot

In my experience, VAAPI is also available in headless mode. But in this case, a connected monitor is needed, or try to install Jellyfin and the new version of Mesa in docker.

Sorry about the noob question here, but what does headless mean? I can connect to the machine with a monitor, but I don’t have a desktop environment installed as it is puire ubuntu server 20.04.

In regards to your suggesting about trying to install latest mesa and jellyfin in docker, shouldn’t I make sure it runs on metal first? Wouldn’t Docker just add another layer of complexity?

Cheers

Ubuntu server lacks of Xorg x11 GUI comparing to Ubuntu desktop that may result in the requirement of a display.

Passing the vaapi device to docker seems can avoid this problem.

Here is a basic ffmpeg command to verify vaapi transcoding.

ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i /home/user/input.mp4 -c:v h264_vaapi -b:v 8000000 -level 4.1 -vf 'format=nv12|vaapi,hwupload,scale_vaapi=format=nv12' -c:a copy -strict -2 -y /tmp/output.mp4

So just to see if I understood you correctly, you’re saying that because I am trying jellyfin on metal on ubuntu server 20.04 without Xorg, that’s why hardware acceleration is not working properly? And also the fact that my docker doesn’t have latest mesa drivers it doesn’t work through docker, but if I install latest mesa drivers on docker this all should work?

Running that command on metal, I get: https://pastebin.com/7ufd1H3W

[h264_vaapi @ 0x559993432140] Driver does not support some wanted packed headers (wanted 0xd, found 0).

[h264_vaapi @ 0x559993432140] Driver does not support packed sequence headers, but a global header is requested.

[h264_vaapi @ 0x559993432140] No global header will be written: this may result in a stream which is not usable for some purposes

Does this mean anything?

Thanks

@nyanmisaka This worked. Yayyyy

I am running LSIO Jellyfin docker image, I updated the mesa drivers in the docker container to latest, and now hardware acceleration works fine all around. Thanks so much for the help and patience with me so far.

So I am guessing the problem really was running Jellyfing on metal without Xorg(desktop environment) installed, and using docker bypasses this!

Thanks so much

[h264_vaapi @ 0x559993432140] Driver does not support some wanted packed headers (wanted 0xd, found 0).

[h264_vaapi @ 0x559993432140] Driver does not support packed sequence headers, but a global header is requested.

[h264_vaapi @ 0x559993432140] No global header will be written: this may result in a stream which is not usable for some purposes

This usually does not affect our usage.
It’s a WIP function in amdgpu driver that may affect the encoding of MKV videos.