Emby 硬解排查要先确认是否真的发生转码,再看 /dev/dri、权限、CPU、日志和缓存目录。
\n
Emby 播放卡顿时,很多人第一反应是“硬解没开”。我现在会先停一下,把问题拆成几层:客户端是在直连播放,还是服务器在转码?转码是因为视频编码、音频、字幕、码率,还是因为客户端设置限制?容器能不能看到硬件设备?转码缓存是否可写?CPU 和日志是否真的显示压力在转码环节?
硬件加速只解决一部分问题。家里网络不稳、无线信号弱、客户端解码能力有限、字幕格式触发烧录、临时目录写不进去,都可能表现成卡顿。把所有问题都归到硬解,最后只会把 Compose 越改越复杂。
先确认是否转码
我会先在 Emby 的播放状态里看当前会话。如果显示 direct play 或 direct stream,说明服务器并没有做完整视频转码,此时挂不挂 /dev/dri 都不是主要矛盾。应该去查客户端、网络、文件读取速度或字幕设置。
只有确认进入 transcoding,才继续看硬件加速。这里还要分清转的是视频、音频还是字幕烧录。音频转码通常不会让 GPU 派上用场,字幕烧录也可能让 CPU 压力上来。日志里出现 ffmpeg 命令和转码参数时,再结合 CPU 占用判断更可靠。
/dev/dri 只是入口
Linux 主机上常见的 Intel 核显会通过 /dev/dri 暴露设备。容器里能看到设备节点,是硬解排查的第一步,不是最后一步。
services:
emby:
image: lscr.io/linuxserver/emby:latest
container_name: emby
restart: unless-stopped
environment:
- PUID=1000
- PGID=1000
- TZ=Asia/Shanghai
volumes:
- /srv/appdata/emby:/config
- /srv/media/authorized:/media/authorized:ro
- /srv/cache/emby-transcode:/transcode
devices:
- /dev/dri:/dev/dri配置写上以后,我会进容器确认:
docker exec emby ls -lah /dev/dri
docker exec emby id
docker compose logs --tail=160 emby如果能看到 renderD128 之类的节点,但日志仍然提示权限不足,就要回到宿主机看设备属组、容器运行用户和镜像文档要求。有些系统升级后设备权限会变化,原本可用的硬解会突然失效,这时盲目重建容器没有意义。
缓存和磁盘也要看
转码过程会写临时文件,/transcode 不可写或空间不足时,表现可能像播放失败或频繁中断。我会把转码缓存放到单独目录,并用 df -h、du -sh 定期看空间。缓存目录不进长期备份,清理策略也要和配置目录分开。
如果机器内存充足,可以考虑把转码缓存放到更快的磁盘或临时文件系统,但我不会一开始就这样做。先确认普通磁盘路径稳定可写,再优化性能。家庭服务的调优最好一步一步来,否则出问题时不知道是哪一次优化带来的副作用。
看 CPU 和日志,不看感觉
播放时我会同时打开三个观察点:Emby 会话状态、宿主机 CPU/GPU 负载、容器日志。CPU 长时间满载而日志显示视频转码,才说明硬解可能没有生效或设备能力不足;CPU 很低但客户端卡顿,问题就可能在网络、客户端缓冲或文件读取;日志不断报权限或路径错误,则先修基础配置。
常用命令很简单:
docker stats emby
docker compose logs -f emby
ls -ln /srv/cache/emby-transcode
df -h /srv/cache/emby-transcode我还会准备几段自己熟悉的测试视频:一个客户端肯定能直连的,一个会触发转码的,一个带常用字幕的。每次调整硬件加速、缓存目录或客户端设置后,只用这几段对照,避免拿不同内容反复测试导致结论混乱。
别急着追求全设备通吃
家里设备差异很大,同一份内容在电视上直连,在手机上可能需要降低码率,在浏览器里又可能受格式限制。我的目标不是让服务器对所有场景都强行转码,而是尽量让常用客户端直连,只有必要时才让 Emby 接手转码。
硬解配置稳定后,我会记录主机型号、设备节点、容器用户、Emby 版本、测试内容和观察结果。下次升级驱动、换机器或改 Compose 时,能根据这份记录判断是能力变化、权限变化,还是应用配置变化。硬件加速不是玄学,把“是否转码、设备是否可见、权限是否正确、缓存是否可写、日志是否匹配”这几件事看清楚,排查就不会绕太远。
此处评论已关闭