Server Version#: 1.21.3.4021 (via official plexinc/pms-docker:latest docker image)
Player Version#: Any (Roku Player and Web player all have same issue)
OS: Archlinux (updated as of last week) running Linux 5.10.16
Motherboard: Supermicro X9DRi-F
CPU: Dual Xeon E5-2650 v2 @ 2.60GHz (8 cores each, total of 32 threads)
RAM: 128GB of DDR3 1600Mhz ECC (16x8GB) (mix of 1r and 2r, if I remember correctly, but they’re balanced correctly)
I’ve got a Plex server running on some pretty decent hardware. SDR transcoding works perfectly fine, even 4K HDR > 1080p HDR (I limit my remote stream quality to 12Mbps 1080p). However, with HDR tonemapping on, the same transcode struggles to stay realtime (usually running at 0.9 or so). Dropping to 8Mpbs doesn’t really help.
The weird thing is that the hardware isn’t really being taxed at all. In fact, it appears to use slightly LESS resources than the non-tonemapped transcode. I’ve gone through all the possible bottlenecks I can think of. During either transcode, CPU load is barely hitting 10.0 on a 32-thread system (e.g. roughly 30% usage). The transcoding temp directory is on a RAM disk (tmpfs). The ZFS pool that the original media is on can easily pull over 2 GiB/s sequential reads with more than enough IOPS to deal with reading high bitrate video (it’s currently 9x8TB mirrors). There’s no noticeable spike in iowait.
I’m a little confused. I get that the tonemapping is more CPU intensive, but wouldn’t you then expect to see higher CPU usage, or even getting close to load limits before queuing happens? The server can handle 2+ non-tonemapped transcodes in realtime, so why not even a single tonemapped one?
The only thing I can think of is the transcode dir being in RAM? Is the tonemapping overtaxing the memory bandwidth since it needs to read and write to RAM for the same operation? I can try testing again with the transcode dir on another zpool (single mirror of SATA SSDs).
