7.3 带宽分配与编码器联动

7.3 带宽分配与编码器联动

估计器给出总预算之后，分配器接手：把一块蛋糕切给音频、各路视频、重传与冗余的开销。本节讲分配的判据体系与保底逻辑，并用一次手工演算演示多路并存时的份额推演。这是 QoS 三节里最贴近产品决策的一节——"谁先糊、谁先卡"的最终裁决权在这里。

分配的判据：价值、边界与保底

分配器读三样输入。每条流的价值权重：业务语义的优先级，共享屏幕讲课时通常高于摄像头，主講人高于与会者，由应用层声明。每条流的参数边界：编码器声明的最小与最大码率——低于最小码率再编只是浪费字节，不如明确降档；边界是分配的物理约束。必须保底的项：音频享有事实上的优先地位，几十千比特每秒的保底换来的是"再弱网对方也听得见"；重传与冗余的开销同样占用预算，它们的额度与 7.2 的动态策略联动。

切分的顺序体现价值排序：先保音频与保底项，再按权重与边界把剩余预算分给各路视频，冗余开销从各路的份额内计提。预算膨胀时反向执行：冗余先撤、低权重流先降，音频几乎永动。这套"保底优先、按价值让路"的次序，就是弱网时"听得见、看得到、共享变糊"这一体验序列的机制来源。

图：多路并存时的份额切分

与编码器的联动：份额如何变成画质

分配结果下发给各路编码器后，落地遵循 5.2 讲过的四级递进。这里补充一个分配视角的细节：分配器并不等预算跌破极限才动作，而是按比例平滑调整，并给编码器留出量化调节的余地——同样一分预算，静止画面能撑高分辨率，运动画面就该降档。分配器与编码器之间还有一条回程路：编码器的实际消耗、上限利用率会回馈给分配器，长期"吃不饱"的流会被调低名义份额，把余量让给真正需要的流。两端的联动是闭环的，任何一端单看都会误判。

权重与边界的声明实践

分配的输入全部来自应用层的声明，声明的质量直接决定分配质量。权重是相对值，引擎按比例切分，因此不必纠结绝对数值，关注相对序即可；但权重跨度也别拉太开——十倍以上的权重差会让低权重流在预算宽松期也长期挨饿，体验断层明显。边界是最容易被乱设的输入：最小码率设得过高会让弱网时"降无可降"直接断流，最大码率设得过低则浪费好线路。校准边界的务实做法是拿目标设备实测：跑一遍编码器能力探测，把各档位实际可承受的码率范围写进配置，而不是抄模板。

声明之外，还有一条分配器的运行纪律值得交代：分配是周期性的平滑过程而非事件驱动的一次性切割。预算变化时，份额按时间常数逐步逼近目标值，避免编码器参数被高频锤打。这个设计的推论是：观测分配结果要用滑动窗口的趋势，不能拿单次采样下结论——单点看"份额没到位"，趋势看是正常逼近中。

分配结果的观测口径

分配机制的观测有两个容易踩的口径坑，提前排掉。第一，目标份额与实际消耗是两条曲线：分配器给出的是目标，编码器吐出的是实际，稳态下两者重合、动态下实际滞后于目标。只采目标会漏掉"实际压不下去"的执行问题，只采实际会误判"分配不公"。第二，份额比例要在同一时刻切片比较：分配是平滑逼近过程，拿不同时刻的比例相除会得到荒谬结论——尤其预算变化后的几秒内，两条曲线一升一降交错，切片不同结论相反。规范做法是取预算稳定窗口内的滑动均值再比。

观测口径对齐之后，分配机制就拥有了完整的"审计能力"：任何一次"为什么我这么糊"的质询，都能沿着总预算、份额、实际消耗、编码执行四级链条给出每一步的数据。这种可审计性在多人产品的客诉处理里价值极高——它把体验问题的对话从"感觉不对"拉回到"数字在哪一步不对"。

两个高频设计问答

音频真的永远不让路吗

几乎，但不绝对。音频保底是几十千比特的小额，预算再紧也先保它；但音频自身的冗余与纠错开销会随弱网加码，极端情况下引擎会在"保清晰度"与"保可懂度"之间选择后者——降低冗余换取不断流。所以准确的说法是：音频让的是"锦上添花"，从不让"听得上"。

新增一路流时，份额从哪里出

按让路次序从低价值端挤出：先动探测余量与冗余余量，再压低权重流的份额，动高权重流之前会先触发它的降档而非直接剥夺。整个再分配在几个分配周期内平滑完成，业务层的感受是新流逐渐清晰、老流轻微变软——这在多人会议的进出场时刻最常见，属于设计的正常表现。

权重相同的多路流一定均分吗

份额会向"实际用得上"的流倾斜：某路画面静止，其编码实际消耗远低于名义份额，分配器会把富余让给变化剧烈的流。均分是名义规则，按需倾斜才是实际结果——这也是为什么观测分配要用实际消耗而不是目标值。

案例：三路并存、预算三兆的手工演算

背景。一场培训直播的上行要同时发一路音频、一路摄像头、一路共享屏幕，接入方把上行预算定在三兆。产品要求提前推演：预算跌到一半时，各路的表现序列是什么，先糊的是谁。

操作。按分配规则手工推演，各流参数取产品声明的边界：音频保底四十千比特；共享屏幕声明最小五百千、上限两千五、权重高；摄像头最小一百五、上限一千五、权重普通；冗余按线路状况预留一成。

预算三兆时的切分：音频四十、共享一千六、摄像头一千、冗余约三百，探测余量少量。预算跌到一兆半：冗余压到一百五、摄像头压到五百——仍在边界内、画质变软；共享先保一千三——足够维持可读的文档画面。预算再跌到七百千：摄像头触底一百五、开始降分辨率档位；共享压到五百的边界值、同样降档；冗余接近撤防，丢包防护改由重传独挑。

结果。推演得到的让路序列——冗余先撤、摄像头先降、共享后降、音频不动——与产品预期的"看得见讲义、听得清人声"完全一致，据此把权重与边界写进了接入配置。

解读。手工演算的价值不在算术而在把体验翻译成参数：产品说"讲义比人脸重要"，翻译成权重差与边界差；说"再弱也要听得见"，翻译成音频保底。分配机制的参数语义直白，产品与工程可以用同一张表对话，这是它比黑盒策略更适合团队协作的原因。演算之后务必用 7.1 与 7.2 的演练环境实测验证——纸面推演定方向，实测数据定阈值。

变式。对称会议（人人发言）与转播场景（一人主講）的参数取向截然不同：前者各路权重应拉平、让全体维持中等画质，后者应极端加权主讲流。同一套分配机制，参数取向即可覆盖两类场景，不需要为业务定制引擎——这是把产品需求留在配置层解决的又一例证。

要点回顾

本节要点：分配读权重、边界、保底三样输入，切分按价值排序；音频保底与"听得见优先"是体验序列的锚；分配与编码器双端闭环，份额与实际消耗互相校正；手工演算把产品语言翻译成参数语言，演练实测定阈值。下一章视角上移：当连接的另一端变成服务器，这套调度台会发生什么变化。