RTC業務中的視頻編解碼引擎構建

正文字數:6146  閱讀時長:9 分鐘
視頻編解碼技術一直是視頻內容應用中的核心業務,基於各個平臺和各個渠道的視頻內容採集與分發都涉及到視頻編解碼技術的介入。在RTC業務場景下,如何構建高效快速的視頻編解碼引擎,如何對現有的編解碼技術進行優化改進,如何在公有協議基礎上實現私有協議,如何重寫編解碼框架等問題都值得關注。我們邀請到了網易雲信 音視頻算法工程師 何鳴 爲大家詳細介紹網易雲信RTC業務場景下的編解碼技術優化與實踐,以及未來的發展方向。  


文 / 何鳴
整理 / LiveVideoStack


大家好,我是來自網易雲信的何鳴,目前主要負責網易雲信G2音視頻框架中視頻編解碼引擎的開發與優化工作。

本次分享的內容主要有以下三個方面:

1
視頻編解碼器技術背景



通過實時通訊,或者是高清直播的方式爲用戶提供視頻內容,視頻內容每天都在網絡中產生並收發,這些視頻內容都是被壓縮過的,這個壓縮過程就是要實行編解碼技術,現在除了少部分的電影拍攝場景可能會用到原始視頻流,大部分視頻都是經過編解碼壓縮過後的視頻內容。所以,視頻編解碼技術在視頻內容的產生 分發過程中至關重要。


接下來我們討論下來,視頻編解碼技術究竟運用在什麼地方呢?像一個視頻序列當中,常見的YUV視頻中,一個像素點就需要1.5個字節的數據來存儲像素點。如果涉及到360P、720P、4K這樣的視頻的話,數據量是呈指數級的上升,到4K時每秒需要傳輸數據達到了759MB。與之對比,5G的傳輸帶寬1Gb/s換算成字節表示的話,就是125MB/s。這樣的傳輸帶寬是遠遠不能滿足於我們對高清視頻內容的要求,所以就需要視頻編碼技術對視頻進行壓縮處理。

我們現在常用的視頻編碼技術是預測器+量化器+熵編碼器的一個基本框架,其中量化器的話需要進行反量化操作,下方我們會詳細介紹這三部分各起到什麼作用。基於這三部分框架,我們將視頻重新劃分爲I幀、B幀和P幀,具體在哪些內容會遇到這些幀,接下來也會詳細介紹。

1.1 預測器


首先我們說預測器,預測器我們劃分爲幀內預測和幀間預測,在幀內預測中,以HEVC角度預測爲例,最新的技術發展VVC技術也只是將角度的方向增加了更多,預測的內容更加豐富,但總的來說還是角度預測、DC預測、平面預測。

幀內預測指預測內容全部來自本幀內,它的像素點是由它的當前塊重建出來的,所以預測方式所需要的參考方式全部來自當前幀,故稱作幀內預測。

與之對應的幀間預測,就需要構建參考幀信息,通過參考幀中尋找到的塊來補償當前塊,當前塊與參考塊之間的運動關係,我們稱爲運動矢量。在傳輸時需要將運動矢量傳輸到解碼端,通過解碼出運動矢量,在解碼幀中重新構建當前塊。這樣僅僅通過傳輸一些運動矢量信息,就可以快速構建當前塊,所以幀間預測是提高壓縮效率的主要辦法。現在根據新技術,比如Affine技術可以對一些塊的平移、旋轉、縮放進行預測。或者我們直接使用縮放對塊進行預測,最新的有些論文中也提到對預測方式的改進。此外,構建多參考幀可以在其中選擇多個參考幀作爲對當前預測幀的候選,這樣我們可以選出更好的塊來預測當前塊。

作爲視頻編解碼技術中的預測器技術,它也是在不斷的發展中,從最開始的H261、H263到最近的VVC技術,我們每代標準也是豐富了預測器技術。

1.2 量化器


先簡單看一下Lena圖經過DCT變換和反變換後的區別,從肉眼上看我們對變換和反變換是看不出差別的,但我們中間的頻域圖的能量大部分集中在0附近,且能量特別大的信息是比較少的。我們對這部分信息可以通過量化器進行量化,生成量化係數,對原圖的信息壓縮就達到了,所以量化有壓縮數據的功能。在實際編解碼應用過程中是通過預測器預測之後,將殘差圖經過變換之後再送量化器生成量化係數。所以量化器是在預測器的基礎上進一步提高壓縮率。

1.3 熵編碼器


熵編碼器依賴香農的第一定律,由於第一定律規定了編碼一旦有損信源編碼時,我們有一個固定的碼長。明確編碼器是一種信源編碼,信源編碼要儘可能去壓縮碼流,將壓縮過的碼流送到信道中,通過信道傳輸後再用解碼器還原出來。所以熵編碼器中我們主要涉及到無損編碼功能,像我們現在常用的哈夫曼編碼、指數哥倫布編碼或者遊程編碼這種可以提高壓縮效率。但在最新編碼器技術中,基於上下文模型的算術編碼對壓縮率提高是極大的,它對於大概率、小概率符號生成不同的碼率,極大的壓縮信息量。變換器和預測器生成的信息會送到熵編碼器後進行進一步的壓縮再送入信道中。
2
視頻編解碼引擎工程化


上述部分我們主要簡單介紹了一下編碼器的技術背景,但我們要實現商業編碼器相當於工程化,這些技術是遠遠不夠的。


我們在實現商業編碼器還面臨以上幾點難題。首先,實時性能,我們現在通過直播或點播這類業務,觀衆對於30fps、60fps這種實時應用要求非常高,像低分辨率的360P或720P要求30fps,但如果是高分辨率1080P、4K對時間尺度上fps要求也會提高,基本上是60fps。除了實時性的要求,現在對高清內容的要求也越來越多,比如1080P、2K、4K甚至8K的支持。即使做到實時高清性也要保證低延遲,因爲實際的網絡環境是極其複雜的,我們會遇到窄帶或者弱網傳輸,我們要保證這種網絡環境下,視頻的流暢傳輸。最後一部分希望視頻可以在更多的平臺上分發,所以對於CPU的佔用越小越好,能夠適用編解碼器,對於硬件的兼容性要友好。


爲了解決這些問題,我們在工程化中要解決這些問題,比如說碼控技術,一些快速算法、快劃分技術的提升,指令集優化、視頻前後處理技術以及私有協議的構建。下面會依次介紹各個部分的內容。

2.1 碼控技術


我們一般會用CQP測一下算法,CQP即恆定QP值,他會給編碼器中每個塊設定一樣的QP值,根據QP值分配每個CU的碼率,決策出最好的模式。這種情況下,有個碼率不固定的問題,所以主要用於模型測試。如果做商用在帶寬有限的情況下,我們會使用一些控制碼率的技術,比如說CBR/ABR技術。對於VBR和CRF,這兩種碼控技術對碼率控制還不是那麼好,VBR對於碼率壓縮效率比較高,在相同編碼質量下,編碼質量比較高,圖像呈現比較好。實時直播情況下,更多用到的是ABR和CBR,這種技術好多商業編碼器對它們並沒有做很大區分,ABR/CBR提前設定好一個碼率,根據碼率估計每個CU的碼率進行動態調節,最後使碼率固定在一個範圍內,不會超發和少發的情況出現。

爲了實現商業編碼器的碼率控制,我們在技術領域首先做到的是AQ技術,AQ的Q即QP值,AQ即Adaptive QP值,動態調節QP。對於實時編碼器,一般都是1-pass的情況下,在編碼前需要估計每個CU的碼率,在編碼過程中也會根據已編碼率動態調節QP。在AQ技術基礎上,又實現了一個CTU行級碼控,針對調節每個CTU行的碼率控制,如果前面CTU編的比較少,後面就多編點,如果前面CTU編的多後面就少編點碼率。幀級碼控道理是一樣的,現在幀級碼控基本是幾幀一起,作爲平均的碼控,碼率波動控制在可控範圍內。上線之後,這些碼率通過VQC技術去檢測控制,檢測到網絡狀況,下發碼率、幀率、分辨率。這種情況下,即有時候我們僅僅調節碼率,在720P情況下編出來很差,不如360P,就得去調分辨率,或者怎麼降分辨率也不能降低碼率,就要降低幀率,這樣調節這三個量,可以提高視頻的流暢度。碼控技術對於商業編碼器的重要性是無可言比的,主要工具實現後,如果沒有好的碼控技術調控,輸出的碼率是沒法達到商業編碼的標準,所以碼控技術對商業編碼器是非常重要的環節。

2.2 塊劃分技術


除了碼控,我們也討論了塊劃分技術,上圖舉例了MPEG系列的編碼器塊劃分圖。在最開始AVC的塊劃分中,只有BTQT兩種塊劃分。到後來HEVC中塊劃分 最大塊是64×64,最小塊是8×8,還有不同的PU劃分以及非對稱的矩形劃分。到VVC時出現了三叉劃分,最大塊達到了128×128。

這種大塊小塊的劃分,大塊主要是節省碼率,對於更高分辨率的內容,用大塊劃分的壓縮效率非常高。小塊更加精細圖像細節,用不同形狀的塊預測當前運動,把具體每個圖像中,每個塊都會表示出來。對這種複雜的塊劃分技術,我們在實際編碼器上線時,就需要簡化各種算法,使得這些塊劃分能夠更快找到最優模式。這個塊的算法在塊劃分預測模式中,應各個編碼器各自的情況,也是各自編碼器的核心技術。這些技術大家有專利或論文去研究這方面內容,但核心參數在論文中不會公開,需要各家編碼實驗嘗試,控制各個模塊的劃分技術。只有一個合適的快速劃分技術,我們才能在提高壓縮率的同時,提高編碼器的速度。

2.3 自研編碼器框架與快速算法


我們自研的編碼器框架在之前也測試過內部開銷,我們發現RDO的開銷是比較大的,我們是避免去做一些大塊RDO,先把主觀的黃色部分skip、split、Inter、Intra實現。然後將橙色部分塞進資源的快速算法,在快速算法中有個模塊進行分開測試,將快速算法進行上線。在做完這些部分後,做delay RDO,避免複雜的RDO運算,提高編碼的速度。通過這種分離式框架,我們方便測試每個快速算法的效果,如果哪個部分出問題需要哪部分的算法,在自己的訓練上包括標準訓練上,都測試了算法結果。

2.4 視頻前後處理技術


接下來介紹視頻前後處理技術,我們不僅 聚焦在編碼器內部優化,我們還在前後處理上提供了ROI的視頻編解碼技術。我們通過檢測ROI的人臉或者人像區域化,提供去噪算法,動態調節碼率,非ROI區域碼率降低,ROI區域碼率升高,在弱網或背景固定場景下,我們提高了畫質。右圖的畫質圖可以明顯看出,於ROI編碼的人臉部分處理更好,非ROI編碼上,人臉部分就不如右邊清晰。通過截取兩幀視頻,可以直觀感受出它的效果。


在一些場景下,可能沒法發送很高分辨率的圖像,我們可以通過超分技術提高當前分辨率。上圖左邊是基礎的雙線性拉伸的超分,右邊是基於深度學習的超分,效果比雙線性好很多。在比如下發720P的情況下,可以超分到1080P,給用戶提供更清晰的感覺。對於超分我們有自研的深度學習背景框架,在AI的支持下將我們的背景框架落地,把超分實現在我們的端側。相較於傳統的超分效果,我們把編碼器的小分辨率圖像進行超分後的SSIM、PSNR效果更好。在網絡受限的情況下,在端側給觀衆的主觀體驗感更好。

2.5 私有協議的構建


目前主流公開的編解碼協議都有專利保護,自己要做編解碼引擎其實有一定的專研風險的,其次我們對用戶內容的隱私保護,私有協議化提供我們自己的編碼器能夠互通互解,這樣外人沒辦法解出我們的碼流。另一方面私有協議能夠提高壓縮率,降低視頻對CPU開銷的影響,通過各方面優化視頻編碼器。在實現自有協議NEVC的情況下,主要考慮以下幾點,首先是專利保護,我們寫了一些專利去申請專利保護我們的協議。第二部分是與公有協議的兼容性,解碼器要兼容現有主流的AVC、HEVC的碼流,這些碼流過來我們也能解出來,使得解碼器的兼容性更好。另一部分是實現的複雜度,畢竟是商業編碼器,要在幾個季度工作時間內把協議實現,並上線部署。主要流程是設計文檔、工程仿真、撰寫專利、工程落地,這部分是我們一個團隊共同完成的,這樣就把一個成果落地實施了。


NEVC與傳統x264相比,速度想當的情況下,壓縮質量提高30%,與x265相比下,質量想當但速度是它的50倍,根據編碼器的快速算法可以給私有協議劃分不同的檔次級別。作爲商業編碼器,在速度方面最快可以達到x265的70/80倍,但質量會變差。


以上是兩張主觀圖,在600kb/s的碼率下,720P與x264的對比。可以從圖中 看出,人臉這部分NEVC的私有協議人臉仍然是可以比較清晰的編碼出來,但x264人臉信息丟失比較嚴重。左邊背景塊的紋理信息,x264也沒有辦法很好的編出來,但在NEVC自有協議下,仍然可以將紋理信息編碼清楚。


另外與x265做對比,相近編碼速度下,我們對天空的背景、屋頂等細節部分處理都比x265要好得多。包括柱子部分的信息,x265在編碼時,暗處信息完全丟失,但在NEVC編碼時,可以展示出來。

2.6 基於WebRTC的音視頻引擎


最後我們說一下,怎麼把自有編碼器寄存到RTC業務中。首先說到RTC,不可避免的提到WebRTC這個音視頻引擎,WebRTC作爲一個能夠提供實時音視頻直播和通話的框架,其優點也是很明顯的,簡單易用、多平臺支持、免費開源。但它也有缺點,它自身自帶的音視頻引擎能力明顯不足,還使用了openh264或者VP8等技術是無法滿足商用的實施要求的。對多人場景的支持度也不夠,當人數過多時對編碼接入就比較卡頓,像WebRTC這種P2P最多隻能支持8、9個人,如果有服務器P2S支持度就會更高。對於傳輸質量也沒有可靠的保證,也沒有對Native應用的開發。我們今天主要解決音視頻能力不足的問題,我們將自研編碼器集成到RTC中。

2.7 NE-RTC中視頻編解碼引擎


在我們自己的NE-RTC編解碼器中,首先NE-RTC支持4個端,PC端、安卓手機端、MAC端以及IOS端。將編解碼引擎放進去肯定需要Video factory中去構建編碼實現和解碼實現,這部分我們集成了一個軟件平臺上的編解碼引擎,這個引擎通過放到RTC中,調用外部的Code。

這個Code我們也做了一個指令集的優化,目前PC/MAC還是x86加工合作sse\avx的優化,IOS和安卓做了arm的優化。這部分放進去之後,由於私有協議,我們現在能做到的大部分終端會支持,但事實上也不是所有設備都能支持,所以還需要一個白名單控制這部分編解碼器的開啓。這樣我們就通過與服務器的交互,服務器上我們需要對碼流NAL的parse,需要知道我們是私有協議還是公有的。另一部分是轉碼錄製,需要在服務器上實現解碼和轉碼的工作,通過轉碼錄製把視頻存下來。其次還有Codec信令下發,因爲白名單控制現在NE-RTC集成了多套編解碼器,通過Codec信令下發控制Codec的切換。所以在服務器上我們實現了這麼多工作,支持我們引擎的工作。像這種引擎我們一般做在單側,比如做在PC、MAC或者安卓和IOS中,剩下做在信令服務器或者媒體服務器上。


我們來看下效果,通過自己demo實現了一個至少在大流放上了私有協議,能夠做到高清低延遲,使得整個視頻觀感以及網絡帶寬的佔比更小。小流上由於分辨率比較低,目前小流用的180P等,小分辨率首先保證流程用的是公有的264編碼器,使得CPU佔用低,省資源,但目前更多的還是看大流的內容。

3
網易雲信的業務與發展方向




接下來會簡單介紹一下我們把商業編碼器應用到業務或發展中的情況。


商業編碼器最重要的是用到自己的通信或者是直播場景中,在線上發現問題,編碼器內部可能有些問題在實驗中是無法發現的,但在線上搭配我們百萬級、千萬級用戶使用的情況下,可以使得編碼器的問題暴露,及時改進,提供更優的編碼器效果。進一步也需要參與音視頻標準制定,將我們的音視頻做到標準化,就可以用現有的音視頻框架,構建和改進技術。另一部分是積極的在會議上發表我們的文章,或者在專利上保護我們的技術,讓更多人瞭解我們的技術。更重要的是與高校產生合作,通過高校最新技術改進編解碼的技術內容。

Q/A環節:

問:硬解應該無法支持NEVC的吧,是否只能用在封閉系統中?
答: 硬解無法支持,只能支持軟解。

問:有沒有考慮導入第三方硬編外設?
答: 這個考慮過,在一些機型上會適配硬編硬解,但硬編的功耗會增加。

問:商業化編碼器會消耗端上的性能,端上如何選擇是用硬編還是軟編NEVC?
答: 會用白名單裏控制,相同帶寬下,軟編的NEVC提供更好的畫質體驗。

問:CRF 碼率控制中,CRF比較常用的取值?用什麼算法能夠更好的評價使用後的質量變化效果?
答: 碼控是個很複雜的內容,通過評價來調整碼控有很多方法,例如傳統的JND模型,或者現在比較流行的深度學習評價方法,都可以改善碼控。

問:基於ROI的視頻編碼網易雲信目前有具體應用在哪些場景嗎?效果如何?
答: 目前處於自研階段,後期根據產品情況上線會議或直播場景,效果只展示了部分實驗數據,後面上線後會有更多評測數據。

LiveVideoStackCon 2021 ShangHai
我們準備好全新的內容
在上海歡迎您的到來

LiveVideoStackCon 2021 上海站
北京時間:2021年4月16日-4月17日

點擊 【閱讀原文】瞭解大會詳情

本文分享自微信公衆號 - LiveVideoStack(livevideostack)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章