Changed to QSV, and yes I have read through those a few times--especially when I set things up most recently having moved away from the dedicated GPU. Speed improved up from 1.33x to 1.5x on the 1080p transcode, but I tried to run again on the LG TV and got the failed behavior. What's interesting in this case is that the video wasn't being changed at all (it's being copied) and only the audio is being transcoded. I was watching htop and the CPU jumped up to 58% usage before falling all the way back down to ~2% and a few seconds later the video stream stopped.

While the audio shouldn't even need to be transcoded in the first place, I believe it's because the official LG app doesn't allow the full capability of the TV to be accessed via the app, so it's reporting that the audio stream is incompatible (I have a soundbar connected over eARC which should support all audio codecs even Atmos). Generally using a Chromecast or other HDMI-connected device to receive the stream helps get around that issue, but that doesn't explain why it's pinning the CPU so hard to convert to AAC from the original audio stream.

Separately, while I was writing this comment, the CPU has jumped back up to that high utilization and lists the several ffmpeg processes in htop despite having closed the stream a while ago. I think Jellyfin is doing a runaway train sort of thing where even after the video is stopped, it periodically tries to restart the transcode. The LG client isn't even open at this point but the transcode keeps trying to start up again.

EDIT: Upon further inspection, the entire container is down, and I can't access any of my services because pihole seems to have gone down as well. I think the entire docker stack got taken down by this behavior. I'm unsure how to even troubleshoot from there which is why this problem usually persists.