技术干货 | 视频直播关键技术和趋势
導讀：移動互聯網的興起為人類信息傳播帶來了更便捷的通道、更立體的視角和更豐富的選擇。視頻直播等多媒體通信技術在新的時代背景下逐漸嶄露頭角并不斷滲入到人們的日常生活中，以提高人們的信息傳輸效率、降低信息傳輸成本。
文｜鄭文彬
網易云信云平臺融合通信技術團隊負責人/架構師
直播概覽
進入后疫情時代，視頻直播技術在眾多行業市場的應用日益廣泛，也吸引了眾多的從業者投入到相關技術領域的學習、研究和應用開發中來。一方面，在電商營銷、社交娛樂、在線教育、金融服務等垂直行業，視頻直播技術能夠推動企業生產經營活動進一步提升價值、控制成本，幫助企業實現開源節流的同時加速推動企業進入數字化轉型的快車道；另一方面，5G 網絡基礎設施的加速建設、云計算和人工智能技術的大幅推廣進一步催化和加速了視頻直播產業的升級和發展壯大。如圖1所示，在未來的三年里，國內企業直播服務市場的規模預計仍將延續較高的增長勢頭。
?直播架構?
對組織者而言，準備一場直播活動，所需要的工具和依賴的平臺既可以很簡單，也可能非常復雜。
在簡單使用場景下，主播端借助常見的推流工具（如 OBS）就可以實現音視頻數據的采集和編碼，并將媒體流推送到云端，而播放端也可以借助常見的媒體播放工具（如 VLC）直接拉流播放，如圖2所示。
但是，在某些特定的直播場景，組織者可能會對直播活動的規模和品質提出多樣性的要求。最典型的需求是支持媒體流的多個碼率輸出以適配不同觀眾所處環境的網絡狀況，其次是支持大量觀眾同時在線觀看。甚至在一些大型直播活動中，比如網絡在線演唱會，活動方希望能夠對活動現場的多個媒體源或攝像機位進行直播切換控制。為了支持這些復雜的直播特性和需求，開發者需要引入更復雜的直播服務架構，如圖3所示。
?直播流程?
一個典型的視頻直播完整流程如圖4所示。
主播端負責音視頻數據的采集、預處理、編碼壓縮，并將封裝后的媒體流推送到云端的直播媒體網關。
直播媒體網關在接收到來自主播端的媒體流之后，將其轉發給媒體處理服務（MPS）進行云端的媒體加工處理，比如添加水印、轉碼等等。處理后的媒體流通過直播媒體網關轉推到 CDN 網絡，或者通過 CDN 回源拉流的方式，進行媒體流的分發。
最后，播放端通過訪問直播 URL 地址從 CDN 的下行邊緣節點拉取指定的媒體流，對其進行解碼并做必要的后處理，然后再輸出到渲染模塊進行播放。
?QoS 指標?
在一場直播活動中，影響觀眾直播體驗（QoE）的因素有哪些呢？下面我們介紹在視頻直播過程中需要關注的一些 QoS 指標。
首屏時間：即播放器從發起直播請求到顯示第一幀視頻圖像所需要花費的時間。這個時間越短，用戶體驗越好。
尺寸：即視頻圖像的分辨率（長度x高度，單位為像素值）。一般情況下視頻的尺寸越大，清晰度越高。
幀率：又叫幀速度，即每秒鐘采集的視頻圖像的幀數量（Frame per Second，fps）。一般而言，視頻幀率越高，播放流暢度也越高，但是較高的幀率也導致了較大的數據傳輸量。
碼率：即視頻采樣數據經過編碼壓縮后，在網絡上正常傳輸的速率（Bitrate）。在同等編碼條件下，碼率越高，意味著傳輸的媒體數據量越大，因此在音視頻的清晰度和流暢度上會帶來更好的播放體驗，另一方面，高碼率的媒體流將對傳輸網絡的帶寬帶來更大的壓力。
延遲：即一幀視頻圖像從開始采集到最終播放，期間所花費的時間。延遲越小，意味著視頻直播的實時性越高。從上面的直播流程可以看出，視頻直播從媒體數據采集到最后渲染播放經歷了很多環節，所以影響延遲的因素也很多。
抖動：即視頻數據包在傳輸過程中由于網絡擁塞、傳輸緩存或路由變化導致偏離正常傳輸延時的現象。媒體傳輸的抖動問題會影響到播放的連貫性，引起卡頓等不良體驗。
關鍵技術
視頻直播的關鍵技術主要涉及媒體處理和媒體傳輸兩個方面。從視頻直播技術應用伊始，針對這兩個技術領域展開的一系列的創新研究和優化升級就從未停止。
?媒體處理?
結合視頻直播業務的特點，我們根據直播流程中的不同階段將媒體處理分為三大類：主播端媒體處理、云端媒體處理和播放端媒體處理。主播端媒體處理又可細分為預處理和編碼，而播放端媒體處理又可細分為解碼和后處理。
主播端處理
常規的圖像增強處理方法在視頻預處理環節依然發揮著主流的作用，比如降噪、補償、平滑、銳化、圖像增強（飽和度/對比度）等等。隨著視頻業務在社會生活中應用場景的不斷拓展，一些有趣的媒體應用處理技術也在視頻直播場景中逐漸普及開來，比如美顏、瘦臉、換臉、打碼、背景虛化/替換、AR/VR 等等。
另一方面，如何提高視頻編碼壓縮效率是業界面臨的主要挑戰之一。視頻編碼本質上是一種有損壓縮過程。通常情況下，為了獲得更低的視頻傳輸碼率，編碼器需要增大圖像編碼壓縮率，而這勢必引起更多視頻圖像細節的失真和損耗，從而導致視頻播放質量的下降。所以，如何在獲得更低傳輸碼率的基礎上保證足夠好的視頻播放用戶體驗，成了圖像處理領域研究者和視頻引擎技術開發人員需要研究的重要課題。近些年來，人們嘗試結合人眼視覺系統（Human Visual System, HVS）對事物感知存在內容偏好的生理特性，將人工智能技術特別是神經網絡和深度學習方法引入到了視頻圖像預處理和編碼壓縮算法中，并在基于顯著性的視頻預處理、基于紋理分析和綜合的預處理、端到端神經視頻編碼等研究方向上[2]均取得了一些積極的進展。
網易云信技術團隊投入了大量研發資源，致力于 HVS 和 AI 技術相結合的視頻圖像處理算法和應用的研究工作，而且在圖像紋理增強 、顯著性檢測處理和 JND 感知編碼技術等方面的開發已經跨出了卓有成效的一步。該系列技術研究的成果正在逐步應用到云信的直播、點播和 RTC 等業務中，為云信的客戶帶來更好的播放體驗和更高的業務價值。
圖5 網易云信視頻引擎優化效果
云端處理
除了主播端的媒體處理之外，在很多情況下需要在云端對媒體流做進一步的加工處理，以滿足直播業務的特定需求。比如為了輸出單路媒體流需要將多路媒體源進行混屏混音、為了支持多種碼率或編碼格式需要進行轉碼（轉換分辨率、碼率或編碼格式）等，甚至為了支持一些個性化的需求還要實現添加水印、生成字幕、數據加密等擴展能力。如前所述，這塊兒加工處理的工作是由云端的媒體處理服務（MPS）負責實現的。
網易云信搭建了一套全新的 MPS 服務，支持跨區域的分布式彈性部署和媒體源的就近接入，為云信的音視頻業務提供了豐富的可定制化的實時媒體處理能力。在不久的將來，我們希望能將這些媒體處理能力進一步開放給外部客戶和合作伙伴，提供多種服務接口，以支持云信生態系統上的客戶和合作伙伴更好地發展他們的多媒體業務。
網易云信 MPS 設計實現了一個實時的媒體處理流水線模型，如圖6所示。該模型封裝并打通了媒體流接收、發送、編解碼和加工處理等全流程的各個環節，大幅提升了媒體數據收發和處理的效率，并提供了靈活便捷的媒體處理擴展能力。
播放端處理
播放端的視頻處理方法包括兩大類，即圖像增強技術和超分辨率技術（Super Resolution，SR）。這兩類圖像處理技術的一個顯性區別是，圖像增強技術不會改變視頻圖像的分辨率，而超分技術則主要通過算法推理提升圖像分辨率的方式，達到優化視覺效果的目的。
基于 AI 的超分技術相比傳統的基于差值或重構的計算方法，在超分效果上具有巨大的優勢。不過在多媒體實時傳輸應用領域，AI 超分技術也面臨著兩大挑戰：一方面，網絡視頻流通常都是經過大幅壓縮編碼后的媒體數據流，這種有損壓縮很容易造成圖像紋理細節的失真和畫質的嚴重退化，如果將這類圖像直接進行拉伸，壓縮損失很容易被放大，因此超分的效果將大打折扣；另一方面， 當今流行的 AI 超分算法，如各種深度卷積神經網絡算法，對播放設備的計算能力提出了更高的要求。由于播放設備機型品類繁多、算力良莠不齊，播放端的媒體處理能力和播放實時性都受到了較大的影響。常規的解法是為播放端 SDK 設置一份機型白名單，SDK 只能在指定型號的設備上對媒體數據進行渲染播放前的有限優化處理，而對于算力要求較高的 AI 超分技術，則幾乎絕跡于各種智能移動播放設備。
網易云信提出了一個基于編碼損失復原的視頻超分算法方案，采用數據驅動和網絡設計雙管齊下的策略，通過數據處理模擬失真場景，從模型設計到工程落地進行了多重優化，對制約 AI 超分技術的兩大問題進行了一定的突破，在模型實時性和真實場景超分效果方面均取得了不錯的效果。該算法具有模型小、參數少、實時性好等特點，能夠適配更多的播放設備。我們通過圖8可以直觀地對比一下在視頻圖像細節上的算法優化效果（左圖為傳統超分方法，右圖為網易云信 AI 超分算法）。
?媒體傳輸?
如果將媒體處理過程比喻為烹飪一道美食，那么傳輸技術則是為了把這道美食及時而又安全地派送到觀眾手中。媒體傳輸技術涉及到兩個細分領域，即傳輸協議的選型和傳輸網絡的保障。
傳輸協議
視頻直播常見的媒體傳輸協議規范包括 RTMP、 HTTP+FLV 以及基于 HTTP Adaptive Streaming（HAS）技術的協議，如 Apple HLS、Adobe HDS、MPEG DASH 等。一般而言，RTMP 和 HTTP+FLV 相比 HAS 協議可以獲得更低的直播延遲，但是 HAS 協議具備更好的網絡自適應能力，可以針對網絡可用帶寬的實時動態變化選擇傳輸相應碼率的媒體流片段。近幾年來，HAS 協議設計者們陸續推出了各協議的低延時版本，如 LL-HLS（Low-Latency HLS）[3][4]和 LL-DASH（Low-Latency DASH）[5]，這些改進版本在理想情況下可以將直播的端到端延遲縮短到2秒左右。
從網絡協議四層模型來看，以上這些應用層的直播協議都是基于傳輸層的 TCP 協議實現的。然而，TCP 協議在當今的多媒體通信應用領域存在著諸多缺陷，如建連握手時間長、擁塞控制不靈活、隊頭阻塞問題嚴重、抗弱網能力差等等。為了解決 TCP 協議的這些問題，一個全新的運行于用戶態的傳輸層標準協議 QUIC[6]應運而生。QUIC 協議設計了一個基于 UDP 的多路復用且安全可靠的傳輸機制，為應用程序提供了區別于傳統流式傳輸協議的重要特性：
快速的連接握手。支持 0~1RTT 建立連接
連接多路復用。支持連接內的 multiple streams，避免了隊頭阻塞問題
連接遷移。通過 Connection ID 綁定連接，解決了 NAT 映射失效和移動設備多網切換等問題
靈活的擁塞控制機制。在用戶空間（而不是內核空間）實現，可結合應用場景靈活配置和調優
另一方面，在多媒體數據傳輸如視頻直播的應用場景，選擇合適的擁塞控制算法對提升傳輸效率、降低傳輸延時尤為重要。Google 公司在2016年提出了一個全新的擁塞控制算法：BBR（Bottleneck Bandwidth and Round-trip time）[7]。相比基于丟包檢測的傳統擁塞控制算法（如當前 Linux 內核默認的擁塞控制算法 CUBIC）而言，BBR 基于傳輸帶寬和往返時延估計的擁塞發現機制更加與時俱進，更適用于新時代的互聯網基礎設施部署環境。
圖9顯示了一個 TCP 連接中從一端向另一端發送數據時，數據傳輸速率和 RTT 與 inflight 數據量（已發出尚未收到 ack 的數據量總和）之間的關系。在網絡擁塞尚未發生時（即 app-limited 階段），隨著數據傳輸速率的持續提升，RTT 可以保持穩定。當 inflight 數據量增加到 BDP（傳輸瓶頸帶寬 BtlBw 與往返時延 RTprop 的乘積）之后，擁塞開始發生，瓶頸路由節點開始緩存數據，RTT 開始變大，數據傳輸由此進入到 bandwidth-limited 階段。當 inflight 數據量持續增加到 BDP+BtlneckBufSize 之后，意味著 bottleneck buffer 已滿，只能進行丟包處理，數據傳輸也隨即進入到 buffer-limited 階段。
顯而易見，理想的情況下我們希望在 inflight 數據量恰好達到 BDP 時就可以檢測到網絡擁塞的發生。然而，基于丟包檢測的 CC 算法需要等到 buffer-limited 階段（即丟包開始發生時）才能發現這一點。這將帶來兩個問題：當 BtlneckBufSize 比較大時，因 bottleneck buffer 溢出丟包才確定擁塞很容易引起高延遲、高抖動等 bufferbloat 問題；而當 BtlneckBufSize 較小時，丟包不一定就意味著擁塞的發生，此時的誤判將會促使發送端減小發送窗口，從而造成傳輸吞吐量遲遲無法提升上去。BBR 的設計思路就是在數據傳輸過程中通過對 BtlBw 和 RTprop 進行持續地探測和更新評估，計算出動態的 BDP 值，從而達到發現網絡擁塞的目的，并依此進行數據發送節奏的控制。BBR 算法在 GCP（Google Cloud Platform）上的部署應用為 Google 服務在優化傳輸延遲、提升吞吐量和 QoE 等方面帶來了大量的收益[8]。
QUIC 協議和 BBR 算法的珠聯璧合為業務應用的優化帶來了新的選擇。網易云信視頻直播系統在推流端和拉流端同時集成了對 QUIC 協議和 BBR 算法的支持，在直播活動上下行的第一公里或最后一公里通過 RTMP over QUIC 進行媒體流的傳輸能夠有效地改善媒體數據的傳輸效率以及抗弱網和抗抖動的能力，進一步提升了視頻直播的用戶體驗。
傳輸網絡
常見的視頻直播傳輸網絡環境包括公共互聯網（公網）、專線網絡、CDN 網絡和RTN 網絡等。
公網是運營成本最低的傳輸網絡，但是它的缺點也很明顯，那就是網絡可靠性（帶寬、延遲、抖動等）缺乏保障，所以通常被用于直播的最初或最后一公里鏈路。
使用專線網絡可以解決網絡可靠性的問題，但是缺點是使用成本較高。
CDN（Content Delivery Network）是一種在互聯網中被廣泛使用的網絡基礎設施。在視頻直播應用場景中，CDN 可以為直播用戶提供廉價的跨區域的大規模的數據分發能力，它的主要問題是傳輸延遲較大（秒級）且各 CDN 廠商的服務能力參差不齊。
RTN（Realtime Transmission Network），顧名思義，就是設計用于提供實時數據傳輸能力的大規模分布式網絡傳輸系統。RTN 基于公網基礎設施，通過純軟件方式實現，不依賴硬件也不借助專線網絡進行優化，而能夠將端到端的延遲控制在百毫秒級別。另一方面，為了實現 RTN 實時穩定的數據傳輸能力，RTN 廠商不僅要投入研發資源進行路線探測、路由調度等各種算法的持續升級調優，也需要在網絡節點部署、帶寬租用等方面投入大量的資金，其投入成本堪比 CDN。
網易云信自研推出了新一代大規模分布式傳輸網絡，即WE-CAN（Communications Acceleration Network）。WE-CAN是一個架設在公網之上，通過智能鏈路探測算法和智能路由調度策略將數據從全球任意端點快速、穩定、高效地發送到任意目標端點的多功能實時傳輸網絡系統，如圖10所示。
相比傳統的 RTN 網絡，WE-CAN 的傳輸速度更快，傳輸成本更低，適用場景也更加豐富。WE-CAN 不僅能夠對 RTC 媒體流進行高到達、低延遲的傳輸，也能對視頻直播流進行大規模、低延遲的分發，還能對信令、即時消息（IM）和其他業務數據進行可靠傳輸。WE-CAN 的媒體數據傳輸在全球范圍內延遲不超過 250ms，而優質傳輸率則達到了 99% 以上。
通過集成 WE-CAN 和國內外眾多主流的 CDN 廠商，網易云信設計實現了一套基于推流線路智能切換和融合 CDN 智能調度的高可用直播服務框架，如圖11所示。
在傳輸網絡上，網易云信直播服務具備以下幾個主要特點：
上行推流多線路智能切換。?通過主備推流多條線路的自動識別和切換機制，保障了上行推流的高可用；
下行融合多CDN智能調度。根據實時的 CDN QoS 監控機制進行播放拉流的調度分配，保障了下行拉流的最優解；
端到端的全鏈路數據安全。除了常規的傳輸層加密、防盜鏈和推拉流黑白名單等安全應用，還支持在媒體封裝層進行加密，該層加密對媒體傳輸協議和網絡透明，且只有授權的客戶端才能進行解密播放；
支持低延時直播應用場景。通過集成 WE-CAN 網絡和最后一公里的 WebRTC 技術，可以做到1秒以內的端到端直播延遲；
千萬級用戶并發在線能力。得益于融合 CDN 解決方案的落地和 WE-CAN 系統的大規模部署節點覆蓋，網易云信已經具備了支持千萬量級大型直播活動的技術能力。
技術趨勢
如同自然界萬物生靈周而復始、生生不息地繁衍進化，視頻直播技術也在不斷地迭代演進發展中。近年來，隨著視頻直播應用場景的不斷拓展和深入，相關技術的研究和應用方向呈現出兩個明顯的發展趨勢，一個是低碼高清，另一個是降低延遲。?
?低碼高清?
所謂低碼高清技術，就是在更低碼率的傳輸條件下為用戶呈現出更清晰流暢的視頻播放效果。“既要馬兒跑得快，又要馬兒不吃草”是驅動低碼高清技術不斷向前發展的永恒的追求。通過低碼高清技術的應用實踐，視頻直播活動可以適配更差的用戶網絡帶寬狀況，覆蓋更多的觀眾群體，帶來更好的視頻播放體驗，同時，也能大幅降低企業的媒體數據傳輸成本。
網易云信在視頻圖像預處理、視覺感知編碼和 AI 超分等低碼高清技術領域的研發方面已經邁出了堅實的一步，相關技術成果通過持續的迭代優化正在逐步落地應用到 RTC、直播和點播等業務中來。
?降低延遲?
在某些特定的視頻直播場景中，主播和觀眾之間除了要推送直播媒體流之外，還需要傳遞實時的互動信令，如在線搶答、文字互動、搶紅包等，這對媒體流的傳輸延遲提出了更高的要求。傳統的直播技術動輒5秒以上的端到端延遲已經無法滿足這類場景的互動需求，即便是 LL-HLS 和 LL-DASH 技術想方設法將延遲縮短到最小2秒左右，也難以帶來令人滿意的用戶體驗。真正的低延時直播應用需要將端對端的延遲控制在2秒以內，甚至在1秒左右。
業界在降低傳輸延時技術方向上進行了諸多探索和嘗試，引入了 RTN 并應用了一些基于 UDP 的實時數據傳輸協議，如 QUIC、SRT、RTP 等，如圖12所示。目前主流的低延時直播技術，在推流端主要通過 RTMP（或 RTMP over QUIC）進行推流，在云端通過 RTN 網絡將媒體流快速分發到各個下行邊緣節點，最后利用 RTC 技術將媒體流實時傳輸到播放端，完成最后一公里的投遞。
網易云信在低延時直播技術領域也進行了布局，通過集成 WE-CAN 網絡和 NE-RTC 技術，網易云信直播服務可以提供1秒以內的端到端直播延遲能力。
總結展望
我們生活在一個數字化的時代，視頻直播技術依然處于信息傳播應用普及的黃金賽道，發展前景向好。將來隨著新業務應用形態的不斷涌現，必將產生新的技術訴求及其應對之道。
網易云信在視頻直播技術領域積累了豐富的經驗，特別在大型直播高可用解決方案、分布式媒體處理服務、低碼高清直播和低延時直播等技術方向逐漸建立起了自身的核心技術競爭力。網易云信將繼續順應技術發展趨勢，持續優化打磨媒體處理和傳輸能力，持續研究創新技術，以更好地助力客戶和合作伙伴內生成長、創造更多美好的價值。
?作者介紹?
鄭文彬，?網易云信云平臺融合通信技術團隊負責人、架構師，在實時多媒體處理和傳輸技術、網絡會議和視頻直播系統等技術領域深耕多年。
?參考文獻?
[1] 艾瑞咨詢. 2021年中國企業直播服務行業發展研究報告.
[2] Dandan Ding, Zhan Ma, Di Chen, et al. Advances in Video Compression System Using Deep Neural Network: A Review and Case Studies.
[3] APPLE.COM. Enabling Low-Latency HLS. https://developer.apple.com/documentation/http_live_streaming/enabling_low-latency_hls?
[4] Roger Pantos. HLS 2nd Edition. https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis?
[5] DASH-IF. Low-latency Modes for DASH. https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf?
[6] Jana Iyengar, Martin Thomson. QUIC: A UDP-Based Multiplexed and Secure Transport. https://datatracker.ietf.org/doc/html/rfc9000?
[7] Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, et al. BBR: Congestion-Based Congestion Control. https://dl.acm.org/doi/pdf/10.1145/3012426.3022184
[8] GOOGLE.COM. TCP BBR congestion control comes to GCP – your Internet just got faster. https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster
?相關閱讀推薦?
技術干貨 | 網易云信本地服務端集群錄制探索與實踐
技術干貨 | WebRTC 系列之 GPU 方案的探索與落地
技術干貨 | 實時音視頻性能評價實踐
總結
以上是生活随笔為你收集整理的技术干货 | 视频直播关键技术和趋势的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 网易云信入选《2021 年浙江省首版次软
- 下一篇： 资讯｜WebRTC M95 更新