3、分辨率与帧率：分辨率选择策略、帧率对质量的影响、动态分辨率调整

分辨率跟帧率，这俩参数是WebRTC编码里最直观、也最容易让人纠结的东西。很多刚入行的朋友上来就问：「我该设720p还是1080p？30帧够不够？」说实话，没有标准答案。但如果你理解了背后的权衡逻辑，自己就能做判断。

我个人习惯把分辨率看作「画质的容量」，帧率看作「流畅度的节奏」。两者互相牵制，又共同决定了用户的观看体验。今天咱们就掰开揉碎聊聊。

3.1 分辨率选择策略：不是越高越好

先讲个我踩过的坑。几年前做一款在线教育产品，老师端摄像头是4K的，我心想「高清多好」，直接推了1080p。结果呢？学生端频繁卡顿、花屏，尤其是移动网络用户，体验极差。后来我意识到：分辨率的选择，本质是带宽与画质的博弈。

分辨率越高，每帧包含的像素越多，编码器需要处理的数据量就越大。在带宽固定的情况下，强行推高分辨率只会导致两个后果：

• 码率不足：画面模糊、出现马赛克
• 延迟飙升：数据堆积，端到端延迟变高

那怎么选？我总结了一套经验法则：

3.2 帧率对质量的影响：流畅度与清晰度的取舍

帧率这事，很多人有个误区：觉得帧率越高越好。其实不然。

你想想看，人眼对帧率的感知是有上限的。在视频通话场景下，15fps就能提供基本流畅的体验，24fps已经很舒服了，30fps以上边际收益递减明显。但帧率每翻一倍，编码器需要处理的帧数就翻一倍——在码率固定的情况下，每帧能分配到的比特数就减半。

这就导致一个现象：高帧率反而可能让画面更模糊。

我在项目中遇到过这种情况：用户抱怨视频「看着卡」，我一看码率才800kbps，但帧率设了60fps。每帧只有13kbps，画面全是块状模糊。降到30fps后，每帧码率翻倍，画面清晰度明显提升，用户反而觉得「流畅了」。

不同场景的帧率建议：

• 普通视频通话：24-30fps，兼顾流畅与画质
• 屏幕共享（静态内容）：5-15fps，大幅节省码率
• 体育/游戏直播：30-60fps，运动场景需要高帧率
• 弱网环境：15-20fps，优先保证画面不花屏

3.3 动态分辨率调整：WebRTC的自动适应机制

WebRTC最强大的地方之一，就是它能根据网络状况自动调整分辨率。这个机制叫「码率自适应」，核心逻辑很简单：

1. 接收端通过RTCP反馈包（REMB或TWCC）报告丢包率、RTT、可用带宽
2. 发送端的码率控制器根据反馈调整目标码率
3. 编码器根据目标码率，动态切换分辨率

具体到代码层面，WebRTC内部维护了一个分辨率切换表。我简化一下核心逻辑：

// 伪代码：WebRTC分辨率自适应逻辑
function onBandwidthEstimate(bandwidthKbps) {
  if (bandwidthKbps > 1500) {
    setResolution(1280, 720);  // 720p
  } else if (bandwidthKbps > 800) {
    setResolution(854, 480);   // 480p
  } else if (bandwidthKbps > 400) {
    setResolution(640, 360);   // 360p
  } else {
    setResolution(426, 240);   // 240p
  }
}

当然，实际实现比这复杂得多。WebRTC会考虑帧率、码率、CPU负载等多维因素。但核心思想就是：带宽下降 → 降分辨率 → 保流畅。

我曾经调试过一个诡异的问题：用户网络从4G切到WiFi时，分辨率反而下降了。查了半天发现，切换网络时RTCP反馈出现短暂中断，码率估算器误判为带宽骤降，触发了降分辨率逻辑。后来我加了平滑滤波，避免瞬时波动导致频繁切换。

3.4 知识体系：分辨率与帧率的决策流程

下面这张图是我自己总结的决策流程，帮你快速理解整个逻辑：

3.5 实战建议：如何配置分辨率与帧率

最后，给你几个可以直接用的配置建议。嗯，这些都是我踩坑后总结出来的：

1. 不要写死分辨率：用 RTCPeerConnection.getStats() 监听带宽变化，动态调整
2. 帧率上限设为30fps：除非是游戏直播，否则30fps足够
3. 弱网时先降帧率：降到15fps后如果还不行，再降分辨率
4. 屏幕共享用独立策略：静态内容用低帧率（5-10fps），高分辨率（1080p）
5. 避免频繁切换：加一个「冷却期」，比如3秒内不重复触发分辨率变更