大家好，今天跟大家分享下在支持4K/8K超高清視頻的實(shí)時(shí)編碼、媒體處理、系統(tǒng)架構(gòu)、專(zhuān)有云流量分發(fā)所遇到的困難和挑戰(zhàn)，希望能給大家?guī)?lái)幫助。

分享內(nèi)容分為六個(gè)部分：

01

4K/8K超高清視頻的背景

隨著央視冬奧會(huì)和央視8K頻道的播出，超高清視頻已經(jīng)走進(jìn)了人們的生活，需求也逐步上升。然而，8K視頻的普及度仍然不夠，原因如下：

1、對(duì)原有的直播系統(tǒng)架構(gòu)帶來(lái)極大沖擊。比如，8K直播的碼率普遍高于100M。其次，通常直播流的分發(fā)要通過(guò)媒體處理的手段將8K的原始流轉(zhuǎn)成不同的分辨率、碼率、幀率之后再進(jìn)行分發(fā)。對(duì)系統(tǒng)的算力消耗、處理速度、處理成本帶來(lái)了新的難點(diǎn)。

除此之外，真8K的視頻制作流程也需要高昂的制作成本，導(dǎo)致8K的片源還比較稀少。但也許AI手段能提供一些幫助，例如將原本4K視頻超分至8K以達(dá)到8K的清晰度，來(lái)彌補(bǔ)高清片源稀少的問(wèn)題。一套成本低廉、壓縮率高且有一定增強(qiáng)能力的實(shí)時(shí)直播媒體處理平臺(tái)，以上問(wèn)題和痛點(diǎn)都可以解決。

基于這樣的背景，開(kāi)始投入超高清直播媒體處理平臺(tái)。首先遇到的問(wèn)題是技術(shù)選型，通過(guò)CPU的方式支持還是專(zhuān)有芯片的方式來(lái)支持。硬件方案的優(yōu)點(diǎn)是極高的編碼出幀穩(wěn)定性，低廉的計(jì)算成本。軟件方案的優(yōu)點(diǎn)是算法設(shè)計(jì)能更加靈活，純CPU編碼器可以通過(guò)算法設(shè)計(jì)達(dá)到比硬件方案更高的壓縮率。同時(shí)軟件方案的升級(jí)更加方便。如：原硬件芯片支持8K265編碼，后續(xù)若想要升級(jí)支持266編碼，對(duì)于硬件來(lái)說(shuō)需要重新設(shè)計(jì)，軟件則只需要進(jìn)行代碼升級(jí)即可，系統(tǒng)可以持續(xù)迭代支持最新的能力。

綜上考慮，最終的選型還是偏向純CPU的實(shí)時(shí)編碼方案。優(yōu)點(diǎn)是：壓縮率更高、能夠自由地?cái)U(kuò)展編碼器和解碼器、更容易支持復(fù)雜的邏輯和業(yè)務(wù)。另外，純CPU方案使用的是通用算力，當(dāng)不進(jìn)行8K轉(zhuǎn)碼的時(shí)候，可以很方便的釋放這部分資源進(jìn)行通用CPU算力利用。

目前我們達(dá)成的成果：

1、從8K的實(shí)時(shí)編碼來(lái)說(shuō)，8K單機(jī)能達(dá)到60FPS的實(shí)時(shí)編碼，分布式集群轉(zhuǎn)碼能達(dá)120FPS的實(shí)時(shí)編碼；

2、因?yàn)檐浖撵`活性，8K實(shí)時(shí)轉(zhuǎn)碼系統(tǒng)能夠支持所有主流視頻編解碼標(biāo)準(zhǔn)；

3、在2022 MSU最新編碼器評(píng)測(cè)報(bào)告，獲得全項(xiàng)最佳；

4、擁有100+項(xiàng)H.266/VCC編解碼專(zhuān)利技術(shù)。

02

編解碼加速

在對(duì)8K編碼器優(yōu)化時(shí)，主要分為兩個(gè)方向：

1、優(yōu)化編碼器的并行度，讓編碼器同時(shí)編碼更多幀，提高CPU資源利用率。目前我們支持多TILE并行編碼。在8K場(chǎng)景下，8K視頻幀的拷貝會(huì)成為耗時(shí)的操作，而編碼過(guò)程中避免不了將YUV標(biāo)準(zhǔn)排列格式轉(zhuǎn)為編碼器內(nèi)部?jī)?yōu)化后的YUV排列格式，這一過(guò)程需要進(jìn)行訪問(wèn)拷貝操作，為此我們支持了將8K視頻幀分為多個(gè)SLICE區(qū)間，每個(gè)SLICE一個(gè)線程來(lái)并行加速視頻幀拷貝過(guò)程。此外還支持預(yù)分析和幀級(jí)并行、幀間多線程解耦，根據(jù)層級(jí)特點(diǎn)自適應(yīng)選擇參考幀，提高整體編碼的并行度。

2、另一個(gè)方向是直接對(duì)編碼器算法進(jìn)行優(yōu)化。針對(duì)8K超高分辨率的編碼特性，可以通過(guò)預(yù)分析mvp跳過(guò)原先編碼器中的搜索過(guò)程；進(jìn)行幀內(nèi)幀間分析時(shí)，可以自適應(yīng)選擇先做幀內(nèi)還是幀間，進(jìn)行快速搜索。

在對(duì)編碼算法進(jìn)行加速優(yōu)化后，會(huì)發(fā)現(xiàn)8K場(chǎng)景/DCT耗時(shí)占比較大。為此支持了非標(biāo)DCT加速來(lái)提升整體速度。

對(duì)編碼器優(yōu)化后，純編碼的速度可以達(dá)到60甚至70FPS。但一旦將解碼加入處理流程中，整個(gè)系統(tǒng)的轉(zhuǎn)碼速度和效率發(fā)生極大的下降。

通常4K/1080P解碼并不需要耗費(fèi)很多資源，瓶頸往往都在編碼。但在8K場(chǎng)景，解碼成為了新的瓶頸。

比如：AVS3格式的解碼器，原生輸出的是NV12的格式，F(xiàn)Fmpeg中間有單線程進(jìn)行NV12到Y(jié)UV的轉(zhuǎn)換，最終輸出YUV進(jìn)行后續(xù)的操作。這樣的做法在4K/1080P分辨率下是沒(méi)問(wèn)題的，因?yàn)镹V12到Y(jié)UV的轉(zhuǎn)換是一個(gè)快速的操作，但8K場(chǎng)景下，NV12到Y(jié)UV的轉(zhuǎn)換速率很難滿(mǎn)足50FPS的要求，我們將NV12到Y(jié)UV的轉(zhuǎn)換移到了解碼器內(nèi)部。解碼之后會(huì)在多線程上進(jìn)行NV12到Y(jié)UV的轉(zhuǎn)換，來(lái)提升整體解碼速度。

8K分辨率多TILE的H.265碼流則是不同的方案。FFmpeg中H.265的特點(diǎn)是先把第一行完整地解碼完畢后,才會(huì)進(jìn)行解碼進(jìn)度更新，若遇到多TILE的情況解碼速度會(huì)大幅下降。如上圖所示，多TILE場(chǎng)景解碼完成前兩個(gè)TILE，并完成第三個(gè)TILE第一行時(shí)，才會(huì)更新解碼進(jìn)度，嚴(yán)重拖慢解碼器并行。我們基于多TILE場(chǎng)景對(duì)H.265解碼器進(jìn)行優(yōu)化，將二者結(jié)合，單TILE解碼完成行解碼后，就進(jìn)行進(jìn)度通知，優(yōu)化之后能夠達(dá)到單機(jī)50FPS以上的速度。

在優(yōu)化完編碼和解碼速率之后，我們發(fā)現(xiàn)線上同樣型號(hào)的兩臺(tái)128G內(nèi)存設(shè)備，處理速度相差較大。處理速度快的設(shè)備是8×16G的內(nèi)存，處理慢的設(shè)備是4×32G的內(nèi)存。

內(nèi)存帶寬限制在低分辨率的情況下表現(xiàn)正常，但對(duì)于8K高分辨率會(huì)造成很大的影響。例如，一個(gè)3.2GHz的CPU插了4個(gè)32G的內(nèi)存條，其內(nèi)存的瓶頸帶寬大概在102G，但如果要進(jìn)行8K50FPS10bit的實(shí)時(shí)編碼，也就是說(shuō)一秒需要傳輸?shù)臄?shù)據(jù)帶寬大概在4.7G。在實(shí)際操作中，內(nèi)存搬運(yùn)的過(guò)程只能占用編碼整體非常小的部分，大部分的時(shí)間還是留在編碼的運(yùn)算上。瞬時(shí)帶寬可能是4.7G的幾十倍，尤其是系統(tǒng)內(nèi)部還支持多線程并行視頻幀拷貝，導(dǎo)致瞬時(shí)帶寬增高，從而導(dǎo)致8K編碼的限速。

8K視頻編解碼對(duì)內(nèi)存帶寬的消耗極大，配置設(shè)備硬件時(shí)，需要注意根據(jù)CPU的Memory Channels來(lái)配置內(nèi)存，盡可能增加內(nèi)存帶寬。

以上這些出現(xiàn)的問(wèn)題說(shuō)明在8K場(chǎng)景下，每個(gè)操作都需要多加思考，可能僅僅多加了一個(gè)拷貝，就會(huì)導(dǎo)致系統(tǒng)的慢速導(dǎo)致達(dá)不到實(shí)時(shí)性。在這里對(duì)整個(gè)內(nèi)存池進(jìn)行了重構(gòu)，在解碼、前處理操作、打水印的時(shí)候不申請(qǐng)新的內(nèi)存，將所有操作原地處理，盡量將內(nèi)存數(shù)據(jù)拷貝只進(jìn)行一次。降低內(nèi)存使用的帶寬。

在優(yōu)化完編解碼速度、內(nèi)存之后，系統(tǒng)在大部分情況下可以穩(wěn)定運(yùn)行，但是穩(wěn)定性不高。對(duì)同一個(gè)視頻流進(jìn)行反復(fù)的編碼，但其速度忽高忽低。有的時(shí)候完全滿(mǎn)足實(shí)時(shí)要求，甚至更高達(dá)到60、70FPS，但有時(shí)降速?lài)?yán)重只有40FPS。

現(xiàn)代操作系統(tǒng)通常支持NUMA架構(gòu)來(lái)提升多核心內(nèi)存訪問(wèn)效率。在NUMA架構(gòu)中，處理器被劃分為多個(gè)Node節(jié)點(diǎn)，并且每個(gè)Node節(jié)點(diǎn)都有屬于自己的獨(dú)立內(nèi)存和內(nèi)存訪問(wèn)控制器。CPU可以通過(guò)Node內(nèi)集成的內(nèi)存訪問(wèn)控制器訪問(wèn)同Node節(jié)點(diǎn)內(nèi)存，通過(guò)QPI總線訪問(wèn)其他Node節(jié)點(diǎn)的內(nèi)存，所以對(duì)于同一個(gè)Node里的CPU和內(nèi)存之間訪問(wèn)速度會(huì)快于跨Node訪問(wèn)。

在編解碼過(guò)程中，每顆CPU既進(jìn)行編碼也進(jìn)行解碼，會(huì)導(dǎo)致CPU的對(duì)應(yīng)Node節(jié)點(diǎn)內(nèi)存中同時(shí)存在解碼幀和編碼幀， 當(dāng)編碼過(guò)程中進(jìn)行參考時(shí)，會(huì)產(chǎn)生大量的跨Nde節(jié)點(diǎn)訪問(wèn)內(nèi)存。在8K場(chǎng)景下，跨Node節(jié)點(diǎn)訪問(wèn)帶來(lái)的內(nèi)存帶寬和速度壓力會(huì)快速放大，導(dǎo)致IO阻塞，并發(fā)能力下降。

這個(gè)問(wèn)題的解決方案是：對(duì)CPU做核心綁定，將整體轉(zhuǎn)碼流程精細(xì)化控制。比如，解碼、添加水印、轉(zhuǎn)分辨率、編碼等等操作都分配到指定CPU上進(jìn)行，盡量保證相互依賴(lài)的操作都在同一個(gè)CPU，同一個(gè)Node節(jié)點(diǎn)內(nèi)完成，盡可能降低跨Node內(nèi)存訪問(wèn)。

03

分布式編碼

在優(yōu)化以上問(wèn)題之后，單機(jī)直播系統(tǒng)在線上能夠達(dá)到穩(wěn)定8K 50FPS的實(shí)時(shí)編碼。但我們面臨的挑戰(zhàn)可能是需要達(dá)到120FPS的編碼速度。我們提出了將直播系統(tǒng)支持分布式轉(zhuǎn)碼。點(diǎn)播分布式轉(zhuǎn)碼應(yīng)該比較熟悉，拿到一個(gè)文件之后，將文件切成一個(gè)個(gè)非常小的碎片，將碎片發(fā)到多臺(tái)機(jī)器上進(jìn)行處理，每個(gè)機(jī)器只處理一個(gè)非常短的碎片，最終將轉(zhuǎn)碼后的碎片形成一個(gè)完整文件。

直播分布式轉(zhuǎn)碼其實(shí)參考了點(diǎn)播的方式。通常直播轉(zhuǎn)碼在一臺(tái)機(jī)器上完成解碼、加水印、filter、編碼等所有操作，但我們對(duì)直播流程進(jìn)行了改造，它不進(jìn)行實(shí)際的編碼，而是拉取一個(gè)直播流按照GOP的維度在直播的場(chǎng)景下實(shí)時(shí)切成一個(gè)個(gè)的小片，將其發(fā)送到現(xiàn)有的點(diǎn)播算力節(jié)點(diǎn)，用文件的方式快速轉(zhuǎn)碼，轉(zhuǎn)完之后的直播系統(tǒng)再回收這些小片拼成實(shí)時(shí)的直播流進(jìn)行下發(fā)。整體思路和點(diǎn)播分布式轉(zhuǎn)碼相似，從一臺(tái)機(jī)器進(jìn)行所有操作到n臺(tái)機(jī)器共同進(jìn)行實(shí)時(shí)轉(zhuǎn)碼，使得編碼速度和效率得到大幅提升。

另一部分是如何支持實(shí)時(shí)超分？通過(guò)視頻增強(qiáng)、AI增強(qiáng)算法等操作可以實(shí)現(xiàn)4K實(shí)時(shí)超分，但是目前還很難支持實(shí)時(shí)超分8K。在這個(gè)背景下，我們利用分布式增強(qiáng)能力，支持直播過(guò)程中從4K到8K的超分。解碼出一個(gè)視頻幀之后，會(huì)對(duì)這一視頻幀進(jìn)行壓縮，將壓縮后的視頻幀以幀維度發(fā)送到下游的增強(qiáng)算力節(jié)點(diǎn)，每個(gè)算力節(jié)點(diǎn)只進(jìn)行單幀的超分辨率操作。通過(guò)算力節(jié)點(diǎn)海量的GPU資源，實(shí)現(xiàn)直播4K到8K的超分辨率增強(qiáng)。

04

網(wǎng)絡(luò)優(yōu)化

作為云廠商，還有很多專(zhuān)有云部署的場(chǎng)景， 專(zhuān)有云環(huán)境下網(wǎng)絡(luò)和設(shè)備環(huán)境更為復(fù)雜。

比如，從我們監(jiān)控中看到大概每過(guò)1-2小時(shí)，整個(gè)直播轉(zhuǎn)碼系統(tǒng)會(huì)產(chǎn)生TCP慢速的過(guò)程。原因可能是我們提供的轉(zhuǎn)碼服務(wù)收到了拉流數(shù)據(jù)包之后，ack報(bào)文從虛擬網(wǎng)卡發(fā)送到物理網(wǎng)卡有3s延時(shí)，而正常應(yīng)該是瞬時(shí)。

首先懷疑是否是系統(tǒng)負(fù)載問(wèn)題，在CPU、內(nèi)存、帶寬利用率情況都良好的情況下，發(fā)現(xiàn)在某些機(jī)器上會(huì)發(fā)生這樣的問(wèn)題。傳輸過(guò)程是TCP→IP層→bond qdisc→ethX qdisc→ethX pcap。在虛擬網(wǎng)卡和物理網(wǎng)卡分別抓包的過(guò)程中發(fā)現(xiàn)慢速產(chǎn)生的原因是bond網(wǎng)卡會(huì)延遲2-3s的時(shí)間發(fā)送ack報(bào)文。通過(guò)netrace工具深入分析，發(fā)現(xiàn)從qdisc取包，到發(fā)送到驅(qū)動(dòng)過(guò)程中，驅(qū)動(dòng)狀態(tài)表示不可以發(fā)送報(bào)文。最終確認(rèn)專(zhuān)有環(huán)境設(shè)備的網(wǎng)卡驅(qū)動(dòng), 在大流量傳輸時(shí)產(chǎn)生了異常。

05

分發(fā)優(yōu)化

另外遇到的一個(gè)問(wèn)題是客戶(hù)的網(wǎng)絡(luò)環(huán)境受限體現(xiàn)在內(nèi)部網(wǎng)絡(luò)帶寬只有千兆的交換機(jī)。

在這個(gè)條件下，需要進(jìn)行更精確的負(fù)載均衡的算法，UDP組播發(fā)包的時(shí)候使用更高性能的API、系統(tǒng)函數(shù)等。這里提供幾個(gè)小技巧：

1、可以對(duì)UDP包進(jìn)行流速的控制。因?yàn)榫幋a碼率無(wú)法做到完全穩(wěn)定，上下浮動(dòng)比較大。因此只要UDP發(fā)包速率控制在低于網(wǎng)絡(luò)帶寬的限制就可以實(shí)現(xiàn)。

2、充分利用交換機(jī)的兩張網(wǎng)卡。配置bond虛擬網(wǎng)卡，用這個(gè)虛擬網(wǎng)卡進(jìn)行交互，能拓展原先單機(jī)的千兆帶寬。

經(jīng)過(guò)一系列優(yōu)化，實(shí)時(shí)8K轉(zhuǎn)碼編碼系統(tǒng)也部署在客戶(hù)的專(zhuān)有環(huán)境落地。央視網(wǎng)內(nèi)部部署的系統(tǒng)支持8K的實(shí)時(shí)編碼。

06

總結(jié)與展望

最后是總結(jié)與展望。先說(shuō)轉(zhuǎn)碼服務(wù)：

1、轉(zhuǎn)碼服務(wù)首先要進(jìn)行編碼器的優(yōu)化。編碼器的優(yōu)化分成兩個(gè)大的方向：首先如何提升整體編碼并行度和CPU資源利用率，其次如何減少CPU運(yùn)算量。

2、針對(duì)不同解碼器進(jìn)行不同的解碼優(yōu)化方案。例如，針對(duì)AVS3，將NV12到Y(jié)UV的轉(zhuǎn)換移到了編碼器內(nèi)核層進(jìn)行操作；針對(duì)H265，通過(guò)多TILE并行編碼進(jìn)行加速

3、解決了內(nèi)存帶寬的瓶頸。通過(guò)管理每一項(xiàng)操作，減少所有內(nèi)存拷貝和對(duì)內(nèi)存帶寬的使用等操作優(yōu)化內(nèi)存帶寬。

4、轉(zhuǎn)碼鏈路穩(wěn)定性提升。涉及了遠(yuǎn)端內(nèi)存和本地內(nèi)存的訪問(wèn)，需要規(guī)劃每一步操作在哪個(gè)CPU上運(yùn)行，減少跨NUMA的操作，提升整體訪問(wèn)效率。

轉(zhuǎn)碼集群：

1、 分布式轉(zhuǎn)碼通過(guò)多機(jī)、并行轉(zhuǎn)碼的能力支持最高8K 120FPS轉(zhuǎn)碼、4K到8K的超分等

2、 針對(duì)客戶(hù)場(chǎng)景，要更關(guān)注可能產(chǎn)生的TCP慢速、丟包等問(wèn)題。其次在客戶(hù)受限的網(wǎng)絡(luò)環(huán)境下進(jìn)行UDP發(fā)包算法的平滑以及對(duì)分發(fā)的負(fù)載均衡算法的優(yōu)化。

編輯：黃飛