6.3 动态降级与分层编码

6.3 动态降级与分层编码

本节摘要：带宽估计器说「只能发五百千」时，编码器往哪儿砍？先砍帧率还是分辨率？音频动不动？一方上传、多方观看时，服务器要不要替每人转一份？动态降级回答「牺牲什么」的问题，simulcast 与 SVC 回答「怎么让多方各取所需」的问题。本节给出降级顺序的工程惯例、两套分层方案的取舍对比，以及可直接落地的配置代码。

本节的学习收获

阅读完本节，你应当能够：

1. 说出弱网降级的标准顺序：帧率先降、分辨率次之、质量档再降、音频殿后；
2. 用 setParameters 动态调整发送码率与帧率，实现发送端降级；
3. 解释 simulcast 的原理：同源多码流与 rid 标识，以及它对上行带宽的代价；
4. 解释 SVC 分层编码的原理：一条流自带层次，以及它对解码端的兼容要求；
5. 在 simulcast 与 SVC 之间按业务场景（上行带宽、终端差异、SFU 能力）选型；
6. 观测降级是否生效：从统计与对端画面双重验证。

一、问题与直觉：降级的次序是一种承诺

带宽缩水时编码器不会自己判断「牺牲什么」，默认行为可能面目全非——有的先糊成一团，有的直接掉帧。工程上把降级次序约定成一种承诺：帧率先降（人眼对帧率下降最宽容，15 帧依然可看）；分辨率次之（降到 360p 依然认得出脸）；画质档再降（压缩加重，细节牺牲）；音频殿后且几乎不动（通话里声音是语义本体，视频糊了还能开会的底线是听得清）。

这个次序背后是「感知敏感度」排序：轻微卡顿比轻微模糊刺眼，轻微模糊比声音损伤刺眼。把排序写进编码器参数与码率分配策略，弱网下的体验曲线就变得可预期——用户看到的是「画质慢慢变朴素」而不是「画面忽好忽坏」。

多方场景再叠一层问题：同一个人的画面，会议室大屏要看高清、地铁里的手机看标清就够。让发送端发一份流显然顾此失彼，让发送端按每个接收者各发一份又耗尽上行——于是有了「一源多发、各取所需」的分层思路，实现路径有两条：simulcast 与 SVC。

二、核心原理：simulcast 与 SVC

simulcast（同步多播）：终端把同一路摄像头编码成多条独立码流——高清、中清、低清各一条（用 rid 标识），全部上行发送；SFU 按每个接收端的能力与带宽，转发其中最合适的一条。优点是技术简单、流之间零依赖、任何标准解码器都能播；代价是上行带宽与编码算力按层数翻倍——三个 simulcast 层意味着约两倍半的上行流量。它适合「上行尚可、下行千差万别」的会议场景。

SVC（可分级视频编码）：编码器把层次做进一条流内部——基础层独立可解码，增强层逐级叠加清晰度；SFU 裁剪增强层后转发，接收端收多少层解多少清晰度。优点是一条上行流就携带全部层次，上行省带宽；代价是编解码复杂、层间依赖使丢包影响放大、对终端解码能力与整条链路的实现协同有要求。它适合「上行紧张、终端较新」的场景。

图：simulcast 多流与 SVC 分层流的结构对比

发送端动态降级的实现入口是发送器参数：

// 弱网降级：按目标码率台阶式调整编码参数
const videoSender = pc.getSenders().find((s) => s.track?.kind === 'video');

async function applyQualityProfile(profile) {
  const params = videoSender.getParameters();
  if (!params.encodings?.length) params.encodings = [{}];
  params.encodings[0].maxBitrate = profile.maxBitrate;
  params.encodings[0].maxFramerate = profile.maxFramerate;
  // 分辨率切换走 replaceTrack 换低清轨（第 2 章的技巧在此复用）
  await videoSender.setParameters(params);
}

const profiles = {
  high: { maxBitrate: 2_500_000, maxFramerate: 30 },
  mid:  { maxBitrate:   800_000, maxFramerate: 15 },
  low:  { maxBitrate:   250_000, maxFramerate: 10 },
};
// 触发源：统计接口的目标码率与丢包率（6.1 的观测入口）
// 惯例：加迟滞与最小停留时间，避免码率在阈值附近来回抖动
​

simulcast 的开启则在 addTrack 时用 transceiver 声明：

// simulcast：一条轨声明多个编码层，rid 顺序即层次顺序
const transceiver = pc.addTransceiver(camTrack, { direction: 'sendonly' });
transceiver.setCodecPreferences(preferredCodecs);
// 发送参数里声明多 encodings（现代浏览器亦可经 addTransceiver 后配置）
const p = transceiver.sender.getParameters();
p.encodings = [
  { rid: 'high', maxBitrate: 2_500_000, scaleResolutionDownBy: 1 },
  { rid: 'mid',  maxBitrate:   500_000, scaleResolutionDownBy: 2 },
  { rid: 'low',  maxBitrate:   150_000, scaleResolutionDownBy: 4 },
];
await transceiver.sender.setParameters(p);
// SDP 对账点：a=rid 行与 a=simulcast 行成对出现（第 3 章的方法）
​

三、工程实践要点：降级的节奏与验证

降级最怕抖动：码率在阈值附近来回穿越，画质跟着反复横跳，比持续低清更难受。工程惯例是给降级加迟滞与驻留——升档的阈值高于降档的阈值（如 0.9 倍降、1.3 倍升），且每档至少停留几秒才允许再动。另一个惯例是降级快、恢复慢：恶化时果断下调（用户对骤卡零容忍），恢复时逐步上调（试探着回，避免再压垮）。

验证降级生效要双重证据：统计侧看目标码率与实际发送码率是否同步下弯，体感侧看对端画面是否相应变化。只看前者会漏掉「参数设了但编码器没执行」的怪现象（多见于参数时序错误）。

完整案例：万人峰会的上行救场

背景：某产品的行业峰会直播（一名主讲人、数千观众）中，主讲人使用家用上行宽带，开启摄像头后上行立刻饱和，自己端预览卡顿、观众端全员低清。

操作：诊断发现两个叠加问题：其一，主讲人端为了「自己预览好看」采集 1080p 三十帧，编码也按此配置，上行被高清流独占；其二，此前未启用 simulcast，服务器只能按最低公倍数转发单一码流。整改：主讲人采集保持 1080p 但发送改三档 simulcast，SFU 按观众带宽各配所需；主讲人本地预览直接挂原始轨道（不占编码器）；为峰清单独设定降级曲线（更早降帧率，因为演讲场景画面动得少）。

结果：主讲人上行占用下降过半，观众端高清比例显著上升，讲义文字清晰度反而变好——低带宽观众被稳定供应在中清档，不再在「高清马赛克」与「极糊」之间震荡。

解读：两个值得带走的经验。其一，「预览」与「发送」用同一轨道听起来自然，实则绑定了采集与发送的命运——预览挂原始轨、发送走编码器，两边解耦后互不拖累。其二，降级曲线应随内容形态定制：演讲、舞蹈、屏幕共享的帧敏感度完全不同，一套全局曲线注定顾此失彼。

变式：若该峰会的观众端大量出现在不支持 simulcast 选流的老旧接入侧，可以折中：服务端做转码再分层（SFU 变 MCU 的一次局部借用，第 7 章会讲这个谱系）——用服务器算力换端侧兼容性，成本与体验的又一次典型交换。

本节要点回顾

• 降级次序是承诺：帧率先让、分辨率次之、画质再让、音频殿后，感知敏感度排序写进策略。
• simulcast 用上行换兼容：多流独立、解码无门槛，是会议场景的主流选择。
• SVC 用协同换上行：一条流带层次，上行省，但链路各环节要协同且丢包代价高。
• 降级要加节奏：迟滞阈值加驻留时间，降得果断、升得试探，杜绝画质横跳。
• 分层离不开 SFU：点对点直连吃不到分层的红利，这为第 7 章的拓扑话题埋下伏笔。