Jump to content

different behaviour in hardware transcoding between emby 4.2.1.0 and 4.4.2.0


Yrosma

Recommended Posts

Yrosma

Not sure if this is in the right location so if it's not just move it.

 

We are trying all kinds of different hardware with xponology and running emby server via docker.

We had some issues before with the intel with hd605 graphics boards. This was fixed for xponology so we could use them for hardware transcoding. At least we tough that was the case.

We were running emby server 4.4.2.0 and transoding kinda worked but was mostly scrambled blocks and stuff so even though emby said vaapi was being used the eventual result was kinda crappy and therefor not usefull.

Just for reference and testing purpose we reversed emby server to the 4.2.1.0 release. And a bit too our surprise everything worked fine with emby server 4.2.1.0.

 

Now we are wondering what could be causing this difference in a messed up transcoding output in 4.4.2.0 and a correctly working transcoding output in 4.2.1.0?

 

Just guessing here, driver difference in the emby docker image? or different build of ffmpeg that is used for the transcoding? I assume the emby docker images contain their own ffmpeg build?

 

For now we can just use the 4.2.1.0 emby server. But would be nice if at one point we could upgrade to the latest one without problems and we also would just like to understand what is happening here.

Link to comment
Share on other sites

Yrosma

Hi there, can we please look at an example?

Hi Luke, what exactly do you need. Friday I'm at my friend again and we can look into this again.

For now I was thinking about getting logs for the emby 4.2.1.0 release. Then upgrade the emby server to emby 4.4.2.0 again and try and collect the log files again.

Is this enough for you as an example? Or should we do also try some other things?

Link to comment
Share on other sites

Hi Luke, what exactly do you need. Friday I'm at my friend again and we can look into this again.

For now I was thinking about getting logs for the emby 4.2.1.0 release. Then upgrade the emby server to emby 4.4.2.0 again and try and collect the log files again.

Is this enough for you as an example? Or should we do also try some other things?

 

I would check out softworkz suggestion and see if that helps. Thanks.

Link to comment
Share on other sites

Yrosma

I couldn't exactly do what was suggested in the other topic. Things like the /opt folder which I don't have in my docker image on my xpenology nas and I also couldn't find anything like the emby server config file to set the export.

But I did manage to try some other things.

I checked the ffdetect on the docker container for emby 4.2.1.0 which is working for us and that one is using DEVICEINFO:Driver=Intel i965 driver for Intel® Gemini Lake - 2.3.0.

We also checked the emby server 4.4.2.0 and latest beta version. Both have newer versions. 2.4.0 for the Intel i965 driver. This one we can't get to work. It does use hardware transcoding but the output is scrambled. We also tried the iHD_drv_video.so driver for the newer versions but they all give the same result.

We also did copy the Intel i965 2.3.0 driver to the 4.4.2.0 emby server and then the transcoding is working correctly again.

 

So somehow things go wrong with the newer drivers for us as the old driver is working.

 

Not sure what to do to get it working with the newer drivers?

Link to comment
Share on other sites

That's interesting, thanks for the investigation. We'll try to chase it down.

Link to comment
Share on other sites

  • 8 months later...

Currently we don't have any custom xpenology nas running on the hardware we saw this issue on.

We can check if we still have some hardware laying around to quickly build a custom nas to check if this is still happening with 4.5. I probably will post an update in a few days when we have tried it out.

 

 

 

Edited by Yrosma
Link to comment
Share on other sites

OK we did try on a xpenology nas with 4.5.4.0 and 4.2.1.0. Same issue is still there. 4.2 works fine. 4.5 does do the transcoding but video is full of artifacts. Time as limited as of covid and us having a curfew in the Netherlands.

But I kinda forgot I have a Synology DS920+ which also has shown the same issue before I could just try on this one.

To make sure we are talking about the same thing, short overview of the setup. I use emby in the docker environment installed on synology (or xpenology). So I'm not using the emby app from the package center but the docker image. I'm using the emby docker images from emby/embyserver. CPU/iGPU from the DS920+ is INTEL Celeron J4125.

emby docker 4.2 is working fine. When I check the detection using ffdetect it shows the following driver/lib:
 

detected as "VAAPI Intel Corporation Device 12677 - MPEG-2"
/dev/dri/renderD128: VA-API version: 1.4 (libva 1.4.0)
/dev/dri/renderD128: Driver version: Intel i965 driver for Intel(R) Gemini Lake - 2.3.0

emby docker 4.5 has the transcoding artifacts and shows the following driver/lib

"DeviceName": "UHD Graphics 605"
/dev/dri/renderD128: VA-API version: 1.7 (libva 1.7.0)
/dev/dri/renderD128: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 (ac0a19f)

About the following I'm not sure anymore now if I did this correctly in my previous attempt seeing the result I have now. I thought I did play around with the drivers on the 4.5 image and it didn't matter at that time. But when I renamed the iHD_drv_video.so that's located it /lib/dri so that it isn't used anymore by emby and emby will use the i965_drv_video.so from the same /lib/dri the transcoding works fine on emby 4.5. So it looks like the at least for my setup the iHD driver doesn't work that nicely. Again not sure if this also already was the case in my previous attempt but then I got it too work by using the i965 driver from the 4.2 docker image.

Conclusion so far: I can get it to work for emby 4.5 by just renaming the iHD driver in the emby docker image.

 

Is there a reason why emby is preferring de iHD driver over the i986 driver? Or is this handled by linux? For me the solution would be to remove the iHD driver from the docker image but I have no idea about the implications of that action and if it would break other setups.

as additional information the i986 driver in the 4.5 docker image is newer then the one in the 4.2 image:

"DeviceName": "UHD Graphics 605"
/dev/dri/renderD128: VA-API version: 1.7 (libva 1.7.0)
/dev/dri/renderD128: Driver version: Intel i965 driver for Intel(R) Gemini Lake - 2.4.0

 

Next Saturday I will check on the xpenology nas again if it's the same there. I think the CPU/iGPU where the same or at least the iGPU so I expect the same solution will work there.

 

Edited by Yrosma
Link to comment
Share on other sites

K22R8CT
On 2/7/2021 at 1:28 AM, Yrosma said:

But when I renamed the iHD_drv_video.so that's located it /lib/dri so that it isn't used anymore by emby and emby will use the i965_drv_video.so from the same /lib/dri the transcoding works fine on emby 4.5.

Emby 4.6 includes an updated iHD driver which fixes encoding/decoding on Gemini Lake (J4125.)

Link to comment
Share on other sites

18 hours ago, Anon28109 said:

Emby 4.6 includes an updated iHD driver which fixes encoding/decoding on Gemini Lake (J4125.)

I had a quick check with emby 4.6.0.22 and that seemed to indeed work on the DS920+. Don't have that much time until Saturday. But might be able to check a bit more on different hardware on Saturday.

I will update the topic if I have more information but so far things look promising :)

  • Like 1
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
×
×
  • Create New...