ASS burn-in takes long time to begin on hw transcoding (vaapi) with adequate hardware

[ezzah 3]

I would like to preface to say that the server should be more than capable of handling the transcode load. I wanted to maintain extract on the fly, but it's very buggy on large shows (it's decent on anything <30 minutes long and takes about 30 seconds to extract). The reason I am using the web app to watch ASS subtitled shows (primarily anime) is because there is no current macOS emby app so I must resort to the web app. Furthermore, Kodi runs poorly on macOS in my experience with lots of sync issues and UI performance problems, etc.

 

Server specs are as follows:

 

CPU: Intel Xeon E3 -1275v6 (with 630 igpu)

RAM: 64GB ECC

HDD: Enterprise SSDs in RAID0 (2x480gb)

Network: 1Gbps 

 

Emby version: 4.3.1.0

 

The problem:

 

I like the extraction on the fly concept, but it is buggy and doesn't work well on say large file sizes (like movies). For larger movies, it will direct play fine but just no subtitles will appear. No problem I will turn it off to transcode and burn in the subtitles. However, when I do so the page will just go to the background image with a loading circle in the middle and go on like this and it will not load the video at all. When I check netdata there is no indication of much CPU usage at all, so I am not sure why the transcode process has begun or what has gone wrong. 

 

The reason that I think the burn-in should work fine is because plex was able to burn-in ASS subs on the web app on the same media on the same hardware. I assume there is some bug that is happening, because it's reproducible for me and other users on my server. I have attached my transcode logs with some stuff redacted; it appears the transcode is extremely slow but my hardware should be able burn in much faster? 

ffmpeg-transcode-try2.txt

Edited March 14, 2020 by ezzah

[pünktchen 1251]

I'm so glad that you've reported this. I've done the same already, but didn't got much attention.
It happens with all text based embedded subtitles with or without HW encoding. The longer the file duration and the more subtitles are embedded, the longer it takes to start transcoding.

14:54:57.673 [Parsed_subtitles_5 @ 0x15f2c80] Shaper: FriBidi 1.0.5 (SIMPLE)
14:54:58.601 [Parsed_subtitles_5 @ 0x15f2c80] Loading font file '/config/fonts/DroidSansFallback.ttf'
14:54:58.626 [Parsed_subtitles_5 @ 0x15f2c80] Using font provider fontconfig
15:01:37.445 Stream mapping:
15:01:37.445 Stream #0:0 (h264) -> format (graph 0)
15:01:37.445 hwmap (graph 0) -> Stream #0:0 (h264_vaapi)
15:01:37.445 Stream #0:1 -> #0:1 (flac (native) -> mp3 (libmp3lame))
15:01:37.445 Press [q] to stop, [?] for help
15:01:37.485 [Parsed_subtitles_5 @ 0x17f2b80] Shaper: FriBidi 1.0.5 (SIMPLE)
15:01:38.949 [Parsed_subtitles_5 @ 0x17f2b80] Loading font file '/config/fonts/DroidSansFallback.ttf'
15:01:38.963 [Parsed_subtitles_5 @ 0x17f2b80] Using font provider fontconfig
15:03:25.013 frame= 2 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s throttle=off speed=N/A
15:03:25.067 [segment @ 0x169f940] Opening '/transcode/transcoding-temp/55ec52c6ccba4e42c748cfa3e7514ce00.ts.tmp' for writing
15:03:25.067 Output #0, segment, to '/transcode/transcoding-temp/55ec52c6ccba4e42c748cfa3e7514ce0%d.ts':

Edited March 14, 2020 by pünktchen

[ezzah 3]

It seems to be highly repeatable. Basically, any text based (or in my case ASS or anime) subtitle media cannot be played at all on the web app. The extract on the fly doesn't work well on large file sizes so then there is no way to watch for example a 2hr ASS embedded movie; it will play but no subtitles will ever appear. I don't think it is realistic to get around this issue by extracting ass out of the files since the library is too large to apply this to everything. Of course, this could be solved for me if there was an official macOS emby app as well, but I don't think that will come soon.

Edited March 14, 2020 by ezzah

[ezzah 3]

I just tried to 'direct play' on the web app a smaller file with ASS subtitles. As usual it took about 1-2 minutes before it would begin playing, but the transcode speed is quite slow. From the dashboard it was about 10-20fps. It is definitely much slower than plex on the same media. Of course, as shown in OP, anything bigger like a movie with ASS subs will not play at all and no transcoding temp files are created (or takes a very very long time). I have attached new logs for the smaller file with ASS subs. If anybody would like access to the files to test, let me know. Also maybe running beta would be better? Not sure if it's worth trying.

 

Also in regards to extract on the fly, I can't find much logs regarding the extraction process. Should I enable debug logging?

ffmpeg-smaller.txt

Edited March 14, 2020 by ezzah

[ezzah 3]

Would anyone be willing to troubleshoot this issue with me?

[ezzah 3]

I am aware that Roku cannot play ASS. This is fine, which means emby should transcode or burn-in the subtitles. I have attached an ffmpeg log using hw transcoding that is barely above playback speed. On the web app and Roku, ASS is virtually unplayable. It won't even play without the subtitles; video simply will not show.

ffmpeg-ass.txt

Edited March 18, 2020 by ezzah

[softworkz 3326]

I apologize for the late response.

 

We are aware of this issue. The problem is that the ffmpeg filter for burning in subtitles needs to read and parse the video file independently, which means that the source video will be opened and read two times simultaneously. The time that it takes and that is causing the playback startup delay depends on many factors like file size, container type, whether the video is located on a local file system  or on a remote network location.

 

This is not a recent change - it has always been like that with Emby. In many cases, the delay is rather low but we know that there are quite a number of cases where the delay is not acceptable.

 

This can only be resolved by some low-level development at the side of ffmpeg. There are three different ways to do it: 'light', 'moderate' and 'insane'. We'll go the moderate way because it will also allow us to overlay subtitles using video hardware acceleration because overlaying 4k videos, is quite a challenge even for average CPUs.

 

I can not give you an ETA for this right now, but I can tell that it's a top priority on the transcoding backlog.

 

@@ezzah - The low transcoding speed your seeing will probably be fixed in the 4.4 release which is supposed to be published within the next few days.

[ezzah 3]

Thank you for helping out. It's good to hear that you are already aware of the issue! I am looking forward to 4.4 and will report back how that goes. 

 

Would it be worth it to try the beta out now? Namely 4.4.0.28-beta

Edited March 19, 2020 by ezzah

[softworkz 3326]

It will surely be worth to try the beta.

 

Normally, we're warning that you may run into problems when going back to the release version, but right now, we're close to the next release version anyway and when you switch to the latest beta it won't be much different than upgrading to the 4.4 release.

[ezzah 3]

What would the problem be from moving to beta branch for now and then 4.4 release? I run emby in docker with the linuxserver/emby image. I have all the emby configuration related things separated out so that I can change the docker image without impacting necessary files; although, if there are going to be db changes then I could see that being an issue.

[softworkz 3326]

What would the problem be from moving to beta branch for now and then 4.4 release? 

None.

 

 I have all the emby configuration related things separated out so that I can change the docker image without impacting necessary files; although, if there are going to be db changes then I could see that being an issue.

 

 

It could be a problem going back to 4.3, but it doesn't make a difference whether from the latest beta or the final 4.4.

[ezzah 3]

I just updated to 4.4 and there is a very slight improvement in the burn-in, but it will not play on the web app at all. It spins forever and if I check the attached log the ffmpeg burn in just stopped by itself. I'm not sure what the issue is.

 

Although extract on the fly appears to be much faster now, finishes within 5 seconds which is fantastic. Although larger files, like anime movies, still cannot rely on extract on the fly unfortunately.

ffmpeg-new.txt

Edited March 22, 2020 by ezzah