容量规划先测一条流的实际码率和处理开销，再估算多路规模。分辨率相同的两条视频，码率、帧率、GOP 和内容复杂度也可能不同，不能用“1080P”直接推算支持多少路。

存储计算

平均码率为 b Mbps、连续录像一天，原始估算为：

一天字节数 = b × 1,000,000 ÷ 8 × 86,400
一天GB = b × 10.8

例如 8 Mbps 一天约 86.4 GB，七天约 604.8 GB。这里使用十进制 GB；还未计入音频、封装、索引、冗余和预留空间。VBR 来源应使用具有代表性的测量区间，不能只看某一秒。

PowerShell 可以自己改参数计算：

Terminal window
$channels = 4
$averageMbps = 8
$days = 7
$estimatedGB = $channels * $averageMbps * 10.8 * $days
"仅按平均码率估算：$estimatedGB GB"

网络与计算分别测

资源看什么
相机到服务器带宽所有接入流的实际总码率、协议开销与峰值
播放出口带宽每路码率 × 同时读取该路的客户端数
磁盘持续写入、随机读取、剩余空间与故障恢复
解码/转码编码格式、尺寸、帧率、CPU/GPU 使用与延迟
推理模型、批次、采样频率、显存和结果队列

仅封装转换与完整转码的成本不同。带宽够不代表 GPU、磁盘或播放器也够；RAID 和多副本也不能自动代替备份。

一个可操作的编码测试

用自己已有的长视频文件，先检查，再计时编码：

Terminal window
ffprobe -v error -show_entries format=duration,bit_rate:stream=codec_name,width,height,r_frame_rate -of json input.mp4
ffmpeg -benchmark -i input.mp4 -an -c:v libx264 -preset veryfast -crf 23 test-output.mp4
ffmpeg -v error -i test-output.mp4 -f null -

看 FFmpeg 日志中的编码速度和最终 benchmark，再结合操作系统的 CPU、内存、GPU 与磁盘指标。不要加 -re 后用约 1x 的结果推断机器极限；-re 会主动按源节奏节流。

逐步增加并发，记录吞吐、延迟、丢帧与错误，再决定容量。一次测试的结果只适用于当时的输入、参数和硬件。

状态与故障入口

至少区分设备控制可达、媒体已接入、读到帧、录像正在写入和算法正在产出结果。配置期望状态与进程实际状态也应分别显示。

进程退出记录退出码与错误摘要，网络调用设超时，重试有次数或时间上限，队列和日志有容量限制。重启可以恢复进程，但不能自动补回已丢失录像或证明业务结果正确。

从 相机接入 开始，依次验证接入、录像和算法，再做多路容量测试。