doffactory 3 Posted September 15, 2020 Share Posted September 15, 2020 So I happen to have the new Asustor Lockerstor 4 NAS, with Intel Celeron j4125. Before I used to have a much weaker AS3202T though also with Intel processor. On both I usually use transcoding. However, since the hardware update, I am unable to use the hardware encoding on the j4125 CPU. Decoding works, however, encoding does not. Under the Transcoding I have enabled the following: Enable hardware acceleration when available: Advanced Preferred Hardware Decoders- [x] MPEG-2: VAAPI UHD Graphics 605 - MPEG-2- [x] H.264 (AVC): VAAPI UHD Graphics 605 - H.264 (AVC)- [x] VC-1: VAAPI UHD Graphics 605 - VC-1- [x] VP8: VAAPI UHD Graphics 605 - VP8- [x] H.265 (HEVC): VAAPI UHD Graphics 605 - H.265 (HEVC)- [x] VP9: VAAPI UHD Graphics 605 - VP9 Preferred Hardware Encoders- [ ] H.264 (AVC): VAAPI UHD Graphics 605 - H.264 (AVC)- [ ] H.265 (HEVC): VAAPI UHD Graphics 605 - H.265 (HEVC) Transcoding thread count: AutoTranscoding temporary path: /tmpEnable throttling [x]Audio boost when downmixing: 2H.264 encoding preset: mediumH.264 encoding CRF: 22Allow subtitle extraction on the fly: [x] As you can see, I am forced do disable the hardware encoders, as the video becomes extremely choppy, if played at all. As soon as I disable the hardware encoding, the video plays, but the encoding part of the transcoding happens with the CPU instead of the GPU. I tried to switch the settings from CPU decoding and GPU encoding, but no luck. I also tried to disable the subtitle extraction, no difference. Is there some known problem with the j4125, or is it just so "new" that it is not supported by emby or its ffmpeg? Any help is more than welcome! Link to comment Share on other sites More sharing options...
Luke 37060 Posted September 15, 2020 Share Posted September 15, 2020 Hi there, let's look at an example. Please attach the information requested in how to report a problem. Thanks ! Link to comment Share on other sites More sharing options...
doffactory 3 Posted September 15, 2020 Author Share Posted September 15, 2020 (edited) Thanks, there are no specific errors that I can see, attaching the ffmpeg log. I enabled the hardware encoding, but no movement was visible on the screen, only music playing. If I disable the hardware encoding, the video plays, while CPU is on 100% (all cores). Again, this used to work on an older CPU, emby is running in a docker, so basically nothing changed only the hardware. ffmpeg-transcode-4f8fdecd-c459-49d1-b33c-902004f33331_1.txt hardware_detection-63735789268.txt embyserver.txt Edited September 15, 2020 by doffactory Link to comment Share on other sites More sharing options...
Luke 37060 Posted September 15, 2020 Share Posted September 15, 2020 And the emby server and hardware detection logs? Link to comment Share on other sites More sharing options...
doffactory 3 Posted September 15, 2020 Author Share Posted September 15, 2020 Sorry, added. Thanks for looking into this. Link to comment Share on other sites More sharing options...
doffactory 3 Posted September 16, 2020 Author Share Posted September 16, 2020 (edited) @Luke, do you see anything strange in the logs? Edited September 17, 2020 by doffactory Link to comment Share on other sites More sharing options...
doffactory 3 Posted September 19, 2020 Author Share Posted September 19, 2020 Ok, I checked some other containers, and for example tvheadend, and other competitors are having no issue with accessing and using for encoding/decoding `/dev/dri/renderD128` of the AS6604T. This means that your docker image seems to have issues with using the hardware encoding, or it is not supported with the current ffmpeg you put into the container. Link to comment Share on other sites More sharing options...
Luke 37060 Posted September 26, 2020 Share Posted September 26, 2020 Have updated to Emby Server 4.5? Have you tried our native Asustor package to see how that compares? Link to comment Share on other sites More sharing options...
doffactory 3 Posted September 26, 2020 Author Share Posted September 26, 2020 Running 4.5.0.50, from docker, all set up correctly, but the hardware encoding does not work with access /dev/dri/renderD128 (decoding does work). All the other dockers use the hw encoding correctly (e.g. tvheadend), the only issue where hardware encoding does not work is with Emby. I prefer dockerized version and not the one provided by Asustor due to my use case, should not make any difference, should it? You did not answer whether you found anything strange in the logs. Link to comment Share on other sites More sharing options...
Luke 37060 Posted September 26, 2020 Share Posted September 26, 2020 It makes quite a difference actually when running in a virtualized container such as Docker. It would be a useful test to find out how the native package compares, if you can do that. Link to comment Share on other sites More sharing options...
Luke 37060 Posted September 26, 2020 Share Posted September 26, 2020 Also is this only limited to files with mpeg4? Link to comment Share on other sites More sharing options...
doffactory 3 Posted September 27, 2020 Author Share Posted September 27, 2020 Docker is officially supported by Asustor, so IMHO — if correctly set — it should not make such a big difference to use a dockerized version of Emby. As I tested other dockerized containers for transcoding (Plex, etc.) they have no problem with transcoding with Intel UHD Graphics 605. As suggested, I am reporting this for you to test/find a solution, I am an Emby Lifelong subscriber, hope you appreciate the effort and can do something about it. Regarding the files, my answer is negative, there are the same issues with mkv and avi files as well. I will try Asustor's dedicated app in the upcoming days, if it makes any difference. Link to comment Share on other sites More sharing options...
Luke 37060 Posted September 29, 2020 Share Posted September 29, 2020 I understand, I'm just asking from the standpoint of collecting information. Quote Regarding the files, my answer is negative, there are the same issues with mkv and avi files as well. But always mpeg4 video, right? Link to comment Share on other sites More sharing options...
doffactory 3 Posted October 2, 2020 Author Share Posted October 2, 2020 No, it is also mkv encoded in HEVC. Basically anything that needs to be encoded info h264 is choppy or not playing at all. The transcoding seems to occur, however, you can see the increasing number of dropped frames. As soon as I disable hardware encoders, CPU usage goes up (naturally), but the playback is smooth/watchable. I tried to enable only the VAAPI UHD Graphics 605 - H.264 (AVC) encoding exclusively on the server (disabling H.265 hardware encoding), with the same result. If you ask me, something is not ok with VAAPI on Intel UHD 605 and its H.264 hardware encoding. Link to comment Share on other sites More sharing options...
doffactory 3 Posted October 6, 2020 Author Share Posted October 6, 2020 In the meantime I found the reason of this culprit: https://github.com/intel/media-driver/issues/930, which is a bug by Intel's implementation of the driver (not on their priority list). Link to comment Share on other sites More sharing options...
Luke 37060 Posted October 6, 2020 Share Posted October 6, 2020 That's interesting, thanks for sharing that ! Link to comment Share on other sites More sharing options...
doffactory 3 Posted October 29, 2020 Author Share Posted October 29, 2020 An update, finally, I had the opportunity to test the transcoding with the "native" Emby app from the Asustor Store. The transcoding works for some reason, I wonder what might be the issue. I had enabled the access of the docker to `/dev/dri/renderD128`... I would still prefer if the transcoding would work from the docker container, as I prefer to protect my files with the read-only option. Logs attached. embyserver.txt ffmpeg-transcode-e3ac4215-00c2-4e41-9588-420f7982bf1d_1.txt hardware_detection-63739576346.txt Link to comment Share on other sites More sharing options...
doffactory 3 Posted October 29, 2020 Author Share Posted October 29, 2020 (edited) OK, checking the logs in greater detail, and the difference is: Native Emby 4.5.2.0 from Asustor: - "Driver": "Intel i965 driver for Intel(R) Gemini Lake - 2.4.0" (transcoding decoding + encoding works) Docker Emby 4.5.2.0 - "Driver": "Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 (223f94d)" (transcoding with decoding + encoding does not work) For this reason, would it be please possible to select the driver? Or potentially fix it for Asustor AS6604T in the docker? I would greatly appreciate it. UPDATE: removing the file /lib/dri/iHD_drv_video.so from the docker solved the issue, as it immediately started using /lib/dri/i965_drv_video.so. Maybe it will help somebody. >>>>>> Processing Plan Info Name CanDoInHardware WillDoInHardware Reason Info VAAPI UHD Graphics 605 - H.264 (AVC) >> True True Hardware Codec Info VideoInput >> True True Same adapter (/dev/dri/renderD128), s... Info Scaling >> True True Info VideoOutput >> True True Hardware encoder Info VAAPI UHD Graphics 605 - H.264 (AVC) >> True True Hardware Codec Edited October 29, 2020 by doffactory typos, update 1 Link to comment Share on other sites More sharing options...
Luke 37060 Posted November 3, 2020 Share Posted November 3, 2020 Thanks for the investigation. We're looking into it. Link to comment Share on other sites More sharing options...
YeJ 0 Posted December 18, 2020 Share Posted December 18, 2020 My device is also j4125, emby version is 4.5.4.0, have same problem. Then refer this topic, I move /opt/emby-server/lib/dri/iHD_drv_video.so to other location, then hardware accelerate is ok, thanks! Link to comment Share on other sites More sharing options...
Luke 37060 Posted December 18, 2020 Share Posted December 18, 2020 7 hours ago, YeJ said: My device is also j4125, emby version is 4.5.4.0, have same problem. Then refer this topic, I move /opt/emby-server/lib/dri/iHD_drv_video.so to other location, then hardware accelerate is ok, thanks! Hi, where did you move it to? Link to comment Share on other sites More sharing options...
appoli 5 Posted December 18, 2020 Share Posted December 18, 2020 I was having some transcoding issues & noticed that Emby was defaulting to the iHD/i915 driver via the logs & had been doing the ‘workaround’ of renaming the iHD driver every time I updated Emby. However, within the past few updates (I’m on the ‘latest’/beta release fork) renaming or even removing the driver from /opt/Emby-server/lib/dri doesn’t have any effect; Emby still loads up using the iHD driver. I had tried to just embrace the change and bring the whole system into alignment so I set the driver for proxmox & the LXC container running Emby to be iHD via envi variable & I installed the intel va non-free driver via apt (I believe this is the i915 driver, right?), but that seems to have not really done much. I’ll give it another go and probably build some of the software manually, but it would be nice if there was at least a work around to getting Emby to use i965. note: I have a kaby lake Xeon e3 1245 v6 on a supermicro x11-ssh w/ the c236 chipset & provisioning for the igpu. It has not always been the most stable thing (culprit might be a bifurcated breakout board for my 2 u.2 nvme drives - it seems as though this particular model is supposed to have an SMBios hook up to the mobo, but my board doesn’t have that kind of header. It’s really only VA stuff that causes a fuss so maybe it’s not related - I have heard that the pcie port may provide enough comms from that end, but then again the VA work is probably when disk IO is at its highest...) Link to comment Share on other sites More sharing options...
doffactory 3 Posted December 18, 2020 Author Share Posted December 18, 2020 I still believe there should be an option to select which driver to use (fed up with deleting iHD every single emby update), as many of us are using emby from a docker container, there is not much one can fool around with the NAS host system drivers... Link to comment Share on other sites More sharing options...
appoli 5 Posted December 18, 2020 Share Posted December 18, 2020 Agreed. & as mentioned that doesn’t seem to be working anymore either... Link to comment Share on other sites More sharing options...
YeJ 0 Posted December 19, 2020 Share Posted December 19, 2020 (edited) 23 hours ago, Luke said: Hi, where did you move it to? move to /root, in fact, It is mean delete this file, I just want to restore if necessary, so I use move. Edited December 19, 2020 by YeJ Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now