Plex HW Transcoding with Subtitles

General Discussions Plex Features
,
1

I would like to find out more about this comment left here:

I just wanted to let you guys know that one of my first tasks for the newyear is going to be to overhaul subtitle burn in, to not only include a similar change to this (but for more than just linux) but hw assisted burn in for image based subtitle formats such as pgs. Keep an eye out for a preview build in the plex forums in jan or feb.

Yet I see here Plex’s attitude to ‘we do not release roadmaps and we wont release roadmaps’, this feature is interesting because as far as I know, Jellyfin is able to burn in subtitles using the GPU/HWA.

Using SRT subs likely will work but the quality is obviously much, much lower.

I am using a 12100 i3 and whilst this can handle lots of transcodes at the same time, as soon as PGS subs are involved it cannot handle one stream of HDR → SDR with PGS burn, I understand this is intensive but why is it single-threaded and why is it CPU? Is this AT ALL on the feature list to revamp as per the comment list on the github above?

I am happy upgrading my HW to handle it, but if the issue is in the software then its not really the solution.

FWIW I would be happy paying a higher tier ‘plex pass gold’ for more features such as this that favour the performance.

The only way I have been able to mitigate the constant buffering is removing HDR tone mapping which allows the transcode to work at 1.2 rather than 0.4.

1 Like
2

Plex has said they are working on using the GPU to burn subtitles. They’ve mentioned possible delivery, at least in a forum preview, in 1Q2024 (reference). I doubt you’ll see more definitive information (dates, PMS version, etc.). As you noted, Plex does not publish such information.

Current subtitle burning is performed on a frame by frame basis: Decode the frame, add the subtitle to the video frame, encode the frame. Decoding & encoding can be performed by the GPU, but adding the subtitle to the video frame is performed by the CPU.

As far as upgrading the system, given how things currently work, you would need a CPU with faster cores. Unfortunately, I’ve not seen any information regarding what CPU is needed to burn subtitles into 4K media.

Personally, I’m holding off any upgrades until we have an idea of what Plex will deliver and its requirements. In the mean time I’ll proceed like I always have: local 4K HDR playback is direct played (Shield, FireStick 4K), and I don’t share 4K remotely, so no need to worry about transcoding & burning subtitles.

1 Like
3

That link is fantastic, thats what I was trying to search for, something on HERE which said that they have found a way/working on it, thats all I wanted to see.

I am currently sorting out my collection so that I have 1080p copies of files as the 12100 can handle burning subs via cpu on 1080p just about, which is ‘acceptable’. Its the HDR → SDR → 1080p + burn PGS thats killing it.

Great to see they have found a way and are eyeballing/scheduling a release thats not next year. I’ll take it with a pinch of salt but I would assume that they deem this quite a priority of a feature.

4

well this…

its exactly what i ran in to as well… hearing from 2 people that they issues with transcoding…
but only when using subs… but this even happens with srt, if you start the movie with 4k hdr and subs enabled and correct one selected then no issues.
start playing the movie and then select the srt? bad luck for you.

plex needs to step up their game…

5

As we will be nearing the end of Q1 next month, I would like to understand if Plex have made any further advancements with this feature, given it was posted on Github Issue response in December 2023 and references here were a while ago.

@ChuckPa - not to harass you here or hold you to anything (as you specified in the previous post not to - I am not!!) but do you have any further progress internally on the testing of this? I tested it with Emby and they burn subs with no problems using quicksync.

1 Like
6

@JoshUK

We’re still on this task.

In complete candor, it’s “do we sleep, eat, or continue to work on the other fires?”

(We’ve had a few problems we needed to address first of higher priority. Those are where we’re at. This work is sitting there and ready for final; we only need get everything else out of its way)

3 Likes
7

Makes perfect sense and thought that would be the case, but wanted to check in on it. Are higher priority fires coming in quicker than they can be put out?

If we assumed that no new major issues were coming in, would you see this being released to testing before the end of Q2?

I would pay for an additional Plex pass super for things like this.

8

Do you have your client set to only burn in image based formats for subtitles? IME, SRT seems to play nicely on Plex, Roku, and ATV clients, but haven’t tested most others.

9

It’s fine to me, but because it’s a client setting I can’t control it for those I share with. And people don’t understand the complexity and just assume it’s a general Plex issue (making Plex crap in their eyes) or a connection issue so they try to then force transcoding by changing the resolution.

I tested Emby and it handled subs WAY better, but I obviously want to use Plex not Emby.

1 Like
10

Both Emby and Jellyfin…

Pretty crappy the amount of issues like these for such a big paid product. I guess adding more ad backed content and sharing your activity on weekly digest emails are the main fires to put out

11

Just noting I was not replying to you @JoshUK.

12

I know but the point still stands because he said others are having issues, really hoping we can get some kind of tentative timeline even for like alpha testing.

13

This is awesome news!

Out of pure interest and perhaps off-topic, what are the higher priority tasks? I only ask as I read in your first post about this that Windows PMS was getting some love and was hoping what you mentioned here is related to that!

Back on topic though, I’m restructuring my build to a later CPU. It’ll be an i9 14900k, my first CPU with P cores and E cores and with this new development, I’m wondering if I can get away with mostly if not exclusively E cores used for plex. I’m trying to figure out what scenarios would be left where the CPU would need to handle subtitle burn-in after this is implemented.

14

Hi all. While we are working to open up communications a little bit more, I am not comfortable just yet in calling out any higher priority work that the team is focused on at this time. What I can tell you is that like most organizations that have grown past a single digit count of engineers, we definitely have more than one team here so any assumptions that people are dropping server focused work to go tackle ad/streaming or sharing issues is not accurate.

What can also be shared that is specific to this thread is that one area we are focusing on currently includes issues around subtitles. I see issues in that project related to transcoding with subtitles. While this is no guarantee that those are going to address everything for everyone in this thread, we are at least working in this area right now. Before you ask, no, I don’t have a target release date to share yet. The work is slated for the first half of this year though.

3 Likes
15

I am not sure anyone in this thread has been dropping the assumptions you claim about small teams or server focused is working on the streaming / ads side of the business, so not sure where that answer has come from…

I would expect Plex to have more than 9 engineers, yes, it would be news to be if this wasn’t the case. I would very much hope you are not a single digit number of engineers.

There is only 14 replies to this thread including yours, and we all have the same identical issue with subs not using quicksync to burn in like Emby and Jellyfin do. I have seen code on Github where people are replacing the plextranscoder executable with a shell script that regex’s out the args you are passing it and replaces them with different ones which do ultimately end up using the gpu to burn in subs, so it works and is possible. The side effect of this though is it broke other areas of the app, understandably.

I think what Avsynthe is asking is as he said, is pure interest, however I feel it is extremely valid question to ask given we are all paying money to Plex to use the software, what level of importance is this, and what other tasks are in front of this in terms of priority?

Who defines the priority? How is it defined?

I find your reply a bit blunt and dismissive to be honest with you. Perhaps its just the way I am reading it. I have found Chuck’s replies about this on this thread and other threads to be much more realistic and a better attitude, even though he is essentially saying the same thing… lots of problems and little hands, what do you fix first?

I definitely wouldn’t have started off the reply with a sentence about opening up communications because you went on to say you are not making any effort to open up comms.

On the topic of growing staff, my next thread I open will be questions relating to what’s going on with Apple? Why is Apple TV suffering a lack of updates? Do you have more Apple engineers yet? That will be another topic for another time, right now, burning subs is critically important feature and it can quickly become software that people including myself don’t want to use because of the impact it has. We don’t even have the facility to turn off subs if burning in, its just not a feature.

I will say this again too, I would be much happier paying MORE MONEY towards Plex, if that was a problem. But I would expect things like this to be fixed given you are the only media server which is now unable to do this yet.

16

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.