Page 286 - Web性能权威指南

各种目的地。这样，我们完成了实时电话会议应用的一半，剩下的就是把数据传输
给另一端了！

要了解 Media Capture and Streams 还提供了哪些 API，请参考 W3C 官方标
准：http://www.w3.org/TR/mediacapture-streams/。

音频（Opus）与视频（VP8）比特率

在通过浏览器请求音频和视频时，要注意流的大小和品质。虽然硬件有时候可以
捕获到高质量的流，但 CPU 和带宽必须跟得上！当前的 WebRTC 实现使用 Opus
和 VP8 编解码器：
• Opus 编解码器用于音频，支持固定和可变的比特率编码，适合的带宽范围为
6~510 Kbit/s。这个编解码器可以无缝切换，以适应不同的带宽。
• VP8 编解码器用于视频编码，要求带宽为 100~2000+ Kbit/s，比特率取决于
流的品质：
Œ 720p，30 FPS：1.0~2.0 Mbit/s
Œ 360p，30 FPS：0.5~1.0 Mbit/s
Œ 180p，30 FPS：0.1~0.5 Mbit/s

因此，单方高清音视频流最多需要 2.5 Mbit/s 以上的带宽。如果是多方视频通话，
那么考虑到要额外占用带宽、CPU 和 GPU 及内存资源，就必须降低品质。

18.3 实时网络传输

实时通信讲究的就是及时、当下。因此，处理音频和视频流的应用一定要补偿间歇
性的丢包：音频和视频编解码器可以填充小的数据空白，通常对输出品质的影响也
很小。类似地，应用必须实现自己的逻辑，以便因传输其他应用数据而丢包或延迟
时快速恢复。及时和低延迟比可靠更重要。

音频和视频流还要适应人类大脑的特点。换句话说，我们的大脑非常擅长
填充空白，但对延迟非常敏感。忽长忽短的几次延迟就会让人觉得“肯定
是哪里出问题了”，而从中间删除一些采样数据，却很可能不会引起我们大
脑的注意！

正因为及时性的要求高于可靠性，所以 UDP 协议才更适合用于传输实时数据。TCP
适合传输可靠的、有序的数据流：如果中间有丢包，TCP 就会缓冲后续所有包，等
待重传，然后再严格按照次序交给应用。相对来说，UDP 则提供下列“不服务”：

276 ｜ 第 18 章