srt subtitles and transcoding

[Statick 15]

I'm trying to prevent transcoding from happening when watching 4k HDR videos on my 4K TV, as the quality suffers too much (I don't mind so much when regular HD videos get transcoded). a lot of my videos contain forced subs and this causes transcoding to happen. I understand why this happens when it's PGS, ASS, etc subs as my TV can't play those natively, so they have to be burned in. but it still also happens if I select SRT subs and those subs are muxed in the MKV container with the video, rather than being stored as a wholly separate SRT file

if I extract the SRT sub track and store it as a separate file, and select that instead of the embedded subs, then the video plays direct and everything is fine. but the exact same SRT subs cause transcoding if they're embedded. and of course my entire video library has embedded SRT subs.... so now I'm facing going through hundreds of episodes and movies to extract the sub tracks to separate files

is there a reason for the behaviour to be different? I don't see why the SRT subs should cause transcoding just because they're embedded in the container file?

I've tried the option to extract subs as plain text on the fly, but the results of this are out of sync with the video and audio by several seconds, so it's not usable

[visproduction 315]

Stat,
Doesn't this help?
-  Admin Dashboard / Transcoding / Allow subtitle extraction on the fly:  uncheck this box.

If that doesn't work then I agree, better user choice control over embedded srt subs seems like a good idea.  I think there is a way to remux multiple media files, all at once, to remove all embedded subs.  A full version of ffmpeg probably can do that with a command line.  I think MKVtools or AVIDemux can also be set to do multiple files in subdirectories.  If you can get one of those to work, you could do all your media with a click of the Enter key.  Just have enough hard-drive space to save the new files.  Typically remux and removing subs takes about 30 seconds per 2 hour media on an 8 year old notebook.  It's pretty fast.

Hope that helps.

[yocker 1248]

Those sub titles should indeed play without burnin as they are text based..

If not then that's worrisome as i just got half done muxing my entire library to remove graphical subs and keep text based subs plus re-encode audio to get better compatibility with Samsung devices. (Starting to hate Samsung devices.)
Don't want to do that again.

Edited October 8, 2024 by yocker

[Statick 15]

43 minutes ago, visproduction said:

Stat,
Doesn't this help?
-  Admin Dashboard / Transcoding / Allow subtitle extraction on the fly:  uncheck this box.

If that doesn't work then I agree, better user choice control over embedded srt subs seems like a good idea.  I think there is a way to remux multiple media files, all at once, to remove all embedded subs.  A full version of ffmpeg probably can do that with a command line.  I think MKVtools or AVIDemux can also be set to do multiple files in subdirectories.  If you can get one of those to work, you could do all your media with a click of the Enter key.  Just have enough hard-drive space to save the new files.  Typically remux and removing subs takes about 30 seconds per 2 hour media on an 8 year old notebook.  It's pretty fast.

Hope that helps.

I have unchecked that, unchecking this option causes embedded SRT subs to be burned in, checking it does avoid transcoding but the subs appear out of sync by several seconds so it doesn't help much. and yes I'm aware of the options for remuxing etc but it's a heck of a lot of work, much of which can't easily be automated, and importantly the subs need to be extracted to separate files (and named correctly for emby to use them) not just removed from the mkv container. even with automation there's still a lot of manual work and checking involved, and a lot of manual work went in to having SRT subs embedded in these rips in the first place (using OCR to convert the default PGS format). and my 4k UHD rips are diect muxes of blurays around 10-25GB per hour, so they take significantly longer than 30 seconds to remux

[Statick 15]

50 minutes ago, yocker said:

Those sub titles should indeed play without burnin as they are text based..

If not then that's worrisome as i just got half done muxing my entire library to remove graphical subs and keep text based subs plus re-encode audio to get better compatibility with Samsung devices. (Starting to hate Samsung devices.)
Don't want to do that again.

indeed, extracting the SRT to a separate file solves the problem but all my SRTs are embedded...! if "extract on the fly" worked properly then I'd just use that, but it seems like a lot of people have had problems with this feature for a long time as well (lots of forum posts about subs being out of sync with this enabled) so I'm not holding any hope of that changing any time soon

 

 

[Luke 42078]

26 minutes ago, Statick said:

indeed, extracting the SRT to a separate file solves the problem but all my SRTs are embedded...! if "extract on the fly" worked properly then I'd just use that, but it seems like a lot of people have had problems with this feature for a long time as well (lots of forum posts about subs being out of sync with this enabled) so I'm not holding any hope of that changing any time soon

 

 

Hi, it works just fine, as long as it happens quickly enough on your server machine. If it doesn't, then we have the option to disable it, which will force burn-in transcoding.

[Statick 15]

hi Luke, sorry it doesn't work fine, the subs do extract and appear on the screen as plain text so they "seem" to work, but the sub track is badly out of sync and the subtitles appear on the screen several seconds too early. I could understand it being a performance issue if they were appearing late but they appear several seconds before the audio they're supposed to align with. disabling this mode puts the subs perfectly in sync. this happens consistently with every sub track on every video I try with this mode enabled, I searched this problem and found a bunch of posts from other people having similar issues with the subs being out of sync when in this mode, going back over several years so it looks like it's been an issue for a long time and therefore not really a priority

which is fine, I wouldn't even need to look at using this mode, except for the fact that embedded plain text SRT subs are burning in anyway for some reason, and the only way to stop this seems to be manually extracting them and storing them as a separate file. this is more what my thread is about as this seems like incorrect behaviour and something that should be quite easy to solve? identical plain text SRT subs should exhibit the same behaviour whether they're embedded in a container or stored as a separate file, no?

one thing I've noticed is that when the subs are embedded, they appear in the selection box as SUBRIP format, and when they're a separate file they appear as SRT format. I'm not sure if this actually indicates anything but I figure it's worth mentioning

 

 

Edited October 8, 2024 by Statick

[Statick 15]

is there any answer or follow on to this, other than I just have to manually extract the plain text subs from all my media files if I want them to not burn in? it really seems like these shouldn't burn in when they're embedded?

 

Edited October 14, 2024 by Statick

[rbjtech 5284]

Any reason why don't you just pre extract all the SRT subs from the files ?  (you don't need to remove them from the MKV, I believe any external SRT file will be used instead of an embedded file)

There are plenty of free tools/scripts out there to extract them.

[pwhodges 2012]

Since I never have this issue with 1080p files, and there have been many threads with issues playing 4k files specifically - even Direct Playing - I do wonder what is so different, and whether the problems arise from something in the server or in the players concerned.

While I'm happy to endorse or recommend work-arounds, they are just that, and should not be allowed to divert from fixing the problem itself.

Paul

[rbjtech 5284]

31 minutes ago, pwhodges said:

Since I never have this issue with 1080p files, and there have been many threads with issues playing 4k files specifically - even Direct Playing - I do wonder what is so different, and whether the problems arise from something in the server or in the players concerned.

While I'm happy to endorse or recommend work-arounds, they are just that, and should not be allowed to divert from fixing the problem itself.

Paul

Well the logical explanation is extracting subtitles from say a 50-100 Gbyte 4K Remux is going to take significantly longer than extracting from a typical 5-15 Gbyte 1080p file.    From a NAS it effectively means dragging the entire file over the network to do so.    Thus 'real-time' extraction is not going to be realistic.

Pre-process all files to extract the SRT's in advance seems an obvious thing to do as the majority of players will pick up SRT's without the dependency on reading the main file.

This is what I have always done over many many years and I've never seen 1 file transcode because of subtitles.    I actually go one step further are remove the text based embedded subs, but I leave the PGS embedded for those players that can direct play those as they generally look nicer than text based subs.

Some extreme examples will take a long time to process @ 125 Gig - I believe ROTK is even bigger @ 140Gig ...

Edited October 14, 2024 by rbjtech

[Neminem 1519]

I use Tdarr to do this.

[Carlo 4561]

28 minutes ago, rbjtech said:

Well the logical explanation is extracting subtitles from say a 50-100 Gbyte 4K Remux is going to take significantly longer than extracting from a typical 5-15 Gbyte 1080p file.    From a NAS it effectively means dragging the entire file over the network to do so.    Thus 'real-time' extraction is not going to be realistic.

This almost always overlooked by people!

[pwhodges 2012]

1 hour ago, rbjtech said:

Well the logical explanation is extracting subtitles from say a 50-100 Gbyte 4K Remux is going to take significantly longer than extracting from a typical 5-15 Gbyte 1080p file.

According to the author of MKVToolNix, the blocks of a subtitle stream are spread through the file in order so that all streams have the data for a particular time close to each other.  If this is true, then extracting the subtitles first is exactly what you should not be doing.

However, on reflection, this cannot be true in all cases.  If I extract an ASS stream from a file, it will be returned in whatever time order the maker of the subtitles used - and very frequently the subtitles for the OP and ED songs are grouped at the start or end of the file for some reason.  When seeing that, I have always presumed that in this case the subtitles are stored as a block which could be fetched quickly for sorting by the client - but actually, this isn't consistent with my experience of subtitle extraction, which in the program I use clearly goes through the whole file.  So I've probably been insulated from the consequences of sorting out subtitles by the small files I generally have (and the fact that I always sort ASS subs into time order).  I don't know if SRT subs are required to be in time order, but if not, that would explain why it's necessary to get them all in advance.

OTOH, there is also in some situations a presumption that subtitles will inevitably be streamed at a point close to the corresponding audio and video - any live or broadcast stream, for instance.

I guess it's just more of a mess than I allowed myself to acknowledge, so the most consistent solution is - yes - curating your media to avoid embedding SRT or ASS subs into large files; plus having a really fast route to your disks - which is one reason why I have all my media on disks (hard or SSD) attached to the server's motherboard.

But of course there's no excuse for the subs to be out of sync, ever.  They are timed and so that should be that.

Paul

[visproduction 315]

Maybe there is a code fix to make this work better.

In the meantime...

If you run a business, you could always just charge 20 times more!  Ha!  Charging up also helps dissuade clients from asking for the service in the first place.  Of course, that only works when there is a client paying for the service. 

Or hire a freelancer to come in.  Even if you are doing this as a hobby, it would be nice to do other tasks instead of this.

[Statick 15]

On 14/10/2024 at 16:55, rbjtech said:

Any reason why don't you just pre extract all the SRT subs from the files ?  (you don't need to remove them from the MKV, I believe any external SRT file will be used instead of an embedded file)

There are plenty of free tools/scripts out there to extract them.

two things

one - extracting all the SRTs that I previously spent ages embedding is a large task when you have a large library, not one that I wish to do

two - you actually do need to remove the subs from the MKV unless you want to manually select the correct sub every time. the embedded sub is what gets selected by default even when an external SRT is there. so if you just select an episode and click "play", like anyone would normally do, and the show contains embedded forced subtitles then 100% that is what gets used, and so you get transcoding, and if it's a 4k HDR media then playback falls to pieces because my system cannot transcode 4k effectively. I have seen many posts that "it doesn't matter as it will select the external sub by default anyway" but this is not my experience, 100% every time if there are both embedded and external subs, the embedded subs are top of the list and selected by default. so the only way I can get smooth direct playback including subtitles every time without having to remember to click across and change the selected sub, is to remove the embedded subs from the media entirely so that only the external sub remains. using "extract subs on the fly", which is also supposed to solve this, means the subs appear 5 seconds ahead of the video, so this is useless as well

so the large and apparently necessary task of extracting the subs from every single media file I have, becomes significantly larger thanks to also having to remux the media files with the subs removed, and if I actually do this to my entire library this will also cause my backups to grow enormously as all my media files will change and be re-backed up. in fact it probably means I will have to delete all my original backups as I won't be able to hold two unique backups of my entire library on my available storage. okay it's not the end of the world but you can probably understand why I'm keen for the plain text subs I have to just play without transcoding, right? especially when I'm repeatedly told there are several different ways around this and none of them actually work!

 

 

 

 

Edited October 23, 2024 by Statick

[pwhodges 2012]

There ae GUIs for MKVToolNix which will enable you to extract in bulk really quite easily; I use one which I can't recommend as it's no longer available on the Internet (!), but others are linked at the end of the MKVToolNix install process.

Similarly, rather than tediously removing embedded subtitles, you can just reset the "forced" flags, again in bulk, and without rewriting the whole files, using jMkvpropedit.

Paul

[rbjtech 5284]

11 hours ago, Statick said:

two things

one - extracting all the SRTs that I previously spent ages embedding is a large task when you have a large library, not one that I wish to do

two - you actually do need to remove the subs from the MKV unless you want to manually select the correct sub every time. the embedded sub is what gets selected by default even when an external SRT is there. so if you just select an episode and click "play", like anyone would normally do, and the show contains embedded forced subtitles then 100% that is what gets used, and so you get transcoding, and if it's a 4k HDR media then playback falls to pieces because my system cannot transcode 4k effectively. I have seen many posts that "it doesn't matter as it will select the external sub by default anyway" but this is not my experience, 100% every time if there are both embedded and external subs, the embedded subs are top of the list and selected by default. so the only way I can get smooth direct playback including subtitles every time without having to remember to click across and change the selected sub, is to remove the embedded subs from the media entirely so that only the external sub remains. using "extract subs on the fly", which is also supposed to solve this, means the subs appear 5 seconds ahead of the video, so this is useless as well

so the large and apparently necessary task of extracting the subs from every single media file I have, becomes significantly larger thanks to also having to remux the media files with the subs removed, and if I actually do this to my entire library this will also cause my backups to grow enormously as all my media files will change and be re-backed up. in fact it probably means I will have to delete all my original backups as I won't be able to hold two unique backups of my entire library on my available storage. okay it's not the end of the world but you can probably understand why I'm keen for the plain text subs I have to just play without transcoding, right? especially when I'm repeatedly told there are several different ways around this and none of them actually work!

Unless a bug has crept in - the EXTERNAL SRT will be used as a priority over an identical internal/embedded subtitle - confirmed by the devs in this thread :-

https://emby.media/community/index.php?/topic/95500-how-do-i-set-srt-subtitle-files-as-default/

So some examples

example 1

embedded - movie.srt (English + no flags set)

external - movie.en.srt 

Result - With no previous subtitle selection - the external movie.en.srt will be used

example 2

embedded - movie.srt (English + default flag set)

external - movie.en.srt 

Result - With no previous subtitle selection - the embedded subtitle will play - as the default flag now overwrites the external sub

example 3

embedded - movie.srt (English + default flag set)

external - movie.default.en.srt 

Result - With no previous subtitle selection - the external movie.default.en.srt will be used - (as external superseeds embedded)

If you ALWAYS want an external sub to play - then use .forced. instead of default

So in summary - You do not NEED to remux out the subs - you just need to ensure the external sub is named correctly.

The external sub needs to have (in ranking priority)

a) language must match client request

b) forced > default > none (in that order)

c) external > embedded (in that order)

d) client preference - personally, I set to forced only, but can also be set to Default or 'Smart'.

 

So yes, I agree it's 'complicated' but to use external subs when embedded are present, emby needs this logic to make a good programatic decision.

 

Sadly, this level detail is not in the Emby Wiki - but probably should be.   @Carlo

Edited October 24, 2024 by rbjtech
formatting

[Carlo 4561]

https://emby.media/support/articles/Subtitles.html
This explains how to name external subs as eithers default or forced.
 

There are programs that can extract the subs for you as well as many other functions: Fileflows, Unmanic, Tdarr
Those are listed from easiest to most complex. Search Youtube for each tool. Set up a test library to play with vs your actual libraries while learning the tools.

 

 

[rbjtech 5284]

43 minutes ago, Carlo said:

https://emby.media/support/articles/Subtitles.html
This explains how to name external subs as eithers default or forced.
 

There are programs that can extract the subs for you as well as many other functions: Fileflows, Unmanic, Tdarr
Those are listed from easiest to most complex. Search Youtube for each tool. Set up a test library to play with vs your actual libraries while learning the tools.

 

 

Sure - but I think you are missing the important point here - what will emby select if there are embedded subtitles of the same type ?

A classic example is if the embedded subtitle - lets say Eng - it may have a Default flag in the MKV.     If I download an external file - name it according to your link above - movie.en.srt - the internal sub will STILL be the one used by Default.     Only if you name it movie.en.default.srt will it then use it as the Default.   Alternatively of course, you could just remove the 'Default' flag in the MKV, and then it would use the external SRT as a preference.

That is not explained in the wiki ...

My personal opinion is an external file named movie.en.srt should be used as priority over any embedded sub for en - default or not.  If the admin has bothered to download/extract it - then it's probably the one they want to use. 

Edited October 24, 2024 by rbjtech

[Carlo 4561]

If the same subtitle is embedded and external (properly named) the external subtitle will get used. Caveat, if the external subs aren't named correctly with default, forced or hearing impaired while the flags are present on the embedded tracks AND the user has a subtitle mode set to use default, forced or hearing impaired the embedded track will ger used. This is actually a naming problem on the external subs.

If you don't want the server to use embedded subs you can always do this as well.

[rbjtech 5284]

13 hours ago, Carlo said:

If the same subtitle is embedded and external (properly named) the external subtitle will get used. Caveat, if the external subs aren't named correctly with default, forced or hearing impaired while the flags are present on the embedded tracks AND the user has a subtitle mode set to use default, forced or hearing impaired the embedded track will ger used. This is actually a naming problem on the external subs.

If you don't want the server to use embedded subs you can always do this as well.

This is for transcoding only - the whole idea of this thread is to NOT use transcoding in the first place .. ?

tbh - I'm a little confused as you are repeating what I said above.       All the external progs that do the extraction will NOT name the file using 'default' thus embedded wins every time.     IMO this is Emby that is at fault - if nobody else does it that way, then it's Emby that need to change - not enforce an illogical name standard.

I'm suggesting you put something like your first paragraph in the wiki, with examples, so at least people will realise they need to name their subs with an extra 'default' in there to superseed the Default flag on the embedded sub... 

From your sig -

 

Edited October 25, 2024 by rbjtech

[Statick 15]

my external subs are correctly named as far as I know, but they never get selected over the embedded subs
 

Quote

 

tv episode.mkv

tv episode.en.forced.srt

 

the embedded forced subs are what get selected. I've tried both "default" and "smart" sub selection, and clearing previous selections, and it's the same every time. the embedded subs can be the same identical srt track (which was extracted to produce the external file which I then name as above), they can also be something entirely different such as a PGS sub (some of my rips still contain these), doesn't seem to make a difference, whatever the embedded sub is it still gets chosen over the external sub

 

[Statick 15]

On 24/10/2024 at 17:44, rbjtech said:

Sure - but I think you are missing the important point here - what will emby select if there are embedded subtitles of the same type ?

A classic example is if the embedded subtitle - lets say Eng - it may have a Default flag in the MKV.     If I download an external file - name it according to your link above - movie.en.srt - the internal sub will STILL be the one used by Default.     Only if you name it movie.en.default.srt will it then use it as the Default.   Alternatively of course, you could just remove the 'Default' flag in the MKV, and then it would use the external SRT as a preference.

That is not explained in the wiki ...

My personal opinion is an external file named movie.en.srt should be used as priority over any embedded sub for en - default or not.  If the admin has bothered to download/extract it - then it's probably the one they want to use. 

oh it's THIS
the embedded subs are flagged as default, my external subs are not, because I've named them the way the documentation explains, and the way every forum post I've seen on it explains as well. this is the first time I've seen anything that mentions putting "default" in the name as well

 

 

[Carlo 4561]

On 10/25/2024 at 6:00 PM, Statick said:

my external subs are correctly named as far as I know, but they never get selected over the embedded subs
 

the embedded forced subs are what get selected. I've tried both "default" and "smart" sub selection, and clearing previous selections, and it's the same every time. the embedded subs can be the same identical srt track (which was extracted to produce the external file which I then name as above), they can also be something entirely different such as a PGS sub (some of my rips still contain these), doesn't seem to make a difference, whatever the embedded sub is it still gets chosen over the external sub

 

On 10/25/2024 at 6:15 AM, rbjtech said:

This is for transcoding only - the whole idea of this thread is to NOT use transcoding in the first place .. ?

tbh - I'm a little confused as you are repeating what I said above.       All the external progs that do the extraction will NOT name the file using 'default' thus embedded wins every time.     IMO this is Emby that is at fault - if nobody else does it that way, then it's Emby that need to change - not enforce an illogical name standard.

I'm suggesting you put something like your first paragraph in the wiki, with examples, so at least people will realise they need to name their subs with an extra 'default' in there to superseed the Default flag on the embedded sub... 

I don't want to update the knowledge base yet, because I think the behavior has changed if it's favoring embedded subs over external.

I just did it in tdarr so I k know it can do it, but it has a bit of a learning curve.  ffmpeg can extract both graphical and txt subtitles. Subtitle Edit has a CLI that could be used as well.This is a very powerful subtitle program that can even convert graphical subs to txt based ones as well as fix errors in subtitles. I need to check to see if it can automatically pull the subtitles out, saving them with the track name.  Either of them could be wrapped in a script or C# program.

We really shouldn't need to extract the subs to keep the server from using them.  A far simpler solution would be adding a couple new config options to the server so we could have:
Disable use of internal graphic subtitles
Disable use of all internal subtitles

With internal subtitle use disabled, the file names of subtitles downloaded from Open Subtitles or other sources would not conflict or matter.

The downside might be that no client would get a direct play file if it contained internal subtitles. Remuxing the video is not CPU intensive and would actually save bandwidth, especially on a lot of ripped content having 40+ subtitles in it.

What do you think?