TV Show Subtitles Issue

[Carlo 4330]

Please see Paul's response above. We don't understand what you're trying to say since srt is just the extension of the subrip file.

1 hour ago, speechles said:

If the extension is SRT Roku understands what they are. If they come up as SUBRIP Roku drops the ball and will strip them.

 

[speechles 1920]

Please see my many responses about your posts. I don't need you to understand. You get in the way. You obfuscate. Then denigrate. Then irritate. I get it you must be bored?

When you see SRT the Roku will be able to show those correctly. When it says SUBRIP and believe me it does you will see it say this it might get them wrong on the Roku.

Ask @Luke why it says SUBRIP because it does. We even write capabilities for SUBRIP. If it didn't exist why is it there? I am not saying these things to confuse you. The two are listed individually on the subtitles presented by Emby. There is SRT. There is SUBRIP. We show them verbatim on the Roku how Emby presents them to the application. Haven't you ever seen it say SRT on one then say SUBRIP on some other one. You go wow.. confusing..which is which. Yeah me too. But I know that SUBRIP will get munged on Roku because it doesn't understand they are truly SRT. Same as ASS/SSA will be munged.

I see how we can get the captons on Roku working for Live TV too via EIA-708 container or EIA-608 itself.

Edited November 12, 2020 by speechles

[Carlo 4330]

Calm down speechles. I can't support something I don't understand, thus I'm asking for clarification on what you mean.
WE are just asking for clarity on what you said as it doesn't make sense to us.  By this we mean "How is srt and subrip different?"

It's our understanding that SRT is just the file extension for a subrip file.

No I haven't seen the difference but I don't use subtitles very often, thus I'm asking.
Can an SRT file ever be anything other than a subrip file in Roku land?

[Happy2Play 8296]

I will assume context is needed so I searched my Library as the subtitle codec filter does show SRT and SUBRIP as separate codecs.  Could be something legacy but here is an example

 

Is the primary difference internal vs external?  It would appear all my internal ones show as SUBRIP and external show as SRT, at least in my searching.

[Carlo 4330]

That's a good question Happy2Play. If you feel like doing a test, extract the subtitle to an SRT file removing it from the main media and see how Emby identifies it after this. I'd assume if reading a text file there is no "codec" associated with it so it will just show SRT or the file extension in place of the codec (not a codec anyway and the wording IMHO should be "format").

But I'm guess this is a Server issue calling the same things by two different names as they are both subrip formats.

I don't know if this is still current or not but from http://www.rokoding.com/subtitles.html it says:

"The SRT file must be external when used with MP4/M4V and can be either external or internal when used with MKV."

[Happy2Play 8296]

5 minutes ago, cayars said:

That's a good question Happy2Play. If you feel like doing a test, extract the subtitle to an SRT file removing it from the main media and see how Emby identifies it after this. I'd assume if reading a text file there is no "codec" associated with it so it will just show SRT or the file extension in place of the codec (not a codec anyway and the wording IMHO should be "format").

But I'm guess this is a Server issue calling the same things by two different names as they are both subrip formats.

I don't know if this is still current or not but from http://www.rokoding.com/subtitles.html it says:

"The SRT file must be external when used with MP4/M4V and can be either external or internal when used with MKV."

Same subtitle internal vs external

 

[Carlo 4330]

That's what I thought.  Emby calls it "Codec" vs format but both are subrips.  The only difference seems to be internal vs external in what Emby calls it.

[pwhodges 1533]

So, is there any reason for the Emby server not to normalise this in what it outputs (even if it has to recognise both to cope with varying legacy practice)?

Paul

[Carlo 4330]

That would be a question for @Luke

[Happy2Play 8296]

Or is this more of another defect in the Roku itself?

[Carlo 4330]

Can anyone test the following:

MP4 with internal & external subs

MKV with internal & external subs

Do the MKVs both play fine but MP4 only with external/srt and fail with internal?

What Roku device did you use if you try this?

[pwhodges 1533]

Roku Streaming Stick +  v9.3 and 9.4 (it hadn't yet updated, so I did it manually between tests).
Emby 4.0.12 (beta).

I made an mp4 copy of an mkv with srt subtitles, and also extracted them into a separate file. 

For the mkv file, MediaInfo called the subs simply "UTF-8", and MKVToolNix called them "SRT".
For the mp4 file, MediaInfo called them "timed text (sbtl)", and MKVToolNix didn't see them at all (to my surprise).

Emby on the Roku called the mkv subs "SUBRIP" and they played.
Emby on the Roku called the mp4 subs "MOV_TXT", and they did not play.
Emby on the Roku called the separate subs file "SRT", and they played in both instances.

The results were the same before and after updating the Roku; I didn't try the non-beta version of Emby.  The files both direct-played.

Paul

Edited November 13, 2020 by pwhodges

[Carlo 4330]

Thanks Paul, I did the same test with same results, mp4 with internal subrip doesn't play.

[speechles 1920]

Do the same test but abandon using the Emby audio/subtitle picker. Press * instead as the video plays and navigate to accessibility and click it. You will wind up on the menu shown below. Now pick them from the choices available pressing left/right to change.

It won't show what type of subtitle it is it will strictly use the NAME or the LANGUAGE. Does using the Roku Player UI itself to select it play? Go around Emby completely.

External subtitles DO NOT show on the Roku Player UI captioning track choices. This will limit you to internal subtitles only which is what we want to test.

If your Roku is NOT on firmware 9.4.x it will not update automatically. You must choose UPDATE SYSTEM to manually update. Roku limits the pool that auto updates and increases it every day by serial number. To get the update faster you must manually choose to do so.

Edited November 13, 2020 by speechles

[pwhodges 1533]

My Roku has no menu item called "Accessibility" that I can find.  However, because my wife is deaf, I have Roku set, through its "Captions" menu, to play any English subtitles/closed captions if available.  This setting was on when I did the tests above.

This Roku is not playing the embedded subtitles in my mp4 even when both the Roku and Emby are set to play them.

EDIT: A search found a recent Roku statement that the accessibility options are only available in the US market (not even in Canada, for instance).

Paul

Edited November 13, 2020 by pwhodges

[speechles 1920]

13 minutes ago, pwhodges said:

My Roku has no menu item called "Accessibility" that I can find.  However, because my wife is deaf, I have Roku set, through its "Captions" menu, to play any English subtitles/closed captions if available.  This setting was on when I did the tests above.

This Roku is not playing the embedded subtitles in my mp4 even when both the Roku and Emby are set to play them.

EDIT: A search found an official Roku statement that the accessibility options are only available in the US market (not even in Canada, for instance).

Paul

 

Press playback correction once after you enable the subtitles. Does using playback correction force them to show? They should work after that if it is what I am thinking it is. Roku assumes captions inside MP4 are chapter points ie. it ignores them.

Edited November 13, 2020 by speechles

[pwhodges 1533]

Yes, that worked!

Paul

[speechles 1920]

This is why playing some MP4 will start over entirely. MP4 are not supposed to have captions and Roku interprets them as chapter points. Add more than 1 caption to an MP4 and Roku may always restart at the beginning when you seek during Direct Play. Converting to MKV would immediately fix the problem. But the app should know this and we can train the capabilities to understand now.

Edited November 13, 2020 by speechles

[pwhodges 1533]

6 minutes ago, speechles said:

MP4 are not supposed to have captions

In what sense "not supposed to"?   What about MPEG-4 Part 17 "timed text", approved in 2005?

Paul

[speechles 1920]

9 minutes ago, pwhodges said:

In what sense "not supposed to"?   What about MPEG-4 Part 17 "timed text", approved in 2005?

Paul

The Roku. It misinterprets them as chapter points. Still does.

Every other device might support them. The Roku is "not supposed to" have captions in MP4 because of the confusion. We can train the capabilities to know this and then present them as if you had pressed playback correction once. Without you having to do it or wait for the player to respawn with the new play method. We can extract the subtitles and send them as WebVTT rather than let the Roku player think they are chapter points and strip them and possibly do odd behavior during playback.

It might be a bug on Roku they have yet to fix. But rather than wait for them to fix it we have to work around it. You would keep your MP4 in Direct Play and only the subtitles would be converted from subrip->webvtt and delivered. Using playback correction just confimed my suspicion. Playback correction causes a full remux. Subtitle extraction and conversion is much easier on your CPU. I would barely call it transcoding. The most mild form of it there is.

Edited November 13, 2020 by speechles

[pwhodges 1533]

Ah - so simply the Roku not being up with the standards.  OK...

Good that you can make a workaround, though!

Paul

[speechles 1920]

This must be why Roku raced to get support for WebVTT onto their devices last year. In an effort to make it easier to provide "slipstreamed" subtitles in the manifest when dealing with MP4. That must be what they did to fix it. They gave us WebVTT.

[Carlo 4330]

I like your idea of WebVTT with manifest.  How would we do this in your oppinion? If a user is direct playing a mp4 and 10 minutes in turns on subtitles?  Do we stop playing, switch to "remux" with the WebVTT and continue playing from that point on just as if the user changed resolution or bitrate? That sounds like a reasonable thing to do.

Another thing that could be done on the server is have an option to extract the subrip from the mp4 when new media is encountered, which could also be a job that runs on the server.  That would assure there is always an SRT for these files to avoid the problem in the first place.  This is actually pretty easy to do outside of Emby with a script as well.