NVidia Shield: SRT subtitles causing "burn subtitles" to activate when audio is also transcoded

android-tv
fire-tv

#1

Hi all,

I'd just written a lengthy post wondering why some media was transcoding instead of direct-streaming when there seemed to be no good reason why it should - when I realized that in my Tautulli logs it noted that the subtitles were being burned (despite being .srt subs, not an image format.)

"But that can't be," I thought to myself, "because some of my media direct plays just fine, and I always have subtitles enabled!" After some more digging through logs, I realized that this is only happening on media that has EAC3 audio streams, which incurs an audio transcode (since my sound bar is connected via optical audio, which doesn't support EAC3.) When it's AC3? Plays fine. DCA? Plays fine.

This seems like a bug! Are others experiencing the same? Can we expect a fix?

Thanks much!


External Player on Nvidia Shield
#2

I’ve noticed a similar behavior, but haven’t been able to pin it down as specifically as it sounds like you have. All I know is sometimes SRT subs require transcoding, and sometimes they don’t. I’ll start checking the corresponding audio codecs and see if that shows a pattern.

Right off the bat I can tell you that the last few shows that had forced SRT subs that required transcoding were all EAC3. I’m watching a show right now that’s AAC audio and when I enable SRT subs it still Direct Plays with no transcoding. Both of those initial pieces of evidence seem to line up with what you were saying.


#3

Yeah, sounds like the same issue. This is problematic for me because more and more content has EAC3 audio streams, and my PMS is running on a somewhat underpowered Synology NAS. I just picked up a Shield because I heard such great things, and by and large the experience has been great, but this seems like a big negative…


#4

Plex burned text based subtitles into the video cause they were going out of sync in HLS. But that was fixed in ExoPlayer v2. They should never be burned now that the Android App is based on ExoPlayer v2… So it’s probably a bug. But lets face it… Plex fixing bugs on the Android Client? LOL gl with that.


#5

Depressing response. Seems like it should be a straightforward fix, and one that improves quality of life for a relatively large population of users… :confused:


#6

This is happening a lot, so I thought maybe I could bump this and they can try and get to the bottom of it.

tl;dr: If for any reason the audio needs to be transcoded then the subs are burned in, causing the video to be transcoded as well, even for files where direct play of the subs works when the audio is not transcoded.

As an example, see this image:

On the left is AC3 5.1 and on the right is AC3 2.0. All I did was start the file and then change the audio track from 5.1 to 2.0 and, as you can clearly see, everything Direct Plays just fine with AC3 2.0, including the forced subtitles, but requires complete transcoding with AC3 5.1, because it has to burn the subs.

That’s a huge amount of resources being used up just because the audio needs to be transcoded.

I’m also attaching the client logs where you can see the MediaDecisionEngine clearly say in regards to the AC3 5.1 stream:

Unable to direct play; AC-3 audio is not supported by the device

Even though 14 seconds later it decides AC-3 2.0 is just fine.

Regardless, I don’t care if it’s transcoding the audio stream, what I do care about is that consequently if the audio needs transcoding then it’s also transcoding the video stream in order to burn in the subtitles, which is completely unnecessary as they direct play just fine when the audio doesn’t need transcoding.

I hope I’ve explained this clearly enough. If the devs have any questions, or want me to do more tests or provide more info, don’t hesitate to ask. I’m happy to provide a video sample if a dev responds and asks for it.

Client: Nvidia Shield
Plex Version: 6.16.2.4628
PMS: Windows 10 1.12.1.4885
Setup: Shield direct via HDMI to Stereo Samsung TV, no audio receiver/etc.
File Information: See Attached MediaInfo


#7

After searching a bit, there are actually quite a few threads detailing the same issue. This is a widespread problem, and one that seems fairly easy to pinpoint if what Dion250 said is correct, and this is a remnant of a prior fix for an ExoPlayer v1 issue. It’s a critical bug in the transcoder, essentially making my ShieldTV (and apparently any Android client) useless for those of us who use subtitles by default, and I’d honestly prefer not to have to switch to Kodi with the Plex plugin - that’s really not an ideal solution.

Would really love at least a response from Plex on this…


#8

According to a post in another thread, the beta release of 6.18 addresses this issue, so hopefully it gets released soon.


#9

@rwoffice Can you link to that thread? Subtitles on the Android app are a complete disaster since the switch to ExoPlayer v2. The only way I can get my .srt to show up is by choosing always burn in… it’s driving me insane!


#10

@mtappert said:
@rwoffice Can you link to that thread? Subtitles on the Android app are a complete disaster since the switch to ExoPlayer v2. The only way I can get my .srt to show up is by choosing always burn in… it’s driving me insane!

It shouldn’t be burning subtitles just cause audio is transcoding now with ExoPlayer 2. Only the devs can help you at this point. You will be waiting awhile im afraid or convert all your EAC3 to AC3.


#11

@mtappert said:
@rwoffice Can you link to that thread? Subtitles on the Android app are a complete disaster since the switch to ExoPlayer v2. The only way I can get my .srt to show up is by choosing always burn in… it’s driving me insane!

Now that I’m re-reading it, it might not be exactly right, but here you go anyway:

@mmhorda said:
6.18 version finally doesn’t force transcoding with turned on subtitles but still buffering on Sony Android TV. Works perfectly on SHILED with HDR and high bitrate videos, no buffering.

Fingers crossed it’s true, since the burning subs just because you’re transcoding audio thing is super annoying :slight_smile:


#12

Well, 7.0.2.5441 is out, and the bug isn’t fixed. (sigh.)

Please, devs, this is killing those of us who use subtitles.


#13

@antoniolg I know you said this isn’t your area… But can we please get an update on the subtile disaster on Android since the update to ExoPlayer v2? It’s been months and months that .srt files (regardless of codec, audio format, etc.) have not worked for me, and MANY, MANY others on Android. This issue is huge, as the only way to get .srt subs to work is to burn them in. Can you guys please, please, please fix this?

Thanks.


#14

Confirm bug still exists in latest Android TV client. If the audio stream transcodes and SRT subtitles are enabled, the video will also be transcoded. This is a serious problem with HDR video since transcoding breaks it, essentially, but also an issue in general, especially if the Plex server isn’t particularly powerful and the client would otherwise direct play the video stream.

Exoplayer 2 was supposed to fix this but clearly something else is amiss. The problem doesn’t exist for me on my Roku client, btw (it will transcode audio and direct play video with SRT subs enabled) with the same server and media for both.


#15

+1 to what @planetix said. I can also confirm that video still unnecessarily transcodes and so still broken for me with 7.0.2.5441 on my Shield.

I recently moved to a new Windows 10 server, so this isn’t the end of the world for me, but my Synology before that would be absolutely crushed by this bug. I imagine a lot of others are unaware of what’s happening and don’t even understand why they can hardly play anything back.


#16

Still an issue in latest builds, including beta. Hard to believe such a critical bug is still going unanswered for all Android-based clients.


#17

Please address this bug… it makes Plex unusable for me to play 4k movies with subtitles and audio that has to be transcoded.


#18

Maybe ping @MovieFan.Plex or @marekszulik as I don’t see any response from plex in this thread.


#19

This isn’t a bug, it’s a limitation that we are trying to remove but haven’t yet.

Basically when the audio needs to be transcoded and subtitles are enabled, the only way we can keep them in sync (and to deliver them to the clients) is to burn the subtitles into the video. When the audio doesn’t need to be transcoded everything direct plays rather than direct streams, so the subtitles can be played directly by the client.

The limitation itself is in the HLS protocol which only supports subtitles over WebVTT, which we currently don’t support.


#20

What’s happening here is that your connected to a sound device that doesn’t support PCM 5.1 and your Android device doesn’t support AC3 decoding natively, so we are using our AC3 software decoder for stereo content. When you switch to AC3 5.1 because we can’t output PCM 5.1, we can’t use our software decoder so the client asks the server to transcode into a codec that we can output on your Android device without dropping channels.