摘要
隨著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最佳實踐內容。