This workaround should no longer be necessary with newer Plex versions: https://forums.plex.tv/t/subtitle-burn-in-improvement-test-build/884481
Old content left here for reference:
For some reason, although Plex supports hardware-accelerated HDR tone mapping, Plex decides not to use it when subtitles need to be burned in. This results in extremely slow transcoding on hardware that should be able to keep up using hardware acceleration. I've noticed this issue on my server with Intel QuickSync, and this fix is made specifically for that case.
Before the fix, the SW tone mapping was only able to do 6-7 fps on a i5 7400T for an HDR 4K->1080p transcode. With the fix, that same transcode happens with HW tone mapping, and goes up to 82 fps. Even for HDR 4K->4K, this CPU is able to do 35 fps using QuickSync, thus keeping up with at least one video stream.
By wrapping "Plex Transcoder" with a script which replaces the software tone mapping with hardware tone mapping.
A filter configuration for software tone mapping looks like this:
[0:0]scale=w=1920:h=1080:force_divisible_by=4[0];[0]format=p010,tonemap=mobius[1];[1]format=pix_fmts=nv12[2];[2]inlineass=font_scale=1.000000:font_path=/usr/lib/plexmediaserver/...[3];[3]hwupload[4]
A filter configuration for hardware tone mapping looks like this:
[0:0]scale_vaapi=w=1920:h=1080:format=p010[0];[0]hwmap=derive_device=opencl,tonemap_opencl=tonemap=mobius:format=nv12:m=bt709:p=bt709:r=tv,hwdownload[1];[1]format=pix_fmts=nv12[2];[2]inlineass=font_scale=1.000000:font_path=/usr/lib/plexmediaserver/...[3];[3]hwupload[4]
For the linuxserver.io Plex docker image, I've attached a script which can be added into custom-cont-init.d (by using a bind mount) that fixes the issue described here. Use at your own risk, it may cause issues in other transcoding scenarios which I didn't test yet.
This is for the Linux server Plex container. https://github.com/linuxserver/docker-plex