技术帮助 · 发布时间：
媒体转码的瓶颈不一定在带宽：软件编码可能先吃满 CPU，硬件编码则可能把压力转移到显卡、存储或网络。规划台湾节点运行媒体转码服务的CPU与带宽配置时，应先弄清转码任务类型、目标码率和并发数，再决定资源比例，而不是只按机器规格选型。
疑问一：先加 CPU，还是先买更高带宽？
如果任务使用 FFmpeg 的 x264 等软件编码器，编码复杂度、分辨率和帧率都会影响 CPU 消耗。1080p、较高帧率或较慢的编码预设通常更费处理能力；此时单纯扩带宽不能缩短编码队列。相反，若编码进程仍有余量，但上传、下载或成品分发接近网卡上限，扩带宽才更直接。
初步判断可同时观察 CPU 使用率、任务等待时间、网卡吞吐和丢弃情况。连续高负载且队列增长，优先评估增加 vCPU、降低并发或改用硬件编码；网络长期接近可用上限，则检查码率和并发，再考虑提高带宽。台湾节点运行媒体转码服务的CPU与带宽配置，核心是分别满足计算和传输需求。
疑问二：转码方式会怎样改变配置？
软件编码与硬件编码
软件编码依赖 CPU，优势是参数选择较灵活、编码质量控制成熟，适合重视画质或任务数量较少的场景；缺点是并发增加时容易争抢算力。硬件编码可利用支持相应编码格式的 GPU 或专用媒体引擎，通常能减轻 CPU 压力，但要核对实例是否实际提供编码设备、驱动是否可用，以及并发会不会受设备能力限制。
H.264 兼容性较广；H.265 在相近画质目标下可能降低输出码率，但编码复杂度和终端支持情况也需考虑。不要仅凭格式名称推断资源消耗，应在目标分辨率、预设与画质条件一致时比较。
疑问三：带宽按什么公式估算？
先估算同时传输的流量，而非把所有任务数直接当作带宽。可用“单路平均码率 × 同时传输路数”得到基础吞吐，再预留约 20%–30%余量，应对码率波动、协议开销和短时峰值。比如 20 路输出、每路约 8 Mbps，基础值约为 160 Mbps；预留余量后，规划值约为 190–210 Mbps。该估算假设这些流同时持续传输，不代表任何服务商的实测性能。
还要区分输入与输出：上传源文件占用入站流量，回传成品或向用户分发占用出站流量。若媒体存储与转码节点分离，节点之间的传输也会占用链路；具体计费和可用带宽应以所选云平台或机房的产品说明为准。
疑问四：并发设置多少才合适？
并发越高，任务完成时间未必越短。软件编码时，多个任务可能争用 CPU 与内存；硬件编码时，也要防止编码设备队列堆积。台湾节点运行媒体转码服务的CPU与带宽配置，应以目标任务的实际耗时和峰值流量校准，不宜按 CPU 核数简单推算并发。
疑问五：如何用小规模测试定配置？
- 选取实际会遇到的源视频，记录分辨率、帧率、时长和目标编码参数。
- 固定编码预设，分别测试单任务与预计峰值并发，观察 CPU、内存、设备占用和任务等待时间。
- 记录每路输入、输出码率及并发传输数，按峰值而非日均值核算网络余量。
- 逐步增加并发；一旦队列持续增长或吞吐逼近可用上限，分别调整计算、码率或带宽后复测。
测试应覆盖长视频和短视频等真实任务类型。短任务启动开销占比可能较高，单次测试结果不宜直接外推到长时间批量作业。
结论与常见问题
先定位瓶颈，再扩容：编码排队看 CPU 或编码设备，传输受限看峰值吞吐与链路余量。台湾节点运行媒体转码服务的CPU与带宽配置没有通用固定比例，需结合编码方案、目标码率和并发实测。
常见问题
- 只提高带宽能解决转码慢吗？不能。若编码器受 CPU 限制，带宽提升通常不会让编码更快。
- 硬件编码一定更省钱吗？不一定。需比较实例成本、设备可用性、编码能力和目标画质。
- 带宽余量要留多少？可先按约 20%–30%做规划，再根据码率波动和峰值监测调整。
- 什么时候该增加并发？当 CPU 或编码设备仍有余量、网络未逼近上限且队列可控时，逐步测试增加。
