Emby transcoding capped at 12fps?

[SuperSaiyanCaleb 0]

I'm at my wit's end trying to figure this out...  I decided to give up on ARM systems and bought a Beelink S2 to use as an Emby server.  The system has an Intel N4100 CPU which supports hardware decoding of the latest codecs in 4K.  I installed Ubuntu 18.04 (64-bit) on the system, and out of the box it plays back a 4K HEVC test file flawlessly in MPV with around 5-10% CPU usage on all four cores.  As long as X is running, I can also use hardware decoding in ffmpeg (which apparently maxed out at 48fps for this file, although CPU usage remained low).

 

I installed Emby, and did a quick baseline test without hardware transcoding enabled.  Went to play that same file via the web interface, and, since transcoding was required, CPU usage predictably went to 100% on all four cores and the video only played back at about half speed, halting every three seconds or so for about three seconds.  Which made sense, since this is a 24fps file and it was decoding at around 12fps.

 

So then I set Emby to use VAAPI for decoding and encoding.  Restarted emby and started playing back the same file via the web interface.  Transcoding kicked in again, but this time, three out of four CPU cores remained mostly idle, and only one core rose to around 70% usage.  But the video still only transcodes at 12fps...  Playback halts every three seconds or so for about three seconds, just as before.

 

So Emby seems to be using hardware acceleration to decrease CPU usage...  but still won't transcode the file fast enough for realtime playback.  What could be causing this, and what can I do to fix it?

 

A few things I tried:

• I disabled hardware encoding, thinking maybe there was some bottleneck in attempting to use the GPU for both decoding and encoding simultaneously.  This resulted in higher CPU usage, but no change in transcoding speed.
• I tried choosing lower resolutions and bitrates within the web interface, which also had no effect on the problem.  The systems are connected via gigabit ethernet, so bitrate should not be a problem in any case.

I will PayPal money for a beer to anyone who can help me successfully resolve this.

Edited September 9, 2018 by SuperSaiyanCaleb

[Luke 42078]

Hi, can you attach the ffmpeg log? Thanks.

[SuperSaiyanCaleb 0]

Hmm, well I made an interesting discovery...  I wanted to post those logs you asked for, so I remuxed the video I'd been trying to play so that no titles/metadata would show in the logs.  The video has several audio and subtitle tracks, and without thinking about it, I stripped out all the extraneous audio and subtitle streams in the video when I remuxed it so that there would just be one video and one audio track.  The stripped down file plays fine!  I remuxed the file again with all of the original streams in tact to check and see if the original problem had been some sort of problem with the way the original file was muxed, but that reintroduced the original problem.  So evidently one of the other streams in the file is the culprit.  Maybe a subtitle stream?  Which seems odd since no subtitles were playing in the part of the video I played back...

 

I've attached two logs:  One for the stripped down file that played fine, and one for the file with all original streams that played poorly.  Maybe something in the logs will give away what the problem is.  Otherwise, tomorrow I'll experiment some more and try to find out exactly which stream(s) are causing the problem.  That actually partially solves my problem though, since I can remux this file, and hopefully this will not be a problem for a majority of files I'll be playing back.

stripped down (success).txt

all streams (plays slow).txt

[Luke 42078]

The slow one is burning in subtitles and it looks like that might just be too much for your machine to handle. You can also try turning the subtitles off and obtaining external srt subtitles.

[SuperSaiyanCaleb 0]

Sure enough, disabling subtitles on the first file resolved the issue straight away!  That surprises me, since I didn't realize subtitles incurred an overhead over non-subbed transcoding even when none are being actively displayed.  I wonder if, someday, a new feature might be that graphical subs could be streamed to the client and overlaid client-side without needing to burn them into the video stream?    But that does resolve this problem!  Much more easily than I thought.  So thank you!  Guess now I owe you a beer, so feel free to PM me a PayPal-able email address if you'd like. 

[mastrmind11 722]

external subs.  no one does burned in subs efficiently.  glad you got it sorted.

[Luke 42078]

Yes external subs are the best option. Apps that support the graphic subtitle format natively can already handle them without transcoding.

[SuperSaiyanCaleb 0]

Hmm, so I encountered another set of files I'm having issues with.  These are also 4K HEVC and will decode at around 40 fps with the system's ffmpeg.  But in Emby they transcode at about 18-20 fps--with no subtitles.  CPU usage climbs to 25% on one core at the most, with the other three cores mostly idle.  Anything in the log jump out as being the culprit?

ffmpeg-transcode-85217fec-a68a-44f5-bc82-527f1ad5e7ee_1.txt

[Luke 42078]

Well we're transcoding 4k to 4k which will be very costly as well. We should probably transcode 4k to 1080p and then it should be fine.

[SuperSaiyanCaleb 0]

That's strange...  I have playback set to 1080p@10Mbps and it is still transcoding to 4K.  It keeps transcoding at 4K until I lower it down to 1080p@4Mbps, at which point it jumps down to transcoding to 720p...

 

(Once it shifts down to 720p it plays smoothly, and I presume it would also do so at 1080p, but it doesn't seem to want to transcode to that resolution even when I manually pick that setting during playback.)

Edited September 25, 2018 by SuperSaiyanCaleb

[Luke 42078]

Thanks, we'll take a look at that.