This is somewhat of an update.
Two new builds pushed up today. “21127” with the latest neo packages and also “new-transcoder” which is an update using the post @ChuckPa was talking about. I actually get worse performance on a quick test of the new transcoder with the latest neo packages then i do with the old transcoder. When running 1 stream i was getting brief hangs of the stream vs the old transcoder I can do 1 stream all day without major issues (i still get a little bit of the grey snow/static in the image but not enough to make it unwatchable)
The install method for the new transcoder was to use my latest standard build but add a couple lines to the plex-common.sh to download the test version then do i standard dpkg install to layer it in.
1 Like
The latest forum preview build is enabling hardware transcoding on kernel 5.13 / ubuntu 21.10 for me just fine.
Two new images pushed. 21220 has the latest neo drivers with the public release of plex, 21220-NT is the latest neo drivers with the preview build of plex from the forums. Will be testing next and will post the results.
EDIT:: made an edit to the new transcoder container so it doesn’t try to install the old version of plex and upgrade to the new one, just install the new one to avoid it thrashing on subsequent startups
The latest version of plex server officially mentioned rocket lake support in its changelog
Plex Media Server 1.25.0.5246 is now available to Plex Pass users in the Beta update channel.
…
- (Transcoder) Support for hardware transcoding on Intel Xe/Gen12 (TGL, RKL) GPUs
- (Transcoder) Update to newer upstream ffmpeg
…
Quick sanity check with my setup (docker + ubuntu 20.10 + i5-11600K) went very well and everything works smoothly so far.
I’m planning on reinstalling my server this weekend and testing the official image on ubuntu 20.04, i’ll let everyone know the results
Thanks, @scuffe! Looking forward to your results. Any chance you could try against 21.10?
I have had success using the latest official version:
- plexinc/pms-docker:1.25.1.5286-34f965be8
- Ubuntu 21.10
- i5-11400 @ 2.60GHz
Thanks to everyone that contributed to this work!
I tried a fresh 20.04 with the 5.15.7 kernel (TuxInvader ppa), cri-o 1.22, k8s 1.23 and hardware tone mapping is still a bust. If tone mapping is enabled when hardware decode is enabled it just never starts, it doesn’t crash or show any hanging in the logs, just sits there and spins like it’s buffering but not going anywhere. If tone mapping is disabled hardware decode works as expected. If tone mapping is enabled and hardware decode is disabled it works as expected (software fallback).
I’m going to try a fresh install of 21.10 next like @CheckeredFlag mentioned.
@CheckeredFlag could you let me know what version of the kernel your running? what version of docker (or containerd or whatever your running) is? and anything else you did to the system beyond just installing the os? did you apt update to the latest of everything? Did you install the neo packages? basically anything so i can try to get the same results your seeing?
I tried a fresh 21.10 install, apt update to the latest, cri-o 1.22, k8s 1.23 and it works about the same as it did back on 21.04. I can do 1 stream without issues, 2 and it starts to buffer and swap between them.
Other things i can try is just ubuntu and docker, that would rule in or out the container runtime, different kernel based on what @CheckeredFlag is running, any other suggestions people have.
My setup is rather vanilla.
- ASRock Z590M-ITX/ax
- CPU: i5-11400 @ 2.60GHz
- Ram: 16GB
- Ubuntu 21.10
- Kernel: GNU/Linux 5.14.9-051409-generic x86_64
- Neo drivers: 21.49.21786
- Docker 20.10.7 & docker-compose via
apt install docker.io docker-compose
(Is this obsolete? Should I be usingdocker-ceandcontainerd.ioas per official docs?) - Plex 1.25.1.5286 with hardware acceleration & tone mapping enabled
- Using ramdisk for transcoding directory (see below)
Here’s my docker-compose.yml:
---
version: "2.1"
services:
plex:
image: plexinc/pms-docker
container_name: plex
network_mode: host
devices:
- /dev/dri:/dev/dri
environment:
- PUID=1001
- PGID=1001
- VERSION=latest
- TZ='America/New_York'
volumes:
- /srv/media/config:/config
- /srv/media:/data
# Use ram disk for transcoding cache
- /dev/shm:/transcode
restart: unless-stopped
Note that I rarely have multiple transcoding streams happening at once (usually direct stream) so I’m not sure whether or not I might be encountering your issue.
Also note that I encountered problems with the ramdisk dir filling up at times…trying it again.
Hope this helps.
What repo did you use to install the kernel? The out of the box one i have is 5.13.0-22. Did you just grab the deb’s from the ubuntu site, or build it or grab it elsewhere?
I installed 5.14.9 from the ubuntu kernel ppa and no change in behavior.
I used this deb for my kernel - generic:
kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.9/amd64
How are you testing to encounter your issues? Is it simply transcoding two streams at once? I’m not sure I know what you mean by “buffer and swap”. I just want rule out that I am not indeed having the exact setup you have but just haven’t encountered your problems yet.
If i start a 4k HRD stream and have it transcode to a single point it works at like 95-97%. If i start a 2nd stream once the initial buffer period basically runs out (50-55 seconds) then one of the two streams will act like its buffering (spinning circle in the middle of the screen). It will buffer for 3-5 seconds then continue playing. Once that starts it will keep behaving like that. If i start more streams the same behavior continues with each one. Sometimes i’ll see GPU hang messages in dmesg sometimes not, that changes with each kernel version.
I’m running the kernel from the same location. The biggest difference is CRI-o vs docker for the container runtime. If you don’t see any of this behavior i might try to just lay down docker and see what the behavior looks like.
Sorry, I think I missed a critical part: I’m not doing any 4K HDR streams at all.
I’m recording OTA broadcasts via HD-Homerun and they’re all HD or SD. I have the latest Homerun with an UHD tuner and they’ve started to broadcast in UHD in my market but I haven’t yet explored any of that since I don’t have a 4K tv…yet.
My interest in this thread was due to having lots of trouble with green artifacts when hw transcoding 1080p and 720p and couldn’t make them go away reliably. After I upgraded to 21.10 and its kernel, I couldn’t get hw transcoding to work at all. It would attempt to, fail, and resort to software encoding.
Finally, after using the latest Plex release with support for Rocket Lake, it all seems to work well for me - hw transcoding is working and green artifacts are gone. So nice to see my cpu load at 1-2% instead of 20-30% per stream.
Sorry if I wasted your time trying to chase a solution that I may not have.
Your all good. Hardware transcode in general was the first part of this issue that we tackled, the HDR part is the second half of the problem. So think of this as an advanced crash course for the future 
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
