close

//

編者按:近年來,騰訊雲在編解碼領域投入了許多,不同於許多廠商基於開源方案做增強,騰訊從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等一起做起來,這樣的編碼器才更容易落地。

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

▼識別二維碼或猛戳下圖訂閱課程▼

掃描圖中二維碼或點擊閱讀原文
了解大會更多信息

喜歡我們的內容就點個「在看」吧!
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 鑽石舞台 的頭像
    鑽石舞台

    鑽石舞台

    鑽石舞台 發表在 痞客邦 留言(0) 人氣()