You’re missing the point. The CPU has more than enough power to process subtitles and the video as proven by the 2.x transcode speed on SW. There is no CPU bottleneck. The bottleneck is transcoding logic which my thread is about. If what you’re saying was true than I’d be seeing 100% CPU utilization while the system struggles to software-encode subtitles on top of the video. I’ve provided proof that this isn’t the case. CPU usage is 20% when HW is on.
You’re right that those two don’t run at the same rate, they can’t because they depend on each other. They’re definitely not simultaneous though.
It’s not about about being CPU-bound. If anything I’d assume that HW encoder only uses a single thread for some reason
EDIT: after searching for new keywords, I conclude that we were both partially right, HW encoder seems to lock transcoding to a single core, but your arguments lost a lot of background and were incomplete - that’s why I was arguing. The root cause is not because CPU doesn’t have enough power or that it needs to stay in sync, it’s that because HW acceleration in Plex locks itself to a single CPU core it’s not able to process burning subs fast enough and that apparently A/V sync has to be done on the same core. With multiple threads running at the same time this limit is no longer relevant and having multiple threads outweights the gains from hardware acceleration
So I guess the best solution was if Plex would allow to disable hardware acceleration when subtitles are being burned, but keep it on otherwise
Thanks for guiding me in the right direction
