Jump to content

Hardware Encoding Issues (j4125)


doffactory
 Share

Recommended Posts

doffactory

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: Auto
Transcoding temporary path: /tmp
Enable throttling [x]
Audio boost when downmixing: 2
H.264 encoding preset: medium
H.264 encoding CRF: 22
Allow 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

doffactory

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 by doffactory
Link to comment
Share on other sites

doffactory

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

doffactory

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

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

doffactory

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

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

doffactory

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.

image.png.dc56cdac014577618886701e126be1f2.png

Link to comment
Share on other sites

  • 4 weeks later...
doffactory

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

doffactory

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 by doffactory
typos, update
Link to comment
Share on other sites

  • 1 month later...

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

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

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

doffactory

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

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 by YeJ
Link to comment
Share on other sites

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
 Share

×
×
  • Create New...