利用多種演演算法和策略進行網路傳輸控制，最大限度滿足弱網場景下的音視訊使用者體驗。

良逸｜技術作者

01 什麼是QoS？音視訊通訊QoS是哪一類？

QoS（Quality of Service）是服務質量的縮寫，指一個網路能夠利用各種基礎技術，為指定的網路通訊提供更好的服務能力，是網路的一種安全機制，是用來解決網路延遲和阻塞等問題的一種技術，包括流分類、流量監管、流量整形、介面限速、擁塞管理、擁塞避免等。通常QoS提供以下三種服務模型：Best-Effort service（盡力而為服務模型），Integrated service（綜合服務模型，簡稱Int-Serv），Differentiated service（區分服務模型，簡稱Diff-Serv）。

上面的這些描述，都指的是傳統的、原始的QoS的定義和技術棧，其來源於早期網際網路的網路傳輸裝置間的質量保證體系。而本文要討論的QoS，是在一個完全不同層次的質量保證體系，我們先看一下這兩個層次QoS的關係。

視訊會議公司Polycom的H323白皮書QoE and QoS-IP Video Conferencing裡提到，QoS分為兩類，一類是基於網路的服務質量（Network-Based QoS）NQoS，一類是基於應用的服務質量（Application-Based QoS）AQoS。 下圖展示了兩種QoS不同的作用使用場景和不同的質量保障層次。

NQoS是網路傳輸裝置間的基礎通訊質量保障能力，是這類通訊裝置間特有的一組質量保障協定，這些裝置有路由器、交換機、閘道器等。而AQoS則是應用程式內部，根據應用對應的終端裝置型別、業務場景、資料流型別所實現的，在不同網路狀態下盡力而為地保障使用者體驗的能力。

雖然NQoS和AQoS都會對終端使用者的體驗有決定性影響，但如果將應用場景限定在音視訊通訊領域，則AQoS這種基於應用的QoS就極為重要了，因為NQoS作為網際網路的基礎設施的一部分，為兼顧各種使用場景，更多的是一種「普適」的傳輸質量保障技術，很難對特定領域做太多的針對性優化，所以本文重點討論的音視訊通訊QoS其實是一類基於應用的AQoS，是針對音視訊通訊領域的相關應用程式的傳輸質量保障技術。

02 音視訊通訊QOS背景

個人理解，音視訊通訊QoS是「利用多種演演算法和策略進行網路傳輸控制，最大限度滿足弱網場景下的音視訊使用者體驗的能力」，如下圖所示：

資料從音視訊媒體生產環節，經過各種弱網網路條件的中間傳輸環節，到音視訊媒體的消費環節，形成最終的使用者體驗。QoS通過各種策略和演演算法，對端到端全鏈路進行控制，最終讓使用者能夠獲得最佳體驗。

03 音視訊通訊QoS面臨的挑戰

網路場景

各種網路條件非常複雜：網路的種類和組合多樣，特別是在最後一公里，有雙絞線、同軸電纜、光纖、WIFI、4G、5G等；即使同樣的網路連結，又會隨著不同的場景產生變化，比如4G，5G，WIFI這種無線訊號，會隨著位置的變化訊號強弱也飄忽不定，會出現4G、5G、WIFI訊號的切換。即使是有線網路，也會因為鏈路上多種App共用、多個使用者共用，出現競爭擁塞等問題。

業務場景

各種音視訊通訊業務場景多樣，例如，點播、直播(RTMP/RTS)、會議、互動娛樂、線上教育、IOT、雲遊戲、雲渲染、雲桌面、遠端醫療等等。不同的業務場景，又有不同的體驗需求，例如，直播場景注重流暢的體驗，而對音視訊互動時效性，要求並不是太高；會議場景則對溝通交流的實時性要求會比較高，而對音視訊畫質的要求沒有那麼高；但對雲遊戲等場景，則要求極低的延時，同時要保證極高的清晰度。

使用者體驗

如下圖所示，音視訊通訊場景，使用者體驗主要從清晰度、流暢性、實時性三個方面來衡量。

清晰度，是使用者感受到的視訊畫面清晰還是模糊，一般情況下解析度越高越清晰，越清晰的畫面包含的資訊量就越多，傳輸時佔用的流量就多；

流暢性，是使用者感受到的視訊畫面運動起來的時候是順暢還是卡頓，一般情況每秒鐘看到的畫面數量越多越流暢，同樣每秒畫面數量越多，傳輸時佔用的流量也越多；

實時性，是音視訊資訊從其發生到被遠端使用者感受到所需要的時間，時間越短實時性越好，實時性越好對傳輸速度的要求就越高。

前面說過，不同的業務場景對清晰度、流暢性、實時性三者的要求有著不同的側重，然而隨著音視訊通訊業務場景的不斷髮展，越來越多極低延時和可沉浸的場景不斷湧現，使用者對音視訊體驗，可以說是既要又要還要，而且要求越來越高，留給技術人輾轉騰挪的空間越來越小。在這種趨勢下，對音視訊傳輸QOS的技術要求也變得越來越高。

從底層協定來看，基於TCP傳輸的音視訊通訊，例如直播、點播等，一般都延時比較大，而且因為資料都封裝在TCP協定內部，依靠TCP本身的抗弱網機制來保證可靠性，應用層很難有機會參與其中的控制和優化，只適用於延時容忍度較大的場景。對於延時容忍度較小的場景，基本都是基於UDP的，大家都知道UDP傳輸的特徵就是可靠性差，需要應用層通過各種抗弱網技術手段來保證資料傳輸的可靠性，QoS技術就有了大顯身手的機會。

本文主要討論基於UDP傳輸的，最具挑戰性、技術最複雜的音視訊短延時通訊QoS技術，包括實時音視訊通訊RTC場景和低延時直播RTS場景。

04 弱網的分類

假如我們的傳輸網路非常的完美，有足夠大的頻寬、有足夠低的延時、有足夠高的保障，那我們就能很容易地實現像真人一樣的面對面交流，我們也不需要QoS技術，不需要編解碼，只要把音視訊採集下來，再瞬間傳送到對端播放出來就可以了，人與人的遠端互動將變得十分美好。

然而，現實離這種美好相去甚遠，現代的音視訊通訊是建立在網際網路的基礎設施之上的一類應用，這讓網際網路的傳輸質量，變成了音視訊通訊傳輸質量不可能突破的天花板。眾所周知，網際網路的傳輸是複雜的、昂貴的、不可靠的、不穩定的，沒有辦法搞清楚所有的傳輸環節的狀況，我們需要對這些問題進行抽象分類，以便於更好地針對不同的場景進行有效應對，竭盡所能的保證使用者的音視訊體驗不受太大的影響。

我們一般把網路傳輸質量不符合預期的場景叫弱網場景，弱網分成擁塞、丟包、延時、抖動、亂序、誤碼等。擁塞，是可用頻寬不足的表現，如同高速堵車；丟包，是資料在傳輸過程中丟了，不知去向，如同快遞丟失包裹；延 時，一般是中轉太多或者擁塞排隊導致時效性變差，如同轉機或堵車；抖動，是資料傳輸間隔忽大忽小，如果不做處理，可能會導致音視訊忽快忽慢；亂序，是後發先至，先發出去的資料比後發出去的資料到的還晚，如果不處理，可能會導致音視訊的回放；誤碼，是傳輸過程中資料錯誤，由於傳輸層會有校驗、修正、重傳，所以應用層一般都無感知、無需特別處理。

上圖用管道灌水比較形象的把幾種弱網場景做了說明：左邊是流量生產側，右邊是流量消費側，管道的長度是鏈路的基本延時；管道傳輸過程中會產生一些錯誤和丟包；當管道由寬變窄而且流量超過管道的寬度，就會產生頻寬擁塞；當擁塞產生時會出現流量排隊的情況，部分流量會被放到快取佇列，相應地產生佇列延時；當快取佇列滿了之後，會產生佇列溢位，溢位的流量就對應了溢位丟包；鏈路資料傳輸過程中會有一些波動和訊號干擾，導致資料的傳輸速率不是恆定的，最後收到的資料變得忽快忽慢，我們將其歸類為鏈路抖動。現實中，這些不同的弱網型別往往是混合在一起同時出現，對其做不同的分類，可以方便我們從技術上對其各個擊破。

05 音視訊通訊QoS技術體系

QoS技術分類

音視訊通訊QoS技術和策略就是為了對抗上述弱網場景而誕生的，其目的就是盡最大可能消除因為網路變差給使用者帶來的體驗衰退，所以對應上面講的不同弱網場景的分類，用到的QoS技術也被分成了幾大類：擁塞控制、信源控制、抗丟包、抗抖動，每一類技術都包含很多的不同的技術點和技術細節，後面再來展開。

擁塞控制，是網路狀況探測和資料傳送方式的決策中心，是整個傳送側QoS技術的核心，是傳輸控制的大腦；

信源控制，是在擁塞控制的決策下，控制音視訊信源產生的方式，控制信源的位元速率，來適應探測出來的網路狀況，實現抗擁塞的目的；

抗丟包，是在網路有丟包的場景下，對信源資料增加冗餘資訊，達到部分資訊被丟失的場景，也能夠完整地恢復出原有資料；

抗抖動，是在網路延時有波動、資料時快時慢、時有時無的情況下，增加一部分延時，對資料進行緩衝，讓使用者體驗更流暢，不至於卡頓；

上面也說明了不同類的QoS技術對應可以解決不同的使用者體驗問題，可以看出都是圍繞流暢性、清晰度、實時性這三點來改善的。擁塞控制是總指揮，很多時候對整個鏈路的體驗起決定性作用，信源控制可以提升流暢性和清晰度方面的體驗，抗丟包和抗抖動可以提升流暢性和實時性方面的體驗。

QoS在音視訊通訊流程中的位置

我們知道音視訊通訊是端到端的全鏈路通訊，其涉及的技術領域非常廣泛，跨度非常大、非常複雜。比如，使用者端側就包含了市面上能見到的Windows、MacOS、iOS、Andorid四個平臺的所有終端的適配、相容、互通，甚至要跟瀏覽器進行互聯互通，同一個平臺每款不同的裝置也存在較大的差異，很多時候需要單獨的適配。還有音訊3A（AEC、AGC、ANS）、音訊編解碼（Opus、AAC）、視訊編解碼（H264、H265、AV1）等任何一個領域展開都是非常複雜的技術棧。而云端的各種伺服器也是實現互聯互通不可缺少的環節，包括信令伺服器、媒體伺服器、混流、轉碼、錄製、節點部署、排程選路、負載均衡等等，每個節點、每種服務都是複雜的存在。

在如此複雜的音視訊通訊技術鏈路中，QoS技術也只是其中的一個比較窄的領域，但也是不可或缺的，對線上的音視訊通訊的可用性有著決定性意義。QoS技術看起來也是音視訊通訊領域為數不多的全鏈路的技術，它端到端、全鏈路控制著媒體傳輸、媒體編解碼的各個環節，以至於從事QoS技術的相關工程師需要對使用者端和伺服器的全鏈路的技術都要有一定的瞭解，需要從全域性的視角來看整個音視訊通訊。

下圖是對音視訊實時通訊鏈路功能的一個抽象，用媒體傳送和媒體接收的P2P模式，省略了複雜的伺服器傳輸部分，方便大家的理解。

音視訊通訊的基本流程：首先是推流使用者端，從終端裝置的音視訊採集模組採集的音視訊資料是未經過壓縮的原始資料，按幀（frame）儲存的、尺寸較大的媒體資料，是沒有辦法直接在網路上傳輸的，需要先進行壓縮，就到了編碼部分，用到了音視訊的編碼器，編碼完成之後，資料依然很大，需要進行切片，然後經過RTP對切片後的資料做封裝，封裝完之後，從傳送佇列傳送到網路上，經過伺服器的一系列透傳或處理，到達拉流使用者端，拉流端收到網路傳送過來的RTP封包之後，要先進行RTP包的完整性判斷，判斷編碼後的資料框切片資料是否都已經被收到，之後再解RTP封裝，恢復編碼後的端資料框，並送給解碼器進行解碼，解碼完的資料送到渲染模組，使用者就看到和聽到了推流端的畫面和聲音。

上圖左邊是媒體傳送側的處理流程：音視訊採集模組、前處理模組、編碼模組、RTP封裝模組、傳送佇列、網路資料傳送。右邊是媒體接收側的處理流程：網路資料接收、RTP包解析模組、接收佇列管理、解碼模組、後處理模組、渲染模組。中間的左邊藍色的框內功能是傳送側QoS相關的功能，右邊的藍色框內的功能是接收側QoS相關的功能。另外，從RTCP協定本身的定位看，它就是對基於UDP的媒體RTP資料進行控制的協定，所以也可以看成QoS控制的一部分。

從上圖還可以看出兩個特點，第一，QoS功能跟很多其它模組都相關，這是因為QoS技術是全鏈路控制的技術，需要觸達的模組比較多；第二，傳送側的QoS功能明顯比接收側的QoS功能多，這是因為目前很多都是傳送側頻寬估計和擁塞控制，因為這樣會更接近資訊產生的源頭，從源頭解決問題的效率更高，防患於未然。接收側的技術往往是比較被動的，是出了問題之後的最後補救，亡羊補牢。

QoS技術體系

講完QoS技術的分類和QoS技術在音視訊通訊技術中的位置，接下來我們聚焦在QoS技術領域內部，從使用者端和伺服器媒體鏈路來看QoS技術體系和其中比較大的技術點，如下圖所示。左下角的推流使用者端側，用到了信源控制、擁塞控制、抗丟包技術；中上部的媒體轉發伺服器SFU，用到了信源控制、擁塞控制、抗丟包技術；右下角的拉流使用者端側，用到了抗丟包、抗抖動技術。下面簡要串一下相關的技術點的大概流程和意義。

l 音視訊推流使用者端

所有媒體RTP封包傳送的時候，會在RTP的擴充套件頭中增加一個統一的序列號，可以認為每個封包有一個唯一的編號，這樣所有發出去的資料都有了對應的序列號、傳送時刻、包大小三個資訊。在接收端收到這些RTP封包之後，會把每個收到的序列號以及收到的此序列號的接收時刻資訊，按照TransportFeedback（twcc）報文定義的格式封裝到RTCP包中，反饋到推流端。參考：《WebRTC研究：Transport-cc之RTP及RTCP》,推流端根據這些反饋資訊，就能估算出當前網路傳輸的狀況，包括丟包、延時、頻寬三個方面的資訊。這些估算的演演算法，就是頻寬估計演演算法（也叫擁塞控制演演算法），上圖提到了比較常用的兩種，一個是GCC（google congestion control），一個是BBR（Bottleneck Bandwidth and Round-trip Time），兩個都是谷歌推出的擁塞控制演演算法。

為什麼不單純叫頻寬估計演演算法呢？這些估計演演算法一般都會跟平滑傳送PacedSender配對使用，很少出現只估計不控制的情況，平滑傳送控制策略也是估計演演算法架構設計中的一部分，為了讓傳送的碼流盡量是比較平順的，防止忽高忽低的波動，以免對鏈路造成衝擊，帶來不必要的擁塞。

基於這些擁塞控制演演算法的設計，很多時候為了相對準確的探測到足夠大的可用頻寬，在原始的音視訊資料不足以填滿期望的頻寬到時候，比如視訊畫面靜止不動、音訊靜音的場景，就需要傳送一些Padding資料來臨時填充頻寬，這些Padding資料有時是用重複傳送原始包的方式，有時就乾脆發一堆垃圾資料，目的只是用來填充頻寬，收到之後也會將其丟掉。

經過估計演演算法的估算，得到網路的可用頻寬、傳輸延時、丟包率資訊之後，就可以將這幾個資訊廣播到各個需要的模組，例如頻寬分配模組。在頻寬分配模組中，會按照一定的優先順序和分配策略，將可用的頻寬，分給每一條音視訊流，而且在有丟包的場景，需要同時為每條音視訊流分配對應的冗餘資訊頻寬。

分配完頻寬資源之後，就到了信源控制部分，音視訊流的碼控模組會根據各自的碼流特徵、編解碼能力、技術手段進行各自的控制，例如基礎的音訊位元速率、幀長、視訊的位元速率、影格率、解析度、QP等基本控制，同時也有一些編碼相關的特定技術點的控制，例如音訊DTX（Opus編碼器不連續傳輸-->降低頻寬佔用）、視訊simulcast（同時推播多流-->滿足不同訂閱場景降低頻寬）、視訊SVC（可分層視訊編碼-->實現動態抽幀能力降低擁塞）、視訊LTR（長期參考幀-->降低重傳頻寬）、視訊螢幕共用SCC（螢幕內容編碼-->降低螢幕共用場景頻寬）等等。

在網路有丟包的場景下，我們要儲備抗丟包的技術手段。抗丟包手段一般有兩種：

一種是丟包重傳，收流端發現資料丟包了，不再連續的時候，主動通過NACK報文（RTCP報文的一種）傳送重傳請求到推流端，而推流端則需要隨時快取之前發過的資料，以滿足丟包之後的重傳需求，對丟失的資料進行補發。這是一種滯後性的補救措施，所以相對比較節省頻寬，但是會增加延時；

另一種是傳送資料的時候，同時傳送一部分冗餘資訊，一旦傳輸過程中出現丟包，則可以靠這部分冗餘資訊，恢復部分或全部的原有資料。這是一種預防性的技術手段，因為冗餘和原始資料同時傳送，所以可以即刻進行丟包恢復，不存在延時問題，但因為有冗餘資訊存在，所以會佔用更多的頻寬。這裡增加冗餘資訊的方式有2種，一種是RED封裝，用在封包比較小的音訊傳輸場景；另一種是FEC編碼封裝，用在封包比較大的視訊或音訊場景，目前有很多種FEC編碼方式可用，這方面演演算法的研究也比較多。

l 媒體轉發處理伺服器SFU

到了媒體轉發伺服器，其一方面作為收流側對應推流側使用者端，另一方面媒體伺服器會作為傳送側對應拉流使用者端。收流側基本只提供抗丟包能力，和拉流側的抗丟包能力配合使用就形成了全鏈路的分段抗丟包能力，分段意味著上行和下行分開來做抗丟包，互不影響，好處是可以簡化設計，同時對不同的下行弱網和非弱網使用者，可以提供按需服務，有比較強的自適應能力。收流側和拉流側的抗丟包跟上面說的使用者端的抗丟包一樣，也包含丟包請求、重傳，對應RED編解封裝，對應FEC編解碼、編解封裝的功能，這部分功能相對比較固定，在跟使用者端推流側進行SDP媒體能力協商之後，就確定了哪些功能可以開或者是關。

伺服器的傳送側功能，跟使用者端推流側一樣也比較複雜，包含擁塞控制GCC、BBR、平滑傳送、Padding等擁塞控制演演算法以及頻寬分配，伺服器上的這些演演算法跟使用者端推流側的演演算法基本的框架結構和基本功能都是一樣的，只是演演算法的引數設定、使用的策略，都跟使用者端是不一樣的，因為伺服器側的信源控制力跟使用者端推流側的信源控制力，是完全沒法比的，不可同日耳語。同時，伺服器需要顧及很多的推流端和很多的拉流端，更需要平衡各種關係，眾口難調是伺服器面臨的主要矛盾。

伺服器的這種地位也衍生出了一些特定的技術手段，比如視訊的抽幀（抽掉一些不影響解碼的幀資料來降頻寬）、視訊切流（主動切換到頻寬和清晰度較低的流上來降低頻寬）、視訊按需推流（根據實際的訂閱關係准許推流端直推需要的流來降低頻寬）、音視訊頻寬反饋（特定場景可以將拉流測資訊反饋給推流側讓其提供更準確的碼控服務）、音訊AudioRanking（多人會議場景將不說話人的聲音過濾掉來降低頻寬）等等。伺服器相關的更詳細的技術點描述，可以參考《阿里雲 GRTN QoS 體系 — 構建實時音視訊產品最佳體驗》。

l 音視訊拉流使用者端

最後到了音視訊拉流使用者端，這裡的抗丟包功能除了上面說的丟包重傳、RED、FEC，又多出了兩個，一個是關鍵幀請求，一個是長期參考幀LTR請求，這兩個視訊幀請求目的都是為了恢復視訊幀的參考鏈，以便能夠重新開始視訊解碼。

關鍵幀請求是需要視訊重新開始編碼，讓收到關鍵幀的任意使用者端都可以解碼，使視訊幀的參考鏈重新開始。長期參考幀則是在確認已經收到一個長期參考幀的情況下，不必再從關鍵幀開始編碼，只要傳送一個長期參考幀就可以恢復參考鏈，即用傳送長期參考幀的方式替代傳送關鍵幀。這樣做的好處主要是降低重傳頻寬，但同時增加了複雜性，因為伺服器需要確認每個拉流使用者端，都收到了某個特定的長期參考幀，在拉流使用者端數量較多的場景，這個條件比較難以滿足。可以參考《阿里雲 RTC QoS 弱網對抗之 LTR 及其硬體解碼支援》。

另外拉流使用者端比其它部分多了抗抖動的功能，主要思想是增加一個資料緩衝的buffer，增加了一部分延時。就像一個水庫一樣，雨季的時候蓄水，將快速流入的水儲存起來，旱季的時候放水，將之前儲存起來的水慢慢放出來，確保自始至終有水流出。

音訊和視訊的資料流有各自不同的特徵，對應音訊的抖動快取機制和視訊的抖動緩衝機制也是不一樣的，目前用的較多的都是WebRTC裡面的音視訊抖動控制機制，視訊是基於卡爾曼濾波器的JitterBuffer，音訊是NetEQ，具體的演演算法都非常複雜，這裡就不展開了，有興趣的同學可以參考《WebRTC視訊JitterBuffer詳解》和我之前的一篇白話文《白話解讀 WebRTC 音訊 NetEQ 及優化實踐》。

音視訊的拉流側或播放側一般都會有音視訊同步（又叫脣音同步lip sync）的需求，否則會出現只聞其聲不見其人，或只看到閃電聽不見雷聲的情況。WebRTC原有的音視訊同步機制非常的複雜，我之前也有過介紹《WebRTC 音視訊同步原理與實現》，而且在NetEQ及優化實踐中也提到了一種簡單的替代方案，這裡也不展開。

06 音視訊通訊QoS技術的演進

上面粗略地講述了音視訊通訊QoS用到的技術體系，任何技術都是需要一定的軟體架構來承載和實現的，音視訊通訊領域的QoS技術也是隨著音視訊通訊的軟體架構演進而不斷升級的。對於實時音視訊通訊RTC的演進歷史，可以參考《歷經5代跨越25年的RTC架構演化史》。這裡面提到「谷歌在2011年開源了WebRTC，作為RTC技術領域的里程碑事件，大大降低了RTC開發的門檻，催生了後來行動網際網路RTC應用的大時代」。

WebRTC以前

在WebRTC面世以前，因為門檻較高，音視訊通訊基本都是幾大頭部玩家的之間的遊戲，例如Polycom、華為、思科、微軟、BT、Vidyo等，各家都有自己的私有架構，都在閉關修煉。他們用到的QoS技術也都是各自的武功祕籍，只能從一些公開的文章或者協定標準的提交中窺探一二。2012年當我在Polycom看到WebRTC開源的訊息時，還完全沒有覺得是什麼了不起的事情，Polycom當時有著一眾音視訊技術的科學家，支援各種編解碼技術，是行業裡的絕對頭部，沒想到幾年光景下來就泯然於眾了。

WebRTC以後

在WebRTC面世以後，音視訊通訊領域第一次將其技術棧較全面的暴露在了陽光下，人人都可以基於上面做自己的實驗、優化、演進，吸引了大量開發者、初創企業、網際網路巨頭的參與，不管是技術小白，還是行業專家，都不自覺的、主動或被動地捲入了WebRTC重新定義的音視訊通訊行業。因為WebRTC本身也是一個比較優秀的架構，其QoS技術和帶來的通訊效果都是不錯的，所以很多企業也都放棄了原有的私有架構，轉而在WebRTC的基礎之上適配自己的業務邏輯，增加自己業務場景特有的QoS演演算法優化。

然而，WebRTC本身定位源於P2P的網際網路瀏覽器間的通訊，其重點在使用者端側的架構與實現，而伴隨雲上音視訊通訊業務場景的發展，媒體轉發伺服器變成了兩個使用者端之間不可缺少的一環。支援WebRTC協定的媒體伺服器也有多種，例如janus、mediasoup、srs、licode、kurento、jitsi等，可以參考《十大必知開源WebRTC伺服器》。但很多媒體轉發伺服器SFU都只是實現了轉發功能，對鏈路控制的QoS技術支援非常的薄弱，有的甚至聊勝於無，而且由於伺服器程式碼架構跟WebRTC的端側程式碼架構差異巨大，導致遷移原有WebRTC的QoS演演算法，也變得非常困難。

QoS技術演演算法優化階段

大概在2021年疫情前半段以前，網際網路逐漸走到巔峰，大家都是業務高漲、快速迭代，各家都是拿來主義，直接把WebRTC編譯通過之後，就整合到自己的SDK裡面去了，先把業務做起來，再慢慢調優QoS演演算法，只要能滿足高漲的業務需求，不會考慮架構是否複雜、實現是否優雅。這個階段都是基於WebRTC的QoS演演算法優化，各類技術文章層出不窮，基本上覆蓋了上面QoS技術體系中提到的各個技術點，網上90%以上關於QoS優化的文章都是這一類單點演演算法的優化和演演算法的深度解析。大家的技術水平很快被拉到了同一個起跑線上，對新入坑的音視訊技術同學非常友好，只要願意學很快就能上手。

這種QoS單點技術的優化升級，是提升QoS效能的核心手段，是最終提升使用者體驗的立足點，將會一直持續下去。但是這些單點演演算法優化也有瓶頸，一旦到達現有基礎科學研究的天花板，想再提高就很難了，因為需要基礎理論研究的突破為前提，這個投入產出不是一般商業公司願意承擔的，也不是一般的演演算法技術人員能夠突破的，所以大部分的國內的公司和技術人員都選擇了知難而退，也是大環境使然。

當然，大家也不用擔心演演算法技術人員就無用武之地了，畢竟很多技術還沒有到達基礎科學的天花板，我們還有一些時間；畢竟我們最擅長的就是拿來主義，搞不了腦力，就搞體力，短期提高不了技術的高度，那我們可以從技術的廣度入手，只要能挖掘足夠多的使用者場景，我們就可以針對特定的場景，進行量體裁衣，通過縫縫補補，就可以讓各種場景都有一個比較好的體驗，這也是一種價值體現罷。不止是QoS技術，我們的很多科學技術領域，每每說到這個層面總是讓人心酸，也是沒有辦法的事情，希望有一天這種局面能有改觀。

QoS技術架構升級階段

隨著疫情進入後半段，網際網路熱潮不再，IOT、雲渲染、雲遊戲等新場景的出現，大家逐漸慢了下來，重新開始思考WebRTC這套框架是否是適合自己業務的，有沒有更好的解法。對WebRTC原始碼有一些瞭解或者參與過相關編譯的同學都應該知道，WebRTC是非常龐大的一個實現，包含參照的第三方庫的話，原始檔數量接近20萬個，這種數量級的程式碼給環境部署、編譯設定、工程參照都帶來了很大的麻煩，以至於網上有人把編譯WebRTC做成了一門生意，按次收費。很少有公司能拿WebRTC直接使用，都是需要找專門的同學，做環境的設定、程式碼的裁剪等一系列對業務沒啥價值的事情，費力不討好。

QoS技術作為WebRTC中最有價值的技術之一，則被深度捆綁在整個程式碼框架裡面，如果不做傷筋動骨的改造，很難直接被用在非WebRTC的程式碼框架中。下圖是簡單梳理的WebRTC中跟QoS相關的媒體處理部分流程，熟悉WebRTC程式碼的同學應該可以比較清楚地知道圖裡面每個模組的意義和作用，這裡就不展開介紹了。其中紅色的部分是QoS相關的模組，我們可以看出，整個流程相互耦合在一起，沒有辦法單獨將QoS功能抽取出來。

同時，對於IOT、雲遊戲、雲渲染等場景，由於有自己特有的採集渲染、編解碼功能，不能使用WebRTC的整個框架，而只需要媒體傳輸、QoS控制能力，所以不得不對WebRTC做裁剪，對QoS演演算法進行剝離。這種業務需求推動了，對原有WebRTC架構的思考和升級，推動了QoS技術的架構演進。

這種架構的升級演進具體如何來做？我認為，首先要從音視訊通訊技術鏈路和功能模組的抽象來入手，抽象到一定高度，就看清了事物的本質，看清了本質，就能比較容易看清各個模組之間的關係，然後才能物以類聚進行解耦。下圖是對QoS推拉流功能和處理流程的抽象。

經過上面的抽象之後，我們就能比較清楚地定義出QoS功能的邊界，能夠進一步將QoS內部的各個功能進行重新設計實現，最終可能會變成下圖分層解耦、功能模組化的樣子。有了這種架構的QoS模組，就可以非常方便地遷移到各種不同的場景，甚至可以遷移到媒體轉發伺服器SFU上面去，實現QoS能力的快速複用，一次優化多點受益，加速新場景的商業化速度。例如，央視三星堆奇幻之旅的專案中的QoS部分，就是使用了演進後的QoS模組功能，《三星堆大型沉浸式數位互動空間最佳實踐》。

從音視訊通訊軟體演進的形態來看，最終的結果可能是又回到了WebRTC開源之前的狀態，各家有各自的私有軟體架構，各家又回到了自己的QoS技術優化的小圈子，看起來繞了一圈又回到了起點，只是每家都吸收了WebRTC的精華。

本文從更宏觀、更寬泛的角度介紹了QoS的概念和分類，從音視訊通訊QoS領域的常用技術到架構的演進過程做了簡單彙總。隨著音視訊通訊新場景的不斷湧現，更實時，更高清變得越來越重要，相關技術也會往這個方向傾斜，同時基於巨量資料分析的QoS相關技術應用將會逐漸滲透。