在 10 月 21 日 QCon上，融云視頻算法專(zhuān)家黃博士分享了《AI 算法在視頻可分級(jí)編碼(SVC)中的應(yīng)用》，從 ① 三種常用的可分級(jí)視頻編碼的特點(diǎn);②WebRTC 采用的編碼器及其應(yīng)用方式;③可分級(jí)編碼在 WebRTC 中的應(yīng)用現(xiàn)狀;④基于可分級(jí)編碼的目標(biāo)檢測(cè)和碼率分配方式;⑤AI 和可分級(jí)編碼結(jié)合的應(yīng)用前景和研究方向五部分深度拆解了 AI 與 SVC 相結(jié)合的應(yīng)用實(shí)踐。
一、三種常用可分級(jí)視頻編碼的特點(diǎn)
視頻圖像經(jīng)過(guò)數(shù)字化之后數(shù)據(jù)量非常大，現(xiàn)有的網(wǎng)絡(luò)和存儲(chǔ)設(shè)備無(wú)法直接存儲(chǔ)原始的視頻圖像，必須對(duì)視頻和圖像進(jìn)行壓縮，現(xiàn)有的主流壓縮視頻算法為 H.264，VP8，VP9，HEVC，VVC 等。一方面，從 H.264 到 VVC，編碼復(fù)雜度越來(lái)越高，壓縮效率也越來(lái)越高;另一方面，傳輸?shù)木W(wǎng)絡(luò)帶寬大小不一，且隨時(shí)變化，單一的碼流無(wú)法適應(yīng)多種不同接收端的網(wǎng)絡(luò)和設(shè)備環(huán)境。比如 4G 網(wǎng)絡(luò)和 5G 網(wǎng)絡(luò)傳輸帶寬不一樣，若在 4G 和 5G 網(wǎng)絡(luò)中傳輸同一套碼流，有可能會(huì)導(dǎo)致 5G 網(wǎng)絡(luò)帶寬沒(méi)有充分利用，最終影響視頻的觀看效果。
現(xiàn)在視頻應(yīng)用的環(huán)境存在多個(gè)不同的接收端，解決這個(gè)問(wèn)題可以采用以下兩種技術(shù)：聯(lián)播(Simulcast)和可分級(jí)視頻編碼(SVC)。
如圖 1 所示，聯(lián)播 Simulcast即同時(shí)傳輸多路碼流，不同的碼流具有不同的碼率，用以傳輸在不同帶寬下的碼流。當(dāng)終端設(shè)備處于高帶寬的網(wǎng)絡(luò)環(huán)境中，可以傳輸高碼率的視頻，以便獲得更好的視頻觀看體驗(yàn);當(dāng)終端設(shè)備處于低帶寬的網(wǎng)絡(luò)環(huán)境中，可以傳輸?shù)痛a率的視頻，以便減少視頻播放卡頓的現(xiàn)象。但是 Simulcast 支持的碼率種類(lèi)是有限的，難以適應(yīng)復(fù)雜的網(wǎng)絡(luò)環(huán)境。針對(duì)這個(gè)問(wèn)題，研究人員提出了可分級(jí)視頻編碼 SVC，視頻數(shù)據(jù)只壓縮一次，卻能以多個(gè)幀率、空間分辨率或視頻質(zhì)量進(jìn)行解碼。比如采用三層空域可分級(jí)和兩層時(shí)域可分級(jí)，可以組合的模式達(dá)到六種，和 Simulcast 方式相比，系統(tǒng)的適應(yīng)性得到很大提升。
(圖1 聯(lián)播&可分級(jí))
常用的可分級(jí)編碼有三種，分別是：空域可分級(jí)(Spatial Scalability)、質(zhì)量可分級(jí)(Quality Scalability)和時(shí)域可分級(jí)(Temporal Scalability)。
(圖2 可分級(jí)編碼常用的三種方式)
空域可分級(jí)編碼(圖 3 )，即對(duì)視頻中的每幀圖像產(chǎn)生多個(gè)不同空間分辨率的圖像，解碼基本層碼流得到的低分辨率圖像，如果加入增強(qiáng)層碼流到解碼器，得到的是高分辨率圖像。
(圖3 空域可分級(jí))
質(zhì)量可分級(jí)(圖 4 )，一個(gè)可行的做法是，基本層碼流編碼這一路對(duì)原始圖像 DCT 變換后進(jìn)行一次粗糙量化，熵編碼后形成基本層碼流。粗糙量化后的數(shù)據(jù)經(jīng)反量化后形成基本層系數(shù)，與原始圖像 DCT 變換系數(shù)相減形成差值信號(hào)，再對(duì)此差值信號(hào)再進(jìn)行一次細(xì)量化和熵編碼生成增強(qiáng)層碼流。
(圖4 質(zhì)量可分級(jí))
時(shí)域可分級(jí)(圖 5)，即把視頻序列不重疊地分割成多層，對(duì)基本層的幀進(jìn)行普通的視頻編碼，提供具有基本時(shí)間分辨率的基本層碼流;對(duì)增強(qiáng)層則是利用基本層數(shù)據(jù)對(duì)增強(qiáng)層的幀間預(yù)測(cè)編碼，生成增強(qiáng)層數(shù)據(jù)。
(圖5 時(shí)域可分級(jí))
二、WebRTC 采用的編碼器及其應(yīng)用方式
WebRTC 支持的編碼器包括 VP8，VP9 和 H.264。在用戶感受層面, VP8 和 H.264 兩種編碼器的效果基本上是類(lèi)似的。VP9 作為 VP8 的下一代編碼器，在高清視頻壓縮方面，比 VP8 和 H.264 效果要好。
如圖 6，綜合編碼器性能和瀏覽器編碼器的支持情況，可以得出如下結(jié)論：VP8 和 H.264編碼效果基本一致，一般情況下兩者皆可;VP9 主要用在 Google 公司自己的各種視頻產(chǎn)品中，其中需要特別指出的是，VP9 支持多種 SVC ;HEVC 目前只能在蘋(píng)果系統(tǒng)中使用，無(wú)法推廣，不建議使用;AV1 同樣太新了，僅僅在 Google 公司的產(chǎn)品中才能很好地支持，暫時(shí)不推薦。
(圖6 編碼器在瀏覽器中的支持情況)
三、可分級(jí)編碼在 WebRTC 中的應(yīng)用現(xiàn)狀
在介紹可分級(jí)編碼在 WebRTC 中的應(yīng)用情況之前，先簡(jiǎn)要介紹下 WebRTC 的通信和組網(wǎng)流程。
如圖 7，客戶端 A 和客戶端 B 通信，可以采用直連的模式，也可以采用服務(wù)器的模式，在大規(guī)模的網(wǎng)絡(luò)中，都會(huì)采用基于服務(wù)器的模式進(jìn)行轉(zhuǎn)發(fā)、信號(hào)處理等。
(圖7 WebRTC 簡(jiǎn)單的流程)
針對(duì)多種應(yīng)用場(chǎng)景具有多個(gè)接收端的特點(diǎn)，WebRTC 提供了三種解決方案：Mesh，MCU，SFU。
Mesh 方案(圖 8)，即多個(gè)終端之間兩兩進(jìn)行連接，形成一個(gè)網(wǎng)狀結(jié)構(gòu)。比如 A、B、C 三個(gè)終端進(jìn)行多對(duì)多通信，當(dāng) A 想要共享媒體(如音頻、視頻)時(shí)，它需要分別向 B 和 C 發(fā)送數(shù)據(jù)。同樣的道理，B 想要共享媒體，就需要分別向 A、C 發(fā)送數(shù)據(jù)，依此類(lèi)推。這種方案對(duì)各終端的帶寬要求比較高。
(圖8 Mesh 方案)
MCU(Multipoint Conferencing Unit)方案(圖 9)，該方案由一個(gè)服務(wù)器和多個(gè)終端組成一個(gè)星形結(jié)構(gòu)。各終端將自己要共享的音視頻流發(fā)送給服務(wù)器，服務(wù)器端會(huì)將在同一個(gè)房間中的所有終端的音視頻流進(jìn)行混合，最終生成一個(gè)混合后的音視頻流再發(fā)給各個(gè)終端，這樣各終端就可以看到/聽(tīng)到其他終端的音視頻了。實(shí)際上服務(wù)器端就是一個(gè)音視頻混合器，這種方案服務(wù)器的壓力會(huì)非常大。
(圖9 MCU 方案)
SFU(Selective Forwarding Unit)方案(圖 10)，該方案也是由一個(gè)服務(wù)器和多個(gè)終端組成，但與 MCU 不同的是，SFU 不對(duì)音視頻進(jìn)行混流，收到某個(gè)終端共享的音視頻流后，就直接將該音視頻流轉(zhuǎn)發(fā)給房間內(nèi)的其他終端。
(圖10 SFU 方案)
三種網(wǎng)絡(luò)不同的帶寬如圖 11 所示?？梢钥闯?，SFU 的帶寬最大達(dá)到了 25mbps，MCU 最小 10mbps。
(圖11 三種不同網(wǎng)絡(luò)的帶寬)
在特點(diǎn)方面，Mesh 方案的靈活性比較差;MCU 方案需要對(duì)碼流進(jìn)行類(lèi)似轉(zhuǎn)碼、合流、分流等操作;SFU 方案服務(wù)器的壓力小，靈活性更好，受到廣泛歡迎。
如圖 12 為 Simulcast 模式和 SVC 模式轉(zhuǎn)發(fā)方式示意圖。從上下兩個(gè)圖可以看出，采用基于 SVC 的碼流分配方式，對(duì)于 PC 端而言，具有更大的可修改性。無(wú)論采用哪種組網(wǎng)方式，采用 SVC 的方式，都會(huì)比采用 Simulcast 的方式具有更好的健壯性。
(圖12 Simulcast 和 SVC 模式轉(zhuǎn)發(fā)方式)
支持情況如圖 13 所示。從圖中可以看出，H.264 僅支持 Simulcast，VP8 支持時(shí)域可分級(jí)，VP9 則全方位支持 SVC 編碼。VP9 是 Google 公司在主推的編解碼器，但是在 H.264 編解碼器優(yōu)化方面的推進(jìn)力度不大，一定程度上限制了 WebRTC 的應(yīng)用，比如蘋(píng)果公司最新出品的 iPhone13 手機(jī)自帶 H.264 的硬件加速功能，如果采用 AV1 編碼器，雖然可以獲得 SVC 的優(yōu)點(diǎn)，但是無(wú)法進(jìn)行硬件解碼。在 WebRTC 中，Simulcast 是默認(rèn)通過(guò)多線程技術(shù)，同時(shí)啟動(dòng)多個(gè) OpenH264 編碼器, SVC 則是可以調(diào)用 OpenH264 進(jìn)行時(shí)域和空域可分級(jí)編碼。
(圖13 可分級(jí)編碼在 WebRTC 的支持情況)
四、基于可分級(jí)編碼的目標(biāo)檢測(cè)和碼率分配方案
對(duì)于 N 路的 SFU 而言，SFU 必須考慮剩余 N-1 個(gè)終端碼率總和。對(duì)于大多數(shù)視頻會(huì)議而言，在給定的時(shí)域和空域?qū)訔l件下的碼率和總碼率比例基本恒定。如圖 14 所示。
(圖14 不同層碼流分布圖)
根據(jù)圖 14 的現(xiàn)象，將視頻運(yùn)動(dòng)作為一個(gè)主要是衡量指標(biāo)，對(duì)碼流進(jìn)行分配。相關(guān)論文具體的方案框架如圖 15 所示。
(圖15 SVC 編碼器碼率分配)
該方案存在兩個(gè)改進(jìn)空間：第一個(gè)是運(yùn)動(dòng)量度的方法采用的當(dāng)前幀和前一幀的差，難以準(zhǔn)確地反映出視頻運(yùn)動(dòng)變化的情況。第二個(gè)是增加除了運(yùn)動(dòng)特征以外的其他特征，以便更好地反映圖像視頻的變化。擬采用的解決方案如圖 16 所示。
(圖16 擬采用的解決方案)
在 WebRTC 中，H.264 的編碼器采用思科公司開(kāi)源的 OpenH264 編碼器，OpenH264 可分級(jí)編碼配置文件展示如下。這個(gè)配置文件設(shè)置了時(shí)域分級(jí)層兩層。
SVC 碼流的特點(diǎn)是一套碼流具有多層結(jié)構(gòu)，在實(shí)際使用中，需要對(duì)碼流進(jìn)行提取操作。對(duì)于時(shí)域可分級(jí)而言，通過(guò)分析每個(gè) NAL 中的 Temporal ID 對(duì)碼流進(jìn)行提取;對(duì)于空域可分級(jí)而言，通過(guò)分析每個(gè) NAL 中的 Spatial ID 對(duì)碼流進(jìn)行提取;對(duì)于質(zhì)量可分級(jí)而言，通過(guò)分析每個(gè) NAL 中的 Quality ID 對(duì)碼流進(jìn)行提取。
從圖 17 中可以看出，OpenH264 的基本層的碼流可以直接采用 AVC 解碼器解碼，基本層的 SVC_extension_flag 等于1。
(圖17 可分級(jí)編碼基本層解碼圖)
SVC 增強(qiáng)層碼流的 NAL 包含 SVC 的語(yǔ)法，需要對(duì) SVC 的碼流進(jìn)行轉(zhuǎn)碼，可分級(jí)編碼的參考軟件 JSVM 中有專(zhuān)門(mén)的轉(zhuǎn)碼模塊，圖 18 為轉(zhuǎn)碼過(guò)程，可以發(fā)現(xiàn)多個(gè) NAL 單元被重寫(xiě)成 AVC 的格式。
(圖18 可分級(jí)編碼增強(qiáng)層 NAL 層轉(zhuǎn)碼)
圖 19 為用 JSVM 轉(zhuǎn)換之后的碼流解碼效果，可以用標(biāo)準(zhǔn)的 AVC 解碼器解碼。
(圖19 NAL 層轉(zhuǎn)碼后的解碼圖)
五、AI 和可分級(jí)編碼結(jié)合的應(yīng)用前景和研究方向
可分級(jí)編碼中最頻繁使用的方法是空域可分級(jí)技術(shù)，但是不同分辨率在轉(zhuǎn)換時(shí)，質(zhì)量下降比較明顯。ICME2020 會(huì)議上，有學(xué)者提出了用于視頻編碼的超分辨模型，該模型通過(guò)提取不同時(shí)刻的圖像進(jìn)行特征融合來(lái)重建出高分辨率圖像。實(shí)驗(yàn)結(jié)果表明，超分效果有提升。
(圖20 視頻超分辨率結(jié)構(gòu)圖)
將該模型用于可分級(jí)編碼器中，可以有效地改善不同分辨率碼流切換的時(shí)候，給人帶來(lái)的不適感。
MPEG5 提出了 Low Complexity Enhancement Video Coding(LCEVC)，該編碼方式和 H.264 相比，在相同的 PSNR 下，壓縮效率更高。編碼器如圖 21 所示。其中基本的編碼器 Base Encoder 可以選用任意一種現(xiàn)成的編碼器，比如 H.264，VP8，VP9 等。
WebRTC 和 LCEVC 相互結(jié)合，是未來(lái)的一個(gè)發(fā)展方向。作為一個(gè)新的視頻編碼標(biāo)準(zhǔn)，其具有幾個(gè)特征：提升了基本層編碼的壓縮能力，具有低編碼和解碼復(fù)雜度，提供了一個(gè)額外的特征增強(qiáng)平臺(tái)等。
從圖 21 可以看出，編碼復(fù)雜度主要在取決于 Base Encoder，在 WebRTC 中廣泛使用的 H.264 如果采用 LCEVC 的方式進(jìn)行增強(qiáng)，在復(fù)雜度增加的情況下，編碼效果會(huì)有明顯地提升。一般而言采用 H.264 編碼的 1080P 高幀率的實(shí)時(shí)體育視頻流需要 8Mbps 的最高碼率，而采用 LCEVC 僅僅需要 4.8Mbps。
(圖21 LCEVC 編碼器)
鑒于 LCEVC 編碼的效果，可以判斷，LCEVC 和 WebRTC 結(jié)合，將是一個(gè)重要的研究和應(yīng)用方向。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。 ）
