編者按： 近年來，騰訊云在編解碼領域投入了許多，不同于許多廠商基于開源方案做增強，騰訊從 2017 年就開始自研編解碼器包括現在的 AV1。LiveVideoStackCon 2022 音視頻技術大會上海站邀請到騰訊云香農實驗室編解碼器研發負責人張賢國老師，為大家介紹騰訊自研 AV1 編解碼器。

文 / 張賢國

整理 / LiveVideoStack

本次和大家分享的主題是《騰訊自研新一代 AV1 編碼器》，距離我上一次 2019 年在 LiveVideoStackCon2019 北京站演講已經過去了快三年，這次就和大家分享下閉關兩三年中我們團隊進行了哪些工作。

首先，我們繼續優化了 V265 編碼器，并在騰訊云全面落地，服務多家海內外的客戶，265 各賽道中的成績也一直保持領先。其次，新研發了 V265 硬件編碼器，低延時 RTC 編碼及其在終端的應用，與其他團隊合作研發了騰訊的滄海芯片。第三，從 2020 年開始啟動自研了新一代 TXAV1 視頻編碼器，在去年的比賽及推廣業務中都取得了不錯的成績。去年上半年開始在騰訊云落地，如 60fps 直播以及最近開始支持 8K30fps，整個周期沿用了 V265 的思路，按部就班地從頭開始做，從標準協議出發優化整個編碼器。

2020 年決定研發 AV1 編碼器之前，我們分別從三個方面進行了調研。

第一，當時的開源軟件很豐富，這意味著良好的生態，在調研了 Google 的 LibAOM、SVT-AV1 的開源編碼器后，我們發現 AV1 對比 V265 確實有性能提升。

第二，AV1 的代碼還有優化空間，我們許多成熟的優化思路是 AV1 所沒有的，在這一點就可以做出差距。

第三，AV1 的市場比較成熟，2020 年就有 MTK 芯片的支持，一旦有了 MTK 芯片，其他廠商也會陸續進入市場。另外，當時 AV1 的開源解碼器就超過了 openhevc，Android、瀏覽器的支持也很豐富。AV1 在 Youtube 也有很多落地，最近的調研發現有 30%-35% 的視頻支持 AV1，而且首頁的熱門視頻都更偏向于使用 AV1 進行播放。

以上幾點都是促使我們最終選擇 AV1 編碼器的原因，而且因為我們部門服務于云部門，所以需要研發出能夠盡快落地的產品。

如今回過頭看我們的決策是正確的。首先，硬件解碼器，除了 MTK 的一系列手機支持硬解之外，三星的 S21、S22、驍龍的下一代也都支持 AV1 硬解，而且現在很多顯卡也支持 AV1 硬解。最新的 Apple 軟件框架中也添加了 AV1 選項，從生態角度來看，AV1 更加成熟。另外從自研角度，也證明了我們確實能做出和開源的差異，并且在去年的比賽中都取得了較好的成績。

1、TXAV1 編解碼器能力及落地應用

接下來我將從以下三方面進行分享。

第一是 TXAV1 編解碼器能力，第二第三點都是技術干貨，包括 TXAV1 壓縮率提升技術和 TXAV1 工程加速技術。

從壓縮性能上，總體來講，TXAV1 可以實現：

（1）相比 SVT-110 最高壓縮率配置 加速 78% 時帶寬節省 12-16%，加速 78 倍時仍有帶寬節省

（2）相比 AOM-3.2 最高壓縮率配置 加速 10.7 倍時帶寬節省 12-20%，加速 613 倍時仍有帶寬節省

（3）相比 VVenc 最高壓縮率配置，在加速 11 倍下，壓縮率相當.

在此我們還測試了主觀感受。圖中可以發現 1.5M 碼率情況下，對比 265 有明顯的性能提升，即使在節省 20% 帶寬情況下，畫質仍略好于 265，也就是 TXAV1 對比自研 265 也有主觀畫質的提升。

在去年的比賽中，關于 AV1 的比賽指標 TXAV1 參加了 29 項，我們取得了 28 項領先，265 有 39 項比賽指標，我們取得了 35 項領先。

編碼器只是一方面，最重要的還是生態，由于 AV1 解碼芯片還不夠普及，大概有 2-5% 硬解占比，那么為了推廣 AV1，我們必須自研 AV1 的解碼。

AV1 解碼包括兩部分，一是解碼速度的比較，也就是絕對速度比較。對比目前開源最好的 libhevc，TXAV1 在性能較好的手機上或是在大部分手機上的解碼已經接近于 libhevc，且顯著優于 iOS265 軟解。

在實際播放中不是 PK 絕對速度，而是 PK 在定速解碼下的 CPU 占用和內存。于是對比了 TXAV1 和開源的 AV1 和 265 的定速解碼，結果顯示 TXAV1 的 CPU 占用率、內存、播放一小時耗電量均低于開源軟件，在性能較差的機型耗電量高于硬解，但在性能稍好的機型上，TXV1 已經接近于硬解。

在 AV1 編解碼器都研發得差不多的前提下，我們花費了更多的時間在編碼器的落地上。

首先為點播業務做 CAE 適配，即內容自適應編碼，目標是提升 vmaf 自測準確率，需要保證任一視頻的 vmaf 準確率均較好才能夠做到 CAE 能力。經過多輪優化，TXAV1 在 CAE 下的 vmaf [-1,1] 區間的預測準確率已經達到 85% 以上，同時相比自研 265 也能夠節省 20% 帶寬。

之后我們在直播上優化了許多加速算法，事實證明直播場景相同質量下，碼率對比 265 能夠節省 20-30% 帶寬，并且已經開始在海內外客戶進行私有化部署服務。

除了應用視頻，AV1 還要應用于圖片。在 Google 生態中，圖片基本能夠用瀏覽器播放，所以 AV1 的圖片應用是非常重要的領域。今年騰訊云對 AVIF 的支持能力也進行了大量宣傳，我們在后方主要做了編解碼庫上的支撐。

AVIF 的鏈路比較簡單，輸入一個視頻后，轉碼為 AVIF 格式，然后大部分可以直接觀看，小部分需要臨時轉碼為 264 播放。

從測試對比看，TXAV1 對比 webp 有 30% 以上的帶寬節省，而競品 AV1 的帶寬節省就差很多。對比 sharpp 也就是自研的 265 格式，帶寬節省顯著提升 20% 以上，耗時只有 1.4 倍。無論是轉碼的資源消耗還是帶寬節省上都有所提升。此外，我們還優化了播放端的解碼，測試結果顯示 AVIF 的播放消耗其實相較 HEIF 還少一些，這其實歸功于我們對包含接封裝在內的解碼的整個鏈路的優化。

其中 AVIF 編碼的細節優化包括：在圖片編碼時優化內存申請、編碼器的啟動流程和配套格式；特別針對很多 4K、8K 的圖像，因為 AV1 標準規定大于某個分辨率后只能使用 TILE 編碼，所以基于 TILE 能力的支持超大圖片的編碼是必需的；目前 α 通道使用比較多，所以 4:0:0 的編碼也是重點做的小技術。

2、新型預分析模型支撐的壓縮率提升技術

介紹完項目落地應用，大家可能會感興趣優化時使用的技術。接著就為大家介紹新型預分析模型支撐的壓縮率提升技術。

我們主要從三個方向提升壓縮率。

第一，預測效率提升，把參考幀管理做到更好。第二，全維度自適應量化優化，包含幀級、GOP 級、塊級的 QP 優化。第三，率失真模型優化。一個標準有許多模式，如何做到最優模式的選擇，這就主要依靠率失真模型。

其中與其他編碼器拉開差距最重要的是全維度自適應量化優化，即通過分析幀間的關系找出最優量化參數分配，實現整個 BD-Rate 最優。這里包含許多細節優化技術，但其實大部分算法都依賴預分析計算每塊的復雜度和塊與塊之間的依賴關系。我會重點介紹在預分析過程中進行的優化。

如圖是在預分析框架下的整個編碼器流程。近兩年的一個重要變化是在 HM 和 VTM 中加入時域濾波，其實在 AV1 的編碼器實現中做得更好。

視頻輸入后先進行幀類型決策，在幀類型決策基礎上做時域濾波，對濾波后的圖像做預分析。預分析是為了各級自適應量化服務的，重點產生幀間及塊間的依賴關系，核心目的是又快又好地為后續圖像提供更準確豐富的信息場景復雜度和時空域依賴。場景復雜度作用是通過估計圖像編碼重要性決定幀級 QP 分配，時空域依賴估計是通過計算塊之間的傳播關系以決定塊級 QP 分配。本次重點介紹時空域依賴估計優化的方面。

時域依賴即從高到低，從后向前的塊級 cost 疊加過程，cost 疊加越大說明塊的重要性越強，量化參數使用得越小。在傳統的時域自適應量化中存在一些問題：第一，傳統的 cutree 參考幀數永遠是 2，與編碼過程不匹配，導致依賴估計不準確；第二，參考基于原始圖像，未考慮重建損失，與量化參數無關，傳播誤差大。而 AV1 編碼器引入了 TPL 技術，分別從以下角度解決了問題：第一，使用多參考幀使其與編碼完全相同；第二，引入量化步長和 DCT 變換，在 TPL 過程中生成重建圖像并使用重建圖像作為參考，避免 cutree 遇到的問題。但 TPL 過程也產生一個重要問題：幀間依賴估計都基于重建圖像會使得預分析只能串行而不能并行，繼而導致 TPL 過程成為整個編碼器在快速檔的瓶頸，嚴重阻塞 CPU 占用率，即使是慢速檔也會阻塞一部分。

所以我們的主要優化思路是使 TPL 并行處理，不依賴重建而使用原始圖像進行參考幀管理。優點是即使在最慢檔也能提升 10% 速度，快速檔甚至能夠加速 50% 以上。缺點不重建后那么使用重建圖像中帶來的收益也隨之消失，導致無法準確估計量化和損失，導致傳播代價不準確。

方案修改前后會有哪些變化較大的因子呢？重建后的 intra cost、inter cost 會變差，overlap 面積也發生了變化 ——overlap 相當于從后往前傳播時需要計算哪些部分已被參考。優化的手段最好能夠使這三個參數的損耗成為可以模型化的系數，這就需要建立模型估計 α、β、γ 參數。

經過優化，TXAV1 所實現的三個參數糾偏模型可以做到：相比最原始的 TPL 方案在做到無串行依賴顯著加速的同時，額外獲得 2% 的壓縮率提升。

3、TXAV1 的工程加速優化技術

在工程加速方面，首先介紹 TXAV1 的數據結構優化。圖中是標準迭代的過程，最明顯的變化是劃分越來越多，這會導致許多數據結構問題。因此在編碼器設計過程中我們完全拋棄了 AOM 和 SVT 的數據結構設計，重新進行優化。

優化過程中包括四個重要問題：

第一，劃分更多導致每個 CU 尋址和坐標計算變得頻繁且復雜，每輸入一個當前塊就要重新計算塊的坐標、相鄰塊可用性和 offset 以定位解碼重建圖像等信息，增加計算復雜度。

第二，由于周邊塊位置復雜，且每個 CTU 行為 128 像素，跨行的 memory 距離較大，導致獲取周邊塊信息時發生 cache miss。

第三，劃分塊可能已經按照相同的信息編碼一遍，因此需要避免重復編碼。

第四，頻繁重建 Block 的同時還要很頻繁的進行 Buffer copy，過程的復雜度非常高。

每個圖像的 CTU 只有四類：左上角、右邊、下邊、右下角。首先我們在編碼器啟動階段創建這四類 CTU 的尋址，直接獲取每個節點屬性信息，那么在編碼 CTU 時只需要讀取節點的寬高、可用性和 offset 信息即可，通過建立 Treenode 解決了頻繁地址計算問題。第二是核心訪存 buffer，目前的編碼器為避免 cache miss 所采取的最好手段就是將其需要的所有信息儲存在一個 local buffer，這樣 local buffer 不僅儲存單行塊的信息，還儲存相鄰 CTU 信息。通過這個 buffer，每編碼一個塊就預先存入信息，那么下一個 buffer 使用信息時只需要讀取周邊塊，節省了頻繁訪問造成的耗時。第三是 identical CU，和第一點相關，在創建節點時能夠得知判斷相同 ID 的 CU，當發現某一 CU 相同的 ID 已經做過時，當前的 CU 就不用重復做，而是直接 copy 編碼結果信息，所以 identical CU 就是避免重復計算的過程。最后是 Swap buffer，本質是使用空間換時間的手段，比如大 CTU 和小 CTU 重建 buffer 的位置不同，那么在決策出 CU 劃分之后，只需要縫合 buffer 就不會發生 copy 現象，也就是通過內存 swap buffer 操作減少 copy 和重算。

一個商業編碼其的實現許多方面會用到編碼器多線程，比如預分析過程、獨立的編碼單元分析過程及后處理過程。編碼器的并行過程大體包括五種：預分析并行、幀間并行、WPP 并行、后處理并行及熵編碼并行。

我們測試 SVT-AV1 后發現它加速 230%，壓縮率損失 3.2%；AOM 加速 120%，壓縮率損失 0.6%；而我們的編碼器可以做到加速 334%，壓縮率只損失 0.28%，這是并行算法發揮了作用。其中核心解決的是分析、后處理和編碼三個模塊的并行問題。

我們提出了 “無 wpp、全假 wpp、半假 wpp、半真 wpp、全真 wpp” 五個概念。

無 wpp： 類似 HM，在分析一個幀之后，再做幀的濾波及幀的編碼。

全假 wpp： 只對分析內部并行，每一行一個線程，但濾波和編碼過程沒有流水的并行。

半假 wpp： 即除熵編碼以外流水并行，我們編碼器的快速檔就使用這種過程：每分析一個 CTU 后會濾波左上角的塊，這樣行與行之間即為流水級的并行關系。編碼不能并行的原因是 AV1 標準不支持 wpp 語法，因此只能串行。快速 AV1 編碼器需要做到半假 wpp 工作。

半真 wpp： 對于硬件編碼器特別是 266 編碼器，它的濾波如果做流水線并行，損失會比較大，所以硬件編碼器就可以做半真 wpp 并行。其中，語法為了減少輸出碼流延遲會并行，但濾波過程為了提升壓縮率就不會并行，分析過程也可以并行。

全真 wpp： 傳統快速檔的 265 編碼器都會使用，分析濾波和編碼一起流水線進行。

AV1 編碼器中包含了半假 wpp 和全假 wpp，有混合的自適應機制。

編碼器加速有許多細節，最重要的一點是數據結構設計決定加速算法上限。AV1 編碼器的開源軟件不能方便獲取相鄰非最優 CU 劃分類型的編碼結果信息，而我們的編碼器能夠通過新建數據結構獲得每個 CU 劃分的編碼結果，通過這種方式可以實現更多更好的快速算法。

4、總結

總結一下，TXAV1 編碼器已經具備行業領先的 AV1 視頻、圖片編解碼能力，擁有豐富的騰訊云 MPS 產品支持的落地案例，歡迎大家使用。

最后針對本次 TXAV1 編解碼器的研發經驗分享，可以概括如下幾點：

第一點是前瞻性，研發方向決策極為關鍵，比如我們在 2020 年決定做 AV1 編碼器就是非常關鍵的時間點。第二點是持續性，我了解到的許多編碼器團隊投入半年后沒有成果就放棄了，這是不現實的，持續的投入非常重要，要么不投入用云方案要么就持續投入。第三點是內外兼修，我們的團隊從來不只打比賽，在做一個產品的同時還會將編碼器速度、碼控和工程優化、CAE 等一起做起來，這樣的編碼器才更容易落地。

以上是本次的分享，謝謝。