Jump to content

Enable hardware acceleration on FreeBSD


Recommended Posts

Hi guys,
I'm currently figuring out how I can enable ffmpeg to use my /dev/dri/renderD128 device which is the iGPU of my intel chip. Currently I have the following things covered:
- drm module is loaded and /dev/dri/renderD128 is accessible in jail
- emby user has access to the device node
- I have installed libva-intel-driver and it is picked up by vainfo
- ffmpeg is compiled with libva support
I'm sure that emby can access the node and use it with the ffmpeg supplied by emby. As show in the following command output:
root@emby:/usr/local/lib/emby-server/bin # su -m emby -c "./ffmpeg -vaapi_device /dev/dri/renderD128"
ffmpeg version 4.0.2-emby_p_2018_12_01 Copyright © 2000-2018 the FFmpeg developers
  built with FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
  configuration: --cc=cc --disable-autodetect --disable-doc --disable-ffplay --disable-shared --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-iconv --enable-libass --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libopus --enable-libtheora --enable-libvorbis --enable-libwebp --enable-libx264 --enable-libx265 --enable-libzvbi --enable-static --enable-vaapi --enable-version3 --enable-libmp3lame --disable-libsmbclient
  libavutil      56. 14.100 / 56. 14.100
  libavcodec     58. 18.100 / 58. 18.100
  libavformat    58. 12.100 / 58. 12.100
  libavdevice    58.  3.100 / 58.  3.100
  libavfilter     7. 16.100 /  7. 16.100
  libswscale      5.  1.100 /  5.  1.100
  libswresample   3.  1.100 /  3.  1.100
  libpostproc    55.  1.100 / 55.  1.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
Use -h to get full help or, even better, run 'man ffmpeg'
Even if I supply an input file and output file for the sake of example it starts transcoding just fine on hardware.

root@emby:/tmp # su -m emby -c "/usr/local/lib/emby-server/bin/ffmpeg -vaapi_device /dev/dri/renderD128 -i /media/movies/Avatar\ \(2009\)/Avatar\ \(2009\).mp4 test.mp4"

Chapter #0:72: start 10688.469000, end 10689.481000

      title           : Chapter 72
    Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080 [sAR 1:1 DAR 16:9], q=-1--1, 23.98 fps, 24k tbn, 23.98 tbc (default)
      creation_time   : 2013-04-18T10:50:46.000000Z
      encoder         : Lavc58.18.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
      creation_time   : 2013-04-18T10:53:43.000000Z
      encoder         : Lavc58.18.100 aac
frame= 1124 fps= 54 q=28.0 size=   12290kB time=00:00:47.29 bitrate=2128.7kbits/s dup=1 drop=0 speed=2.28x


This indicates to me that the user emby is able to use /dev/dri/renderD128 and should be able to use the device node and hardware.

In the web interface under transcoding I see nothing popping up as possible hardware accelerators as show in picture.

I have attached my hardware detection log and my most recent server log where the server starts up and does some hardware detection stuffs.



This is my output from vainfo:

vainfo: VA-API version: 1.4 (libva 2.4.0)
vainfo: Driver version: Intel i965 driver for Intel® Skylake - 2.3.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileH264ConstrainedBaseline: VAEntrypointFEI
      VAProfileH264ConstrainedBaseline: VAEntrypointStats
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264Main               : VAEntrypointFEI
      VAProfileH264Main               : VAEntrypointStats
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointFEI
      VAProfileH264High               : VAEntrypointStats
      VAProfileH264MultiviewHigh      : VAEntrypointVLD
      VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileH264StereoHigh         : VAEntrypointEncSlice
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice






Edited by Duffyx
  • Like 1
Link to post
Share on other sites

I'm installing Emby from ports by using my local patch against the ports tree (the one which is currently in review and soon to be committed for everyone to use; FYI)

Edited by Duffyx
Link to post
Share on other sites
  • 2 weeks later...

Could you please try adding this to the emby-server service file?

export LIBVA_DRIVERS_PATH=/usr/local/lib/dri
Edited by alucryd
Link to post
Share on other sites

Any specific location in the service script I should put this? :) Will test later today.

Edited by Duffyx
Link to post
Share on other sites

Hi, I just added the entry as such:

. /etc/rc.subr
load_rc_config ${name}

: ${emby_server_enable:="no"}
: ${emby_server_user:="emby"}
: ${emby_server_group:="emby"}
: ${emby_server_data_dir:="/var/db/emby-server"}
: ${emby_server_ffdetect:="/usr/local/lib/emby-server/bin/ffdetect"}
: ${emby_server_ffmpeg:="/usr/local/lib/emby-server/bin/ffmpeg"}
: ${emby_server_ffprobe:="/usr/local/lib/emby-server/bin/ffprobe"}

export LIBVA_DRIVERS_PATH=/usr/local/lib/dri

command_args="-f -p ${pidfile} ${procname} /usr/local/lib/emby-server/system/EmbyServer.exe \
        -os freebsd \
        -ffdetect ${emby_server_ffdetect} \
        -ffmpeg ${emby_server_ffmpeg} \
        -ffprobe ${emby_server_ffprobe} \
        -programdata ${emby_server_data_dir} \
        -updatepackage emby-server-freebsd_{version}_amd64.txz"

Although it did not help out, my hardware transcoding menu is still blank after restarting emby-server.

Edited by Duffyx
Link to post
Share on other sites
  • 2 weeks later...

Thanks for the feedback. I'm trying sth with our ffdetect binary, it'll take a few hours to build, but I'd like you to try it out when it is done if that's okay with you. You won't need to export LIBVA_DRIVERS_PATH with this one.

Link to post
Share on other sites

There you go: https://paste.xinu.at/XEifg/


Could you first try running the following with this binary and post the result here?

ffdetect vaencdec

If your vaapi devices are detected it should work within emby as well, you can then try replacing the ffdetect binary shipped with emby with this one.

Link to post
Share on other sites
Result of command:

sudo ./ffdetect vaencdec

ffdetect version 4.0.3-emby_2019_03_26 Copyright © 2018-2018 softworkz for Emby LLC

  built with gcc 8.3.0 (FreeBSD Ports Collection)

  configuration: --cc=gcc --arch=x86_64 --prefix=/usr/home/embybuilder/Buildbot/x64_freebsd/ffdetect-x64_freebsd/staging --pkg-config=pkg-config --disable-doc --disable-ffmpeg --disable-ffplay --disable-ffprobe --disable-vdpau --enable-vaapi --extra-libs='-ldrm -lva -lva-drm -ldl -lm -lpthread' --disable-shared --enable-static

  libavutil      56. 14.100 / 56. 14.100

Link to post
Share on other sites

Can someone provide a command that I can use to assure it is not a driver problem?

E.G. that the device node at /dev/dri/renderD128 works as expected and it is in fact an Emby issue.

I'm starting to think that might not be the case but at least if not we can rule it out.

Edited by Duffyx
Link to post
Share on other sites

As some extra information for the devs, I'm not running any X11 server or Wayland on my server ("headless" with a screen of console output). Of course everything else is loaded, such as the iGPU drm module etc.

Edited by Duffyx
Link to post
Share on other sites

Can't passthrough my /dev/dri directory to KVM because freebsd doesn't support the 9p protocol so this is kinda hard to test, but it looks like a bug in our ffdetect, it should definitely be working when using system libva libraries. We will notify our dev to get some insight.

  • Like 1
Link to post
Share on other sites

You could try these two things:


  • sys_analyzer_linux.zip
    This is a graphics assessment tool from Intel

  • ffdetect_linux_x64.zip
    An ffdetect version with minimal dependencies. Should be run in a plain vanilla shell without any any modifications of environment variables etc. and from a directory that doesn't contain any other libraries (.so) or 'drivers'.




Link to post
Share on other sites
  • 4 weeks later...
  • 3 weeks later...

I just tried with Emby but still ffdetect can't find my drm node for some reason while vainfo still reports everything being fine.

  • Like 1
Link to post
Share on other sites

Just wanted to chime in with the same problem.

I've been lurking in this thread since it was originally posted, and i've been silently trying to same suggestions without any luck.


Just so the devs are aware that there are at least two FreeBSD users out there :D

  • Like 1
Link to post
Share on other sites
  • 2 weeks later...
  • 2 weeks later...

We're still trying to chase this down. If you know someone knowledge about this in the freebsd community let them know we'll be happy to employ them temporarily to help us with it. Thanks.

Link to post
Share on other sites
  • 3 weeks later...

I'm wondering if there is like a hidden option in the web interface that the user can enforce hardware transcoding.

That option would just hard use the render node, instead of relying on the ffdetect to detect it.

That way we could rule out that Emby *can/cannot* use a render node and it is a bug in the fftdetect binary.

Edited by Duffyx
Link to post
Share on other sites
  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...