Jump to content

subtitles are not available


Recommended Posts

Florian2000
Posted

Hi,

I just merged videofiles and subtitles via MKVToolNix and now the subtitles are not available in emby (Windows / Android).
What causes this? Because VideoLAN Player recognizes the subtitles just fine...so they are within the mkv container file.

Any idea?

Br, Florian

Posted

Hi, did you run a library scan after changing the file?

Florian2000
Posted
12 hours ago, Luke said:

Hi, did you run a library scan after changing the file?

yes, I always do.
The interesting thing is that the additional audio language is there for selection. Only the subs are missing.

grafik.png.6e5a35ff0a3979e725369da6eab3a25a.png

subtitles according to VLC:

grafik.png.97c3a8977f97f9dfaab20e7496fedb2d.png

the container format is mkv.
The tracks within MKVToolNix:
grafik.thumb.png.e5071071a7493bf194aa006115c0c4b4.png

 

Posted

Try refreshing the metadata on that file and see if it helps.

Florian2000
Posted
12 minutes ago, Luke said:

Try refreshing the metadata on that file and see if it helps.

just did...nothing changed. still no subs there.

Posted
1 hour ago, Florian2000 said:

just did...nothing changed. still no subs there.

Hi, server log from doing that? Thanks.

Florian2000
Posted
1 hour ago, Luke said:

Hi, server log from doing that? Thanks.

I hope there is nothing in the log which shouldn't be seen...I took the portion where I think this was the related stuff from refreshing the metadata.

embyserver.txt

Posted

Are they internal subtitles or external?

Florian2000
Posted

the subtitle files are srt files which are now in the mkv container.

Happy2Play
Posted

@Lukedoes it matter that the subs at least from image above are internal "WebVTT"?

In a test Emby only sees external VTT not internal VTT.

Happy2Play
Posted

 Additional info from ffrpobe

  Stream #0:4(chi): Subtitle: none (default)
    Metadata:
      BPS             : 43
      DURATION        : 01:49:14.664000000
      NUMBER_OF_FRAMES: 983
      NUMBER_OF_BYTES : 35681
Unsupported codec with id 0 for input stream 4

Media info

Text #2
ID                                       : 5
Format                                   : S_TEXT/WEBVTT
Codec ID                                 : S_TEXT/WEBVTT
Duration                                 : 1 h 49 min
Bit rate                                 : 43 b/s
Count of elements                        : 983
Stream size                              : 34.8 KiB (0%)
Language                                 : Chinese
Default                                  : Yes
Forced                                   : No

Looks like it maybe an old open defect.

#5641 (Support WebVTT according to MKV specs) – FFmpeg

Florian2000
Posted
11 hours ago, Happy2Play said:

In a test Emby only sees external VTT not internal VTT.

what is the difference between external VTT and internal VTT?

pwhodges
Posted

External - separate file; internal - embedded as stream in MKV.

Paul

  • Like 1
Florian2000
Posted

so is it a bug, isn't it?

Florian2000
Posted (edited)
4 hours ago, Florian2000 said:

so is it a bug, isn't it?

interesting thing is that the subtitles from netflix work just fine within mkv.
grafik.thumb.png.f90ed58bc314014547b7c5622c5f9964.png

So there must be a difference between internal SubRip/SRT (netflix format) and internal WebVTT (disney+ format).

Edited by Florian2000
Posted

it looks like ffmpeg currently does not support this, so your best bet for now is to either keep them external, or embed them as a different text format such as subrip.

Florian2000
Posted
On 1/4/2022 at 7:01 PM, Luke said:

it looks like ffmpeg currently does not support this, so your best bet for now is to either keep them external, or embed them as a different text format such as subrip.

and how does the VLC player manage to play them correctly?

pwhodges
Posted

VLC is not just a front-end for ffmpeg; it has additional modules containing codecs etc which are not included in ffmpeg.

Paul

Florian2000
Posted
1 hour ago, pwhodges said:

VLC is not just a front-end for ffmpeg; it has additional modules containing codecs etc which are not included in ffmpeg.

Paul

why not take the code from vlc then?

grafik.thumb.png.ac4efefce3e8c548bff877b6b03e12d4.png

would also solve the *.iso playback...which is much better solved in VLC, too...

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...