FreeBSD 12.0 / Hardware transcoding issue

Hello, I just set up Plex v1.16.1.1291 on FreeBSD 12.0 (p10). I’ve subscribed to Plex Pass and tried out the hardware transcoding - all in line with instructions provided during pkg install.

Unfortunately this isn’t working for me. I’m on a Xeon E3 v5 with QSV support so certain the hardware’s capable.

I’m testing transcoding on a mobile device only. The server is currently hooked up to a monitor via HDMI, however in the near future it won’t be. I’ve read on here that there needs to be video port connection, else hardware is not engaged. That would be laughable so hopefully these reports are wrong.

So… can someone suggest a starting point? How do I troubleshoot / what do I need to test?

Thanks,
J.

Can you post the exact cpu model !?

Is this on the host or a jail ? Since its FreeNAS I assume it’s a jail.

FWIW best support is on freebsd 12 with the newer drm kernel module, and gpu firmware.
The jail needs access to dri/drm devices, the port hints out ot do it and there are other posts here on how to do so.
Also the plex user (or to be more precise the user running pms needs to be added to the video group).

As for th dummy HDMI plug that’s not so strange but it’s also not a pms limitation. It’s the OS and how it exposes the hardware. Tbh I have this working in a freebsd 12 jail and I do use the hdmi port to access the server terminal if needed, so I never had it without and I plugged it off I couldnt repo the reports, but I also dunno if this if it’s not there from start, the reports were not super clear but there are some.
Since my main server uses full disk encryption I need to type the password on boot so for me having a screen is a must :slight_smile:

Feel free to experiment though, not all folks reported that so maybe it’s not really true, but doesn’t look like a huge issue if so.

This is running without the jail and as I’ve mentioned it’s FreeBSD 12 - not FreeNAS. I’ve followed the instructions presented post-install so plex user is in video group, intel media server installed, etc. Data:

System:

# uname -a
FreeBSD <name> 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC  amd64

CPU:

# sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz
hw.ncpu: 4
hw.machine_arch: amd64
# dmesg | head -n20
CPU: Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (3312.16-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c6fbf<FSGSBASE,TSCADJ,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID

Kernel:

# kldstat
Id Refs Address                Size Name
 1   24 0xffffffff80200000  243d228 kernel
 2    1 0xffffffff8263e000    68c98 if_em_updated.ko
 3    1 0xffffffff829e6000   247e20 zfs.ko
 4    1 0xffffffff82c2e000     7628 opensolaris.ko
 5    1 0xffffffff82c36000    120e0 drm.ko
 6    1 0xffffffff82c49000      acf mac_ntpd.ko

It doesn’t make much sense to me to have to have the HDMI cable plugged in. The transcoding operation is carried out without engaging the video output and its result is sent to the client. If it needs to be plugged in, then this is an important consideration which Plex should call out in the requirements - otherwise it’s very misleading.

Much as I like to experiment, I’m hoping for you and/or others to give me some quick tips on what to do - this is a paid for subscription after all and the only reason I got it is to get the acceleration working. Hope you understand my stance. :slight_smile:

This is as you said based on “some user reports” I don’t see this my self.

E3-1225 v5 seems to be a skylake and using Intel® HD Graphics P530 which AFAIK should work.

I do notice you’re not actaully loading i915kms or the output from kldstat is not showing it (try kldstat -v |grep 915), the guide and several posts here should hint to kld_list=“/boot/modules/i915kms.ko”(which is needed if you simply want to using i915 anyway regardless if its for plex or not, this could be the issue... also check if you can access/dev/drm/renderD128in freebsd this is a symlink to/dev/drm/128`

What does that mean?

I was just checking the pkg-message and those instructions not 100% corrupt, I remember chating via email and provide correct instructions to this a while ago but I suppose the email was either missed or the maintainer did not have the time to do it, so here goes step by step:

On a FreeBSD 12.0 HOST:

  1. pkg install drm-fbsd12.0-kmod (It should ask to install gpu-firmware-kmod as a dependency and that’s ok) this is ALL YOU NEED from ports/pkg, you don’t need to install any userland drivers as this is covered by PMS.

  2. Load the pkg/port version of i915kms rather than the one that comes with the system by adding this to /etc/rc.conf and rebooting:
    kld_list="/boot/modules/i915kms.ko" (this step is always needed in any system you want to use i915kms, even if using the one provided by the system, only the path for the system one would be different, its important to understand this, and in fact its possible even the system one works for HWT with plex, but in general its best to keep it updated and the port will always be more recent.

% ls -l /boot/kernel/i915kms.ko 
-r-xr-xr-x  2 root  wheel  967760 May 15 22:27 /boot/kernel/i915kms.ko <----- SHIPS WITH BASE
% ls -l /boot/modules/i915kms.ko 
-r-xr-xr-x  1 root  wheel  2111176 Aug 27 09:07 /boot/modules/i915kms.ko <----- PORT/PKG VERSION

Loading i915kms will load drm.ko since its a dependency so you don’t need to add drm.ko to the list of loaded modules, ex: from my own server:

% cat /etc/rc.conf|grep i915
kld_list="/boot/modules/i915kms.ko"

(Reboot after you do this)

Now in a FreeBSD host (not jail) you just need one extra step, which is adding the plex user to the video group, this is all.

Enable Hardware Transcoding in PMS (Settings -> Transcoder) and try to use it.

Stop here if this is just for the host

@Jay200 Let me know if that works for you and if not I would need PMS logs to see what might be happening.

===================
For other users looking for getting this in a jail, don’t add plex to the video group in the host, instead add a devfs.rules file that you then use in the jail, it should include drm/* and dri/* paths… here is what I use in my server:

# Devices usually found in a jail.
#
[devfsrules_jail=10]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'fuse' unhide
add path 'zfs' unhide
add path 'bpf*' unhide
add path 'pf*' unhide
add path 'tmpfs' unhide
add path 'dri*' unhide
add path 'dri/*' unhide
add path 'drm*' unhide
add path 'drm/*' unhide

Then its inside the jail that plex user is added to the video group.

Thank you - this helped a bit. I can now see (hw) in when a test video is played… however switching from direct stream to transcoding in the Android app eventually kills the app. It freezes. I suspect, the issue is on the server. Specifically the Plex transcoder seems to just hang rather than deliver:

85786 plex 1 21 0 54M 15M drm_gl 1 0:00 0.00% Plex Transcoder
85077 plex 1 20 0 54M 15M &dev-> 3 0:00 0.00% Plex Transcoder

Even more oddly… once the app crashes, the video can still be seen as playing in the Plex dashboard. :slight_smile: Confusing.

If this is of use, here’s the log dump:

Sep 9 13:05:11 kernel: drmn0: on vgapci0
Sep 9 13:05:11 kernel: vgapci0: child drmn0 requested pci_enable_io
Sep 9 13:05:11 syslogd: last message repeated 1 times
Sep 9 13:05:11 kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
Sep 9 13:05:11 kernel: Failed to add WC MTRR for [0xc0000000-0xcfffffff]: -22; performance may suffer
Sep 9 13:05:11 kernel: [drm] Got stolen memory base 0x8e000000, size 0x2000000
Sep 9 13:05:11 kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Sep 9 13:05:11 kernel: [drm] Driver supports precise vblank timestamp query.
Sep 9 13:05:11 kernel: [drm] Connector HDMI-A-1: get mode from tunables:
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.modes.HDMI-A-1
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.default_mode
Sep 9 13:05:11 kernel: [drm] Connector DP-1: get mode from tunables:
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.modes.DP-1
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.default_mode
Sep 9 13:05:11 kernel: [drm] Connector HDMI-A-2: get mode from tunables:
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.modes.HDMI-A-2
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.default_mode
Sep 9 13:05:11 kernel: [drm] Connector DP-2: get mode from tunables:
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.modes.DP-2
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.default_mode
Sep 9 13:05:11 kernel: [drm] Connector HDMI-A-3: get mode from tunables:
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.modes.HDMI-A-3
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.default_mode
Sep 9 13:05:11 kernel: [drm] Connector DP-3: get mode from tunables:
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.modes.DP-3
Sep 9 13:05:11 kernel: [drm] - kern.vt.fb.default_mode
Sep 9 13:05:11 kernel: [drm] Initialized i915 1.6.0 20171222 for drmn0 on minor 0
Sep 9 13:05:11 kernel: [drm] Cannot find any crtc or sizes
Sep 9 13:05:11 kernel: drmn0: successfully loaded firmware image with name: i915/skl_dmc_ver1_27.bin
Sep 9 13:05:11 kernel: [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27)

GPU:

# pciconf -lvb vgapci0
vgapci0@pci0:0:2:0:	class=0x030000 card=0x07c51028 chip=0x191d8086 rev=0x06 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'HD Graphics P530'
    class      = display
    subclass   = VGA
    bar   [10] = type Memory, range 64, base 0xde000000, size 16777216, enabled
    bar   [18] = type Prefetchable Memory, range 64, base 0xc0000000, size 268435456, enabled
    bar   [20] = type I/O Port, range 32, base 0xf000, size 64, enabled

Oh and top also shows this in the next few seconds since transcode is triggered:
68464 plex 10 33 0 128M 64M i915fl 0 0:00 0.00% Plex Transcoder

Can you let me know which Plex logs you need exactly? How do I get them to yoy? Can’t paste here - hitting char limit I guess?

You should be able to upload the zip with the server logs, its possible its also an android app issue not pms, does it happen with other clients? Like web?

Link sent across in a private message. Some other observations:

  • I’ve ran transcoding in Chrome and again in Android… both showed (hw) in the dashboard and… neither crashed.
  • Top showed average CPU utilization at around 60-65%, which is a decrease versus prior, software transcoding tests. This seems to imply that the GPU is now engaged, however it wasn’t showing in top as it did previously - ‘i915’.

So this is a bit confusing. If you could share your thoughts after you’ve had a look at the log, that would be most appreciated. :slight_smile:

What doesn’t show in top, the transcoder process!?

No, the transcoder process is there. Referring to one of the previous posts:

85786 plex 1 21 0 54M 15M drm_gl 1 0:00 0.00% Plex Transcoder
85077 plex 1 20 0 54M 15M &dev-> 3 0:00 0.00% Plex Transcoder
68464 plex 10 33 0 128M 64M i915fl 0 0:00 0.00% Plex Transcoder

The parts in bold no longer show anything that would imply this is the drm driver / i915. Top now shows that the part in bold is CPU1, CPU2, etc.

So performance wise it seems to be utilising the GPU, however top no longer shows anything in relation to the GPU. Also, today nothing crashed. Tested on Chrome, Android client and Roku.

Ah that’s is the “STATE” honestly I have no clue what i915fl or even drm_gl, but I never saw it in that state when HWT is working … maybe it means it was waiting for the driver or something I honest have not clue and searching didn’t help much.

Perhaps a best question for FreeBSD forums.

Btw the best way to check other than pms logs and the dashboard (or pms api. via /transcode/sessions endpoint) is this:

ps axwww | grep Transcoder

Look for:
-hwaccel:0 vaapi -hwaccel_fallback_threshold:0 10 -hwaccel_output_format:0 vaapi
and
-init_hw_device vaapi=vaapi:/dev/dri/renderD128 -hwaccel_device vaapi

This indicates HWT using VAAPI is working

Thanks. I’ve started the machine again to test the above and I’m back to square one. This time, switching from direct play just hangs the client. Chrome froze while dashboard shows the video playing. The same happens for Android clients. The states in top show what I’ve referred to previously. I’m even more confused now. Nothing has changed. Why the odd behaviour?

# ps axwww | grep Transcoder
86470  -  D      0:00.20 /usr/local/share/plexmediaserver/Plex Transcoder -codec:#0x01 h264 -codec:#0x02 aac_lc -analyzeduration 20000000 -probesize 20000000 -i /hddpool/video_library/S2250003.MP4 -filter_complex [0:#0x01]scale=w=1920:h=1080[0];[0]format=pix_fmts=nv12[1];[1]hwupload[2] -filter_complex [0:#0x02] aresample=async=1:ocl='stereo':osr=48000[3] -map [2] -metadata:s:0 language=eng -codec:0 h264_vaapi -b:0 28067k -maxrate:0 37423k -bufsize:0 74846k -r:0 50 -force_key_frames:0 expr:gte(t,0+n_forced*3) -map [3] -metadata:s:1 language=eng -codec:1 aac -b:1 256k -f dash -min_seg_duration 3000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/3yxbxfmh085ven3dgxi5mbp3/8d10bc92-6637-463b-8ff0-3a6e2286f930/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -vaapi_device /dev/dri/renderD128 -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/3yxbxfmh085ven3dgxi5mbp3/8d10bc92-6637-463b-8ff0-3a6e2286f930/progress
87417  -  D      0:00.01 /usr/local/share/plexmediaserver/Plex Transcoder -codec:#0x01 h264 -codec:#0x02 aac_lc -analyzeduration 20000000 -probesize 20000000 -i /hddpool/video_library/S2250003.MP4 -filter_complex [0:#0x01]scale=w=1280:h=720[0];[0]format=pix_fmts=nv12[1];[1]hwupload[2] -filter_complex [0:#0x02] aresample=async=1:ocl='stereo':osr=48000[3] -map [2] -metadata:s:0 language=eng -codec:0 h264_vaapi -b:0 2757k -maxrate:0 3676k -bufsize:0 7352k -r:0 50 -force_key_frames:0 expr:gte(t,0+n_forced*3) -map [3] -metadata:s:1 language=eng -codec:1 aac -b:1 119k -f dash -min_seg_duration 3000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/01ndg70b5lpsjmcsrfnwlaci/c8130c08-c634-4197-bec5-d117c07e841c/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -vaapi_device /dev/dri/renderD128 -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/01ndg70b5lpsjmcsrfnwlaci/c8130c08-c634-4197-bec5-d117c07e841c/progress
88438  -  D      0:00.01 /usr/local/share/plexmediaserver/Plex Transcoder -codec:#0x01 h264 -codec:#0x02 aac_lc -analyzeduration 20000000 -probesize 20000000 -i /hddpool/video_library/S2250003.MP4 -filter_complex [0:#0x01]scale=w=1280:h=720[0];[0]format=pix_fmts=nv12[1];[1]hwupload[2] -filter_complex [0:#0x02] aresample=async=1:ocl='stereo':osr=48000[3] -map [2] -metadata:s:0 language=eng -codec:0 h264_vaapi -b:0 2757k -maxrate:0 3676k -bufsize:0 7352k -r:0 50 -force_key_frames:0 expr:gte(t,0+n_forced*3) -map [3] -metadata:s:1 language=eng -codec:1 aac -b:1 119k -f dash -min_seg_duration 3000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/cionrsneodqekwxtilco8hx8/cbdbe927-ae57-43e8-a542-390b76c574b4/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -vaapi_device /dev/dri/renderD128 -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/cionrsneodqekwxtilco8hx8/cbdbe927-ae57-43e8-a542-390b76c574b4/progress
89077  0  R+     0:00.00 grep Transcoder

Dashboard:

scr

The pic above shows status after roughly 30-60 sec from triggering transcode via each player.

Why would you do this though? Even with HWT it will still need some cpu on the server, and DP works fine, also do you have Direct Stream Disabled? It should copy the Audio since its AAC not transcode.

Do you have another sample? Like HEVC does that transcode with “HW” to h264?

Perhaps I mislabeled what I changed… From the player, I picked another video setting e.g. ‘720 high’ to force transcoding. That’s it.

I followed your advice on testing other files:

  1. MTS file, 1080i (H.264) - attempts to play in original, AC3 stereo - attempts to use AAC transcode and freezes in Chrome. Plays in Android as it does not invoke transcoding at all.

  2. MP4 file, 1080p (H.264), AC3 - plays well in Chrome. Upon trancode trigger it freezes. Android is exactly the same.

  3. MOV file, 1080p (H.264), AAC mono (unknown) - won’t play in Chrome, will play in Android. If I trigger transcode, it freezes.

  4. MKV file, 720p (H.264), no audio - plays in Chrome, upon transcode trigger it continues without any transcoding. Likewise in Android but transcode trigger freezes the app.

Link to a verbose log sent to you via private message.

Re upgrading: if I do this manually, does it not break the dependencies? I can then no longer use the pkg system - i.e. it’s all manual going forward? I would very much like to avoid the hassle. :[

This is top shown after all playback has stopped btw. The transcoder just hangs in the i915fl state - whatever that means.

About the upgrade while its not on ports yet you can try this script or something similar:

Its not ideal but it should update via the PMS API and use the ports/pkg system.

Update: PMS updated to 1.16.6.1592. Not the beta you pointed towards but thought I’d check this first. Same thing.

I started digging around a bit more and found this: 12.0-STABLE r350740 GENERIC amd64 panic when loading i915kms.k · Issue #164 · FreeBSDDesktop/kms-drm · GitHub Suspect I might be suffering from the same issue.

The dmseg output in one of my previous posts shows wrong initialisation vs the guy on github.

Also tested different versions of the libva driver as per PMS install notes (below). No change.

@@@ INTEL GPU OFFLOAD NOTES @@@

If you have a supported Intel GPU, you can leverage hardware
accellerated encoding/decoding in Plex Media Server on FreeBSD 12.0+.

The requirements are as follows:

  • Install multimedia/drm-kmod: e.g., pkg install drm-fbsd12.0-kmod

  • Enable loading of kernel module on boot: sysrc kld_list+=“drm”
    ** If Plex will run in a jail, you must load the module outside the jail!

  • Load the kernel module now: kldload drm

  • Install the supporting Intel VA support library for your GPU
    ** multimedia/libva-intel-driver: [LEGACY] Intel GMA 4500 or newer
    ** multimedia/libva-intel-media-driver: Intel HD 5000 (Gen8) or newer
    *** This must be installed beside Plex. e.g., in the jail with Plex

  • Add plex user to the video group: pw groupmod -n video -m plex

  • For jails, make a devfs ruleset to expose /dev/dri/* devices.

e.g., /dev/devfs.rules on the host:

[plex_drm=10]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_jail
add path ‘dri*’ unhide
add path ‘dri/’ unhide
add path 'drm
’ unhide
add path ‘drm/*’ unhide

  • Enable the devfs ruleset for your jail. e.g., devfs_ruleset=10 in your
    /etc/jail.conf or for iocage, iocage set devfs_ruleset=“10”

Please refer to documentation for all other FreeBSD jail management
utilities.

@@@ INTEL GPU OFFLOAD NOTES @@@