与 Jellyfin 的功能对比

这是全书最容易被写成站队的一篇。为了避免废话，本文的写法是先把对比维度列清楚，再分别说明两者各自的真实表现。所有结论基于两个项目当前稳定版的实际使用，不预设谁应该赢。姊妹篇《自建影音中心 Jellyfin 实战》对 Jellyfin 侧有完整展开，本文只做交叉对比，不重复细节。

两者的历史关系

Jellyfin 在 2018 年从 Emby 分叉，起因是 Emby 宣布服务端闭源并推出付费会员后，社区围绕能否继续维护一个开源版本产生了分歧，最终一部分开发者带走了最后的开源代码，另起炉灶。这段历史决定了两件事实：第一，两者的媒体库模型、目录结构、刮削逻辑非常相似，从 Emby 迁到 Jellyfin 或反向迁移，媒体文件本身几乎不用动；第二，七年的独立发展已经让两者在客户端生态、功能边界与商业模式上拉开明显差距，今天已经不能简单用谁是谁的替代品来概括。

顺便澄清一个常见误解：分叉不等于落后。Jellyfin 的代码基础虽然来自当年的 Emby，但七年里刮削引擎、播放管线、配置体系都已重写过大半，和 Emby 各自演进。把 Jellyfin 当成旧版 Emby 的印象是过时的，反过来把 Emby 当成收费版 Jellyfin 同样不准。两者共享的是设计哲学的起点，不是当下的产品。

简单概括商业模式上的区别：Emby 服务端闭源、可免费运行，高级功能与官方体验打包进 Premiere 订阅；Jellyfin 服务端完全免费开源，所有功能不设付费墙。这笔账在 em-0105 会详细算，这里先看功能。

功能逐项对比

下面这张表把家庭用户最关心的能力逐项列出，对照着看比读长段描述更直观。

表中同一行的支持三类硬件加速是事实陈述，不代表实际转码性能。影响转码性能的核心因素是你手上的硬件本身，两个项目的调用路径非常接近，同一台机器上跑出来的转码帧率差距通常在百分之十以内，属于可接受范围。也就是说，比较转码时先比硬件，再比方案，顺序不能颠倒。

关于 TV 客户端，需要多说几句。Emby 的 Android TV、Fire TV 客户端是官方主导开发，遥控器焦点逻辑、播放进度恢复、字幕下载这些细节经过多个版本迭代，稳定性口碑较好。Jellyfin 的 TV 端由社区维护，近两年在 Android TV 上的完成度快速逼近，偶尔还会遇到个别片型的兼容问题。如果你家里的主播放设备是电视盒子，这一条值得实际装来试试，而不是只看网上结论。

顺带一提，Apple TV 平台的情况比较特殊。Emby 官方有 tvOS 客户端，功能与移动端基本对齐；Jellyfin 目前没有一等一的官方 tvOS 客户端，常见做法是用 Infuse 这类支持自建服务器的第三方播放器对接，体验各有取舍。若 Apple TV 是你家唯一的播放终端，这条差别可能直接决定选型。

硬件转码是另一处容易产生误解的地方。两个项目都支持 Intel QuickSync、NVIDIA NVENC、AMD AMF 三类硬件加速，差别只在于 Emby 把它放在 Premiere 会员里，Jellyfin 完全免费。也就是说，硬件上能不能跑得动，两者判断方法完全一样：看 CPU 核显或独立显卡是否在支持列表里，这部分在 em-0103 会给出选型清单。反过来，如果你已经为 Emby 付过 Premiere，转码体验并不会因此比 Jellyfin 更好，付费改变的是功能可用性，而非性能本身。

客户端生态差异

服务端之外，客户端生态是两个项目最大分野。Emby 走的是官方客户端路线：移动端、TV 端、网页端全部由官方团队维护，版本节奏与行为一致性可控，代价是部分客户端功能与会员绑定。Jellyfin 走的是开放生态路线：官方维护核心客户端，同时第三方客户端遍地开花，网页、桌面、命令行都有多个实现可选，代价是质量参差，挑选成本完全落在用户头上。

一个具体的影响场景是外网观看。Emby 官方客户端与自建服务端配合时，远程播放的连接逻辑由 Emby 统一处理，断线重连、码率回落的处理相对一致；Jellyfin 侧则取决于你选的客户端实现，有的第三方客户端在弱网下的表现明显不如官方 App。如果你经常在通勤路上看家庭服务器里的片，这一点值得纳入考量。

另一个隐性差别是更新节奏。Emby 客户端版本由官方统一把控，跨平台功能同步较快；Jellyfin 各客户端的贡献者不同，新功能落地先后不一，比如同一播放统计或字幕样式，可能在网页端已经可用、TV 端还要等下一版。介意这种不一致的人，往往更适应 Emby 的集中式发布。

元数据与媒体库

两者的媒体库模型同源，目录命名规范几乎一致：电影一个目录或一个文件一部，剧集按剧集名、季、集号分目录，音乐按艺人、专辑分层。从 Plex 迁移过来的目录大多可以直接被两边识别，差别在刮削环节。

Emby 的刮削设置项集中、默认规则保守，冷门内容需要手动指定匹配；Jellyfin 的刮削插件可选数据源更多，组合灵活，但偶尔出现同一部影片在不同库被匹配成不同条目的情况。对于常规热门内容，两者的表现没有实质差距；内容越冷门，越考验你对刮削规则的理解，这部分在 em-0203 会讲。

还有一处差异在媒体库的高级整理上。Emby 的合集、分类与海报编辑功能集中在服务端，并且支持家长控制的分级策略与观看时长限制；Jellyfin 同样提供家长控制，但配置项分散，初次上手需要对每个库逐一设。对家里有小孩、需要按内容分级过滤的用户，Emby 这套开箱体验略省心。

长期成本差异

选型时容易只看眼前的功能清单，忽略三五年后的成本变化。Emby 的 Premiere 按服务器设备数计费，家里如果陆续添置第二台 NAS、一台小主机做备用服务器，许可费用会随设备数叠加；Jellyfin 在这块没有任何支出，但时间成本可能转移到排查问题与适配客户端上。

另一个隐性变量是插件与扩展。Jellyfin 社区插件多、迭代快，遇到新需求往往能找到现成实现，也可能遇到插件长期无人维护、随服务端升级失效的情况；Emby 官方插件目录总量少，但每个都跟服务端版本对齐，出问题的概率低、解决的指望也只有官方。这两种模式的取舍，本质上和你愿意花时间还是花钱是一致的。

该怎么选

给出一个不求精确但实用的判断流程：

补充一句：以上判断假设硬件条件相同。如果你手上的 CPU 核显恰好不在某个项目的支持列表里，结论可能完全反转，所以先翻 em-0103 的硬件清单，再回到这张表。

无论选哪个，硬件层面的准备工作是同一套。下一章 em-0201 的 Docker 部署流程对 Jellyfin 同样有参考价值，容器参数换个镜像名即可。

延伸阅读

• em-0101 讲了 Emby 的定位与授权结构，是本文的前提
• 硬件是否支持转码看 em-0103 的选型清单，Premiere 的费用账看 em-0105
• 打算从 Plex 迁移的读者，em-0104 验证过目录与元数据的迁移路径
• 想深入 Jellyfin 侧的读者，《自组 NAS 完全指南》里有配套的硬件搭建内容，而姊妹篇《自建影音中心 Jellyfin 实战》覆盖全部 Jellyfin 细节；网络前置条件可参考《软路由入门指南》