让四路视频承载更多清晰度：多分辨率发布与策略演进

视频会议中的同一个人，可能同时出现在不同参会者的大画面、九宫格和侧边栏里。每个窗口需要的清晰度不同，网络和设备条件也在变化。发布端怎样提供足够多的分辨率选择，同时控制编码和上行开销，是 RTC 产品需要解决的一个基础问题。

在支持四路 Simulcast 之后，我们进一步设计了多分辨率发布能力：在四个通道的框架下，让每个通道按订阅需求动态决定发送哪一档分辨率。业务因此可以表达更细的观看需求，系统也获得了更多升降级的选择。

初始的通道取值策略在随后的具体业务中暴露出问题，我又推动了一期优化，让同通道的取值方式能够按场景、按通道配置。底层发布订阅、汇聚及媒体处理机制，由团队共同设计和实现。

四路固定档位，开始限制业务的选择

最初，四路 Simulcast 提供 720P、360P、180P、90P 等固定档位，分别承接大画面、小窗口和密集宫格的需求。随着视图和设备能力发展，业务需要的分辨率逐渐落在这些档位之间。

例如，九宫格中的窗口适合使用 270P，但原有档位只有 180P 和 360P。选择 180P，画面细节不足；选择 360P，又可能投入超过当前窗口所需的带宽和处理资源。类似地，720P 与 360P 之间也有继续细分的空间。

另一类需求来自覆盖范围的扩展。大屏希望使用 1080P，密集宫格需要 90P，二者还要与原有中间档位共存。每增加一种需求，就增加一路编码发送，终端的性能和带宽压力会持续上升。

这里需要重新审视两个数量：业务可以选择多少种分辨率，以及发布端同一时刻编码发送多少路流。把它们分开设计，才能在有限的并发资源下覆盖更多观看场景。

我们引入了“通道”：一个通道可以包含多档候选分辨率，在同一时刻选取其中一档编码发送。

以一种四通道配置为例：

这是一组配置示例，具体划分需要结合业务与设备条件确定。它可以表达九种分辨率选择，同时将并发发送控制在四路以内；没有订阅需求的通道，也不必持续发送。

订阅端根据当前窗口尺寸和设备条件表达目标分辨率，RTC 将请求匹配到候选档位。服务端汇聚多个订阅端的需求，再通知发布端选择各通道实际发送的分辨率。

业务接入的表达方式也随之改变。发布端设置最大分辨率或明确需要的编码档位，RTC 在能力范围内补齐候选配置；订阅端按窗口宽高提出需求，减少对固定“大、中、小流”编号的依赖。窗口布局演进时，业务可以围绕实际像素需求调整订阅。

这种灵活性仍有边界。多个请求落在同一通道时，需要共享一档实际发送的流，无法让所有候选分辨率同时独立存在。设备能否承担各通道组合，也需要检查并发编码的总负荷；只看最高支持到多少 P，并不足以说明能力。

新旧版本的使用方式同样需要衔接。新端可以表达更细的分辨率需求，旧端仍按原有档位订阅，双方能力不一致时保留相应的兼容路径。

对业务而言，多分辨率首先扩大了视图设计的空间。九宫格可以请求 270P，大画面与侧边栏可以提出各自的清晰度需求，不同窗口尺寸也能在候选范围内找到更合适的档位。

它还提供了更细的资源调整空间。原来从 720P 降到 360P，分辨率变化幅度很大。如果当前资源已经无法维持 720P，却仍足以支撑中间某一档，系统就有机会选择 630P 或 540P，保留更多画面细节。

这为弱网和性能升降级提供了更丰富的选项。具体怎样使用这些选项，需要与通道配置、订阅汇聚、帧率调节和实际资源条件共同设计。增加候选档位，并不意味着每个接收端都能独立、连续地切换到任意分辨率。

从产品角度看，这项创新的价值在于：在有限并发资源下，扩大可表达的需求范围，再让系统根据实际需求形成供给。清晰度提升有了更细的调节基础。

通道带来灵活性的同时，也引出了一个关键问题：同一通道出现不同分辨率请求，应该发送哪一档？

初始策略是取这些订阅请求中的最低分辨率。例如，同通道内有人请求 180P、有人请求 144P，就统一发送 144P。这样选择了较低的供给，但也让较高需求的接收端共同承担了画质损失。

这个问题后来在共享场景的侧边栏中表现得很具体。业务为侧边栏的几个人像窗口配置了 180P，但只要其他接收端同时请求同通道的 144P，最终就只发送 144P。需要 180P 的窗口也只能收到较低分辨率，嘉宾画面因此显得模糊。

这类问题不能只从单个订阅端排查。窗口尺寸和目标请求可能都已设置正确，清晰度仍然在多个请求汇聚时被压低。

还需要区分低分辨率请求的来源：它可能只是窗口较小，也可能与设备、网络条件有关。一个较低请求，并不能直接代表同通道其他人的观看需要。最低值汇聚所隐含的体验取舍，在不同场景下需要重新评估。

针对这个问题，我推动的后续优化，是在保持对外 API 不变的情况下，增加服务端配置能力，允许同通道出现多档订阅请求时向上取值，并按通道分别设置取值方式。

例如，同通道同时存在 360P、450P、540P 请求时，可以选择发送 540P，优先满足较高的清晰度需求。不同通道可以采用不同策略：中小画面通道向上取值，大画面通道仍保留原有汇聚逻辑。

在产品定义上，我们将三类体验取舍纳入策略范围：偏向较低需求、偏向多数人的需求，以及偏向较高需求。它们各自适合的条件，需要结合通道承载的场景判断。较低取值会限制高需求窗口的清晰度；较高取值可能增加资源开销；偏向多数人则需要考虑少数需求怎样得到合理承接。

因此，可配置的意义，是让不同通道有机会采用符合其体验目标的规则。共享侧边栏、大画面和密集小窗口，对清晰度、资源成本及退化方式的要求可能不同，不能只靠一个全局取值方向覆盖所有情况。

向上取值也需要保留网络与性能约束。提高汇聚后的发送规格，无法替代实际的带宽和设备适配。

这两阶段的演进，对应着两个紧密相连的产品问题：有限资源能提供哪些选择，以及多个需求共同存在时怎样作出选择。

多分辨率通道把业务可选的档位扩展到并发流数之外，为视图订阅和弱网调整提供了更细的空间。随后的取值优化，则进一步明确这些需求发生冲突时，系统应该怎样分配画质与资源。

设计类似的平台能力时，可以先明确资源上限和业务需求，再检查需求聚合后的实际供给：谁的请求得到满足，谁承担了损失，这种损失是否符合当前场景的目标。对于需要跨场景复用的策略，还应明确哪些规则适合作为默认值，哪些需要按业务或通道调整。

只有把需求表达、共享资源的分配规则，以及条件变差时的处理方式接起来，更多的技术选项才能持续转化为用户看得见的体验价值。