Issue with subtitle glyph display

[justmeyep 5]

Quick question, I have an issue regarding the display of Japanese subtitles in videos.

It looks like this when watching it on Emby:

 

When using Plex it looks like this:

 

Is there anything I can do to fix it? I couldn't find a setting so far which changed the behaviour so far, also the font is different for some reason, even though its the same file.

Edited June 9, 2023 by seanbuff
amended second "Emby" per OP comment to avoid confusion

[Luke 42078]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[justmeyep 5]

Sorry, here is the requested information.

I expected to see the missing subtitle content like in Plex (works everywhere I tried it so far), but it doesn't seem to work on PC (Chrome and the MS Store App). Both are direct playing.

The Android app which is also direct playing is displaying them just fine.

 

I have attached the relevant log, I hope this helps

 

embyserver.txt

[pwhodges 2012]

That looks like a font problem with ASS subtitles.  Can you supply a small file with the problem so that we can see?

Paul

[justmeyep 5]

22 hours ago, pwhodges said:

That looks like a font problem with ASS subtitles.  Can you supply a small file with the problem so that we can see?

Paul

Sure, I have attached a video where the issue can be seen in the opening. 

sample.mkv

[Luke 42078]

Can you try our hosted web app and let me know how that compares?

http://app.emby.media

It has an updated font file. Thanks.

[justmeyep 5]

8 hours ago, Luke said:

Can you try our hosted web app and let me know how that compares?

http://app.emby.media

It has an updated font file. Thanks.

I tried it, but unfortunately it looks exactly the same.

[Luke 42078]

This is the font we’re using:

https://github.com/satbyy/go-noto-universal
 

does it not have the characters you need?

[pwhodges 2012]

The fonts required for those subs are: DFKai-SB (for the Japanese karaoke), Monotype Corsiva (for the romaji/English karaoke), Vesta (for the main subs); they are not provided as attachments in the video (at least, the supplied sample), which is bad practice.  I have attached a zip file with these three fonts in.

The fonts need to be on the machine where the ASS subs are rendered - i.e. the client if direct playing or the server if burning in.  If the fonts are not found, I don't know how Emby decides what alternatives to try.  Playing the sample directly (not through Emby) on my Windows machine without those fonts, I get all the characters, but ill-proportioned (like the English in your example above, but including the Japanese characters).

Monotype Corsiva and Vesta are widely available.  DFKai-SB is provided on Windows 10/11 in the Traditional Chinese font pack (it is used here because it is somewhat cursive and so matches the italic MT Corsiva font nicely). If you choose to install the fonts I've provided on your server, be sure to install for all users, if you are running the server with its own user.

(Sorry for the delay - I've been away for a long weekend).

Paul

ReqFonts.zip

Edited June 5, 2023 by pwhodges
(forgot fonts attachment)

[pwhodges 2012]

GoNoToCurrent includes the necessary characters (I made a version of the subs which requested it explicitly, and they were all there, but less good-looking).  But @Lukeare there circumstances in which a request for a specific other font which is absent (DFKai-SB in this case) will fall back to a font other than GoNoToCurrent?

Paul

[justmeyep 5]

47 minutes ago, pwhodges said:

The fonts required for those subs are: DFKai-SB (for the Japanese karaoke), Monotype Corsiva (for the romaji/English karaoke), Vesta (for the main subs); they are not provided as attachments in the video (at least, the supplied sample), which is bad practice.  I have attached a zip file with these three fonts in.

First of all thanks for the great insight once again! I think you forgot the attachment though. Also how can I check whether the files are supplied with the original video file? Is that possible with MKVToolNix(GUI)? I took a quick look but couldn't really find what I was looking for.

50 minutes ago, pwhodges said:

The fonts need to be on the machine where the ASS subs are rendered - i.e. the client if direct playing or the server if burning in. 

(I have video transcoding disabled)

I assume if the fonts are bundled with the video file, the Emby player will still not display them when direct playing?

53 minutes ago, pwhodges said:

If the fonts are not found, I don't know how Emby decides what alternatives to try.  Playing the sample directly (not through Emby) on my Windows machine without those fonts, I get all the characters, but ill-proportioned (like the English in your example above, but including the Japanese characters).

I have the same behaviour with the default Windows 11 player. However mpv (and Plex) seem to play them correctly. I assume this means they have the correct subtitles bundled with them or have better fallbacks?

I really appreciate the help!

[justmeyep 5]

36 minutes ago, pwhodges said:

GoNoToCurrent includes the necessary characters (I made a version of the subs which requested it explicitly, and they were all there, but less good-looking).  But @Lukeare there circumstances in which a request for a specific other font which is absent (DFKai-SB in this case) will fall back to a font other than GoNoToCurrent?

Do I understand it correctly?

You edited the container to use another font which Emby supports?

I'm not sure English isn't my first language ^^

[pwhodges 2012]

I edited the attachment in - it's there now.

MKVToolnix has an attachments tab on the main multiplex section - that's where fonts go. - so you can see them there, or add them.  Take care - it can get a bit messy, as there is no checking for duplicates (which don't really matter, but are untidy and take up a little extra space).  For a series, just put them in the attachments tab, then as you drop each episode and simply press the Multiplex button, it will be rewritten including them - the new attachments are preserved during a run, so it's quick and easy.

If the fonts are correctly attached, yes, the Emby clients will use them. 

Other players may not be correct in that they may be falling back to suitable but not identical fonts; there is probably no standard approach there!  And the subs file doesn't always give clues; in this case, for instance, the requested romaji font (Corsiva) is italic in itself, so the subs file doesn't specify italic - which is why in your example at the top of the thread, the (overlapping) characters are upright.  Here's the karaoke on my machine:

(The italic characters overlap slightly because the subs requested bold, which the font doesn't have - so the player just thickened them which made them touch.)

I determined what fonts were required by extracting the subs from the video (using a program no longer available, but you can use MKVExtractGUI) and looked at it in a subtitles editor (Aegisub).  To check the Emby font had the characters, I just edited the style that used the missing DFKai-SB to use GoNoToCurrent instead and played the video using that (as the specified font was present, the player wouldn't fall back to another just for individual characters).

Paul

Edited June 5, 2023 by pwhodges

[justmeyep 5]

I see, thank you very much.

I hope the behaviour can be improved.

I actually tried the original source file (I automatically transcode them with ffmpeg to av1) and it turns out they do have the attachments included..

 

This is a bit off topic but do you, by any chance, know if it is possible to preserve them in the output file when transcoding the files with ffmpeg?

(currently the command looks like this 'libsvtav1 -preset 8 -crf 12 -svtav1-params tune=0:enable-overlays=1:enable-tf=0:keyint=5s:lp=6 -pix_fmt yuv420p10le')

 

[pwhodges 2012]

It must be possible with ffmpeg, but I don't know the commands, as I use HandBrake for transcoding - which does copy over the attachments.

Paul

[justmeyep 5]

I'll try my best and will report back if I manage, in case someone else wishes to do something like that

[justmeyep 5]

On 05/06/2023 at 20:46, pwhodges said:

If the fonts are correctly attached, yes, the Emby clients will use them. 

I got around to trying the original file which has them attached in Emby, but unfortunately it looks the same. 

Do you by any chance have an idea as to why that doesn't work?

Thank you!

[pwhodges 2012]

What version of Emby server are you using?

There have been a lot of changes in the handling of subtitles in Emby over the past year or two, and I haven't bothered to remember the state at various times (for instance, some subtitle things were in the 4.7 beta, but not release, which is a particular confusion for me).  I am using the current beta 4.8 of the server (and also of the clients I use), so I am well up to date with the changes - which have affected SSA/ASS subs most of all.

The crucial thing here is the behaviour of Emby when transcoding is involved - it may be as simple as the fact that in that past subtitles could be stripped and reduced to text (effectively SRT) before passing on to the client or being burnt in to the video, which destroys ASS formatting and features. 

At the bottom of the transcoding settings page is an option "Allow subtitle extraction on the fly" - I have that off, which is probably the preferred value, as it can cause long delays in starting viewing of large files (they may need to be scanned right through to get the subs). 

The other settings I have require the beta server and the diagnostics plugin installed.  With those, there is a settings page (near the bottom) called "Subtitle Options".  The first option there is "Subtitle delivery method", and I have selected "prefer burn-in".  The result, for me, is that if the client can handle ASS subs, then the file will be direct played (other things such as video codec being equal), but if it can't (e.g. web client) then the subs will be burnt in - with all the ASS features included.  To get the full effect of complex karaoke you should select "Enable high frame-rate subtitle burn-in", if your machine can handle it. That should be all you need.

Paul

[justmeyep 5]

5 minutes ago, pwhodges said:

What version of Emby server are you using?

I am currently running the latest beta for testing.

7 minutes ago, pwhodges said:

The crucial thing here is the behaviour of Emby when transcoding is involved - it may be as simple as the fact that in that past subtitles could be stripped and reduced to text (effectively SRT) before passing on to the client or being burnt in to the video, which destroys ASS formatting and features. 

I wish to prevent transcoding whenever possible. The server which I am running on is unfortunately quite weak as well. As such video transcoding is disabled.

34 minutes ago, pwhodges said:

At the bottom of the transcoding settings page is an option "Allow subtitle extraction on the fly" - I have that off, which is probably the preferred value, as it can cause long delays in starting viewing of large files (they may need to be scanned right through to get the subs). 

When the setting is disabled, it will not show any embedded subtitle from what I can tell. Whether video transcoding is enabled or not. The fonts are present in this video as attachments.

Off topic but also it would be great if it were possible to do it 'really' on the fly like Plex does it, since I assume it can display the required part before having read the whole file (much faster).

 

But I have found very weird behaviour:

The files are direct playing, subtitle extraction on the fly is enabled. I think it's the easiest to explain with images.

 

Embedded subtitles (extracted on the fly)

External subtitles (they do NOT have the fonts attached inside them (the filesize is smaller than the fonts combined..)

 

 

Both episodes display the subtitles correctly, with the external subtitle that do not have the language tag in them.

???????????????????

I have tested this on both the MS-Store Emby client and Chromium. This must be a bug.

I really hope this can be resolved, it was quite a pain to figure this out to be honest.

Could you look into this @Luke?

I can provide the files if this is helpful.

[justmeyep 5]

I just yet (wow) noticed that the second picture in the top post also says 'Emby' that should've been 'Plex' all along, I hope that didn't cause any confusion. :D

[pwhodges 2012]

As I said, allowing Emby to extract the subs will lose the fonts and maybe more.  I would never recommend allowing Emby to extract ASS subs (or any, in general), nor using external ASS subs.

The various Emby clients other than the web client will handle embedded ASS subs just fine, so long as they are not extracted by Emby.  When transcoding, the burn-in option also ensures that they work, and this covers the web client issue.  The greater part of my viewing is anime, and I have kept pushing for this to work smoothly, and now, for me it does.

It may be that you have to install the diagnostics plugin so that you can select the right burn-in option; I'm not sure, because when I uninstalled it, the subs continued to work, but that might just be because the settings are currently persistent (in some earlier betas they were not) - but in any case I recommend you install it and enable the settings I have.  (I'm a bit puzzled that now subs are IME working so well, the code that makes it happen is still not being fully released.)

Anyway, just to see if there was anything odd I downloaded the exact file I presume you are using in your examples, the [CUNNY] encoding of Redo of Healer (I'm amused that the series concerned gets the worst reviews I have ever seen for any anime!), and as they come the embedded ASS subs show perfectly when direct playing in the Android, iOS, and Windows clients, and when transcoding (and hence being burnt in at the server) in the web client.  That's with the settings I listed earlier, and no external files at all.  But if your machine can't handle transcoding, then you'll be out of luck with the web client whatever you do (other than burning in the subs in advance using HandBrake).

Paul

 

[justmeyep 5]

I know that the playback of ASS fonts is unfortunately not possible in the web client as is.

However I find it unfortunate that the language tag seems to filter out(?) the other characters since that makes it look even worse in my opinion.

This naming scheme (with language) results in display of the blank Unicode boxes as seen in the first post:

This one makes the foreign subtitles appear in the web client, but also without the correct font:

I did try the Diagnostics plugin and the settings you suggested do work. I was able to play two streams at the same time and the subtitles indeed get represented with the correct font and everything, thank you.

However this indeed causes a big loss in quality and even then it looks like at most two 1080p streams.

Is there a Windows client that utilizes e.g. mpv?

 

Edited June 8, 2023 by justmeyep

[pwhodges 2012]

The windows client is Emby Theatre, and there is also a(n inferior) store version; by default it plays your file (with embedded subs) correctly without transcoding.  It can be configured to use an external player, but doing so loses some facilities; I used that feature in the past (before Emby handled subtitles as well as it does now).

If transcoding is leading to a significant loss of quality, perhaps you have set a bandwidth limitation somewhere; by default Emby tries to transcode using a bandwidth at which the AVC encode will match the quality of whatever the original was - so it may go for a higher bandwidth than the original.

I don't know about the effect of the language flag on subs.  What you describe does sound like a bug; but I rigorously avoid having separate subs at all, so I've never seen the effect.

Paul

[justmeyep 5]

12 hours ago, pwhodges said:

The windows client is Emby Theatre, and there is also a(n inferior) store version; by default it plays your file (with embedded subs) correctly without transcoding.  It can be configured to use an external player, but doing so loses some facilities; I used that feature in the past (before Emby handled subtitles as well as it does now).

Thank you for the link, this version of Emby Theatre, not like the one in the store, seems to display them without issue. External subtitles seem to work as good as the embedded ones.

Unfortunately the app immediately becomes nonfunctional/freezes when trying to seek in my AV1 files and issues such as this occur:

 

It also freezes when exiting out of AV1 playback.

When it freezes, the app must be force closed.

12 hours ago, pwhodges said:

If transcoding is leading to a significant loss of quality, perhaps you have set a bandwidth limitation somewhere; by default Emby tries to transcode using a bandwidth at which the AVC encode will match the quality of whatever the original was - so it may go for a higher bandwidth than the original.

It should be set to the highest option everywhere, I assume it uses a slower preset because the hardware isn't strong enough.

12 hours ago, pwhodges said:

I don't know about the effect of the language flag on subs.  What you describe does sound like a bug; but I rigorously avoid having separate subs at all, so I've never seen the effect.

I extract the subtitles in my workflow, so Emby doesn't have to do it on the fly which would cause them to appear pretty late after starting playback in some scenarios.

[pwhodges 2012]

1 hour ago, justmeyep said:

Unfortunately the app immediately becomes nonfunctional/freezes when trying to seek in my AV1 files and issues such as this occur:
It also freezes when exiting out of AV1 playback.

I have a lot of AV1 files, and I can't reproduce either of these behaviours...  I guess my machines are more powerful than yours, but can't see any good reason why that would matter.  I suppose there could be a race condition that could be triggered by multiple fast commands on a slow machine, but in that case I'd expect more reports of it.

Quote

I extract the subtitles in my workflow, so Emby doesn't have to do it on the fly which would cause them to appear pretty late after starting playback in some scenarios.

But Emby doesn't extract them on the fly unless you tell it to.  A properly structured file for streaming can be played without the subs being extracted.  In my tests for the hangs you get, I jumped back and forth between the ends of a video while playing with subs, and the jumps were instant, with the subs appearing instantly as well.

Paul