想象你要给远方的朋友寄一箱刚从果园摘下的草莓。草莓又大又软又娇贵——视频通话里的每一帧画面就是这样一筐“草莓”，原始数据量惊人，直接塞进网络瞬间就会把道路堵死。这时候，打包师傅（编码器）出场了：他用特殊技巧把草莓“脱水浓缩”成一小块冻干颗粒（压缩码流），到了朋友家，拆包师傅（解码器）再把它还原成草莓的样子。虽然还原出的草莓和原来不完全一样，但依然鲜甜可辨。 这趟快递里有两套主流“包装箱规格”——VP8 和 H.264；而声音这种娇贵货，则要交给专门定制的“防震箱”——Opus。发货前，双方必须先对好箱子规格（SDP 协商）；路况不好时，师傅会适当少装一些货（码率控制）。理解这套“打包与还原”体系，是驾驭 WebRTC 实时通话的关键一步。

岗位关联

掌握音视频编解码机制，你才能在 WebRTC 项目中正确选择编解码器、排查卡顿问题并做出合理的带宽与质量权衡，让实时通信从“能通”走向“好用”。

目录
  1. 可视化演示
  2. 编码基础概念
  3. 视频编码对比
  4. Opus音频编码
  5. 协商策略机制
  6. 码率控制方法
  7. 通话质量优化
  8. 方案选型权衡
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示音视频编解码三大核心：视频编解码对比（VP8开源免费兼容广 vs H.264硬件加速画质高需授权压缩率/延迟/质量/兼容性四维对比）、音频Opus编解码（SILK语音/CELT音乐/混合三模式+6-510kbps码率+26ms超低延迟）、WebRTC协商与码率控制（SDP offer/answer六步协商+ABR自适应码率高/中/低三档）,三模式切换理解编解码全貌。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+C1+'

编码基础概念

快递打包的第一步，是把一筐草莓变成一颗冻干颗粒。原始视频帧是数据洪流——1080p 30fps 的画面每秒约需近 1.2Gbps 带宽，远超普通网络承载。打包师傅（编码器）利用画面中的重复信息，把“大量相同的红色”合并成一句“这里全是红”的简短描述，这份描述叫码流；打包过程叫编码，拆包过程叫解码。

编码器将原始像素帧压缩成二进制码流，解码器反向还原。WebRTC 场景里多数采用有损压缩，它愿意舍弃一些人眼不易察觉的细节来换取小体积。压缩的核心在于“相似性”：同一帧内相邻像素相似（空间冗余），相邻帧之间画面变化小（时间冗余），把相似的东西合并装在一起，箱子自然就小了。

帧被分为三种：I帧是关键帧，打包了完整画面，不需要参考其他帧就能解码；P帧是预测帧，只记录与前一帧的差异；B帧是双向预测帧，同时参考前后帧。I帧是整套货的大箱子，P/B帧是可叠加的补件，体积小但依赖其他帧。分辨率与帧率也直接决定原始数据量：分辨率越高、帧率越高，带宽需求越大。

回到快递比喻：压缩率就是打包师傅的“成箱比”——同样一筐草莓，厉害的师傅能让箱子小一半，还保证草莓不烂。I帧是这箱“完整草莓”，P/B帧是“追加补发”的几粒，画面变化不大时，师傅只补发必要的粒子，快递费自然省下不少。

R=S原始S压缩\displaystyle R = \frac{S_{原始}}{S_{压缩}}
压缩率 R 是一个比值：原始数据量除以压缩后的数据量，数值越高意味着打包师傅的“压缩本领”越强。
  1. 原始体积$S_{原始}$ 表示压缩前视频帧的数据量大小。
    S原始S_{原始}
  2. 压缩体积$S_{压缩}$ 表示经过编码器压缩后码流的大小。
    S压缩S_{压缩}
  3. 计算压缩率两者相除得到压缩率 $R$，这个数越大说明压缩效果越好。
    R=S原始S压缩R = \frac{S_{原始}}{S_{压缩}}

视频编码对比

VP8 像一只“开源木箱”——免费、开放，但坚固程度和通用范围有限；H.264 则像“专利集装箱”——全球港口通用、硬件支持好，但使用可能需要支付专利费。两者都是视频画面的主流“打包方案”，在 WebRTC 世界里经常被放在一起比较。

VP8 由 Google 推出，免专利费，是 WebRTC 规范强制要求支持的视频编码器之一，所有主流浏览器都能解码；H.264（AVC）由 ITU-T 与 ISO/IEC 联合制定，压缩效率略高，且 GPU/NPU 硬件编码器普遍支持，在 Safari 和 iOS 生态中表现尤其流畅。同等画质下，H.264 码率大约节省 10%~20%，但 VP8 的开源免费特性使它成为成本敏感项目的首选。

浏览器兼容性也是选型关键：Chrome、Edge、Firefox 原生支持 VP8；Safari 对 H.264 支持更好；老设备往往只有 H.264 硬件解码器。实践中常把 H.264 设为首选、VP8 作为降级选项。

两种箱子各有千秋：H.264 是标准化集装箱，哪里都能接；VP8 是免费木箱，省了关税。选哪种，要看你的“船”（设备）和“港口”（浏览器）停在哪里。

Bitrate=W×H×FPS×Qfactor\displaystyle Bitrate = W \times H \times FPS \times Q_{factor}
码率估算公式说明：视频每秒需要的比特数，约等于分辨率（宽×高）、帧率与压缩因子的乘积。
  1. 分辨率$W \times H$ 表示视频宽和高的像素个数，像素越多数据量越大。
    W×HW \times H
  2. 帧率$FPS$ 表示每秒显示的画面帧数，帧率越高数据量越大。
    FPSFPS
  3. 压缩因子$Q_{factor}$ 是编码器的量化因子，数值越小压缩越狠、画质损失越多。
    QfactorQ_{factor}
  4. 估算总码率三者相乘得到每秒输出比特数 $Bitrate$，是评估带宽需求的起点。
    Bitrate=W×H×FPS×QfactorBitrate = W \times H \times FPS \times Q_{factor}

Opus音频编码

声音是快递中的“易碎品”，不能像视频那样简单粗暴地压缩。Opus 就是为声音量身定制的“防震泡沫盒”——它由 IETF 标准化，融合了 SILK（语音）和 CELT（音乐）两种技术，既能高效处理说话声，也能还原完整音乐，被 WebRTC 规范强制要求支持。

Opus 支持 6~510 kbps 的比特率范围，以及 8/12/16/24/48kHz 的采样率，覆盖从电话音质到全频带音乐的所有档位。它的算法延迟仅 6.5~22ms，远低于传统音频编码器，非常适合实时对话。带宽不足时，Opus 可以自动降低比特率，甚至切到窄带模式，优先保证人声可懂。

在音频质量评估中，信噪比（SNR）是衡量压缩还原后声音“干净程度”的核心指标：

Opus 就像懂行的老师傅，能根据货物种类自动选防震材料：说人话时用小而紧的包装，放音乐时换大而稳的箱子，送到时字字清晰、声声入耳。

SNR=10×log⁡10(PsignalPnoise)\displaystyle SNR = 10 \times \log_{10} \left( \frac{P_{signal}}{P_{noise}} \right)
信噪比将有用信号功率与噪声功率的比值换算成分贝值，数值越高，声音越干净，就像快递送到时“草莓”完好无损。
  1. 信号功率$P_{signal}$ 表示声音中有用的那部分能量。
    PsignalP_{signal}
  2. 噪声功率$P_{noise}$ 表示压缩和传输过程中引入的失真与干扰。
    PnoiseP_{noise}
  3. 计算比值$\frac{P_{signal}}{P_{noise}}$ 是信噪比的原始比值，越大于 1 说明信号越强。
    PsignalPnoise\frac{P_{signal}}{P_{noise}}
  4. 换算分贝取以 10 为底的对数再乘以 10，得到更符合人耳感知的 dB 值。
    10×log⁡10(PsignalPnoise)10 \times \log_{10} \left( \frac{P_{signal}}{P_{noise}} \right)

协商策略机制

发货前要签“箱子规格合同”。买卖双方各自列出自己能处理的箱子规格，只有两边都有的规格才能用。WebRTC 里这份合同就是 SDP（Session Description Protocol）。

发起方通过 createOffer 生成自己支持的媒体能力清单，接收方通过 createAnswer 回应自己支持的能力；双方取交集后确定最终使用的编解码器及参数，比如编码器类型、profile 级别、采样率、码率上限。若没有交集，就用转码网关（SFU/MCU）中转——先拆包再重新打包成对方能接的箱子。

为避免协商失败，开发者通常会设置优先级和回退机制：例如优先生成 H.264，协商失败时自动降级到 VP8，再不行就退到低分辨率模式，保证通话始终能建立。

这份“合同”确定了整条运输链路中大家都能接受的装货量，是通话稳定性的地基——先谈好箱子，再谈发货量。

Bcall=min⁡(Bsender,Breceiver,Bnetwork)\displaystyle B_{call} = \min(B_{sender}, B_{receiver}, B_{network})
协商出的通话码率上限，受发送端、接收端和网络三者中最弱一方的限制。
  1. 发送能力$B_{sender}$ 表示发送端编码器可支持的码率上限。
    BsenderB_{sender}
  2. 接收能力$B_{receiver}$ 表示接收端解码器可支持的码率上限。
    BreceiverB_{receiver}
  3. 网络带宽$B_{network}$ 表示当前网络路径实际可用的带宽。
    BnetworkB_{network}
  4. 取最小值$B_{call}$ 取三者最小值，确保发送端发了能收、收端能解、网络能扛。
    min⁡(Bsender,Breceiver,Bnetwork)\min(B_{sender}, B_{receiver}, B_{network})

码率控制方法

路况不好时，有经验的司机不会硬装更多货，而是看路况减少每趟的货量。WebRTC 的带宽估计器就扮演着看路况的角色：它持续监测丢包率、RTT（往返时间）和延迟梯度，判断网络是否拥塞，然后把这个信息反馈给编码器。

GCC（Google Congestion Control）是代表性算法：发送端根据反馈估计可用带宽，动态调整目标码率。当带宽下降时，自适应策略会先降编码比特率，还不够就降帧率，最后才降分辨率，优先保证画面流畅不断裂。这就像堵车时先少装货、再放慢发车频率、最后才换小车送。

丢包也是实时通信的家常便饭。NACK 重传能针对性地补发丢失的数据包；FEC 前向纠错则通过额外冗余包来抵抗少量丢包；当画面严重损坏时，接收端还可以请求发送端立刻刷新一个 I 帧来整体重置画面。

打包师傅兼司机，时刻盯着路况调整“车上装多少”，才能既不堵车又不空跑。

Best[t]=α⋅Best[t−1]+(1−α)⋅Bsample[t]\displaystyle B_{est}[t] = \alpha \cdot B_{est}[t-1] + (1-\alpha) \cdot B_{sample}[t]
指数加权移动平均：用历史估计和最新采样共同决定当前带宽估计，避免码率剧烈抖动。
  1. 上次估计$B_{est}[t-1]$ 表示上一时刻的带宽估计值。
    Best[t−1]B_{est}[t-1]
  2. 本次采样$B_{sample}[t]$ 表示当前测得的一次瞬时带宽。
    Bsample[t]B_{sample}[t]
  3. 平滑系数$\alpha$ 是 0~1 之间的权重，$\alpha$ 越大越依赖历史值、反应越平滑。
    α\alpha
  4. 加权更新$B_{est}[t]$ 将新旧信息加权求和，得到兼顾灵敏与平稳的新估计值。
    α⋅Best[t−1]+(1−α)⋅Bsample[t]\alpha \cdot B_{est}[t-1] + (1-\alpha) \cdot B_{sample}[t]

通话质量优化

快递的时效由整条链路决定：从装箱、上路、中转、卸货到上门，每一段都在消耗时间预算。视频通话的端到端延迟同样由采集、编码、传输、解码、渲染五个环节构成，每个环节都要精打细算。

网络不是匀速的，数据包到达时间会忽早忽晚（抖动），这时就需要 JitterBuffer（抖动缓冲）：接收端先缓存一小段数据，再按稳定的节奏播放，抵消抖动和乱序。但缓冲越大延迟越高，所以 JitterBuffer 大小必须动态调整——就像司机在颠簸路上放一层泡沫垫，垫太薄会颠坏，垫太厚又太慢。

音频侧的质量保障还包括回声消除（AEC）、降噪（NR） 和自动增益控制（AGC），它们让说话声在嘈杂环境中依然清晰；视频侧则通过调整 GOP 结构、丢包重传关键帧来降低卡顿。带宽受限时，“保流畅”优先于“保高清”是更务实的取舍。

每个环节都是预算法案里的一笔开销。作为实时通信的调度员，你要知道钱花在哪里，才能把总运费压下来。

Dtotal=Dcapture+Dencode+Dtransmit+Ddecode+Drender\displaystyle D_{total} = D_{capture} + D_{encode} + D_{transmit} + D_{decode} + D_{render}
端到端总延迟等于采集、编码、传输、解码、渲染各环节延迟之和，人眼可明显感知的延迟阈值约为 150ms。
  1. 采集延迟$D_{capture}$ 表示摄像头/麦克风采样和处理所需时间。
    DcaptureD_{capture}
  2. 编码延迟$D_{encode}$ 表示压缩打包消耗的时间。
    DencodeD_{encode}
  3. 传输延迟$D_{transmit}$ 表示网络信道传播和排队的时间。
    DtransmitD_{transmit}
  4. 解码延迟$D_{decode}$ 表示接收端解包还原的耗时。
    DdecodeD_{decode}
  5. 渲染延迟$D_{render}$ 表示屏幕显示或扬声器播放的输出延迟。
    DrenderD_{render}
  6. 总延迟$D_{total}$ 将各环节相加，完整链路的延迟预算。
    Dtotal=Dcapture+Dencode+Dtransmit+Ddecode+DrenderD_{total} = D_{capture} + D_{encode} + D_{transmit} + D_{decode} + D_{render}

方案选型权衡

选物流公司，要比报价、比覆盖网点、比损坏率，还要看未来能否升级。WebRTC 项目的编解码选型也是如此，没有“永远最优”，只有“在约束下最合适”。

成本方面，VP8 + Opus 组合完全开源免专利费，适合预算敏感的产品；兼容性方面，H.264 + Opus 凭借硬件加速和 Safari 生态广受欢迎；场景方面，在线会议、直播推流、语音客服对码率、延迟和清晰度的要求各不相同，需要定制组合。如果大量用户使用 iPhone，H.264 几乎是必选项；如果以 Chromium 系浏览器为主，VP8/VP9 就够用。

服务器转码成本也不可忽视：视频转码极其消耗 CPU 和带宽，设计时要尽量避免不必要的转码。行业趋势上，AV1 编码器正在以更高压缩率吸引眼球，但实时编码的算力开销仍较大，适合作为未来的平滑升级选项。

没有“必选最优”，只有“在约束下选择最合适”。真正优秀的快递调度员，是帮客户在预算、时效与安全之间找到平衡点的人。

S=∑i=1nwi⋅si\displaystyle S = \sum_{i=1}^{n} w_i \cdot s_i
选型综合评分：将成本、兼容、质量、功耗等维度分别打分，再按权重加权求和，分数最高者胜出。
  1. 权重$w_i$ 表示第 $i$ 个维度（成本、兼容、质量、功耗等）在决策中的重要性。
    wiw_i
  2. 得分$s_i$ 表示候选方案在第 $i$ 个维度的评分。
    sis_i
  3. 累加求和$S$ 将各维度加权得分求和，得到可以横向比较的综合总分。
    ∑i=1nwi⋅si\sum_{i=1}^{n} w_i \cdot s_i

AI 应用场景

视频会议的码率自适应调度

阶段：实时音视频传输与网络适配

解决的问题：会议中 Wi-Fi 波动导致画面卡顿。传统固定码率方案在带宽下降时仍发送高清码流，造成大量丢包；利用 WebRTC 带宽估计和自适应码率，网络拥塞时自动把码率从 1.5Mbps 降到 400kbps，保证通话不掉线。

具体案例：某在线教育机构的在线课堂，教师端网络负载高时，画面在 720p/30fps 与 480p/15fps 间自动切换，学生端声音始终保持清晰，会话无中断。

多端直播推流的编解码选型

阶段：编码与转码分发

解决的问题：主播推流时各终端兼容性不一致。统一用 H.264 推流在部分 Android 老设备上解码失败，统一用 VP8 在 iPhone/Safari 上兼容差且缺少硬件加速。通过 SDP 协商与转码网关，让推流端与播放端自动匹配最佳编码组合。

具体案例：一个支持 Web 和移动 Web 的互动直播产品，服务端部署 VP8→H.264 转码网关，检测到 Safari 观众时自动切换流，保证全端可解码。

语音客服通话的 Opus 档位优化

阶段：音频采集与增强

解决的问题：嘈杂环境中客服与用户声音不清。单纯提高比特率会占用更多带宽，且对噪声无济于事。利用 Opus 多模式能力和编码前降噪、自动增益（AGC），在弱网下用最低码率保留人声清晰度。

具体案例：某电话营销质检系统接入 WebRTC 后，在 2G/3G 弱网下将 Opus 码率动态调整为 12kbps，同时启用噪声抑制，通话可懂度显著提升。

Python 演示

python44 行
# -*- coding: utf-8 -*-"""Utility for picking a codec and bitrate given bandwidth.""" CODECS = [    # name, min_bps, max_bps, quality_score, patent_free    ("H264", 100_000, 4_000_000, 9, False),    ("VP8",  80_000,  3_000_000, 8, True),    ("VP9",  60_000,  2_500_000, 9, True),    ("AV1",  50_000,  2_000_000, 10, True),]  def estimate_bitrate(width, height, fps, q_factor=0.5):    """Estimate a raw bitrate before compression."""    return int(width * height * fps * q_factor)  def pick_codec(bandwidth, width, height, fps):    """Choose the best codec and bitrate for the given bandwidth."""    raw = estimate_bitrate(width, height, fps)    candidates = []    for name, lo, hi, score, free in CODECS:        if lo <= bandwidth <= hi:            bitrate = min(raw, hi, int(bandwidth))            candidates.append([name, bitrate, score, free])    if not candidates:        return None, 0, "no suitable codec in this bandwidth"    candidates.sort(key=lambda x: (-x[2], not x[3]))    return candidates[0][0], candidates[0][1], "ok"  def main():    scenarios = [        (800_000, 1280, 720, 30, "weak wifi"),        (2_500_000, 1920, 1080, 30, "good broadband"),        (60_000, 640, 360, 15, "extremely narrow"),    ]    for bw, w, h, fps, label in scenarios:        codec, bps, msg = pick_codec(bw, w, h, fps)        print(f"{label}: {codec} {bps}bps {msg}")  if __name__ == "__main__":    main()
目的：模拟在给定网络带宽、分辨率和帧率下，自动选择最合适的编码器与目标码率。
  1. CODECS = [...]定义编码器配置表，包含名称、带宽区间、质量分和是否免专利费。
  2. def estimate_bitrate(width, height, fps, q_factor=0.5)用分辨率、帧率和 Q 因子估算原始码率。
  3. raw = int(width * height * fps * q_factor)码率随像素数和帧率线性增长，是估算的基准。
  4. if lo <= bandwidth <= hi:检查当前带宽是否落在该编码器的可用区间内。
  5. bitrate = min(raw, hi, int(bandwidth))目标码率取原始需求、编码器上限和网络带宽三者最小值。
  6. candidates.sort(key=lambda x: (-x[2], not x[3]))先按质量分降序，再让开源免专利的编码器优先。
  7. main()模拟弱网、好网、极端窄带三种场景，输出推荐结果。

常见误区

误区H.264 压缩率比 VP8 高，又有硬件编码，任何项目直接选 H.264 就行了，不需要纠结。

正解H.264 在压缩效率和硬件兼容上确实占优，但它存在专利授权成本；VP8 开源免专利费，且是 WebRTC 强制要求支持的基线视频编码器，所有符合规范的浏览器都能解。正确做法是按业务场景组合：把 VP8 作为降级选项，保证任何终端都能接通，同时避免不必要的授权费用。

为何常见：人们容易把“压缩率高”等同于“绝对更好”，忽略了专利、硬件、浏览器支持和开源生态这些现实约束。

误区只要带宽够，码率开到越高，画面就越精细，用户体验就越好。

正解码率存在收益递减曲线。超过编码器能表达的细节上限后，再提高码率画质提升微乎其微，却会占用带宽、增加排队和延迟，甚至引发拥塞。正确做法是基于内容动态调整：静态画面适当降码率，动态场景才提高码率，让每一比特都花在刀刃上。

为何常见：直觉上认为“数据越多信息越多”，但视频压缩中的感知编码告诉我们，人眼注意不到的部分根本不需要传输。

误区把音频编码改成 Opus，声音马上就会变清楚，之前听不清都是因为编码器不行。

正解编码器只负责“压缩还原”。如果麦克风采集环境嘈杂、存在回声，或网络抖动导致乱序丢包，再好的编码器也难保证听感。实际音质是采集、AEC、降噪、抖动缓冲以及编码参数协同的结果，Opus 的优势只是让你在给定带宽下尽可能保留原声。

为何常见：用户习惯把单一环节当“银弹”，忽略了通话质量是一整条链路共同决定的。

误区卡顿就是帧率不够，应该先加帧率，帧率越高越好。

正解帧率提升对动态画面有好处，但对屏幕共享、静态讲解等低动感场景帮助甚微。带宽受限时，优先保分辨率能保留文字和细节清晰度，反而更重要。WebRTC 的自适应策略也往往是先降码率、再降帧率、最后降分辨率，或按内容类型做不同取舍。

为何常见：“流畅=高帧率”是游戏领域的直觉，但实时通信里“看得清”和“不卡顿”需要平衡，不能只押一个维度。

面试题

Q1. WebRTC 强制要求支持哪个视频编码器？

单选题 · easy

  • A.VP8，开放免专利费且为强制基线← 正确答案
  • B.H.265，压缩率虽高但专利费用高
  • C.AV1，最新标准但编码开销较大
  • D.VP9，由 Google 推出的开源编码

答案：A。WebRTC 规范将 VP8 列为必须实现的视频编码器之一，确保不同浏览器之间开箱即通。H.265、AV1、VP9 都是可选编码器，不是强制要求。就像快递站必须配备最基础的纸箱，其余才是可选升级。

Q2. 下列哪个是 WebRTC 强制支持的音频编码器？

单选题 · easy

  • A.Opus，支持宽带且延迟极低← 正确答案
  • B.AAC，iOS 生态广泛使用普及
  • C.G.711，传统电话线中普遍使用
  • D.Speex，过去 VoIP 语音常用格式

答案：A。Opus 是 WebRTC 强制支持的音频编解码器，集合语音与音乐处理能力，延迟最低可达 6.5ms。AAC 与 G.711 可用于特定转码场景，Speex 已基本被 Opus 取代，它们都不是强制要求。快递里的“标准音频盒”，只能是 Opus。

Q3. H.264 相比 VP8 最突出的优势是？

单选题 · mid

  • A.硬件编码加速广泛且 Safari 兼容← 正确答案
  • B.完全开源免费，专利授权成本零
  • C.压缩率极高，可支持 8K 超清视频
  • D.编码速度很快，CPU 占用率最低

答案：A。H.264 在 GPU/NPU 硬件编码支持和 Safari/iOS 生态方面优势明显，因此适合对功耗和兼容性敏感的场景。B 是 VP8 的优势，C 更接近 AV1 的目标，D 不符合事实。就像标准集装箱虽然要交“专利费”，但在全球港口都能吊起来装船。

Q4. I 帧（关键帧）在视频中的核心作用是？

单选题 · mid

  • A.不依赖其他帧即可解码完整画面← 正确答案
  • B.只记录与前一帧的差异像素变化
  • C.压缩率比 B 帧更高且体积更小
  • D.必须出现在视频流的每一帧位置

答案：A。I 帧是完整的“大箱子”，不需要参考任何其他帧就能还原全部画面，因此可作为随机访问点和错误恢复点。B 描述的是 P 帧，C 通常不成立（I 帧体积比 B 帧大很多），D 也不对，I 帧按 GOP 间隔插入即可。

Q5. WebRTC 中 SDP 协商的主要目标是？

单选题 · mid

  • A.找到双方都能支持的编解码器组合← 正确答案
  • B.将视频分辨率提升到最高可支持值
  • C.强制所有终端使用同一种编码格式
  • D.必选 CPU 占用率最低的候选方案

答案：A。Offer/Answer 模型里，双方交换媒体能力清单，取交集确定最终编码器及参数，这正是“发货前对箱子规格”。B、C、D 都试图单方面主导，违背了双方协商的初衷。

Q6. 网络发生拥塞时，WebRTC 自适应码率首选策略是？

单选题 · hard

  • A.降低编码比特率，匹配估计带宽值← 正确答案
  • B.无限重传所有丢失的数据包直至全收
  • C.断开当前连接，切换至其他网络通道
  • D.同时运行多个编码器并选择最好的

答案：A。带宽估计器（如 GCC）通过丢包率与延迟判断可用带宽，发送端据此降低目标码率，从源头减少数据注入。无限重传会加剧拥塞，断开切换和多重编码也不是常规首选。这就像拥堵时少装货，而不是原地发更多车。

Q7. 关于 Opus 的描述，正确的是？

单选题 · hard

  • A.支持 6~510kbps，延迟极低且双模式← 正确答案
  • B.仅支持 8kHz 采样率，只面向电话语音
  • C.延迟高于 200ms，不适合实时通话
  • D.必须配合 H.264 使用，不能单独出现

答案：A。Opus 支持语音与音乐双模式，比特率 6~510kbps，算法延迟 6.5ms~22ms，非常适合实时通信。B、C、D 都与 Opus 的真实规格相反。它就像为声音打造的“定制防震箱”，能小能大、又能快。

Q8. 下列哪些属于 WebRTC 中应对丢包的有效手段？

多选题 · mid

  • A.使用 NACK 机制重传丢失数据包← 正确答案
  • B.增加 FEC 前向纠错冗余数据包← 正确答案
  • C.请求关键帧刷新被破坏的画面← 正确答案
  • D.强制把音频采样率降到 8kHz 以下

答案：ABC。NACK 重传、FEC 冗余和关键帧请求是 WebRTC 三种常见的丢包恢复手段。FEC 可以预置冗余对抗随机丢包，NACK 适合重传关键数据，I 帧请求用于严重损坏时的画面重置。D 只针对音频编码策略，不是通用丢包方案。

Q9. 关于 VP8 编码器，以下说法正确的有？

多选题 · mid

  • A.由 Google 主导开发并开放免专利费← 正确答案
  • B.WebRTC 规范中要求浏览器必须支持← 正确答案
  • C.在开源生态中广泛集成无需授权费← 正确答案
  • D.压缩效率显著高于 H.264 最高档位

答案：ABC。VP8 开源免专利费，并且是 WebRTC 强制支持的两个视频编码器之一（与 H.264 并存），Chromium/Firefox 生态广泛集成。D 错误：VP8 的压缩效率通常略低于 H.264 同档位，而非显著更高。VP8 是“免费木箱”，能到许多港口，但不一定比“专利集装箱”装得更巧。

Q10. 在音视频通话链路中，下列哪些环节会贡献端到端延迟？

多选题 · hard

  • A.摄像头采集与麦克风采样阶段← 正确答案
  • B.编码器压缩打包所需的时间← 正确答案
  • C.解码还原与屏幕渲染输出过程← 正确答案
  • D.网线长度产生的电流传导热损耗

答案：ABC。端到端延迟由采集、编码、网络传输、解码、渲染共同构成。D 是干扰项：电信号传播延迟确实存在，但“电流传导热损耗”与业务延迟无关。要压低延迟，就得像调度员一样严格压缩每一段运输时间。