Hadware transcode: Ubuntu 17.10, VAAPI and AMD

[KingDaveRa 2]

Hi,

 

I've been trying on and off for a while to get hardware transcoding working, but thus far had no success. My box was running Ubuntu 16.01, and I'd tried hacking on VAAPI support, but to no avail. Following a not wholly pleasant upgrade to Ubuntu 17.10, I decided to rebuild the box. Not only that, but cross-grading Emby to the new .net core version corrupted my database, and I had no backup...

 

So anyway, I've set the box up a fresh, and have been trying to get hardware encode working. I've had limited success:

 

The inbuilt version of ffmpeg fails to start the vaapi encoder with the following error:

radeonsi: driver missing
[AVHWDeviceContext @ 0x68ef20] libva: /opt/emby-server/lib/dri/r600_drv_video.so init failed
[AVHWDeviceContext @ 0x68ef20] Failed to initialise VAAPI connection: 2 (resource allocation failed).
Device creation failed: -5.
Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Input/output error
Error parsing global options: Input/output error

However, ffmpeg installed from apt, run using exactly the same command line (albeit tweaked to drop the output into /tmp) works perfectly OK with VAAPI. There's no errors, and the CPU usage is easily half (audio must be consuming the rest of the CPU time).

 

Both my login user and emby's user are members of video, so can access the DRI device. However, the error does suggest issues with the files included with the ffmpeg version packaged with emby. Indeed, the mentioned library vary wildly; emby's copy is 1.6mb, mine is 4.4mb. 

 

Prior versions of emby allowed me to specify a custom ffmpeg, but I can't do that anymore. Is there a way round this? I'm SO close to getting this working.

 

My box:

AMD A8-7600, 32Gb RAM, Ubuntu Server 17.10 x64, Emby 3.2.70.0 from .deb.

[Luke 37112]

Hi there, can you please attach the complete emby server log from the failure? thanks.

[KingDaveRa 2]

Log attached.

ffmpeg-transcode-d41048c7-ce7c-41e7-9716-a169270eaad0.txt

Edited February 12, 2018 by KingDaveRa

[KingDaveRa 2]

I forgot the actual server log, which is what @@Luke asked for. Duh.

Log.txt

[dcrdev 251]

This is because the ffmpeg bundled with emby is compiled against the amdgpu kernel implementation of the radeonsi driver. Ubuntu uses radeon/gallium for pre GCN 1.2 cards a la a8-7600, support for GCN 1.1 in amdgpu is considered experimental. 

 

The correct DRM driver implementation for gallium, is gallium_drv_video.so - ffmpeg would have to be built against that for it to work. So yes you'd have to supply a custom build, which is problematic because of the self contained nature of the package - you'd also have to modify the startup script to remove the lib directory export and revert to externally managed dependencies; or create symbolic links.

 

I don't believe gallium is well supported by vaapi anyway - it only has a limited number of working extensions; so may not be worth it.

[KingDaveRa 2]

Well I did consider trying to bodge it in, but that just doesn't sit right with me, especially as an update would probably break it (or break the update). I figured it was best to report the issue.

 

IMHO, if I just had the option of a custom ffmpeg binary back, I'd be OK, but I'm guessing that got removed for a reason.

[Luke 37112]

Primarily because we became overwhelmed with having to troubleshoot user's personal ffmpeg builds.

[KingDaveRa 2]

Ahh. Thought as much.

 

It's annoying, because I now have all the components, but I just can't join them up! Point is though, I'm using nothing custom - my ffmpeg is straight from Ubuntu's repos, and that seems to work. Is there anything I can do, or am I out of luck here? I mean, plan B is I rebuild the box with an i5 I have kicking around and go with quicksync.

[Luke 37112]

You can always just replace the binaries if you really need to. Yes that means you have to do that following updates, but i imagine that's not something you're doing every day.

[KingDaveRa 2]

OK, I'll give it a go and see if it works.

[dcrdev 251]

You can always just replace the binaries if you really need to. Yes that means you have to do that following updates, but i imagine that's not something you're doing every day.

 

Just to add to this - you shouldn't replace them, that will not help.

 

If you must create symbolic links to the distro provided ones, otherwise the paths will be incorrect.

[KingDaveRa 2]

Yeah, I was looking at the included libraries with ldd, and there's a boatload of them, so it'll be very messy. I've just tried tweaking about the emby-server startup script, but no joy becuase I think the LD_LIBARY_PATH needs duplicate stuff in it, which will just make more problems than it solves. So what I'm thinking I might try is making a wrapper script for ffmpeg to set the environment back just for ffmpeg/ffprobe. That might well work. Bit hacky, but cleaner, and more easily maintained.

 

Can't try now though, too late in the day, so I'll have a whack tomorrow.

[KingDaveRa 2]

I had a think, and decided it was far easier to concede defeat and put the i5 back in. So I have, and now it's doing hardware transcode without any fuss. I was looking to do hardware transcode with TVHeadend as well, and that was goofing up, so I decided it was best to go with the best-supported solution.

 

Thanks for the help all.

[KingDaveRa 2]

A final postscript: I've also got TVHeadend and the TVHeadend plugin setup, and it happily transcodes with QuickSync with that too, which in itself is oddly ironic considering tvheadend errors when trying to use libaav.

 

Anyway, all Just Works, which is exactly what I wanted. Thanks for all the hard work on making this work, it's truly appreciated. I use Emby a lot for watching my media remotely, and do sometimes make use of the TV streaming, so this is a great enhancement.