Emby struggles to transcode large files with ASS subs

[Mikoyan 6]

 

Link to my previous post where there was a related issue, but same symptoms. (previous issue was resolved, FYI)

When Emby starts the process of transcoding a video with embedded (burned in) subtitles, it starts ffmpeg process to read, then start creating segments. However, the main Emby process only waits 10 seconds before calling exit signal on ffmpeg (I timed this multiple times with a stopwatch so probably a hard value somewhere). This behavior is not visible for relatively small files (TV episodes, or files around or less than 4GB) because the process usually finishes quickly, but anything larger than that, it takes somewhat more time to complete the pre-transcode process - The time it takes for ffmpeg to start writing segments seems to scale linearly with the size of the video file. And since Emby forces the process to exit before it finishes, transcoding does not begin, resulting in stream failure.

For some files, Emby seems to recover from this by "unloading" the subtitles entirely and stating that it had recovered from a playback error. In this case, the media starts playing, but with no subtitles.

I am writing this post because this seems to be something other than disk performance issue, I wrote the same file to SSDs and tested, which failed in the same manner. This post is primarily aimed at Linux server but this same behavior can be seen in Windows as well. Far larger files that do not use ASS do not have the same issue (17-26GB), ffmpeg finishes extremely quickly, maximum three seconds, and segments begin streaming to client. In a similar vein, performing subtitle extraction on the fly (therefore bypassing the need to burn in) also does not have issues. This seems to indicate there is a very large compute overhead when burning in ASS/SSA type subtitles, and a lot of time seems to be spent in ffmpeg loading the subtitles from start to finish, then "re-loading" them again in their entirety after libass is loaded. I can post logs to show this later, but because of this associated cost with transcoding ASS/SSA files, it makes large videos (Blu-Ray directs usually, or long movies) impossible to play if they are using ASS/SSA styled subtitles and require burn-in.

To rule out system specs bottleneck, this server uses an AMD EPYC 7313P processor and the disks are on a SAS plane. Nothing else runs on this host except Emby.

Assuming I am right about my assumption regarding ffmpeg timeout, can this time value be increased/scaled with filesize if the processing overhead cannot be reduced? Ideally, the overhead can be optimized or reduced to be in-line with other simpler sub formats.

[Luke 37066]

 

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

 

[Mikoyan 6]

15 hours ago, Luke said:

 

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

 

@LukePlease find files attached.

The three transcodes are from the same attempt to play the file (retries by Emby, not myself). I tried to play from the web UI.

 

Since my last post I have also moved the transcoding directory and cache to an Optane backed storage device, to see if that might help. It didn't

Reading suggests that ffmpeg is bottlenecked to a single thread when transcoding, which might also be part of the problem of it being slow... and this is apparently improved on with multithreading in ffmpeg 7.0, to be released at some point.

ffmpeg-transcode-603b26c0-20b6-4e6f-a417-7530cdecb0d0_1.txt ffmpeg-transcode-bdce834e-a32d-4798-be63-6327ce948218_1.txt ffmpeg-transcode-ee400e11-c72f-410b-b6ad-f954ccea11a3_1.txt embyserver.txt

[Mikoyan 6]

Any updates?

[Luke 37066]

HI, as a test, if you turn off hardware transcoding in server transcoding settings, how does that compare?

Quote

In a similar vein, performing subtitle extraction on the fly (therefore bypassing the need to burn in) also does not have issues.

And also, why not just use this?

[Mikoyan 6]

Turning off hardware transcoding allows most files to be played, there seems to be some kind of playback error initially but the second attempt mostly succeeds and allows the videos to be played. Very interesting behavior.

56 minutes ago, Luke said:

And also, why not just use this?

On the fly extraction is very picky about which media files it will successfully work with in my library, this seems to be exacerbated due to the fact that some subtitle files are also non-English. Sometimes, files will work just fine with extraction on, other times I will see no subtitles at all. I find that having hardware transcoding for any non-supported device (generally the web UI or when I need to transcode down quality due to poor destination network quality) works 95% of the time provided the media has the correct font(s) embedded, and there is no delay between when the subtitle is extracted and the destination device receives the file and is able to display them. Usually this delay is not a big deal but on networks with high latency or poor connectivity the delay can become somewhat significant and result in lack of subtitles for the first ~30 seconds or more. Since I cannot choose to turn on/off extraction for specific file types/scenarios, generally allowing Emby to hardware transcode is more reliable IMO.

Also, for SSA/ASS subtitles with animations or "images" don't react very well to being extracted in some cases, and is just better to view with them overlaid properly on the video (as originally meant to be by the subtitle creator). I would very much turn on subtitle extraction on-fly for certain library folders only, but at the moment it is on or off for everything I believe.