摘要
随着 GPT- 4 的公布，AI 的风越吹越旺。GPT- 4 能够答复问题，能够写作，甚至能够基于一张草图生成 html 代码搭建一个网站。即构社区的一位开发者 @倪同学就基于目前在钻研的 WebRTC QOS 技术点对 GPT-3.5 跟 GPT- 4 进行一场试验，ChatGPT 会取代程序员还是成为最强辅助？
以下为 @倪同学的博文。
ChatGPT 取代程序员还是给程序员加 Buff？
这两周，AI 新闻一个接着一个，3 月 23 日，Google 凋谢了内测已久的 AI 对话服务 Bard，Google 强调，这是一款定位为用户提供创意之源的产品，可生成写作草稿或生存中的聊天机器人。早在一周前 3 月 15 日凌晨，OpenAi 距公布 GPT-3.5 后四个月公布了升级版模型 GPT-4，据发布会说，GPT- 4 可反对图片输出，角色扮演，写作能力更强了。紧接着 3 月 16 日百度公布了文心一言，一共有五大性能：文学创作、商业文案创作、数理逻辑推算、中文了解、多模态生成。
随着近日各大厂商 AI 产品的接连公布，AI 取代人工 这个话题继续在发酵。AI 大幅解放人的生产力或是将冲击一大批职业？
博主近期在输入 WebRTC 相干的技术博客，不如向 AI 发问看他有什么见解。
和大部分人一样，博主都还没拿到 Bard 跟文心一言的内测资格。得悉 NewBing 用的是 GPT- 4 的模型，上面就着WebRTC 通过哪些 QOS 技术晋升音视频通话质量，向 GPT-3.5 和 Newbing（GPT-4）别离发问，看看他们的答案有何差别。
如下图，技术科普类问题都难不倒 GPT-3.5 和 GPT-4，我就该问题持续深挖让它们举实例阐明：
NewBing(GPT-4)
GPT-3.5 给出的后果
NewBing(GPT-4)间接给出了具体操作实例
GPT-3.5 给出的后果（有些空洞）
GPT- 4 和 GPT-3.5 比照论断
通过试验，咱们比拟了同一问题两个版本的答复。在一般的文本处理当中，GPT- 4 和 GPT-3.5 的区别可能比拟小，然而当问题足够具体和简单时，GPT- 4 就会比 GPT-3.5 更精准、更有创意，而且可能解决用户更轻微的指令。
当然，本篇内容不是要探讨 GPT-3.5 跟 GPT- 4 的具体差异，而是程序员如何利用 ChatGPT 晋升工作效率，加上最强 Buff。以下我将以集体开发教训为音视频开发者分享《WebRTC 的 QOS 如何晋升音视频品质》。
WebRTC 技术概述
WebRTC 通过一系列的 QOS 技术来晋升音视频通话质量: 抗丢包策略(NACK、FEC), 拥塞控制策略(TWCC/REMB), SVC 或多视轨, 视频品质自适应策略，Pacer、JitterBuffer 等.
总体 QOS 架构如下图所示：
图 1
1 丢包复原策略
1.1 NACK
NACK(Negative Acknowledgment)相较于 ACK 是通过 ” 非达到确认 ” 进行选择性重传的机制。基本原理是发送端对数据进行缓存，接收端通过达到包连续性检测丢包，联合 rtt 和乱序状况在适合的机会向发送端发动重传申请。
图 2
如图所示,Receiver 在收到报文 4 之后发现报文 2、3 未达到，临时将报文 2、3 放入失落 nack 列表。在超过肯定乱序阈值(通过乱序直方图计算失去，假如这里是 2，那么收到包 4 可认为包 2 失落)，或者超过肯定抖动工夫(依据 rtt 计算)，向 Sender 申请重传失落的报文 2、3。Receiver 的申请通过 RTP FB 发送给 Sender, 具体 NACK 申请格局参考 RFC4585。Sender 在收到 NACK 申请后从新发送报文 2、3。
值得注意的是，NACK 策略丢包复原成果取决于重传申请机会。一是 rtt 的计算(webrtc 默认 rtt 是 100ms)，一是乱序阈值计算。重传申请节奏管制不好容易造成重传风暴，减轻拥塞导致拉流呈现卡顿。
参考：https://www.rfc-editor.org/rfc/rfc4585.html#page-34
1.2 FEC
FEC(Forward Error Correction), 前向纠错, 在数据传输和存储中广泛用于数据纠错。WebRTC 中也应用了该技术进行丢包复原。
webrtc 实现该冗余性能，有三种形式：
1.2.1、RED
将后面的报文间接打入到新包外面，在接收端解析主包和冗余包。
图 3
如图，前面的报文间接蕴含后面报文，所以当其中某个报文失落了，能够通过其相邻报文间接复原。这种形式毛病是抗间断丢包成果差，然而实现简略。
Opus In-band FEC 正是应用这种形式进行纠错：将重要信息以较低的比特率再次编码之后增加到后续数据包中，opsu 解码器依据收包状况决定是否利用以后包携带的冗余包进行丢包复原。
Opus In-band FEC 具体参考：https://datatracker.ietf.org/doc/html/rfc6716#section-2.1.7
RED 具体介绍参考：https://www.rfc-editor.org/rfc/rfc2198.html
1.2.2、ULPFEC
在多个数据包之间应用 XOR 来生成此冗余信息，并可能在须要时在接管方复原失落的数据包。ULPFEC 可能通过抉择受爱护的字节数并利用 XOR 的先前数据包的数量，为不同的数据包提供不同级别的爱护。
图 4
如图，FEC packet 1 爱护 L0 级报文 A、B。FEC packet 2 及爱护 L0 级的 A、B, 也爱护 L1 级报文 C、D。
参考：https://www.rfc-editor.org/rfc/rfc5109.html
1.2.3、FLEXFEC
较 ULPFEC，FLEXFEC 能够灵便抉择 1D 行异或、列异或以及 2D 行列异或，减少网络抗丢包能力。
1-D 行异或纠错
图 5
1-D 列异或纠错
图 6
2-D 行列异或纠错
图 7
FLEXFEC 尽管相比后面两个有更强的恢复能力，行列交织丢包比方图 7 中 (1、2、5、6) 失落就会呈现无奈纠错的状况。
WebRTC 用到 FEC 策略整体丢包恢复能力都偏弱，业界广泛利用 Reed-Solomon FEC 进行丢包复原，Reed-Solomon FEC(K + N : K 个数据包 N 个 FEC 包)能够真正复原分组内任意 <=N 个丢包。
FLEXFEC 具体实现能够参考：https://www.rfc-editor.org/rfc/rfc8627.html
2 带宽评估及码率管制
2.1 REMB-GCC
图 8
图 8 是 REMB-GCC 架构图，根本思维是通过接收端评估带宽，而后通过 RTCP REMB 将带宽反馈给发送端。发送端联合丢包率计算一个带宽后果 As, 和 RMEB 的后果 Ar, 取 min(As, Ar)作为最终带宽后果。
2.2 SendSide BWE
图 9
跟REMB-GCC 相比，TFB-GCC 次要区别在于大部分带宽计算都转移到发端计算，滤波器的实现不再用 Kalman 滤波 而是变成TrendLine 滤波器。
发送端发送的包需在扩大头带：Transport-wide sequence number.
接收端定期发送 Transport-wide feedback 报文，告诉发送端和接收端接管报文的相干信息，包含报文达到工夫、报文达到工夫、报文格式等信息。发送端收到 Transport-wide feedback 报文之后，依据报文携带的信息进行提早滤波计算(Trandline).
Transport-wide feedback 报文格式参考：https://datatracker.ietf.org/doc/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
2.3 速率管制
图 10
图 11
依据过载检测器产生的信号 s，驱动如图 10 所示的无限状态机来调整码率。
GCC 算法原理具体参考：https://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf
3 SVC 、多视轨
3.1 SVC
SVC (Scalable Video Coding，可适性视频编码或可分级视频编码) 是传统 H.264/MPEG-4 AVC 编码的延长，可晋升更大的编码弹性，并具备工夫可适性 (Temporal Scalability)、空间可适性 (Spatial Scalability) 及品质可适性 (SNR/Quality/Fidelity Scalability) 三大个性。
WebRTC 中 h264 不反对 svc 编码，Vp8 仅反对 Temporal Scalability, VP9 和 AV1 反对工夫可适性 (Temporal Scalability)、空间可适性 (Spatial Scalability)。
图 12
下面是工夫可适应示意图。假如图例中显示的图层以 30 fps 的帧速率显示。如果咱们移除所有 L2 层的图片，剩下层（L0 和 L1）依然能够胜利解码，并且产生一个 15fps 的视频。如果咱们进一步删除所有的 L1 图像，那么剩下的 L0 层仍然能够被解码并产生一个 7.5fps 的视频, 所以即使是呈现丢包，相比不可分级编码可显著晋升弱网视频晦涩度。
图 13
如图 12，L0 基层为分辨率最小编码数据，级别越高，分辨率越高。当理论利用中须要较低分辨率时，只需抛弃高 Level 层级数据进行解码。
针对不同的带宽条件用户和以及不同设施性能的用户能够灵便调整分辨。
SVC 扩大参考：http://ip.hhi.de/imagecom_G1/assets/pdfs/Overview_SVC_IEEE07.pdf
SVC 与 H264 联合参考：https://www.itu.int/rec/T-REC-H.264-201704-I
3.2 多视轨
目前支流浏览器都反对 unified-plan sdp, 咱们能够在 sdp 协商的时候增加多个视轨，业务上比拟常见的就是增加两条视轨(相似于 SVC 的 Spatial Scalability)，复用雷同 DTLS 传输通道。
图 14
图 12 典型利用 WebRTC 反对多视轨个性编码一大一小两条流的出帧示意图。
反对多视轨(大小流) 能够让接收端在上行带宽受限的状况下动静切换到能够反对的分辨率，晋升弱网体验。
多视轨 (大小流) 在对网络丢包及带宽受限状况的适应不如 SVC 灵便，然而多视轨实现简略，编码、解码性能耗费较低，在理论的业务场景中失去广泛应用。
多视轨须要反对 Unified Plan SDP 协商, 参考 WebRTC 相干阐明：https://webrtc.github.io/webrtc-org/web-apis/chrome/unified-plan/
4 视频品质调整策略
在网络传输品质变差 (上行带宽有余)、CPU 占有率过高，编码器编码品质 QP 值过大等状况下，WebRTC 会通过降品质来保障视频通话。降品质策略次要分降帧率(即清晰优先模式) 和降分辨率(即晦涩优先模式)，通过 MediaStreamTrack Content Hints 来设置。
清晰优先模式 WebRTC 在编码的时候更重视视频细节，在呈现上述情况须要降品质时，会通过升高帧率、放弃分辨率不变来保障拉流用户的主观感触。对于推流端做屏幕分享内容是 PPT 或者拉流用户大屏显示的业务场景尤为重要。
晦涩优先模式 推流端在须要降品质的时候优先升高分辨率、放弃肯定的帧率来保障拉流用户的晦涩体验。
在带宽或 CPU 资源等不再受限时，WebRTC 会依据降品质偏好设置逆向晋升视频品质。
使用者应该依据本人的业务场景进行适当设置，能力在极其状况下保障主观体验不至于太差。
5 Pacer
WebRTC 的 Pacer 模块次要是让须要发送的包依据评估的网络带宽尽量平均的散布在每个发送工夫窗口收回，起到平滑发包、防止网络拥塞的作用。
假如有一条 5Mbps 和 30fps 的视频流。在现实状况下，每个帧大小约为 21kB，打包成 18 个 RTP 数据包。依照一秒工夫窗口统计的均匀比特率是 5Mbps，但在更短的工夫范畴内，它能够被视为每 33 毫秒突发 167Mbps。此外，视频编码器在忽然挪动的状况下会超过指标帧率，尤其是在解决屏幕共享时，帧比指标尺寸大 10 倍甚至 100 倍很常见。这些数据包如果编码实现马上发进来会导致几个问题: 网络拥塞、缓冲区收缩、甚至数据包失落。大多数会话都有不止一条媒体流，可能同时蕴含音频流、视频流、数据流。如果你一次性将一个帧放在一条传输通道发送，这些数据包须要 100 毫秒能力收回，这可能阻止了任何音频数据包及时发送进来。Pacer 通过有一个缓冲区来解决这个问题。媒体包在其中排队，而后应用漏桶算法将它们调整到网络上。缓冲区蕴含所有媒体轨道的独立 fifo 流，例如 音频能够优先于视频 – 能够以循环形式发送雷同优先级的流，以防止任何一个流阻塞其余流。
图 15
6 JitterBuffer
图 16
WebRTC 接收端收到 RTP 包后，放到 PacketBuffer 进行缓存和排序。如上图，在收到 Mark(帧完结)标记之后，从后往前开始组帧。组完一帧会放到该帧所在 GOP 的缓存外面，依据帧间参考程序进行调整，当帧间参考关系建设好之后就会放到解码器进行解码。能够认为 Jitter 次要先后做包排序、帧排序、GOP 排序。之所以要进行着一系工作是因为网络自身存在肯定的抖动、甚至有丢包，如果有丢包还得等丢包复原能力残缺组帧，所以导致帧达到工夫跟发送工夫存在肯定抖动。Jitter buffer 的存在就很好的解决这个问题，可能在拉流端看待解码数据进行平滑解决，保障咱们渲染进去视频是平滑、晦涩的。
7 关键帧申请
视频流通常是以 1 个关键帧 + N 个增量帧的形式发送，这些增量帧依赖于先前的帧进行解码和显示。如果因为一些起因导致 sps/pps 失落、组包谬误等，如果不采取任何补救措施，就很难持续解码视频流，视频就会卡主, 直到下个关键帧。很多时候为了编码稳固 GOP 设置很大，这个时候意味着长时间卡顿或者黑屏。
图 17
如图接收端因为丢包不能复原导致 Frame 9 组帧失败，前面即便能组帧胜利也无奈解码，此时须要从发送端申请一个 I 帧解码刷新以后视频流。
WebRTC 通过 RTCP 报文向发送端申请发送关键帧，关键帧申请 RTCP 报文格式比较简单，在 RFC4585（RTP/AVPF）以及 RFC5104（AVPF）规定了两种不同的关键帧申请报文格式：Picture Loss Indication (PLI)、Full Intra Request (FIR)。从目前的实现看 WebRTC 在收到 PLI 或者 FIR 之后，都是让编码器编码输入关键帧，而后发送给接收端。
PLI 报文格式参考：https://www.rfc-editor.org/rfc/rfc4585.html#page-36
FIR 参考：https://www.rfc-editor.org/rfc/rfc5104.html
QOS 技术总结：
本文简略介绍了 WebRTC 中所应用到的 Qos 技术，这些技术从不同的角度去晋升 Qos 品质。包含通过 NACK、FEC 技术对丢包进行复原，解决丢包导致的音、视频卡顿。通过 带宽评估和拥塞管制 技术调整编码和发送码率来主动适应网络带宽的变动状况。通过 SVC、多视轨技术保障不同网络品质的拉流的用户差别的视频品质。而 Pacer、JitterBuffer 别离在发送端和接收端晋升音视频的平滑、晦涩度。关键帧申请 对极其网络抖动之后的疾速视频复原起了重要作用。WebRTC 利用这些技术协同作用，晋升整体的 Qos 品质，须要理解技术细节最好的形式还是去浏览 WebRTC 源码。
WebRTC 的 Qos 技术对晋升整体音视频品质效果显著、但 WebRTC 的这些技术还是存在有很多能够优化的中央。音视频厂商 ZEGO 即构自研的 WebRTC 网关对这些策略都做了肯定的优化：包含自研带宽评估算法、NACK 算法、大小流等。
所以，如果你的业务须要一款稳固牢靠的音视频服务，能够试试即构实时音视频 RTC 服务。
点击跳转 ZEGO 即构实时音视频服务理解更多 WebRTC 最佳实际内容。