《WebRTC音视频实时互动技术原理、实战与源码分析》书问题讨论区

此版块是《WebRTC音视频实时互动技术原理、实战与源码分析》一书的问题讨论区。在这里,你可以针对于书中的任何问题向作者提问。

===================================================

《WebRTC音视频实时互动技术原理、实战与源码分析》勘误表

勘误一

a. P3, 1.2节,第三段中的 AVI 应为 AV1.
b. P11, 2.1.3节,第一段中的 AVI 应为 AV1
c. P22,3.2.2 节,第三段中的所有 AVI 应为 AV1
d. P261, 13.5节,第二段中的 AVI 应为 AV1

勘误二

P15,第三段应为:

“从上面的描述中你可以看到,在 WebRTC 架构的四层中,最复杂、最核心的是第三层,即 引擎层,因此,这里我再对引擎层内部的关系做下简要介绍。引擎层包括三部分内容,分别是: 音频引擎、视频引擎以及网络传输。其中 音频引擎 和视频引擎是相对比较独立的。不过,它们 都需要与网络传输层(transport)打交道。也就是说,它们都需要将自己产生的数据通过网络 传输层发送出去;同时,也需要通过网络传输层接收其它端发过来的数据。此外,

音频引擎与 视频引擎由于要进行音视频同步的原因,所以它们之间也存在着关联关系。”

勘误三

P98,表6.2各NAT之间可穿越表应为:

勘误四

P103,6.4.2小节倒数第二应为:

“因为主机 A 拿到了主机 B 的 Relay 类型的 Candidate,即 RelayB,所以主机 A 可以直接将音视频数据发向 RelayB。TurnServer 从 RelayB 接收到数据后,会将数据 打包成 TURN 消息,经 3478 端口发往主机 B 。主机 B 收数据后,再利用 TurnClient 模块将数据从 TURN 消息中取出,交给其它模块做进一步处理; 同理,主机 B 与主机 A 的操作流程是一样的。TurnServer 从 RelayA 收到数据后,将其打包成 TURN 消息, 也要经过 3478 端口转发给主机 A 。”

勘误五

P114,第一段应为:

“程, 默认情况下 WebRTC 会将 VP8/H264 等编码器编码后的数据再交由 red 模块编码,生成带一些冗余信息的数据包,这样当传输中某个包丢了,就可以通过其他包将其恢复回来,而不用重传丢失的包。了解了上面这些内容后,第 16~18 行代码的含义应该就清楚了,即 PT 值为 124 表示需要使用 red 对之前编码好的数据再进行 red 处理,119 是 PT=124 重传数据 包的 PayloadType。如果用 Wireshark 等抓包工具抓取 WebRTC 媒体数据包时会发现它们都 是 red 包,而在 red 包里装的是 VP8/H264 编码的数据。”

勘误六

P124,代码行号69,内容应为:

69 使用Opus时,每个音频帧的最小间隔为10毫秒,使用带内FEC
70 a=fmtp:111 minptime=10;useinbandfec=1

勘误七

P168,图9.10有误,正确的图如下所示:

勘误八

P175,10.1 节的第一段应为:

“在 WebRTC 中包含多种拥塞控制算法,有 GCC、BBR和 PCC。GCC 根据其实现又可细分为基于发送端的拥塞控制算法 Transport-CC4和基于 接收端 的拥塞控制算法 Goog-REMB。”

买了 Kindle 版本,着急看,一晚上刷了一大半,点个赞

1赞

谢谢