摘要
隨著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最佳實踐內容，
音視頻場景解決方案分享，更多詳情可搜索官網（https://zegoguanwang.datasink.sensorsdata.cn/t/pB）轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/548352.html
標籤：其他
下一篇：簡述幾種常用的排序演算法