Jump to content

SSA Subtitles lengthy burn-in compared to Plex, or not playing at all.


Mkilbride

Recommended Posts

Mkilbride

So I am watching a series with SSA Subtitles. Most common form really.  Anyways, if I don't burn in, it plays right away. But a bunch of stuff doesn't get subtitled correctly or is unsubbed due to the way the subtitles are formatted.  i.e, dialogue missing. So I checked the "burn in SSA subtitles" option. This makes the subtitles play correctly.

 

But for some reason, when booting up an episode it can take anywhere from 20-30 seconds before it plays. If it does at all, and I don't have to exit out then go back in.

 

Meanwhile, same file in Plex, SSA subs burned in for formatting...it takes 2s.  Goes right to to it. Is this normal behavior? I don't quite understand. I'm using Hardware Acceleration, but Plex isn't due to no Plex Pass...and yet Plex does it instantly, while Emby fails to play regularly. I sent some logs in.  It's a Hi 10 file, so I know I can't direct play it...but Plex does it instantly, while Emby takes 30 seconds. Why that big of a difference?

 

Starting to wonder if I made a mistake. I jumped ship on Plex due to a lot of reasons; and Emby looked nice, better UI, was playing some files Plex struggled with...now it's the opposite. This is a separate issue to my other thread.  On a SSD by the way.

 

I tried disabling on the fly subtitle extraction and it didn't change anything.

Edited by Mkilbride
Link to comment
Share on other sites

rbjtech

To have any chance of getting constructive help, you'll need to provide the logs including the ffmpeg log.  Also we need the client you are using (Fire TV 4K etc) and MediaInfo for the file you are trying to play.

 

The most compatiable and common subtitle format is actually .SRT (text based) - .ASS and .SSA are also text based and very easy to convert to .SRT but lets see if that is the real issue here.

Link to comment
Share on other sites

Mkilbride

Using a NVIDIA Shield, 2017.  As for media info, it's all ASS / SSA subtitles in general. Burn in on them takes a long time. Meanwhile in Plex it's instant.

 

Here's a log of just a random ASS anime file. Burn in subtitles.

 

It's Hi 10, so of course it won't direct play, but still.  As said, Plex takes 2s or less a and Emby takes at least 20s or more, or fails to do anything. I'd be fine with not burning them, if not for the fact text starts disappearing.

ffmpeg-transcode-ae84ab24-bfaa-4dc9-ab73-6af12050ab83_1.txt

Link to comment
Share on other sites

rbjtech

If you turn off Hardware Decode/Encode - does it produce the same results ?

Link to comment
Share on other sites

Mkilbride

If you turn off Hardware Decode/Encode - does it produce the same results ?

Same results.

Link to comment
Share on other sites

pünktchen

I've learned it's a limitation of default ffmpeg.

If subtitles are embedded into the video container, ffmpeg first needs to extract the subtitles before they can be burned in. This takes time! Plex for sure has modified their ffmpeg version to circumvent this limitation.

Link to comment
Share on other sites

Mkilbride

Web, phone, tablet. Instant. Subtitles take around 1-2s to appear though.  On my Shield, it can take 15 to 30s ~ range.

Link to comment
Share on other sites

pünktchen

Web, phone, tablet. Instant. Subtitles take around 1-2s to appear though. On my Shield, it can take 15 to 30s ~ range.

Please provide a ffmpeg log when playing in the web app. I don't think the subtitles are burned in.
  • Like 1
Link to comment
Share on other sites

Mkilbride

Please provide a ffmpeg log when playing in the web app. I don't think the subtitles are burned in.

Not at home at the moment; but I think they are...because it uses the proper formatting / fonts. Also says unsupported subtitle format as the reason for transcode.

 

 

*******Anyways, as an ultimate test for this issue, among others, I reset my Shield to stock. A factory reset. Nothing changed.  For some reason my Shield takes forever to burn in SSA / ASS Subtitles.  Meanwhile, my browser does it instantly, as does my phone and my cheap ass Fire HD10 tablet.  Also Plex does it instantly.  With or without HW acceleration.

 

 

 

ffmpeg-transcode-eec31325-bc24-4d27-9670-b7bb531ef331_1.txt

Edited by Mkilbride
Link to comment
Share on other sites

Perhaps the font being used is different?  The delay appears to be on the server.  Here is an 8 second delay determining the streams or loading the font:

07:21:18.915 [subtitles@f2 @ 0000027c3f849940] Loading font file 'C:\Users\Mkilbride\AppData\Roaming\Emby-Server\programdata\fonts/DroidSansFallback.ttf'
07:21:18.945 [subtitles@f2 @ 0000027c3f849940] Using font provider directwrite
07:21:36.451 Stream mapping:
07:21:36.451   Stream #0:0 (h264) -> format (graph 0)
07:21:36.451   subtitles (graph 0) -> Stream #0:0 (h264_nvenc)
07:21:36.451   Stream #0:2 -> #0:1 (flac (native) -> aac (native))

Link to comment
Share on other sites

pünktchen

Not at home at the moment; but I think they are...because it uses the proper formatting / fonts. Also says unsupported subtitle format as the reason for transcode.

 

 

*******Anyways, as an ultimate test for this issue, among others, I reset my Shield to stock. A factory reset. Nothing changed.  For some reason my Shield takes forever to burn in SSA / ASS Subtitles.  Meanwhile, my browser does it instantly, as does my phone and my cheap ass Fire HD10 tablet.  Also Plex does it instantly.  With or without HW acceleration.

This is a log from your Android TV session, not from a browser session. I want to see the ffmpeg log when playing in a browser.

Link to comment
Share on other sites

Mkilbride

This is a log from your Android TV session, not from a browser session. I want to see the ffmpeg log when playing in a browser.

Was half asleep. Just got outta work.

 

The font is the same in the browser /  Phone / Tablet, the same font if I burn in the subs. if I don't burn them in, I just get white text subs.

 

It's instant in all them. Including Plex.

ffmpeg-transcode-12b98413-db08-4dd9-add7-42652de988b3_1.txt

Edited by Mkilbride
Link to comment
Share on other sites

The burn in appears to be happening differently for some reason.  We're gonna need @@softworkz to take a look and tell us why that is...

Link to comment
Share on other sites

pünktchen

 

Perhaps the font being used is different?  The delay appears to be on the server.  Here is an 8 second delay determining the streams or loading the font:

07:21:18.915 [subtitles@f2 @ 0000027c3f849940] Loading font file 'C:\Users\Mkilbride\AppData\Roaming\Emby-Server\programdata\fonts/DroidSansFallback.ttf'
07:21:18.945 [subtitles@f2 @ 0000027c3f849940] Using font provider directwrite
07:21:36.451 Stream mapping:
07:21:36.451   Stream #0:0 (h264) -> format (graph 0)
07:21:36.451   subtitles (graph 0) -> Stream #0:0 (h264_nvenc)
07:21:36.451   Stream #0:2 -> #0:1 (flac (native) -> aac (native))

It's been a while since school, but the delay is already 18 seconds not 8 seconds.

Anyway, also it looks like it's a font problem, it is not. It's the time ffmpeg needs to extract text based subtitles.

Link to comment
Share on other sites

It's been a while since school, but the delay is already 18 seconds not 8 seconds.

Anyway, also it looks like it's a font problem, it is not. It's the time ffmpeg needs to extract text based subtitles.

 

Sorry, yes I missed a digit there :).

 

The question, though, is why is the process different when played via the browser...?

Link to comment
Share on other sites

Sorry, yes I missed a digit there :).

 

The question, though, is why is the process different when played via the browser...?

 

The browser is extracting and rendering client-side. The android TV app is having the server burn them in with transcoding.

Link to comment
Share on other sites

I've learned it's a limitation of default ffmpeg.

If subtitles are embedded into the video container, ffmpeg first needs to extract the subtitles before they can be burned in. This takes time! Plex for sure has modified their ffmpeg version to circumvent this limitation.

 

 

The burn in appears to be happening differently for some reason.  We're gonna need @@softworkz to take a look and tell us why that is...

 

@@pünktchen is almost right, but what makes the difference here is the "almost":

 

ffmpeg does not extract the subtitles before starting. But it reads and parses the video file a second time - independently and separate as if it was a different application. Not completely, though - just like ffmpeg does: seeking to the starting point and subsequently reading from there.

That explains why the delay varies: It depends on whether you play from the start or resume from some saved position. The later that position, the longer it may take.

 

The delay also depends on additional factors: Whether it is located on a local disk or on the network, and how well the network server's SMB implementation can deal with such simultaneous requests for different byte ranges of a file. 

It may also depend on the container format and the seek index it provides.

 

That's why we're getting results in the range from hardly noticeable up to very annoying. It's nothing new though. We always had this behavior.

 

There's a plan for this, though. I hope we'll get to it soon.

Link to comment
Share on other sites

Mkilbride

Alright. Just hopefully it can be changed. I watch a lot of anime, and while I'd rather not burn in, a few series I've tried, I've seen random stuff like binary code appearing or random letters / overlapping text - if I don't burn in.  And having to wait up to 30s sometimes.

isn't the end of the world, but it certainly doesn't feel great.  Heck, even with PGS subs, if they put two subtitles on screen at the same time, I've had them overlap / one of them disappear.

 

This is all happening on my local server, in my house, all clients wired except obviously phone & tablet. As said, Plex is just click, take a breath, done. So it should be possible for the same for Emby.

Link to comment
Share on other sites

The reason why we took another loop is that this is not the only problem with subtitle burn-in. With 10 bit and UHD videos growing in share, it takes a lot of CPU power to burn in subtitles onto those videos, and that isn't available on many devices where users are running Emby server.

That's why - in this regard - we don't just want to get equal with the competition - we want to be able to do this with hw acceleration (when possible). It's going to come soon as it is among the top three in the area of transcoding - at least.

 

Meanwhile, as a workaround, you could try to use Emby's subtitle download feature. Downloaded subtitles are separate files and won't expose this kind of problem.

  • Like 1
Link to comment
Share on other sites

Mkilbride

I have that kind enabled, but it's really not downloading any subtitles for anything.

Link to comment
Share on other sites

I have that kind enabled, but it's really not downloading any subtitles for anything.

 

It doesn't when there are already some included which are matching the desired language.

But in most clients you can use the 3-dot button to open a menu from where you can "Edit Subtitles". There you can manually search  and download subtitles.

Link to comment
Share on other sites

Mkilbride

Sadly I tried like 3 different series and got 0 hits. So it's probably a no go.  I can deal with it for now, as long as I know it's going to get fixed, with TrueHD now being fixed by NVIDIA, My Premiere purchase isn't frustrating me anymore.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...