Hard comparison: Why is Emby's transcoding engine so far behind Jellyfin? (And why I'm switching back

[adminyy 0]

 

Hello Emby Team and Community,

I am writing this post out of sheer frustration and disappointment. I was originally a Jellyfin user who decided to give Emby a try, hoping that a paid, commercial product would offer better performance and a more polished experience.

However, after detailed testing and comparison over the last few weeks, my conclusion is shocking: Jellyfin completely outperforms Emby in almost every technical aspect.

Here is a breakdown of why I find the current state of Emby incomprehensible:

1. Ancient FFmpeg Version It is 2026. Why is Emby still clinging to ffmpeg version 5.1-emby_2023_06_25_p4? I understand the argument for "stability" and "compatibility," but this doesn't feel like compatibility anymore—it feels like stagnation. You are sacrificing performance for the sake of legacy support that holds back modern hardware. Jellyfin is already on FFmpeg 7.x, leveraging the latest driver optimizations and AV1 support, while Emby is stuck in the past.

2. Abysmal Transcoding Performance & Hardware Utilization I tested the exact same video file on the exact same hardware (Docker container). The difference is night and day:

• Jellyfin: consistently hits ~80 fps.

• Emby: struggles to reach ~30 fps.

What’s worse is the resource management. Emby fails to utilize the GPU effectively. My GPU sits idle while Emby hammers the CPU. Jellyfin, on the other hand, fully utilizes the GPU for a smooth experience. Why is a free, open-source project optimizing hardware usage better than paid software?

3. The Subtitle Burning Nightmare This is the deal-breaker. Emby seems to force software (CPU) tone-mapping and subtitle burning for almost all graphical subtitles (PGS/image-based). The result? Massive CPU spikes and playback stuttering. Other players handle this by extracting subtitles or handling them on the client side much better. In Emby, it seems to be "burn-in or nothing," and the burn-in process is inefficient and single-threaded. It makes watching foreign content with subtitles a painful experience.

4. The "Brain-Dead" Audio Transcoding Logic This is just as bad as the video issues. Emby seems obsessed with converting almost all audio tracks into mediocre AAC. I tested this on the Web client with both servers set to "Auto" quality:

• Jellyfin: Smartly detects my browser's capabilities. If the browser supports the format (e.g., Opus, FLAC, or high-bitrate codecs), it Direct Streams the audio. No quality loss, no CPU usage.

• Emby: Blindly transcodes everything to AAC. Why? The source audio is pristine, my browser can play it, yet Emby insists on degrading the audio quality and wasting CPU cycles to convert it. It feels like the client detection logic hasn't been updated in years.

5. Lack of Control & Slow Library Scans Why is the library scan logic so slow? Why can't we set the concurrency for scanning tasks? Jellyfin feels snappy; Emby feels heavy and sluggish. It seems you are hiding advanced parameters from users, ostensibly to "simplify" things, but for power users, it’s just restricting. We have powerful servers; let us decide how many threads to use!

Conclusion I really wanted to love Emby. I like the UI and the metadata scraping. But the core function of a media server—playing media—is inferior to the free alternative.

Please stop using "compatibility" as an excuse for an outdated backend. It’s not a feature; it’s a bug. If Emby continues down this path of slow updates and inefficient resource usage, I fear the software is slowly losing its relevance.

For now, I have no choice but to migrate back to Jellyfin. I sincerely hope this feedback serves as a wake-up call.

Edited February 4 by adminyy

[Neminem 1518]

Nice AI generated write up.

Are you a bot, first time poster

[pünktchen 1409]

@softworkzCan you please increase the ffmpeg version number to lets say 15, so people think they have always the latest and greatest?!

[Luke 42077]

 

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

 

[Q-Droid 989]

1 hour ago, pünktchen said:

@softworkzCan you please increase the ffmpeg version number to lets say 15, so people think they have always the latest and greatest?!

The legitimacy of the OP and unknown (likely invalid) comparisons aside, this sort of supports one of the points made in the post.

 

Edited February 4 by Q-Droid

[ebr 16169]

2 hours ago, Q-Droid said:

this sort of supports one of the points made in the post.

It doesn't because he's pointing out that the ffmpeg version doesn't tell the complete story.  We have made modifications and pulled in other updates in our own copy so we aren't really on the version that is shown.

Having said that, we are in the process of a larger update there.

[Q-Droid 989]

17 minutes ago, ebr said:

It doesn't because he's pointing out that the ffmpeg version doesn't tell the complete story.  We have made modifications and pulled in other updates in our own copy so we aren't really on the version that is shown.

Having said that, we are in the process of a larger update there.

That may be the case and only you guys would know how different the reported ffmpeg 5.1 is from newer 5.1.x or the current 7.1 release. But to me it brings up another thing. That Emby transcoding and ffmpeg IS softworkz. And as good as he is it seems that putting all of your eggs in one basket is risky. Between the long release cycles, his availability and the locked-in nature of a forked ffmpeg there's exposure you might not have if you were using the mainline. I get that you have your reasons for this approach.

In my opinion the OP is wrong on most counts though there have been more than a few cases of side-by-side examples where some aspect of HW accel doesn't work in Emby while it does with Jellyfin and standalone ffmpeg.

 

[adminyy 0]

22 hours ago, Neminem said:

不错的AI生成文章。

你是机器人吗？第一次发帖

My English is not good, so I let AI help me express what I mean

[ebr 16169]

16 hours ago, Q-Droid said:

That Emby transcoding and ffmpeg IS softworkz

That isn't true but, with a small team, we have many eggs and few baskets .

[ebr 16169]

3 hours ago, adminyy said:

My English is not good, so I let AI help me express what I mean

Well, much of what you posted is inaccurate so we would like to look at some examples, please.  Thanks.

[darkassassin07 652]

On 2/4/2026 at 3:43 AM, adminyy said:

My GPU sits idle while Emby hammers the CPU. 

This immediately tells me HW transcoding is not being used, and since you're on docker, there is a little extra work to get that functional.

 

I recently had to modify my docker configuration to reenable HW transcoding, after Docker/Nvidia changed how that's setup. I'll link the post when I dig it out.

 

/edit: https://emby.media/community/index.php?/topic/144277-hardware-detection-fails-within-docker-container-on-previously-working-system/#findComment-1488367

Edited February 5 by darkassassin07

[pünktchen 1409]

34 minutes ago, darkassassin07 said:

This immediately tells me HW transcoding is not being used, and since you're on docker, there is a little extra work to get that functional.

It's more likely the OP did not subscribe to Emby Premiere for his tests.