Something I would like to verify quickly…
My understanding is that as of a few versions ago, the linux PMS package now has a driver and tonemapping libraries integrated, right? If so, how old is that driver?
When the transcoder libraries (Intel Compute Runtime) were updated for PMS 1.32.0, Engineering used the then-current version, which I believe is a 2023 release.
I would need to go digging in all the release dependencies to confirm.
Is there a specific problem you’re facing?
I am still having random blockiness when transcoding. However, I saw in the other thread about hardware transcoding that you mentioned not running the newer 6.x kernels. I have been on 6.2, 6.3 and now 6.4, so maybe I’ll try going back to 5.19 hwe or something.
I just figured that because this is the latest gen cpu, it would be better supported in the newer kernels.
So as plex is packaged currently, it’s no longer necessary to install intel-media-va-driver-nonfree and the intel-compute-runtime packages, correct?
-
5.19 kernel is all you need. “Stock distribution” is the key here. The more the installation gets ‘mucked with’, the more it gets ‘mucked up’
Remove the 6.x kernels and go back to 5.19 then regenerate the initramfs and reboot. -
You do not install Intel Media or Intel Compute packages. These are included with PMS. Remove them if you have already installed them.
If you need known good test videos, I can provide them.
So I did this, and now after running for about 24 hours, transcodes just fail to start at all. I had 2 people hit me up to tell me that when they pressed play on something, it just spun endlessly. The output I see in the console isn’t helpful either.
GPU usage is stuck at 100% according to intel_gpu_top, so something has locked up and no other transcodes can run. Direct play works fine.
I restarted the plex service and the gpu was still at 100%, so I’m suspecting firmware as kernel 5.19 forces you to use old GuC firmware (version 70.1.1, newest available is 70.7.0).
Rebooting the VM didn’t work either, it locked up and I had to stop the VM in proxmox and then start it again. “5.19 is all you need” is great in theory, but the hardware support for alderlake and raptorlake is not mature enough. I’m going back to kernel 6.4. At least it didn’t crash.
Plex Media Server.2.log (3.8 MB)
Fair enough. It’s strange how this flies against what I have on our test box
(AlderLake with Ubuntu 22.04.2 LTS native)
The 6.x kernel from Ubuntu will be out shortly. When it comes out, I’ll update and test with it.
Given that’s a production machine, it’s unfortunately the best I can do.
1 Like
Good news @ChuckPa, tomorrow I will have free reign of testing with an Intel NUC i7 11th and 13th gen. I’m hoping to test direct on windows and linux in the ‘supported’ configuration to see if the issues can be reproduced.
I’m hoping to narrow this down to either a physical hardware issue, proxmox issue, or anything else. Are there any specific install configurations you’d like me to start with first? (OS version / distro, any specific PMS install version, etc)
After some initial testing, here is what I’ve come up with:
-
RNUC11PAHi70001 - Intel NUC 11th gen i7 with Intel Iris XE iGPU - latest firmware / bios
- Tested on fresh install of Windows 10 - fresh PMS install - reproduced the issue
- Tested PMS Container on Proxmox with proper gpu passthrough - reproduced the issue
-
RNUC13ANHI7000U - Intel NUC 13th gen i7 with Intel Iris XE iGPU - latest firmware / bios
- Tested PMS Container on Proxmox with proper gpu passthrough - reproduced the issue
Tomorrow I will test Windows 10 direct on the 13th gen and Ubuntu direct on both. At least I know now that this is not a physical hardware issue with my original 12th gen NUC.
I cannot reproduce the issue with the LG Colors demo media, although HW transcoding on windows base install breaks when enabling HDR tone mapping. (Different issue)
- I understand it may be an issue with ‘my media’, however it works perfectly fine on older hardware. I had shared a snippet of the exact content and you were not able to reproduce the issue on your newer lab hardware.
After testing with the 11th gen NUC - I can confirm the low power / efficiency cores are not the cause as the 11th gen is 4c/8t physical.
Just for sanity, check the x265 sample I linked previously (here) and let me know if you also get the blocky-ness. It’s pretty apparent, especially in the darker scenes.
I was not referring to the E cores. The UHD igpu has different ways of interacting with the media engines that decode/encode. I assume this is what they were referring to in the jellyfin thread.
I will add your linked vid tomorrow and verify.
Yup, test file got blocky at 0:06, 0:12, 0:19, 0:34, and finally at 0:40.
@ChuckPa , just did a fresh install of Ubuntu 22.04 LTS on the 11th gen Intel NUC and experiencing the exact same issue. As this is a supported configuration, where should we go from here?
I’d like to determine why you are not able to reproduce this issue on your hardware-
@rozzly and ALL:
I wiped our PlexQA system and started fresh (was not cool but I did it)
-
In order to get the Nvidia 535 drivers to NOT freeze the machine during boot, I had to apply ‘nomodeset’ to grub.
-
I can now boot without the machine freezing and use the Nvidia GPU but I have no QSV support. (the i915 driver did not load because nouveau is shutdown)
-
I attempted to use 22.04, 22.10, and even 23.04 - all to no avail.
I’m working at getting both QSV and Nvidia working again without the machine failing but, given how fubar the 535 drivers are, I don’t think there is any immediate hope.
I’m still working on it and will get back to having a viable machine.
When I get there, I will also have an answer
OK, this all works for me again.
To your questions:
-
Everything, including RaptorLake, is supported for QSV transcoding.
-
RaptorLake CPUs have a Linux deficiency regarding the CPU itself (p/e cores, etc) which is supposed to be fixed in 6.2 kernel.
I upgraded the LabQA machine to
- Strip all Nvidia drivers and configs from the machine
- Upgrade Ubuntu 23.04 (6.2 kernel)
- Nvidia 535 drivers (which did not blacklist nouveau) were included in 23.04
- Added libnvidia-encode and libnvidia-decode
PRETTY_NAME="Ubuntu 23.04"
NAME="Ubuntu"
VERSION_ID="23.04"
VERSION="23.04 (Lunar Lobster)"
VERSION_CODENAME=lunar
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=lunar
LOGO=ubuntu-logo
chuck@plexqa-av1:~$ dpkg -l | grep nvidia
ii libnvidia-compute-535-server:amd64 535.54.03-0ubuntu0.23.04.1 amd64 NVIDIA libcompute package
ii libnvidia-decode-535-server:amd64 535.54.03-0ubuntu0.23.04.1 amd64 NVIDIA Video Decoding runtime libraries
ii libnvidia-encode-535-server:amd64 535.54.03-0ubuntu0.23.04.1 amd64 NVENC Video Encoding runtime library
rc nvidia-compute-utils-535-server 535.54.03-0ubuntu0.22.04.1 amd64 NVIDIA compute utilities
rc nvidia-dkms-535-server 535.54.03-0ubuntu0.22.04.1 amd64 NVIDIA DKMS package
rc nvidia-kernel-common-535-server 535.54.03-0ubuntu0.22.04.1 amd64 Shared files used with the kernel module
chuck@plexqa-av1:~$
Please test with the content here and see the timestamps mentioned by @Eschmacher :
Yup, test file got blocky at 0:06, 0:12, 0:19, 0:34, and finally at 0:40.
You’re starting out with a 2 Mbps video and wondering why it gets blocky when you transcode it???
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 41 s 459 ms
Bit rate : 2 554 kb/s
Width : 1 920 pixels
Height : 804 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
The full file is 5704kbps, this is just a cut from that content and shows a lower bitrate – the issue is still the same in the exact same spots as the full file itself. FWIW, I just redownloaded and imported the same file and plex info is showing 3097kbps in the info / metadata field.
I’m wanting to know why it gets blocky on 13th gen sockets and 11th - 13th gen NUCs with Intel Iris XE iGPU through QSV, but plays perfectly fine on older gen CPUs. This issue doesn’t appear when using nvenc.
Sorry for delay – power outage; transformer blew (it’s 100F+ here)
I’m using the same CPU and do have the problem but I also do have higher bitrate to start and higher output bitrate…
chuck@plexqa-av1:~$ cat /proc/cpuinfo | grep 'model name' | uniq
model name : 13th Gen Intel(R) Core(TM) i5-13400
chuck@plexqa-av1:~$
As I show above, My output bitrate is 19 Mbps video.
What is your video output bitrate ??
Where / what command is used to get the current transcode statistics?
General Summary
Let’s call this issue micro-artifacting, for reference since it’s like a stutter, but only lasts a second.
-
This micro-artifacting occurs in the sample media file provided through plex web app while playing normally, no subtitles enabled.
- If transcoding the same file to view on my samsung TV app, the micro-artifacting does not occur, however it does occur when enabling the subtitles. There are no issues while streaming to my Roku stick plugged into the same TV with the plex app.
-
When transcoding similar x265/hevc content on the samsung tv app, anime for example, the micro-artifacting only occurs when subtitles are enabled. If subtitles are disabled, the issue appears to go away.
- When subtitles are enabled on the samsung tv app, it’s worth noting that during these bits of micro-artifacting, the subtitle area can sometimes produce green artifacts, or can freeze the video for a second (like an actual micro-stutter) before proceeding - audio is not impacted.
-
These issues only came up after switching from NVENC to QSV. I cannot reproduce these issues on my test system with a quadro p4000.
-
I tested PMS running on an older intel 6th? and 8th gen CPU with QSV and was not able to reproduce these issues.
All of these items lead me to the following conclusions -
-
There is something going on with UHD 770 iGPU on Intel 12th / 13th gen cpus, along with 11th - 13th gen intel NUCs with the intel Iris XE iGPU, causing QSV micro-artifacting on lower bitrate x265 transcoded content through the plex web app - which is not a problem with older generation hardware.
-
There is something wrong with the Samsung TV app causing QSV micro-artifacting during the transcode process through PMS on content with subtitles enabled.
My temporary workaround for this issue is to just use my Roku stick. Personally, I’d like to resolve issue 2 more than anything. I am not sure if the two line item issues are related or not.
@Eschmacher - please let me know if you’ve experienced any other issues, or if there’s anything else that should be added.
Rozzly.
Please give me the time index in the movie (Saving Private Ryan) where you see this.
I will compare against my rip (from my original disc here)
I need to rule out bad input data before I pursue this any further.
(If it can be reproduced with my rip as well – then it’s likely an issue)
1 Like
