超高清8k和4k有什么區(qū)別，4K/8K 超高清實時處理與分發(fā)技術

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

分享內容分為六個部分：

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

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

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

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

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

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

目前我們達成的成果：

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

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

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

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

編解碼加速

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

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

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

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

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

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

比如：AVS3格式的解碼器，原生輸出的是NV12的格式，FFmpeg中間有單線程進行NV12到YUV的轉換，最終輸出YUV進行后續(xù)的操作。這樣的做法在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解碼器進行優(yōu)化，將二者結合，單TILE解碼完成行解碼后，就進行進度通知，優(yōu)化之后能夠達到單機50FPS以上的速度。

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

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

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

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

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

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

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

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

分布式編碼

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

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

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

網絡優(yōu)化

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

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

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

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