I just tried the “Early Access” feature of the Plex UI for a Vizio 4K TV (unfortunately I can’t find the brand info). After entering Early Access, I tried to play something with ASS subtitles, and they showed up, but the font and styling was not correct. When I chose to leave Early Access, I went back to the same video and the subtitles displayed correctly.
I doubled checked that the video file has the correct fonts attached and that the subtitle file references those fonts correctly. The subtitle display is also correct if I use Plex from a computer or play the video file directly with mpv.
The Early Access UI suggested that I make a forum topic if something didn’t work. I’m mostly a lurker here, so please let me know if this belongs somewhere else or you need more information to diagnose the issue.
By the default the app will render the subtitles itself to avoid having the server burn in the subtitles (i.e. re-encoding the video with the subtitles added to the video stream which results it a loss of quality). Unfortunately we’re not able to keep the formatting with this method. Normally you can set your Burn Subtitles setting to Only Image Formats so that it will do this with formats such as ASS, but that has a bug at the moment. Until that’s fixed, if you set the setting to Always you can force them to display the way you want.
I’d like to reiterate that this bug only happened on the “Early Access” UI, and only on some videos with ASS subtitles. When I opted out of the Early Access feature, the problem disappeared, so it seems to me like some feature of that UI was causing it.
By the default the app will render the subtitles itself to avoid having the server burn in the subtitles
Yes, and this is what happens the vast majority of the time in my experience. Until now, the only times I’ve ever had issues with subtitles not showing up correctly is if there’s something wrong with the file, usually either an improperly attached font or the wrong font name in the attached ASS stream. What’s strange is that the incorrect display from errors like that usually renders the subtitles in Deja Vu Sans (the default font my server’s OS), but the error I’m referencing here was different. I’m not sure what font it was, but it was much thinner and had wider kerning than Deja Vu Sans. It also had a blue outline, which the original subtitles didn’t have, and which I’ve never seen on any of the other text-based subtitle formats (srt, mov_text, utf-8) as Plex displays them.
Unfortunately we’re not able to keep the formatting with this method
I don’t know what tech stack you’re using to do the burning, but in the past I have successfully burnt subtitles into a video with ffmpeg in a way that kept the formatting. Of course, the output of that operation was a video file, not a video stream; I’m not sure if ffmpeg could do a video stream like that (this was a long time ago but if I’m remembering right it ran at about 0.5x).
Normally you can set your Burn Subtitles setting to Only Image Formats so that it will do this with formats such as ASS, but that has a bug at the moment. Until that’s fixed, if you set the setting to Always you can force them to display the way you want.
If I set Burn Subtitles to Always, won’t it then use the burning method that doesn’t keep the formatting?
When the setting is on Automatic the app (the client running on the TV) will render the subtitles, which means we ask the server to convert the ASS subtitles into a text based format which the app can use to draw the subtitles (edit: actually, we parse the ASS subtitles in the client). This avoids having the server encode them into the video stream which will force a transcode if it wasn’t already going to (which results in a loss of quality), but this does mean we lose all formatting on the subtitles.
On the Always setting, the app will have the server burn the subtitle into the video. I’m not knowledgeable on how accurate the sever rendering of ASS subtitles is, but I presume it is better than the default app rendering which does not use any of the formatting at all.
Thanks for the information about the Burn settings.
I just saw your other post about the Vizio SmartCast Preview. I believe this is the “Early Access” thing that I tried. Per the instructions there, I was able to obtain the following information about the TV:
Model Name: v505-G9
Chipset: MTK-5597 (1)
I just tested the Early Access feature a little more thoroughly than last time. I found that if I changed the Burn Subtitles setting to Always, the subtitles displayed correctly. However, I don’t think this change of settings should be necessary. The old Vizio UI works correctly and doesn’t even have this setting. I also tested the Plex app for a 32 inch Hisense Roku TV, and it could display the subtitles correctly on the Automatic setting, which is the one that didn’t work in Early Access on Vizio. I doubt the Roku TV has better hardware for transcoding since it’s a couple years older, which again leads me to suspect this is a legitimate bug in the new Vizio UI.
Automatic means that the app will make the decision based on it’s capabilities are, with a view to avoiding transcoding (i.e. avoid burning in the subtitle).
Only image formats means the same as above, but if it’s an image format then we’ll burn it. I double checked some things, and I was wrong about this being broken. ASS is not an image format, which is why we can parse it (I was also wrong when I said the server converts it to a text format for us).
Always means no matter what the subtitle is, burn it in.
The old app didn’t have the same capabilities as the new app (it’s not just a UI change, it’s a completely new app). The new app can avoid a transcode for ASS by rendering the subtitles itself, hence the change in default behavior.
For the Roku TV case, it doesn’t know how to handle ASS subtitles, so it just has the server burn them (like the old Vizio app, it doesn’t have any other option).
Apologies for mistaking an entirely new app for a mere new UI. Considering this, it’s actually pretty impressive how quickly it can switch between the two.
The new app can avoid a transcode for ASS by rendering the subtitles itself, hence the change in default behavior.
I take it that this “rendering” is what I saw where the subtitles showed up unstyled. I sampled several shows from my anime library and this only happened on about half of them (the other half worked as expected). If this is due to some incompatibility with Vizio, then I guess there’s nothing you can do about it, but given that it works on some files and not others, your new app could be missing some of the necessary components to render certain ASS files.
For ASS subtitle rendering, are you using libass or VSFilter? If memory serves from some Doom9 threads I read a while back, VSFilter used to be the better option many years ago, but more recently the advantage has shifted to libass. I don’t remember any specifics about why one might be better than the other, but if you have control over which is being used, shifting to the other might be something to try.
In any case, if the client is not capable of rendering the subtitle style correctly, I would prefer that it display some kind of message to that effect, then automatically change the burn setting to Always for that video, instead of the current behavior of dropping the styling with no indication as to why this happened.
On Vizio, if the file is transcoded for any reason, we also have to burn in the subtitles, which means that sometimes ASS subtitles will be burned even on Automatic.
We can’t use those libraries, as the app is written in javascript (i.e. roughly the same as running in a web browser).
I’m going to file an issue about improving this setting, because to me it does seem like we need a way to automatically burn ASS without also forcing a burn on text based subs.
We can’t use those libraries, as the app is written in javascript (i.e. roughly the same as running in a web browser).
Does this mean that there is no way for Plex to properly render ASS subtitles on a TV without burning them? I thought Plex used mpv as its underlying video player, which as far as I know doesn’t burn ASS subtitles when it renders them (at least not on a computer; I don’t know how it works with a TV). This may not be a fair comparison, but if the issue is network bandwidth, I’ve used mpv to play a remote file with ASS subtitles before and I didn’t notice it transcoding.
I’m going to file an issue about improving this setting, because to me it does seem like we need a way to automatically burn ASS without also forcing a burn on text based subs.
Thank you for forwarding this concern. I would also add that if the app is capable of rendering the subtitles with the correct formatting, rendering should be the default as this prevents the loss in quality that comes with transcoding.
I realize that ASS is a very complicated format that is much more difficult to render than any of its competitors (and in some sense this is by design to make it as flexible as possible), but the spec is very well documented, and it actually hasn’t been updated in six years, so any TV with better hardware specs than the average capable computer had in 2014 should theoretically be able to render ASS subtitles properly. Granted, this might require rewriting the libass and/or VSFilter libraries in Javascript (or whatever other (likely proprietary) language a given TV app platform supports), so I wouldn’t expect this to be an easy fix. I also don’t know how high of a priority this is, as it really only affects viewers of subtitled CJK content.
Anyway, if you would please link me to the upstream issue you’re filing, I will close out this bug report.
Correct. Any solution would need to be a javascript solution. It is certainly possible but definitely not trivial. It’s something we want to look into, but I don’t have any idea what the timeline for that would be.
I’ve filed the issue, but it’s not publicly accessible so I can’t link you to it.
Having a similar issue on a 4k LG TV. While setting burn to “Always” does force the subtitles to display, my server is not powerful enough to do this with 4k content on the fly and causes unusable levels of buffering. Commenting to show that others would appreciate a direct solution as well because SRT just can’t cut it for certain types of content.
@PiPMS: If your desire is for subtitles to not burn, then you should use the Only image formats option. That will only burn image formats (which we have to burn anyway) and ASS/SSA will be rendered by the app if possible (i.e. if the video can otherwise direct play).
@alecastle: I have a fix submitted that will change the behavior to what you expected, which will hopefully be in the next update.
Sorry, I missed that you were talking about an LG TV. You’ll probably want to start a new thread tagged with lg-webos so the LG developer will see it, as this sounds like an LG specific issue.
