網(wǎng)易云信RTC業(yè)務(wù)場景下的編解碼技術(shù)優(yōu)化與實(shí)踐

視頻編解碼技術(shù)一直是視頻內(nèi)容應(yīng)用中的核心業(yè)務(wù)，基于各個(gè)平臺(tái)和各個(gè)渠道的視頻內(nèi)容采集與分發(fā)都涉及到視頻編解碼技術(shù)的介入。在RTC業(yè)務(wù)場景下，如何構(gòu)建高效快速的視頻編解碼引擎，如何對(duì)現(xiàn)有的編解碼技術(shù)進(jìn)行優(yōu)化改進(jìn)，如何在公有協(xié)議基礎(chǔ)上實(shí)現(xiàn)私有協(xié)議，如何重寫編解碼框架等問題都值得關(guān)注。我們邀請(qǐng)到了網(wǎng)易云信 音視頻算法工程師 何鳴 為大家詳細(xì)介紹網(wǎng)易云信RTC業(yè)務(wù)場景下的編解碼技術(shù)優(yōu)化與實(shí)踐，以及未來的發(fā)展方向。

大家好，我是來自網(wǎng)易云信的何鳴，目前主要負(fù)責(zé)網(wǎng)易云信G2音視頻框架中視頻編解碼引擎的開發(fā)與優(yōu)化工作。 本次分享的內(nèi)容主要有以下三個(gè)方面：

1 視頻編解碼器技術(shù)背景

通過實(shí)時(shí)通訊，或者是高清直播的方式為用戶提供視頻內(nèi)容，視頻內(nèi)容每天都在網(wǎng)絡(luò)中產(chǎn)生并收發(fā)，這些視頻內(nèi)容都是被壓縮過的，這個(gè)壓縮過程就是要實(shí)行編解碼技術(shù)，現(xiàn)在除了少部分的電影拍攝場景可能會(huì)用到原始視頻流，大部分視頻都是經(jīng)過編解碼壓縮過后的視頻內(nèi)容。所以，視頻編解碼技術(shù)在視頻內(nèi)容的產(chǎn)生與分發(fā)過程中至關(guān)重要。

接下來我們討論下來，視頻編解碼技術(shù)究竟運(yùn)用在什么地方呢？像一個(gè)視頻序列當(dāng)中，常見的YUV視頻中，一個(gè)像素點(diǎn)就需要1.5個(gè)字節(jié)的數(shù)據(jù)來存儲(chǔ)像素點(diǎn)。如果涉及到360P、720P、4K這樣的視頻的話，數(shù)據(jù)量是呈指數(shù)級(jí)的上升，到4K時(shí)每秒需要傳輸數(shù)據(jù)達(dá)到了759MB。與之對(duì)比，5G的傳輸帶寬1Gb/s換算成字節(jié)表示的話，就是125MB/s。這樣的傳輸帶寬是遠(yuǎn)遠(yuǎn)不能滿足于我們對(duì)高清視頻內(nèi)容的要求，所以就需要視頻編碼技術(shù)對(duì)視頻進(jìn)行壓縮處理。 我們現(xiàn)在常用的視頻編碼技術(shù)是預(yù)測器+量化器+熵編碼器的一個(gè)基本框架，其中量化器的話需要進(jìn)行反量化操作，下方我們會(huì)詳細(xì)介紹這三部分各起到什么作用?；谶@三部分框架，我們將視頻重新劃分為I幀、B幀和P幀，具體在哪些內(nèi)容會(huì)遇到這些幀，接下來也會(huì)詳細(xì)介紹。 1.1 預(yù)測器

首先我們說預(yù)測器，預(yù)測器我們劃分為幀內(nèi)預(yù)測和幀間預(yù)測，在幀內(nèi)預(yù)測中，以HEVC角度預(yù)測為例，最新的技術(shù)發(fā)展VVC技術(shù)也只是將角度的方向增加了更多，預(yù)測的內(nèi)容更加豐富，但總的來說還是角度預(yù)測、DC預(yù)測、平面預(yù)測。 幀內(nèi)預(yù)測指預(yù)測內(nèi)容全部來自本幀內(nèi)，它的像素點(diǎn)是由它的當(dāng)前塊重建出來的，所以預(yù)測方式所需要的參考方式全部來自當(dāng)前幀，故稱作幀內(nèi)預(yù)測。 與之對(duì)應(yīng)的幀間預(yù)測，就需要構(gòu)建參考幀信息，通過參考幀中尋找到的塊來補(bǔ)償當(dāng)前塊，當(dāng)前塊與參考?jí)K之間的運(yùn)動(dòng)關(guān)系，我們稱為運(yùn)動(dòng)矢量。在傳輸時(shí)需要將運(yùn)動(dòng)矢量傳輸?shù)浇獯a端，通過解碼出運(yùn)動(dòng)矢量，在解碼幀中重新構(gòu)建當(dāng)前塊。這樣僅僅通過傳輸一些運(yùn)動(dòng)矢量信息，就可以快速構(gòu)建當(dāng)前塊，所以幀間預(yù)測是提高壓縮效率的主要辦法?，F(xiàn)在根據(jù)新技術(shù)，比如Affine技術(shù)可以對(duì)一些塊的平移、旋轉(zhuǎn)、縮放進(jìn)行預(yù)測?；蛘呶覀冎苯邮褂每s放對(duì)塊進(jìn)行預(yù)測，最新的有些論文中也提到對(duì)預(yù)測方式的改進(jìn)。此外，構(gòu)建多參考幀可以在其中選擇多個(gè)參考幀作為對(duì)當(dāng)前預(yù)測幀的候選，這樣我們可以選出更好的塊來預(yù)測當(dāng)前塊。 作為視頻編解碼技術(shù)中的預(yù)測器技術(shù)，它也是在不斷的發(fā)展中，從最開始的H261、H263到最近的VVC技術(shù)，我們每代標(biāo)準(zhǔn)也是豐富了預(yù)測器技術(shù)。 1.2 量化器

先簡單看一下Lena圖經(jīng)過DCT變換和反變換后的區(qū)別，從肉眼上看我們對(duì)變換和反變換是看不出差別的，但我們中間的頻域圖的能量大部分集中在0附近，且能量特別大的信息是比較少的。我們對(duì)這部分信息可以通過量化器進(jìn)行量化，生成量化系數(shù)，對(duì)原圖的信息壓縮就達(dá)到了，所以量化有壓縮數(shù)據(jù)的功能。在實(shí)際編解碼應(yīng)用過程中是通過預(yù)測器預(yù)測之后，將殘差圖經(jīng)過變換之后再送量化器生成量化系數(shù)。所以量化器是在預(yù)測器的基礎(chǔ)上進(jìn)一步提高壓縮率。 1.3 熵編碼器

熵編碼器依賴香農(nóng)的第一定律，由于第一定律規(guī)定了編碼一旦有損信源編碼時(shí)，我們有一個(gè)固定的碼長。明確編碼器是一種信源編碼，信源編碼要盡可能去壓縮碼流，將壓縮過的碼流送到信道中，通過信道傳輸后再用解碼器還原出來。所以熵編碼器中我們主要涉及到無損編碼功能，像我們現(xiàn)在常用的哈夫曼編碼、指數(shù)哥倫布編碼或者游程編碼這種可以提高壓縮效率。但在最新編碼器技術(shù)中，基于上下文模型的算術(shù)編碼對(duì)壓縮率提高是極大的，它對(duì)于大概率、小概率符號(hào)生成不同的碼率，極大的壓縮信息量。變換器和預(yù)測器生成的信息會(huì)送到熵編碼器后進(jìn)行進(jìn)一步的壓縮再送入信道中。 2 視頻編解碼引擎工程化 上述部分我們主要簡單介紹了一下編碼器的技術(shù)背景，但我們要實(shí)現(xiàn)商業(yè)編碼器相當(dāng)于工程化，這些技術(shù)是遠(yuǎn)遠(yuǎn)不夠的。

我們?cè)趯?shí)現(xiàn)商業(yè)編碼器還面臨以上幾點(diǎn)難題。首先，實(shí)時(shí)性能，我們現(xiàn)在通過直播或點(diǎn)播這類業(yè)務(wù)，觀眾對(duì)于30fps、60fps這種實(shí)時(shí)應(yīng)用要求非常高，像低分辨率的360P或720P要求30fps，但如果是高分辨率1080P、4K對(duì)時(shí)間尺度上fps要求也會(huì)提高，基本上是60fps。除了實(shí)時(shí)性的要求，現(xiàn)在對(duì)高清內(nèi)容的要求也越來越多，比如1080P、2K、4K甚至8K的支持。即使做到實(shí)時(shí)高清性也要保證低延遲，因?yàn)閷?shí)際的網(wǎng)絡(luò)環(huán)境是極其復(fù)雜的，我們會(huì)遇到窄帶或者弱網(wǎng)傳輸，我們要保證這種網(wǎng)絡(luò)環(huán)境下，視頻的流暢傳輸。最后一部分希望視頻可以在更多的平臺(tái)上分發(fā)，所以對(duì)于CPU的占用越小越好，能夠適用編解碼器，對(duì)于硬件的兼容性要友好。

為了解決這些問題，我們?cè)诠こ袒幸鉀Q這些問題，比如說碼控技術(shù)，一些快速算法、快劃分技術(shù)的提升，指令集優(yōu)化、視頻前后處理技術(shù)以及私有協(xié)議的構(gòu)建。下面會(huì)依次介紹各個(gè)部分的內(nèi)容。 2.1 碼控技術(shù)

我們一般會(huì)用CQP測一下算法，CQP即恒定QP值，他會(huì)給編碼器中每個(gè)塊設(shè)定一樣的QP值，根據(jù)QP值分配每個(gè)CU的碼率，決策出最好的模式。這種情況下，有個(gè)碼率不固定的問題，所以主要用于模型測試。如果做商用在帶寬有限的情況下，我們會(huì)使用一些控制碼率的技術(shù)，比如說CBR/ABR技術(shù)。對(duì)于VBR和CRF，這兩種碼控技術(shù)對(duì)碼率控制還不是那么好，VBR對(duì)于碼率壓縮效率比較高，在相同編碼質(zhì)量下，編碼質(zhì)量比較高，圖像呈現(xiàn)比較好。實(shí)時(shí)直播情況下，更多用到的是ABR和CBR，這種技術(shù)好多商業(yè)編碼器對(duì)它們并沒有做很大區(qū)分，ABR/CBR提前設(shè)定好一個(gè)碼率，根據(jù)碼率估計(jì)每個(gè)CU的碼率進(jìn)行動(dòng)態(tài)調(diào)節(jié)，最后使碼率固定在一個(gè)范圍內(nèi)，不會(huì)超發(fā)和少發(fā)的情況出現(xiàn)。 為了實(shí)現(xiàn)商業(yè)編碼器的碼率控制，我們?cè)诩夹g(shù)領(lǐng)域首先做到的是AQ技術(shù)，AQ的Q即QP值，AQ即Adaptive QP值，動(dòng)態(tài)調(diào)節(jié)QP。對(duì)于實(shí)時(shí)編碼器，一般都是1-pass的情況下，在編碼前需要估計(jì)每個(gè)CU的碼率，在編碼過程中也會(huì)根據(jù)已編碼率動(dòng)態(tài)調(diào)節(jié)QP。在AQ技術(shù)基礎(chǔ)上，又實(shí)現(xiàn)了一個(gè)CTU行級(jí)碼控，針對(duì)調(diào)節(jié)每個(gè)CTU行的碼率控制，如果前面CTU編的比較少，后面就多編點(diǎn)，如果前面CTU編的多后面就少編點(diǎn)碼率。幀級(jí)碼控道理是一樣的，現(xiàn)在幀級(jí)碼控基本是幾幀一起，作為平均的碼控，碼率波動(dòng)控制在可控范圍內(nèi)。上線之后，這些碼率通過VQC技術(shù)去檢測控制，檢測到網(wǎng)絡(luò)狀況，下發(fā)碼率、幀率、分辨率。這種情況下，即有時(shí)候我們僅僅調(diào)節(jié)碼率，在720P情況下編出來很差，不如360P，就得去調(diào)分辨率，或者怎么降分辨率也不能降低碼率，就要降低幀率，這樣調(diào)節(jié)這三個(gè)量，可以提高視頻的流暢度。碼控技術(shù)對(duì)于商業(yè)編碼器的重要性是無可言比的，主要工具實(shí)現(xiàn)后，如果沒有好的碼控技術(shù)調(diào)控，輸出的碼率是沒法達(dá)到商業(yè)編碼的標(biāo)準(zhǔn)，所以碼控技術(shù)對(duì)商業(yè)編碼器是非常重要的環(huán)節(jié)。 2.2 塊劃分技術(shù)

除了碼控，我們也討論了塊劃分技術(shù)，上圖舉例了MPEG系列的編碼器塊劃分圖。在最開始AVC的塊劃分中，只有BTQT兩種塊劃分。到后來HEVC中塊劃分最大塊是64×64，最小塊是8×8，還有不同的PU劃分以及非對(duì)稱的矩形劃分。到VVC時(shí)出現(xiàn)了三叉劃分，最大塊達(dá)到了128×128。 這種大塊小塊的劃分，大塊主要是節(jié)省碼率，對(duì)于更高分辨率的內(nèi)容，用大塊劃分的壓縮效率非常高。小塊更加精細(xì)圖像細(xì)節(jié)，用不同形狀的塊預(yù)測當(dāng)前運(yùn)動(dòng)，把具體每個(gè)圖像中，每個(gè)塊都會(huì)表示出來。對(duì)這種復(fù)雜的塊劃分技術(shù)，我們?cè)趯?shí)際編碼器上線時(shí)，就需要簡化各種算法，使得這些塊劃分能夠更快找到最優(yōu)模式。這個(gè)塊的算法在塊劃分預(yù)測模式中，應(yīng)各個(gè)編碼器各自的情況，也是各自編碼器的核心技術(shù)。這些技術(shù)大家有專利或論文去研究這方面內(nèi)容，但核心參數(shù)在論文中不會(huì)公開，需要各家編碼實(shí)驗(yàn)嘗試，控制各個(gè)模塊的劃分技術(shù)。只有一個(gè)合適的快速劃分技術(shù)，我們才能在提高壓縮率的同時(shí)，提高編碼器的速度。 2.3 自研編碼器框架與快速算法

我們自研的編碼器框架在之前也測試過內(nèi)部開銷，我們發(fā)現(xiàn)RDO的開銷是比較大的，我們是避免去做一些大塊RDO，先把主觀的黃色部分skip、split、Inter、Intra實(shí)現(xiàn)。然后將橙色部分塞進(jìn)資源的快速算法，在快速算法中有個(gè)模塊進(jìn)行分開測試，將快速算法進(jìn)行上線。在做完這些部分后，做delay RDO，避免復(fù)雜的RDO運(yùn)算，提高編碼的速度。通過這種分離式框架，我們方便測試每個(gè)快速算法的效果，如果哪個(gè)部分出問題需要哪部分的算法，在自己的訓(xùn)練上包括標(biāo)準(zhǔn)訓(xùn)練上，都測試了算法結(jié)果。 2.4 視頻前后處理技術(shù)

接下來介紹視頻前后處理技術(shù)，我們不僅聚焦在編碼器內(nèi)部優(yōu)化，我們還在前后處理上提供了ROI的視頻編解碼技術(shù)。我們通過檢測ROI的人臉或者人像區(qū)域化，提供去噪算法，動(dòng)態(tài)調(diào)節(jié)碼率，非ROI區(qū)域碼率降低，ROI區(qū)域碼率升高，在弱網(wǎng)或背景固定場景下，我們提高了畫質(zhì)。右圖的畫質(zhì)圖可以明顯看出，趨于ROI編碼的人臉部分處理更好，非ROI編碼上，人臉部分就不如右邊清晰。通過截取兩幀視頻，可以直觀感受出它的效果。

在一些場景下，可能沒法發(fā)送很高分辨率的圖像，我們可以通過超分技術(shù)提高當(dāng)前分辨率。上圖左邊是基礎(chǔ)的雙線性拉伸的超分，右邊是基于深度學(xué)習(xí)的超分，效果比雙線性好很多。在比如下發(fā)720P的情況下，可以超分到1080P，給用戶提供更清晰的感覺。對(duì)于超分我們有自研的深度學(xué)習(xí)背景框架，在AI的支持下將我們的背景框架落地，把超分實(shí)現(xiàn)在我們的端側(cè)。相較于傳統(tǒng)的超分效果，我們把編碼器的小分辨率圖像進(jìn)行超分后的SSIM、PSNR效果更好。在網(wǎng)絡(luò)受限的情況下，在端側(cè)給觀眾的主觀體驗(yàn)感更好。 2.5 私有協(xié)議的構(gòu)建

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

NEVC與傳統(tǒng)x264相比，速度想當(dāng)?shù)那闆r下，壓縮質(zhì)量提高30%，與x265相比下，質(zhì)量想當(dāng)?shù)俣仁撬?0倍，根據(jù)編碼器的快速算法可以給私有協(xié)議劃分不同的檔次級(jí)別。作為商業(yè)編碼器，在速度方面最快可以達(dá)到x265的70/80倍，但質(zhì)量會(huì)變差。

以上是兩張主觀圖，在600kb/s的碼率下，720P與x264的對(duì)比?？梢詮膱D中看出，人臉這部分NEVC的私有協(xié)議人臉仍然是可以比較清晰的編碼出來，但x264人臉信息丟失比較嚴(yán)重。左邊背景塊的紋理信息，x264也沒有辦法很好的編出來，但在NEVC自有協(xié)議下，仍然可以將紋理信息編碼清楚。

另外與x265做對(duì)比，相近編碼速度下，我們對(duì)天空的背景、屋頂?shù)燃?xì)節(jié)部分處理都比x265要好得多。包括柱子部分的信息，x265在編碼時(shí)，暗處信息完全丟失，但在NEVC編碼時(shí)，可以展示出來。 2.6 基于WebRTC的音視頻引擎

最后我們說一下，怎么把自有編碼器寄存到RTC業(yè)務(wù)中。首先說到RTC，不可避免的提到WebRTC這個(gè)音視頻引擎，WebRTC作為一個(gè)能夠提供實(shí)時(shí)音視頻直播和通話的框架，其優(yōu)點(diǎn)也是很明顯的，簡單易用、多平臺(tái)支持、免費(fèi)開源。但它也有缺點(diǎn)，它自身自帶的音視頻引擎能力明顯不足，還使用了openh264或者VP8等技術(shù)是無法滿足商用的實(shí)施要求的。對(duì)多人場景的支持度也不夠，當(dāng)人數(shù)過多時(shí)對(duì)編碼接入就比較卡頓，像WebRTC這種P2P最多只能支持8、9個(gè)人，如果有服務(wù)器P2S支持度就會(huì)更高。對(duì)于傳輸質(zhì)量也沒有可靠的保證，也沒有對(duì)Native應(yīng)用的開發(fā)。我們今天主要解決音視頻能力不足的問題，我們將自研編碼器集成到RTC中。 2.7 NE-RTC中視頻編解碼引擎

在我們自己的NE-RTC編解碼器中，首先NE-RTC支持4個(gè)端，PC端、安卓手機(jī)端、MAC端以及IOS端。將編解碼引擎放進(jìn)去肯定需要Video factory中去構(gòu)建編碼實(shí)現(xiàn)和解碼實(shí)現(xiàn)，這部分我們集成了一個(gè)軟件平臺(tái)上的編解碼引擎，這個(gè)引擎通過放到RTC中，調(diào)用外部的Code。 這個(gè)Code我們也做了一個(gè)指令集的優(yōu)化，目前PC/MAC還是x86加工合作sseavx的優(yōu)化，IOS和安卓做了arm的優(yōu)化。這部分放進(jìn)去之后，由于私有協(xié)議，我們現(xiàn)在能做到的大部分終端會(huì)支持，但事實(shí)上也不是所有設(shè)備都能支持，所以還需要一個(gè)白名單控制這部分編解碼器的開啟。這樣我們就通過與服務(wù)器的交互，服務(wù)器上我們需要對(duì)碼流NAL的parse，需要知道我們是私有協(xié)議還是公有的。另一部分是轉(zhuǎn)碼錄制，需要在服務(wù)器上實(shí)現(xiàn)解碼和轉(zhuǎn)碼的工作，通過轉(zhuǎn)碼錄制把視頻存下來。其次還有Codec信令下發(fā)，因?yàn)榘酌麊慰刂片F(xiàn)在NE-RTC集成了多套編解碼器，通過Codec信令下發(fā)控制Codec的切換。所以在服務(wù)器上我們實(shí)現(xiàn)了這么多工作，支持我們引擎的工作。像這種引擎我們一般做在單側(cè)，比如做在PC、MAC或者安卓和IOS中，剩下做在信令服務(wù)器或者媒體服務(wù)器上。

我們來看下效果，通過自己demo實(shí)現(xiàn)了一個(gè)至少在大流放上了私有協(xié)議，能夠做到高清低延遲，使得整個(gè)視頻觀感以及網(wǎng)絡(luò)帶寬的占比更小。小流上由于分辨率比較低，目前小流用的180P等，小分辨率首先保證流程用的是公有的264編碼器，使得CPU占用低，省資源，但目前更多的還是看大流的內(nèi)容。 3 網(wǎng)易云信的業(yè)務(wù)與發(fā)展方向

接下來會(huì)簡單介紹一下我們把商業(yè)編碼器應(yīng)用到業(yè)務(wù)或發(fā)展中的情況。

商業(yè)編碼器最重要的是用到自己的通信或者是直播場景中，在線上發(fā)現(xiàn)問題，編碼器內(nèi)部可能有些問題在實(shí)驗(yàn)中是無法發(fā)現(xiàn)的，但在線上搭配我們百萬級(jí)、千萬級(jí)用戶使用的情況下，可以使得編碼器的問題暴露，及時(shí)改進(jìn)，提供更優(yōu)的編碼器效果。進(jìn)一步也需要參與音視頻標(biāo)準(zhǔn)制定，將我們的音視頻做到標(biāo)準(zhǔn)化，就可以用現(xiàn)有的音視頻框架，構(gòu)建和改進(jìn)技術(shù)。另一部分是積極的在會(huì)議上發(fā)表我們的文章，或者在專利上保護(hù)我們的技術(shù)，讓更多人了解我們的技術(shù)。更重要的是與高校產(chǎn)生合作，通過高校最新技術(shù)改進(jìn)編解碼的技術(shù)內(nèi)容。 Q/A環(huán)節(jié)：問：硬解應(yīng)該無法支持NEVC的吧，是否只能用在封閉系統(tǒng)中？答：硬解無法支持，只能支持軟解。 問：有沒有考慮導(dǎo)入第三方硬編外設(shè)？答：這個(gè)考慮過，在一些機(jī)型上會(huì)適配硬編硬解，但硬編的功耗會(huì)增加。 問：商業(yè)化編碼器會(huì)消耗端上的性能，端上如何選擇是用硬編還是軟編NEVC？答：會(huì)用白名單里控制，相同帶寬下，軟編的NEVC提供更好的畫質(zhì)體驗(yàn)。 問：CRF 碼率控制中，CRF比較常用的取值？用什么算法能夠更好的評(píng)價(jià)使用后的質(zhì)量變化效果？答：碼控是個(gè)很復(fù)雜的內(nèi)容，通過評(píng)價(jià)來調(diào)整碼控有很多方法，例如傳統(tǒng)的JND模型，或者現(xiàn)在比較流行的深度學(xué)習(xí)評(píng)價(jià)方法，都可以改善碼控。 問：基于ROI的視頻編碼網(wǎng)易云信目前有具體應(yīng)用在哪些場景嗎？效果如何？答：目前處于自研階段，后期根據(jù)產(chǎn)品情況上線會(huì)議或直播場景，效果只展示了部分實(shí)驗(yàn)數(shù)據(jù)，后面上線后會(huì)有更多評(píng)測數(shù)據(jù)。

責(zé)任編輯：lq