Lite、Core 与 Full 里的那组数据来自仓库内的确定性 fixture，回答的是「哪个变体更省」。这一页记录真实码率、真实上游和连续负载下的观测结果。两组数据的方法和可复现性完全不同，不要混在一起看。
下面所有数字都来自修复上游 TLS、回退参数和连接池问题后的 v1.1.0 预发布版本。该候选版本与最终发布的 v1.1.0 产物之间仍可能存在构建差异。
一小时连续双路播放
同时消费两个加密 DASH 直播源一小时：一个 4K 频道（约 15 Mbps）走同机链路，一个 1080p 频道（约 5 Mbps）经过额外网络跳点。消费端是 ffmpeg 的完整拉流与解复用，不是只请求一次清单。
| 指标 | 数值 |
|---|---|
| 4K 频道 | 3600 秒实际时间内消费 3551 秒媒体时间线 |
| 1080p 频道 | 3519 秒 |
| 缓冲与欠载事件 | 0 |
| CPU | 均值 3.07%，峰值 13.9%（123 个采样点） |
| 容器内存 | 均值 106 MiB，谷 27，峰 241（上限 1 GiB） |
| 上游入流量 | 约 59 分钟内 8.76 GB，记录均值 19.7 Mbps |
| 对外出流量 | 同一窗口内 8.63 GB，记录均值 19.4 Mbps |
| 服务端告警 | 0 |
CPU 百分比以单核为 100%。这次记录没有单独保存首包时刻和稳态 PTS 斜率，因此媒体时长与实际时间的差额不能拆分为起播耗时、播放列表沿偏移或运行中落后，也不能单凭这一项证明稳态始终跟上实时。
几条读得出来的结论：
- 入出流量几乎相等（19.7 对 19.4）。这与始终拉取主视频时钟、其余轨道按请求拉取的行为一致，但本次没有关闭 rendition idle 的对照组，不能据此量化节省了多少流量。
- 内存是锯齿而不是爬坡。谷 27、峰 241、均 106 MiB，一小时内没有单调上升，符合分片缓冲加 GC 的正常形态；峰值约占 1 GiB 上限的 24%，尚余约 783 MiB。
- 服务端计数器全零：慢分片、重锚、失速、会话重启、握手失败都没有出现。
- 原生路径日志记录到 12 次轨道暂停和 5 次回温，直接证明
rendition_idle_sec在这次运行中触发过，但本次没有量化其节省的字节数。
ffmpeg 输入链路中，4K 那一路记录到 2 条同一时间戳的 Packet corrupt；第二条链路记录到 13 条，其中 7 条是 End of file。-c copy 不执行解码，这些日志只能说明输入或解复用链路观察到了异常，不能仅凭数量归因。两路消费进程都没有中断。
观众扇出
同一个频道同时接入 1、5、10、20 个消费端，测上游拉流是否随观众数增长。
| 并发观众 | 上游入流量 | 对外出流量 | CPU | 容器内存 |
|---|---|---|---|---|
| 1 | 2.01 Mbps | 1.98 Mbps | 0.79% | 67 到 119 MiB |
| 5 | 4.37 Mbps | 21.2 Mbps | 1.74% | 124 到 156 MiB |
| 10 | 5.75 Mbps | 14.9 Mbps | 1.96% | 150 到 214 MiB |
| 20 | 3.84 Mbps | 72.6 Mbps | 2.27% | 143 到 165 MiB |
本轮没有观察到上游拉流随观众数成比例增长。 入流量在 1 到 20 个观众之间始终落在 2 到 6 Mbps 这一档，20 个观众时（3.84）低于 10 个观众时（5.75），而同期对外出流量到了 72.6 Mbps。
服务端计数器给出了更直接的证据：整个过程中 kiln_sessions 始终为 1，上游分片拉取速率在 10 个观众时为每 10 秒 4.3 个，20 个观众时为 3.9 个，而在没有观众、频道尚未空闲超时的间隙里是每 10 秒 3 个。它们处于同一量级，说明这些观众共享同一份上游会话。每档只有一个 60 秒窗口，因此这组数据不建立观众数与上游字节数的统计独立关系。
这次样本里，CPU 从 1 个观众时的 0.79% 增至 20 个观众时的 2.27%，慢于观众数增长；内存没有呈现单调关系。要把这种关系当作容量结论，需要延长窗口并重复多轮。
这些消费端都选了 master 里的第一个渲染层（576p50，约 2 Mbps 含音轨），所以这组数字证明的是同一渲染层的扇出。观众选择非主渲染层时，上游会保留一份主视频轨作为时钟，并为每个被请求的非主轨各拉一份。
流量测算
选择主视频轨时，可按其名义码率估算单人观看的上游消耗量级；选择非主轨时还会保留主视频时钟：
| 渲染层 | 每小时 | 每天看 2 小时的月消耗 |
|---|---|---|
| 约 2 Mbps（576p 加音轨） | 0.9 GB | 约 54 GB |
| 约 5 Mbps（1080p 加音轨） | 2.3 GB | 约 135 GB |
| 约 15 Mbps（4K 加音轨） | 6.8 GB | 约 405 GB |
双路测试的流量计数窗口约为 59 分钟，并非完整一小时，不能把 8.76 GB 直接和 9.0 GB 的小时估算比较。按记录均值 19.7 Mbps 折算约为 8.9 GB/小时；由于没有保留精确窗口秒数与原始字节数，这里不进一步归因差值。表格只适合作为流量配额的初步估算，部署时应以自己的长窗口实测并预留余量。同一频道、同一渲染层的多个观众共享一份上游会话。
直播延迟
这次采样测的是播放列表沿相对上游时间戳的滞后，不是播放器画面的端到端延迟。端到端结果还会受输出引擎、播放列表窗口和播放器缓冲影响；原生引擎与 ffmpeg 兼容路径的输出结构不同，不能共用一组 TARGETDURATION 或 LL-HLS part 参数来推导。
测试环境与方法
测量运行在限制 1 GiB 内存的 arm64 容器中，被测构建为 v1.1.0 预发布版本。
源站为两个加密 DASH 直播流，经 HTTP 转发代理访问，上游分片时长 8 秒。消费端统一使用 ffmpeg 的 -c copy -f null -，完整拉流并解复用但不转码，测的是真实分片下载与封装链路。4K 流走同机链路并作为主判据；1080p 流经过额外网络跳点，只作参考，因为该链路会引入无关抖动。
CPU 与内存取自容器的 cgroup v2 计数器（cpu.stat 的 usage_usec 与 memory.current），流量取自容器 eth0 的 /proc/net/dev 精确字节计数。只保留三位有效数字的汇总网络计数不足以在 GB 量级做短窗口差分。
扇出测量在每档开始后先等 75 秒，让消费端追帧的突发下载过去、进入稳态，再开 60 秒的计数窗口，并在窗口两端确认消费端仍然存活。缓冲判据同时取两侧：消费端 ffmpeg 日志里的欠载与失速，以及 Kiln 服务端的慢分片、重锚、失速、会话重启和握手失败计数。
在自己的部署上复现
上面的链路无法直接复现。仓库里的 scripts/live-performance.sh 可以对自己的频道做相近的单频道短测，覆盖冷启动、首个清单响应时间、吞吐实时比、峰值 RSS 与峰值 CPU；它直接运行宿主机进程并通过 ps 采样，不会复现本文的长稳、扇出或容器 cgroup 测量：
KILN_PERF_CONFIG=/path/to/your/kiln.toml \
KILN_PERF_CHANNELS=my-channel \
KILN_PERF_CAPTURE_SECONDS=60 \
sh scripts/live-performance.sh长稳与扇出没有现成脚本，方法本身不复杂：用 ffmpeg 以 -c copy -f null - 消费自己的频道，同时按固定间隔采样容器的 cgroup 计数器。要点是先等稳态再开计数窗口，并在窗口两端确认消费端还活着，否则测到的是追帧突发而不是稳态。