9.1 WebTransport 与 WebCodecs 的影响

9.1 WebTransport 与 WebCodecs 的影响

收官章先回应一个被问得最多的问题：新平台能力会不会取代 WebRTC。短答案是不会，但会改版图。本节把 WebTransport 与 WebCodecs 的能力边界讲清，并给出一套"留与迁"的判断框架——结论大多是混合，而混合的划分线正是本书反复讲的管线位置。

两块新能力到底给了什么

WebTransport 给应用开了一条低延迟数据通道：不经过连接协商与媒体语义，应用自己决定发什么、怎么发。它与 WebRTC 的数据通道有微妙但关键的差别——它绕开了会话协商的开销与约束，建连更轻、用法更自由，代价是穿越与加密等一系列现实问题要应用自己面对，媒体级的反馈机制也一并无。WebCodecs 则把编解码器直接交给应用：一帧进、一帧出，参数自己定、时机自己控。它把引擎内部的编码器从"黑盒服务"变成了"手边工具"，应用可以构建完全自定义的媒体管线——这是过去只有原生应用才有的自由度。

两块能力组合起来，应用理论上可以自己搭一套"极简实时链路"：自己采集、自己编码、自己走传输、自己解码渲染。听起来像取代，实际上这套自建链路缺的恰恰是 WebRTC 积累最深的部分：穿越与中转的完整性、带宽估计与抗丢包的闭环、跨端协商的互操作性。所以真实的格局不是取代，而是按管线位置分工。

留与迁的判断框架

判断一条业务该留在 WebRTC 还是迁向新能力，核心是分辨业务的语义形态。会话语义强的场景——双方或多方要协商、要互通、要弱网闭环——留在 WebRTC：协商协议、穿越设施、拥塞控制这些"难而invisible"的部分正是它的价值所在。流语义强的场景——服务器到观众的单向低延迟分发、对格式与延迟有极端要求——WebTransport 开始有优势：协商开销为零、分发模型简单。算子语义强的场景——要把自研编码器、特效处理、水印插入管线——WebCodecs 几乎是唯一正解：引擎内置管线再灵活，也不可能为每个应用开放内部编码器的每个参数。

工程成本也要入账：自建链路意味着自建穿越方案、自调弱网策略，这些隐性成本常被低估。多数团队的合理路线是混合——媒体会话留在 WebRTC，新增的分发与算子需求用新能力承接，两边共享信令与账号体系。

迁移评估的四步清单

决定"留与迁"之外，更常见的问题是"怎么迁"。给评估过程立一套四步清单：第一步画管线，把业务的每个环节标注语义形态（会话、流、算子），这是判断的底图；第二步定边界，标出准备迁出的环节与留在会话内核的环节，边界处必须定义清晰的数据交接（时间戳、缓冲所有权、质量信号）；第三步算成本，传输自由与算子自由的收益，减去自建弱网策略与穿越方案的成本，多数自建成本在这一步被低估一倍以上；第四步留退路，新链路按旁路灰度，质量指标不达即切回主链路。

清单里"第二步定边界"最值得展开：混合架构的稳定性几乎全部取决于边界设计。时间戳语义要在边界处统一（同一时钟域、同一单位），质量信号要能跨界回传（新链路的丢包信息要能进入整体监控），缓冲所有权要明确交接（谁在什么时刻可以释放）。把边界当接口设计，混合架构就是资产；把边界当临时拼接，它就是故障温床。

WebCodecs 能替代引擎内部的编码器吗

它提供的是同类零件而非更优零件：底层能力相近，差别在于控制权归属。用 WebCodecs 意味着码率控制、参考关系、并行调度全部自理——这既是自由也是负担。除非业务确实需要引擎管不到的算子自由度，否则内置管线的全自动闭环仍是更省心的选择。

新能力对弱网的处理有帮助吗

不直接。它们不带拥塞控制与抗丢包闭环，弱网处理反而成了迁移方的自建项。可行的折中是复用 WebRTC 的会话做质量探测、把估计结果喂给自建传输——但这条路的工程代价要如实入账，别把"能做"当"已做"。

案例：给转发链路加水印的管线改造

背景。某金融客户要求会议画面在录制与分发时嵌入参会者标识水印，用于泄密溯源。通用会议方案里水印要么烧进共享内容（影响所有人），要么由服务端逐人合成（算力爆炸），团队需要一个逐观看者 differentiated 的水印方案。

操作。用 WebCodecs 重建下行链路的末端：转发服务器仍走 WebRTC 把基础流送到接入网关；网关之后，按观看者维度解码、叠加半透明标识、再编码，最后经 WebTransport 分发到浏览器。观看者专属的合成只发生在网关的算子层，源头的会议负载不变。实现上用 WebCodecs 的解码与编码接口串起算子，算子本身是轻量的图形叠加，逐流参数从信令系统取观看者身份。

结果。方案在试点中把逐人水印的服务端成本压到可接受区间——合成只发生在网关一次，而非转发服务器对每个下游各合成一次；画质损耗控制在可感知阈值以下。泄密溯源能力成为客户续约的关键卖点。

解读。这个案例是混合架构的教科书样本：会话骨干不动（WebRTC 的协商与弱网闭环全部保留），新增的算子需求用 WebCodecs 承接，新增的分发需求用 WebTransport 承接，三者各居管线的一段。划分的依据始终是语义形态——溯源算子是逐人 differ 的，塞进会话内核必然别扭；挪到会话外围，各得其所。

变式。若水印需求变成"所有人相同"，答案就完全不同：在共享源头上一次性烧录即可，连算子层都不用动——同一个需求，量纲一变，架构答案就变。这提醒我们：判断框架里的第一步永远是问清语义与量纲，而不是先看技术栈。

要点回顾

本节要点：WebTransport 给传输自由、WebCodecs 给算子自由，两者都不自带弱网闭环与互操作性；留与迁按语义形态判断——会话留、分发迁、算子迁；多数产品的终局是混合架构；自建链路的隐性成本是穿越与弱网策略；判断前先问语义与量纲。下一节看第二股力量：机器学习落在管线的哪些位置。