上个月把客厅那台老盒子换成一台小主机，我以为 4K 就通了。结果一部 HDR 片放上去，画面两三秒一顿，声音却完全正常。查了三个晚上才想明白：卡的不是网线，也不是硬盘，是我从没算过的一笔账——这台机器每秒到底能解出多少帧。下面所有数字都是刚在这台 Ryzen 5 3550H（4 核 8 线程，Vega 8 核显）的笔记本上跑出来的，你可以照着自己复现一遍。
先看清楚片源到底重在哪
很多人判断一个片子"重不重"只看分辨率，这是个坑。用 ffprobe 一行就能把关键参数打出来：
ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,width,height,pix_fmt,color_transfer,color_primaries,bit_rate,avg_frame_rate -of default=nw=1 片名.mkv会看到 codec_name=hevc、pix_fmt=yuv420p10le、color_transfer=smpte2084、color_primaries=bt2020。后面这两项才是要命的地方：smpte2084 就是 PQ，也就是常说的 HDR10。同样是 4K，8bit SDR 和 10bit HDR 在解码端完全不是一个成本，在输出端更是差了一个数量级。
我做了三段对照样片（4K HDR10、4K SDR 8bit、1080p SDR 8bit，都是 30 帧、10 秒、同一段画面），码率分别是 41.0 Mbps、33.6 Mbps、8.2 Mbps。下面所有测试都基于这三段。
解码：软解 65 帧，硬解只有 46 帧
同一段 4K HDR10，只做解码、不做任何输出，用 -benchmark 记 CPU 时间和实时倍率：
| 方式 | 300 帧耗时 | 折算帧率 | CPU 时间 | 峰值内存 |
| --- | --- | --- | --- | --- |
| 软解 默认线程 | 5.35 s | 57 fps | 21.3 s | 527 MB |
| 软解 -threads 8 | 4.64 s | 65 fps | 20.6 s | 487 MB |
| 软解 -threads 2 | 9.91 s | 30 fps | 17.6 s | 240 MB |
| 硬解 d3d11va | 6.56 s | 46 fps | 1.9 s | 1278 MB |
| 4K SDR 8bit 软解 | 3.09 s | 97 fps | 14.5 s | 343 MB |
| 1080p SDR 软解 | 0.73 s | 411 fps | 3.6 s | 104 MB |
几个反直觉的地方，我一开始也不信。
第一，硬解比软解慢。46 帧对 65 帧，硬解输了。原因是 -hwaccel d3d11va 默认把解码出来的帧再下载回系统内存，这一趟 GPU→CPU 的回读成了瓶颈，而核显本身的解码单元在低压移动平台上吞吐也有限。所以"开硬解就更流畅"这句话不成立——真正决定卡不卡的，是解码之后那一整条渲染链路，不是解码器本身。
第二，硬解省的是 CPU，而且省得非常夸张：1.9 秒对 20.6 秒，十倍出头。如果你那台机器上还跑着 Jellyfin、下载、同步、相册识别，硬解的意义在这里——它把 CPU 让出来了，而不是让画面更顺。
第三，软解只要给 2 个线程就刚好 30 帧，也就是勉强踩在实时线上，一点余量都没有。这也是为什么很多老机器"能放但一拖动进度条就卡"：它本来就只有 1.0x 的能力，任何抖动都变成卡顿。
第四，10bit 解码比 8bit 贵了将近一倍（57 对 97 帧）。所以 4K HDR 的片子放到只能解的机器上，往往比同一部 4K SDR 还难放。
最狠的一刀是色调映射：只剩 6 帧
如果播放端或者屏幕只认 SDR，服务器就得把 HDR 转成 SDR，这一步叫 tonemap。我用的命令是 zscale 那一套：
-vf "zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=hable,zscale=t=bt709:m=bt709:r=tv,format=yuv420p"10 秒的片子跑了 50.2 秒，折算 6 帧，CPU 时间 251 秒——相当于 8 个线程里常年有 5 个满转。原因不复杂：要把 PQ 曲线还原成线性光，得用浮点格式算，然后做色调映射，再转回 BT.709。中间那个 gbrpf32le（32 位浮点）就是内存和算力的黑洞。
这条数据解释了一个特别常见的现象：同一部片子，在支持 HDR 的电视上直通播放丝滑，投到老投影或者笔记本上就卡成幻灯片。不是网速问题，是服务器在拼命做浮点运算。
转码实测：x265 和 HDR 转 SDR 都别碰
这是 Jellyfin、Emby 用户最该看的一张表。源全部是 4K，目标 1080p，10 秒 300 帧：
| 目标编码 | 实时倍率 | 300 帧耗时 | 说明 |
| --- | --- | --- | --- |
| x264 veryfast CRF23 | 1.25x | 8.14 s | 勉强够用，一集 45 分钟要 36 分钟 |
| x264 ultrafast CRF23 | 1.60x | 6.38 s | 快一点，但码率会明显上去 |
| x265 veryfast CRF24 | 0.476x | 21.05 s | 已经慢于实时，越转越卡 |
| 10bit 直通 + x264 | 0.742x | 14.37 s | 不降位深，只是缩放 |
| HDR→SDR tonemap + x264 | 0.12x | 24.58 s（3 秒片） | 一集 45 分钟要 6 小时 |
| AMD 硬编 h264_amf | 0.75x | 3.95 s（3 秒片） | 核显编码，CPU 仍占 2.2 核 |
那张表里最该记住的是 0.12x 和 0.476x 这两个数。前者的意思是：一部 45 分钟的 HDR 剧集，开一次 tonemap 转码要在服务器上烧六个小时；后者意味着只要你选了 HEVC 作为转码目标，转码速度就永远追不上播放速度，播放器会一直在缓冲。
还有一个坑：我想试"核显解码 + 核显编码"的 zero-copy 路径，-hwaccel d3d11va 配 hwupload 加 h264_amf，ffmpeg 直接抛 Error initializing filters。这块核显的 AMF 只吃固定的像素格式，中间那道 scale 必须留在系统内存里做，结果就是所谓硬编实际是"软缩放 + 硬编码"，CPU 还是占了 2.2 核，速度只有 0.75x。想靠核显救老机器的人，最好先在本机跑一遍再决定。
一条命令，判断你的机器带不带得动
不用装任何播放器，直接让 ffmpeg 空跑一遍，看它输出多少帧：
ffmpeg -i 片名.mkv -f null -末尾的 fps= 就是这台机器的解码上限。经验值是：实测帧率至少要到片源帧率的 1.5 倍，才算安全。24 帧的电影要跑到 36 帧以上，30 帧的剧要 45 帧以上。只有 1.0x 的机器，拖动进度条、弹字幕、系统后台更新，任何一个都会把它压垮。
带宽也顺手算一下，很多人在这里翻车：码率除以 8 才是 MB/s。41 Mbps 的 4K HDR 需要稳定 5.1 MB/s，一部 60 Mbps 的高码率 4K 要 7.5 MB/s。百兆网理论 12.5 MB/s，SMB 实际跑到 10 MB/s 就算不错了——也就是说，百兆网放一部高码率 4K，余量只剩两成，客厅里再有人刷视频，就开始转圈。千兆网才谈得上从容。
我最后是这么配的
- 客户端优先直通，能在播放端解的绝对不让服务器转。我把 Jellyfin 里所有"自动转码"相关的开关都调成了"仅在不支持时"。
- HDR 屏幕上的片子不做 tonemap。宁可让播放端自己处理，也别让服务器去算那 6 帧。
- 老盒子只看 1080p 版本。片库里同一部片放两个版本，让客户端按能力挑，比让服务器实时降清晰度便宜太多。
- 确实要转的，只用 x264 veryfast，不碰 x265。多花的那点带宽，比多等半小时划算。
- 字幕尽量外挂，别烧录。烧字幕等于整片重编码，成本直接翻倍。
折腾完这一圈，我最大的感受是：4K 这件事的瓶颈几乎从来不在"网速"和"硬盘"，而在有没有人认真算过一次每秒能解多少帧、转一帧要多少 CPU。买设备之前跑一条 -f null，比看十篇参数评测有用。
你们家里那台现在是自己解，还是靠服务器硬转？如果转过 HDR，一集大概要多久？