前言

        在点播或传统 RTMP 推流里，清晰度往往被简化成：分辨率 × 码率 × 帧率三元组：你定好 1080p、3 Mbps、30 fps，编码器就按这个目标干活。WebRTC 则不同——它天生面向低时延、双向、自适应场景。网络抖动、丢包、CPU 负载、浏览器策略、对端解码能力，都会在毫秒级时间尺度上改写清晰度目标。

        很多人第一次做 WebRTC 推流时会踩到这些坑：

• getUserMedia 明明申请了 1080p，对端却只看到 480p；
• 把 maxBitrate 拉到 4 Mbps，画面仍然糊成一片；
• 本地预览很清晰，远端却周期性模糊、马赛克、卡顿；

        同样一套参数，Chrome 正常，Safari / 某些 Android WebView 却明显劣化。

        这些问题的本质是：WebRTC 的清晰度不是单一旋钮，而是一条跨采集、编码、传输、拥塞控制、接收端适配的质量链路。本文从工程视角拆解这条链路，给出可落地的控制手段与提清策略，并附上关键示意图与代码示例。

一、先建立心智模型：清晰度在整条链路中的位置

        可以把 WebRTC 推流理解成一条流水线：摄像头采集 → MediaStream → 编码器 → RTP 打包 → 拥塞控制与网络发送 → 对端接收解码 → 渲染。任意一环掉链子，主观清晰度都会下降。

图1 WebRTC 媒体链路示意

        图 1：WebRTC 推流质量链路。清晰度问题往往出现在「采集不足 / 编码预算不够 / 拥塞主动降质」三个阶段之一。

        工程上建议把「清晰度」拆成三层指标，避免只盯着分辨率：

        主观观感还受内容类型影响：静态人脸、PPT 屏幕共享、快速运动游戏画面，对码率与帧率的敏感度完全不同。因此调参前先明确场景，比盲目拉高参数更重要。

二、清晰度控制的三大核心旋钮

        在业务侧可直接干预的，通常是分辨率、码率、帧率。三者互相制约：同样码率下，分辨率越高越容易“糊”；帧率越高，单帧可用的比特预算越少。

图2 分辨率 / 码率 / 帧率与清晰度权衡

        图 2：三大旋钮与带宽预算的权衡关系。清晰度优化的本质是「在可用带宽内把比特花在最影响观感的地方」。

2.1 分辨率：从申请到真正发出去

        浏览器里申请摄像头分辨率，常见写法是：

const stream = await navigator.mediaDevices.getUserMedia({
  audio: true,
  video: {
    width: { ideal: 1280, max: 1920 },
    height: { ideal: 720, max: 1080 },
    frameRate: { ideal: 30, max: 30 },
    facingMode: "user"
  }
});

        注意：ideal 只是偏好，不是承诺。设备、驱动、权限、其他应用占用摄像头，都会导致实际拿到的 track settings 低于期望。务必读取真实设置：

const track = stream.getVideoTracks()[0];
console.log(track.getSettings());
// { width: 1280, height: 720, frameRate: 30, ... }

        即便采集到了 1080p，发送端仍可能通过 scaleResolutionDownBy、Simulcast 低层、或拥塞控制主动降分辨率。所以排查「为什么不清晰」时，至少要同时看：

(1).MediaStreamTrack.getSettings()（采集实况）

(2).RTCRtpSender.getParameters()（发送编码参数）

(3).getStats() 里的 framesPerSecond、frameWidth、frameHeight、bytesSent（实际发出去的情况）

2.2 码率：最直接、也最容易被误解的旋钮

        WebRTC 允许你通过 RTCRtpSender.setParameters 设置编码上限：

const sender = pc.getSenders().find(s => s.track?.kind === "video");
const params = sender.getParameters();
 
if (!params.encodings || params.encodings.length === 0) {
  params.encodings = [{}];
}
 
// 单位：bps
params.encodings[0].maxBitrate = 2_500_000; // 2.5 Mbps
params.encodings[0].maxFramerate = 30;
 
await sender.setParameters(params);

        关键点在于：`maxBitrate` 是上限，不是保证值。当 GCC（Google Congestion Control）或传输层估计出的可用带宽更低时，编码器会自动把目标码率压下去。你设 4 Mbps，网络只有 1 Mbps 稳态带宽，最终仍会以接近 1 Mbps 的质量运行——这是正确行为，否则只会换来更大延迟与更多丢包。

        经验取值（仅作起点，需按内容与网络校准）：

2.3 帧率：清晰度与「流畅感」的平衡器

        帧率并不直接等于「清晰」，但对运动场景的主观质量影响极大。30 fps 在通话中通常足够；屏幕共享可降到 10–15 fps，把比特预算留给空间细节（文字边缘）。反之，若强行 60 fps 却码率不足，会出现「每帧都很糊」的糟糕体验。

        可用约束或 encoding 参数限制帧率：

await track.applyConstraints({ frameRate: { ideal: 24, max: 24 } });
// 或
params.encodings[0].maxFramerate = 24;

三、编码参数与编解码器选择

3.1 编解码器优先级：H.264 / VP8 / VP9 / AV1

        通过 SDP 或 setCodecPreferences 可以影响编解码协商结果：

const transceiver = pc.addTransceiver("video", { direction: "sendrecv" });
const caps = RTCRtpSender.getCapabilities("video");
const preferred = ["video/AV1", "video/VP9", "video/H264", "video/VP8"]
  .map(mime => caps.codecs.find(c => c.mimeType.toLowerCase() === mime.toLowerCase()))
  .filter(Boolean);
 
// 把偏好的 codec 排到前面，其余追加
const rest = caps.codecs.filter(c => !preferred.includes(c));
transceiver.setCodecPreferences([...preferred, ...rest]);

3.2 Degradation Preference：糊一点还是卡一点

        当带宽或 CPU 不足时，浏览器要在「降分辨率 / 降帧率」之间做选择。可通过 degradationPreference 表达业务偏好：

const params = sender.getParameters();
params.degradationPreference = "maintain-resolution"; // 或 maintain-framerate / balanced
await sender.setParameters(params);

3.3 硬件编码与功耗

四、传输层：拥塞控制如何「抢走」你的清晰度

五、Simulcast 与分层：让「清晰」可按接收端能力分配

        在多人会议或直播分发中，发送端不可能用一套固定高质量满足所有接收端。Simulcast（多流）与 SVC（可伸缩视频编码）是常见解法：发送端同时产出高/中/低多层，SFU 按接收端带宽与窗口大小选层转发。

图3 Simulcast 分层示意

        图 3：Simulcast 将清晰度拆成多层。核心不是「所有人都看 1080p」，而是「有带宽的人看清，弱网用户仍可流畅」。

        浏览器侧开启 Simulcast 的典型思路（示意）：

const pc = new RTCPeerConnection();
const stream = await navigator.mediaDevices.getUserMedia({
  video: { width: 1280, height: 720, frameRate: 30 }
});
 
pc.addTransceiver(stream.getVideoTracks()[0], {
  direction: "sendonly",
  sendEncodings: [
    { rid: "q", scaleResolutionDownBy: 4.0, maxBitrate: 300_000 },
    { rid: "h", scaleResolutionDownBy: 2.0, maxBitrate: 800_000 },
    { rid: "f", scaleResolutionDownBy: 1.0, maxBitrate: 2_000_000 }
  ]
});

六、采集侧：被低估的「源头清晰度」工程

6.1 约束要写全，但别写死

const constraints = {
  video: {
    width: { ideal: 1920, min: 1280 },
    height: { ideal: 1080, min: 720 },
    frameRate: { ideal: 30, min: 24 },
    aspectRatio: 16 / 9
  }
};

        min 过严会导致 OverconstrainedError，在笔记本外接摄像头或虚拟摄像头场景尤其常见。更稳妥的策略是：先 ideal 申请 → 失败再降级重试（1080 → 720 → 540）。

6.2 光照、对焦、自动曝光

Web 端能力有限，但原生/桌面端常可调：

• 保证面部/被摄主体照度充足，降低 ISO 噪声（噪声在压缩后更糊）；
• 关闭不必要的数码变焦；
• 固定对焦（授课摄像头）可减少呼吸效应导致的间歇模糊；
• 避免强逆光；自动曝光剧烈跳动会被编码成「忽明忽暗 + 细节丢失」。

6.3 不要二次缩放踩坑

        常见错误链路：摄像头输出 720p → CSS/Canvas 放大到全屏预览（看起来还行）→ 业务又把 track 塞进 1080p 编码期望。本地预览的「观感清晰」不等于编码输入清晰。应用 getSettings() 对齐真实像素，预览用 object-fit 即可，别靠拉伸制造错觉。

6.4 屏幕共享的特殊优化

        屏幕共享对清晰度极敏感（文字、UI 线条）。建议：

• 提高分辨率，适当降低帧率（如 1080p@10–15fps）；
• 优先 maintain-resolution；
• 内容偏静态时，可接受更低帧率换取更干净的文字边缘；
• 避免系统缩放非整数倍（125%/150% 缩放桌面）带来的模糊采样；有条件让用户使用 100% 缩放或采集实际渲染缓冲。

七、系统化提清路线图

        把前面的手段串成可执行路线，按投入产出排序推进：

图4 提升 WebRTC 推流清晰度路线图

async function startPublish({ signaling, roomId }) {
  const pc = new RTCPeerConnection({
    iceServers: [
      { urls: "stun:stun.l.google.com:19302" },
      // 生产环境请配置你们自己的 TURN
    ]
  });
 
  const stream = await navigator.mediaDevices.getUserMedia({
    audio: {
      echoCancellation: true,
      noiseSuppression: true,
      autoGainControl: true
    },
    video: {
      width: { ideal: 1280, max: 1920 },
      height: { ideal: 720, max: 1080 },
      frameRate: { ideal: 30, max: 30 }
    }
  });
 
  const videoTrack = stream.getVideoTracks()[0];
  console.log("capture settings", videoTrack.getSettings());
 
  const sender = pc.addTrack(videoTrack, stream);
 
  // 等待协商完成后设置编码参数更稳妥
  const applyEncoding = async () => {
    const params = sender.getParameters();
    if (!params.encodings?.length) params.encodings = [{}];
 
    params.degradationPreference = "balanced";
    params.encodings[0].maxBitrate = 2_000_000;
    params.encodings[0].maxFramerate = 30;
    // 如需强制降尺度：params.encodings[0].scaleResolutionDownBy = 1;
 
    await sender.setParameters(params);
  };
 
  pc.onicecandidate = (e) => {
    if (e.candidate) signaling.send({ type: "candidate", candidate: e.candidate });
  };
 
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);
  signaling.send({ type: "offer", sdp: offer.sdp, roomId });
 
  signaling.onAnswer = async (answerSdp) => {
    await pc.setRemoteDescription({ type: "answer", sdp: answerSdp });
    await applyEncoding();
  };
 
  // 每 2s 观察是否被限质
  setInterval(async () => {
    const stats = await pc.getStats();
    stats.forEach((report) => {
      if (report.type === "outbound-rtp" && report.kind === "video") {
        console.log({
          w: report.frameWidth,
          h: report.frameHeight,
          fps: report.framesPerSecond,
          bps: report.bytesSent,
          limit: report.qualityLimitationReason,
          encoder: report.encoderImplementation
        });
      }
    });
  }, 2000);
 
  return { pc, stream };
}

        我们可以把 qualityLimitationReason !== "none" 的时长占比做成告警：若大量 bandwidth，应引导用户网络或降低默认档位；若大量 cpu，应降分辨率/换硬件编码/减路数。

九、常见「不清晰」故障对照表

十、产品化建议：把清晰度做成「档位」，而不是隐藏魔法数

        对终端用户暴露「高清 / 标清 / 流畅」比暴露 Mbps 更友好；对内部则要把档位映射到明确参数包：

再叠加策略：

(1).开播前探测：用短时上行探测或历史房间质量，默认落到更稳的档位；

(2).运行时自动降档：连续 N 秒 qualityLimitationReason=bandwidth 则提示或自动切换；

(3).禁止无效高档：检测到最大采集仅 720p 时，不要让 UI 仍显示「1080p 高清」；

(4).分场景模板：摄像头通话与屏幕共享使用不同模板，不要共用一套参数。

        这比「全局写死 4 Mbps」更能同时提升平均清晰度与稳定性——因为真正伤害体验的，往往不是峰值不够高，而是质量波动太大。

十一、进阶方向：从「够用」到「精品」

        当我们已经完成基础可控后，还可以继续向精品化推进：

(1).内容自适应编码（CAE）：根据画面复杂度动态分配码率（人脸 ROI、文字区域增强）。

(2).ROI / 背景弱化：会议场景对脸部保真、背景可更强压缩（需编解码与管线支持）。

(3).端云协同：SFU 侧按订阅窗口大小限层；录制流与实时流分离参数。

(4).AV1 / 新一代编码渐进放开：先在强性能桌面端灰度，再扩移动端。

(5).QoE 模型：不止看 PSNR/SSIM，结合卡顿、模糊时长、建联成功率做综合分。

(6).弱网对抗组合拳：FEC、NACK、关键帧请求（PLI/FIR）参数协同，避免重传挤占有效视频带宽。

        这些手段成本更高，但在教育、医疗、远程协作等对「可读 / 可辨」要求高的行业，往往是差异化竞争力来源。

十二、实践清单 

开播前：

[ ] getSettings() 确认采集分辨率/帧率达标

[ ] 编码档位与场景匹配（会议 / 屏幕 / 运动）

[ ] maxBitrate、maxFramerate、degradationPreference 已设置

[ ] ICE/TURN 路径符合预期（尽量 UDP）

[ ] 多人场景 Simulcast 层码率与分辨率对齐

运行中：

[ ] 监控 qualityLimitationReason（bandwidth/cpu）

[ ] 监控实际发送宽高、帧率、有效码率

[ ] 弱网自动降档或提示，避免无效硬扛

[ ] SFU 选层具备迟滞，避免清晰度闪烁

验收标准（示例）：

[ ] 目标网络下，P90 有效发送分辨率不低于产品承诺档

[ ] 糊片持续时长占比 < 阈值（如 5%）

[ ] 无明显「清↔糊」振荡

[ ] CPU 限质占比可控，移动端功耗可接受

总结

        WebRTC 推流清晰度的控制，不是「把分辨率和码率调到最大」，而是在实时性约束下，管理一条会自适应的质量链路。采集决定上限，编码决定预算如何变成细节，拥塞控制决定预算能否兑现，Simulcast/选层决定预算如何在多人之间分配，监控则决定你能否持续把经验变成系统能力。

若只记三条行动原则：

(1).用 `getSettings` + `getStats` 看真相，不要被本地预览骗到；

(2).给场景正确的旋钮组合（分辨率 / 码率 / 帧率 / degradation），而不是单点猛拉码率；

(3).先稳定，再提高：稳态的 720p 往往比剧烈抖动的「名义 1080p」更清晰、更专业。

        希望本文能帮助大家把清晰度从主观感受，变成可配置、可观测、可演进的工程指标。若你正在做会议、直播连麦、在线教育或远程控制，不妨先从本文的测量闭环与档位化参数包开始落地，再逐步引入 Simulcast 与更激进的编码优化。

参考文章：

1).W3C WebRTC 1.0 / Media Capture and Streams 规范中关于 constraints、RTCRtpSendParameters 的说明

2).WebRTC Statistics（getStats）字段释义与浏览器实现差异

3).Google Congestion Control（GCC）与 Transport-CC 相关论文/设计文档

4).各浏览器对 degradationPreference、Simulcast、AV1 的平台支持矩阵（以 CanIUse 与发布说明为准）