Timeout starting movies with internal subtitles

[fuzzthekingoftrees 10]

My subtitled movies are in mkv format with srt subs muxed into the file. The first time I start one of these movies emby kicks off an ffmpeg job to extract the subtitles into an srt file. Whilst this job is running the Samsung app times out. I have to go back to the menu and hit play again. The second time and all subsequent times it plays fine because emby caches the srt file.

Is it possible to extend this timeout? My emby server isn't slow, quad i7, movies on a 4 disk RAID 10.

[SamES 1057]

My subtitled movies are in mkv format with srt subs muxed into the file. The first time I start one of these movies emby kicks off an ffmpeg job to extract the subtitles into an srt file. Whilst this job is running the Samsung app times out. I have to go back to the menu and hit play again. The second time and all subsequent times it plays fine because emby caches the srt file.

Is it possible to extend this timeout? My emby server isn't slow, quad i7, movies on a 4 disk RAID 10.

 

I've noticed this as well recently, and I'm not sure if it's a server or client issue.  Even on subsequent loads (using the cached subs) it can still take about 40 seconds on the loading screen before the title starts to play (even when there is no transcoding going on at that time)

 

The first time it did take a very long time, and I thought it had crashed (I recall from the log that ffmpeg took about 5 minutes to extract the subs)  I'm presuming the server is preventing playback until the subs are extracted/processed.  I wonder if it's possible for playback to start while the transcoding continues at the same time, the same way transcoded playback operates?

[Luke 42080]

can you post the media info from the web client as well as the transcoding logs? thanks.

[SamES 1057]

can you post the media info from the web client as well as the transcoding logs? thanks.

 

So after finding and deleting the sub, I was able to force the sub to transcode again.  This time, it took about 2 minutes for playback to start, although from the transcode log, ffmpeg only took about 25 seconds to process.

 

ffmpeg-sub-extract-e32b462a-ee67-49fe-8c04-8054bf94ba2b.txt

 

Playback using the cached subs still takes about 40 seconds to start without any transcoding.  

 

This long start time may not be a result of the subs.  I first noticed the very long start time because of the subs transcode, and have assumed the the subsequent long start times are related.  I do have other MKV's with subs and don't have any playback issues with them

 

Ironically, the created sub file is very small

 

0cad1904-4524-f28b-497d-0def1146efa8.srt.txt

 

Here is the media info

 

Video

CodecH264

ProfileHigh

Level41

Resolution1280x688

Aspect ratio1.85:1

AnamorphicNo

InterlacedNo

Framerate23.97602

Bitrate6119 kbps

Bit depth8 bit

Pixel formatyuv420p

Ref frames5

CABACYes

Audio

Languageeng

CodecDCA

ProfileDTS

Layout5.1

Bitrate1500 kbps

Sample rate48000 khz

DefaultYes

Subtitle

Languageeng

CodecSRT

DefaultYes

ForcedYes

ExternalNo

Subtitle

Languageeng

CodecSRT

DefaultNo

ForcedNo

ExternalNo

Subtitle

Languageeng

CodecSRT

DefaultNo

ForcedNo

ExternalNo

Containermkv

Size4479 MB

Edited April 11, 2015 by SamES

[Luke 42080]

if there is no transcoding and still a 40 second timeout with cached subtitles, then that suggests some kind of client-side bottleneck. So that should be looked into and/or possibly just having the server burn them in with transcoding. Granted that's not as desirable, but most people probably won't find a 40 second wait time acceptable.

 

as for the 2 minute delay without cached subtitles, that's an area for improvement for the server. we're going to have to decide between pre-caching them with a scheduled task, or just requiring them to be burned in.

[nague 5]

Since upgrade in 3.0.5781.0, I can no longer select mkv internal subtitle (SRT or ASS) for video playback.

 

Starting a video with subtitle enable (or switching on subtitle when video is playing) causes the ffmpeg daemon to fully load the mkv file (What for? To parse subtitles?) before starting transcoding. I’ve reproduiced this issue with all my mkv files, with Chrome and Android client.

 

The main issue is that my video folders are located on CIFS (samba) shares. Downloading the full mkv file is taking 3 ou 5 minutes! Do you have any idea why this behavior appears with last upgrade? Regarding the release note, I can’t see any changes related to ffmpeg…

 

Second issue since 3.0.5781.0 (less important): every time I start emby server, all movies from one (always the same) of my library folders disappeared. After a library scan, movies are back.

 

I forgot to do the a snapshot before upgrade   Is there an easy way to downgrade to the previous emby release? Maybe someone has kept the 5724.6 or 5768.7 deb file?

Edited November 3, 2015 by nague

[nague 5]

A possible explanation for the subtitle issue: according to this ticket (https://trac.ffmpeg.org/ticket/4499), parsing internal subtitles before transcoding is a normal behavior for ffmpeg if we want subtitles to be burnt to the picture. Parsing an 8 to 10Go file can’t take a very long time, especially if the file is located on a samba share.

 

The question is: why I didn’t have to wait for subtitle parsing before upgrade in 3.0.5781.0 ? As I’m often using emby clients from low bandwidth location, direct stream is not an option.

 

Did emby server changed the internal subtitle method for transcoding?

[nague 5]

@@Luke Did you make a decision between pre-caching or burning in?

 

I’m experiencing a strange behavior with mkvs internal subtitles when transcoding (with Chrome Web Client):

 

• For some of my video files, internal subtitles are pre-cache once for all. The first time it’s played, it takes 30 to 100 seconds to start (quite acceptable).
• With others video files, internal subtitles are burning in each time it’s played, each time the video seek-bar is used. As ffmpeg reads the whole file to parse subtitles before transcoding, it takes more than 1 minute to start the video playback (not acceptable).

 

I can’t find any difference between files for first or second category, except… the file size.  First category file are smaller than 6Go other are higher. Did such differentiation have been implemented?

[Luke 42080]

i'm just going to revert the recent change of burning them in. it was added to remove the delay when extraction takes too long, but clearly burning them in seems to be more painful.

[nague 5]

Is this “recent change” concern 3.0.5781.0 ? That could explain why this release made me crazy !

As long as ffmpeg is not able to burn in subtitles on the fly, pre-cache is an acceptable solution. A scheduled task would be perfect  

Edited November 4, 2015 by nague

[nague 5]

@@Luke Did you apply the reverse change you were talking about ? I've made a clean install of emby 3.0.5781.0, internal subtitles are still always burning in.

[Luke 42080]

for the next release, yes.

[nague 5]

I've just upgraded to release 3.0.5781.1: internal subtitles are now always pre-cached. Moreover extraction seems to be proceed in background, during playback. Great choice. Thanks Luke.

 

[nague 5]

@@Luke Did you roll back the internal subtitles changed  for ASS format ? I've just upgraded to 3.0.5781.3 and internal subtitle in ASS format are no more  pre-cached

Edited November 23, 2015 by nague

[Luke 42080]

Nothing was changed. There has never been any pre-caching. The extraction is cached after first use.

[nague 5]

My mistake if I didn't notice this behavior in 3.0.5781.1, I confirm : ASS internal subtitles are not cached, but burned-in. It’s not a big deal, I’ll clean my mkv with ASS subtitles  

[Luke 42080]

.ass subs are just a no-win situation if the client app can't handle them internally. if we use the extraction method we have one kind of user who gets upset about the formatting being lost due to the text conversion. If we burn them in, then another crowd comes after us due to the cpu usage. So it's pick your poison and as of now we're burning them in.

[nague 5]

It sounds like the best choice. Thx for your help.

[psxlover 31]

.ass subs are just a no-win situation if the client app can't handle them internally. if we use the extraction method we have one kind of user who gets upset about the formatting being lost due to the text conversion. If we burn them in, then another crowd comes after us due to the cpu usage. So it's pick your poison and as of now we're burning them in.

 

I don't have a problem with high cpu usage, but the fact that it takes too long to start the streaming means that I cannot see videos more than 1-2GB in size through DLNA in my TV because the stream times out (and unfortunately in contrast to the original issue of the thread, selecting the video a second time does not reduce the time needed for the stream to start).

 

I guess I'll have to let the TV handle the .ass subtitles (and lose all formating plus a couple of lines here and there, because it handles them as simple .srt files).

 

As a feature request, perhaps the web client and the applications could use a javascript library to handle .ass subtitles to avoid transcoding them. I believe I've seen one or two somewhere online, but I don't know how good they are.

[Luke 42080]

well i just pm'd  you about javascript but dlna is a little trickier unless you're willing to forego .ass styles for plain text conversion.