大家好，今天跟大家分享下在支持4K/8K超高清視頻的實時編碼、媒體處理、系統架構、專有云流量分發所遇到的困難和挑戰，希望能給大家帶來幫助。

分享內容分為六個部分：

01

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

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

1、對原有的直播系統架構帶來極大沖擊。比如，8K直播的碼率普遍高于100M。其次，通常直播流的分發要通過媒體處理的手段將8K的原始流轉成不同的分辨率、碼率、幀率之后再進行分發。對系統的算力消耗、處理速度、處理成本帶來了新的難點。

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

基于這樣的背景，開始投入超高清直播媒體處理平臺。首先遇到的問題是技術選型，通過CPU的方式支持還是專有芯片的方式來支持。硬件方案的優點是極高的編碼出幀穩定性，低廉的計算成本。軟件方案的優點是算法設計能更加靈活，純CPU編碼器可以通過算法設計達到比硬件方案更高的壓縮率。同時軟件方案的升級更加方便。如：原硬件芯片支持8K265編碼，后續若想要升級支持266編碼，對于硬件來說需要重新設計，軟件則只需要進行代碼升級即可，系統可以持續迭代支持最新的能力。

綜上考慮，最終的選型還是偏向純CPU的實時編碼方案。優點是：壓縮率更高、能夠自由地擴展編碼器和解碼器、更容易支持復雜的邏輯和業務。另外，純CPU方案使用的是通用算力，當不進行8K轉碼的時候，可以很方便的釋放這部分資源進行通用CPU算力利用。

目前我們達成的成果：

1、從8K的實時編碼來說，8K單機能達到60FPS的實時編碼，分布式集群轉碼能達120FPS的實時編碼；

2、因為軟件的靈活性，8K實時轉碼系統能夠支持所有主流視頻編解碼標準；

3、在2022 MSU最新編碼器評測報告，獲得全項最佳；

4、擁有100+項H.266/VCC編解碼專利技術。

02

編解碼加速

在對8K編碼器優化時，主要分為兩個方向：

1、優化編碼器的并行度，讓編碼器同時編碼更多幀，提高CPU資源利用率。目前我們支持多TILE并行編碼。在8K場景下，8K視頻幀的拷貝會成為耗時的操作，而編碼過程中避免不了將YUV標準排列格式轉為編碼器內部優化后的YUV排列格式，這一過程需要進行訪問拷貝操作，為此我們支持了將8K視頻幀分為多個SLICE區間，每個SLICE一個線程來并行加速視頻幀拷貝過程。此外還支持預分析和幀級并行、幀間多線程解耦，根據層級特點自適應選擇參考幀，提高整體編碼的并行度。

2、另一個方向是直接對編碼器算法進行優化。針對8K超高分辨率的編碼特性，可以通過預分析mvp跳過原先編碼器中的搜索過程；進行幀內幀間分析時，可以自適應選擇先做幀內還是幀間，進行快速搜索。

在對編碼算法進行加速優化后，會發現8K場景/DCT耗時占比較大。為此支持了非標DCT加速來提升整體速度。

對編碼器優化后，純編碼的速度可以達到60甚至70FPS。但一旦將解碼加入處理流程中，整個系統的轉碼速度和效率發生極大的下降。

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

比如：AVS3格式的解碼器，原生輸出的是NV12的格式，FFmpeg中間有單線程進行NV12到YUV的轉換，最終輸出YUV進行后續的操作。這樣的做法在4K/1080P分辨率下是沒問題的，因為NV12到YUV的轉換是一個快速的操作，但8K場景下，NV12到YUV的轉換速率很難滿足50FPS的要求，我們將NV12到YUV的轉換移到了解碼器內部。解碼之后會在多線程上進行NV12到YUV的轉換，來提升整體解碼速度。

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

在優化完編碼和解碼速率之后，我們發現線上同樣型號的兩臺128G內存設備，處理速度相差較大。處理速度快的設備是8×16G的內存，處理慢的設備是4×32G的內存。

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

8K視頻編解碼對內存帶寬的消耗極大，配置設備硬件時，需要注意根據CPU的Memory Channels來配置內存，盡可能增加內存帶寬。

以上這些出現的問題說明在8K場景下，每個操作都需要多加思考，可能僅僅多加了一個拷貝，就會導致系統的慢速導致達不到實時性。在這里對整個內存池進行了重構，在解碼、前處理操作、打水印的時候不申請新的內存，將所有操作原地處理，盡量將內存數據拷貝只進行一次。降低內存使用的帶寬。

在優化完編解碼速度、內存之后，系統在大部分情況下可以穩定運行，但是穩定性不高。對同一個視頻流進行反復的編碼，但其速度忽高忽低。有的時候完全滿足實時要求，甚至更高達到60、70FPS，但有時降速嚴重只有40FPS。

現代操作系統通常支持NUMA架構來提升多核心內存訪問效率。在NUMA架構中，處理器被劃分為多個Node節點，并且每個Node節點都有屬于自己的獨立內存和內存訪問控制器。CPU可以通過Node內集成的內存訪問控制器訪問同Node節點內存，通過QPI總線訪問其他Node節點的內存，所以對于同一個Node里的CPU和內存之間訪問速度會快于跨Node訪問。

在編解碼過程中，每顆CPU既進行編碼也進行解碼，會導致CPU的對應Node節點內存中同時存在解碼幀和編碼幀， 當編碼過程中進行參考時，會產生大量的跨Nde節點訪問內存。在8K場景下，跨Node節點訪問帶來的內存帶寬和速度壓力會快速放大，導致IO阻塞，并發能力下降。

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

03

分布式編碼

在優化以上問題之后，單機直播系統在線上能夠達到穩定8K 50FPS的實時編碼。但我們面臨的挑戰可能是需要達到120FPS的編碼速度。我們提出了將直播系統支持分布式轉碼。點播分布式轉碼應該比較熟悉，拿到一個文件之后，將文件切成一個個非常小的碎片，將碎片發到多臺機器上進行處理，每個機器只處理一個非常短的碎片，最終將轉碼后的碎片形成一個完整文件。

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

另一部分是如何支持實時超分？通過視頻增強、AI增強算法等操作可以實現4K實時超分，但是目前還很難支持實時超分8K。在這個背景下，我們利用分布式增強能力，支持直播過程中從4K到8K的超分。解碼出一個視頻幀之后，會對這一視頻幀進行壓縮，將壓縮后的視頻幀以幀維度發送到下游的增強算力節點，每個算力節點只進行單幀的超分辨率操作。通過算力節點海量的GPU資源，實現直播4K到8K的超分辨率增強。

04

網絡優化

作為云廠商，還有很多專有云部署的場景， 專有云環境下網絡和設備環境更為復雜。

比如，從我們監控中看到大概每過1-2小時，整個直播轉碼系統會產生TCP慢速的過程。原因可能是我們提供的轉碼服務收到了拉流數據包之后，ack報文從虛擬網卡發送到物理網卡有3s延時，而正常應該是瞬時。

首先懷疑是否是系統負載問題，在CPU、內存、帶寬利用率情況都良好的情況下，發現在某些機器上會發生這樣的問題。傳輸過程是TCP→IP層→bond qdisc→ethX qdisc→ethX pcap。在虛擬網卡和物理網卡分別抓包的過程中發現慢速產生的原因是bond網卡會延遲2-3s的時間發送ack報文。通過netrace工具深入分析，發現從qdisc取包，到發送到驅動過程中，驅動狀態表示不可以發送報文。最終確認專有環境設備的網卡驅動, 在大流量傳輸時產生了異常。

05

分發優化

另外遇到的一個問題是客戶的網絡環境受限體現在內部網絡帶寬只有千兆的交換機。

在這個條件下，需要進行更精確的負載均衡的算法，UDP組播發包的時候使用更高性能的API、系統函數等。這里提供幾個小技巧：

1、可以對UDP包進行流速的控制。因為編碼碼率無法做到完全穩定，上下浮動比較大。因此只要UDP發包速率控制在低于網絡帶寬的限制就可以實現。

2、充分利用交換機的兩張網卡。配置bond虛擬網卡，用這個虛擬網卡進行交互，能拓展原先單機的千兆帶寬。

經過一系列優化，實時8K轉碼編碼系統也部署在客戶的專有環境落地。央視網內部部署的系統支持8K的實時編碼。

06

總結與展望

最后是總結與展望。先說轉碼服務：

1、轉碼服務首先要進行編碼器的優化。編碼器的優化分成兩個大的方向：首先如何提升整體編碼并行度和CPU資源利用率，其次如何減少CPU運算量。

2、針對不同解碼器進行不同的解碼優化方案。例如，針對AVS3，將NV12到YUV的轉換移到了編碼器內核層進行操作；針對H265，通過多TILE并行編碼進行加速

3、解決了內存帶寬的瓶頸。通過管理每一項操作，減少所有內存拷貝和對內存帶寬的使用等操作優化內存帶寬。

4、轉碼鏈路穩定性提升。涉及了遠端內存和本地內存的訪問，需要規劃每一步操作在哪個CPU上運行，減少跨NUMA的操作，提升整體訪問效率。

轉碼集群：

1、 分布式轉碼通過多機、并行轉碼的能力支持最高8K 120FPS轉碼、4K到8K的超分等

2、 針對客戶場景，要更關注可能產生的TCP慢速、丟包等問題。其次在客戶受限的網絡環境下進行UDP發包算法的平滑以及對分發的負載均衡算法的優化。

編輯：黃飛