點擊上方“LiveVideoStack”關注我們

實時視頻系統對于時延的要求極高，視頻編碼器必須滿足實時性的要求。新一代視頻標準AV1相比主流H.264在Rate-distortation性能的提升上是以復雜度的上升為代價的，當前應用設備的碎片化非常嚴重、設備的運算能力差異巨大，這些都是新技術落地實時系統面臨的挑戰。本次分享將圍繞拍樂云在設計Pano Venus實時AV1通信系統時的一些技術實踐展開深入分析與講解，期望和大家共同探索實時視頻技術的未來。

文 | 章琦

整理 | LiveVideoStack

? ? ?

我是章琦，英文名是Volvet，從事視頻開發20年了，目前就職于拍樂云，曾就職于Cisco WebEx和網易。拍樂云致力于提供音視頻的PaaS云服務，我們的核心團隊主要來自Cisco WebEx。

今天的分享包括六個部分，第一部分簡單介紹AV1的背景，包括視頻編解碼的歷史和編輯碼器最基礎的概念。第二部分介紹Pano Venus產品和我們為什么開發基于AV1的實時通訊系統。第三部分簡單分析AV1的復雜度，AV1的復雜度非常高，這也就表示將AV1落地于實時系統的挑戰非常大，所以復雜度分析是設計AV1系統的基準和前提。第四部分是基于復雜度分析介紹拍樂云的AV1實時系統設計。第五個部分介紹AV1 Scalability，視頻的可伸縮編碼是非常熱門的主題，但實際上可伸縮編碼一直沒有得到廣泛的應用，借助于AV1，我認為它會迎來自己的機會。最后一部分我會分享拍樂云基于AV1的后續計劃。

1. Introduction

視頻編碼標準的發展已經有近40年的歷史了，在視頻編碼標準的發展中，國際電信聯盟(ITU)和運動圖像專家組(MPEG)這兩個組織具有舉足輕重的地位。

最早是視頻編碼標準H.120和H.261就是國際電信聯盟在上個世紀80年代所制定，然后運動圖像專家組制定了MPEG-1，MPEG-1是以VCD之名被大家所熟知的編碼標準。

接下來兩大組織聯手成立了聯合視頻專家組(JVET)，聯合視頻專家組定了MPEG-2中的視頻部分，也被稱為H.262。MPEG-2是以DVD之名被大家所了解，可以說MPEG-2是迄今為止最成功的視頻標準之一，絕不遜色于現在的H.264-AVC。

后來國際電信聯盟又制定了H.263標準，運動圖像專家組制定了MPEG-4，這兩個標準都沒有取得像MPEG-2這樣的成功。然后兩大組織再次聯手（JVET）制定了H.264-AVC標準。H.264制定于二十一世紀初，到現在已經近20年，卻依然在行業應用占據了絕對的領先地位，獨領風騷二十年。

聯合視頻專家組在2014年制定了H.265-HEVC，其技術值得稱道，但是專利費用的混亂和昂貴，阻礙了H.265在行業內的應用，無法撼動H.264的地位。JVET后續又制定了H.266-VVC，其專利授權問題依然需要被關注，如果H.266能提供比較友好的專利授權方案，未來會是充滿期望的。

另一個重要的視頻標準組織是以Google為代表的開放媒體聯盟(AOM)，AOM制定的AV1標準，展示出超過H.265-HEVC的編碼性能，擁有豐富的編碼工具支持，可以極大地提高視頻的壓縮比，節省大量帶寬。同時，AV1 作為開放媒體聯盟 AOM 制定的第一代標準，除了有非常好的生態支持，還提供了免費的專利政策，相比 H.265 / H.266 等知識產權政策不明確的視頻標準，有巨大的優勢。清晰明確的專利政策也是 AV1 在產業界被推崇的一大優勢。

除了上述三家標準組織，AVS也值得一提。AVS是我國自己的標準組織，它定義的AVS標準迄今已經發展到AVS-3，從AVS分享的數據來看，AVS-3具備了優秀的編碼性能，不過要建立AVS的生態，依然非常困難。

雖然編碼標準的發展經歷了多個迭代，新的編碼工具令人眼花繚亂，不過編碼器的基本框架卻沒有大的變化。

從H.261到現在的H.266和AV1, ?都依然是混合編碼框架，其核心模塊包括：塊的分割(16x16~128x128)、基于塊的預測（intra and inter prediction)、基于塊的變換(transform)、量化(quantization)、熵編碼(entropy coding)。對于開發視頻應用的同學來說，不需要了解編碼器和解碼器的技術細節，不過需要了解一些最基本的概念，比如說關鍵幀(Key-frame/I-frame)。

所謂關鍵幀，就是它的塊預測僅使用幀內預測(intra prediction)，這就意味著，關鍵幀并不依賴于它之前或者之后的幀，只需要關鍵幀的數據是完整的，就可以被正確解碼（這個描述忽略了SPS/PPS等參數集, 參數集的重要性可以被認為是等同于關鍵幀），這就是在實時系統中，當解碼遇到錯誤的時候，會采用關鍵幀請求的技術來恢復解碼的原因。

另一個需要了解的概念是P-frame（實時系統中一般不使用B-frame, 因此本文避免提及）。P-frame也就是使用了前向預測的幀，它的解碼會依賴于前面的某一幀或者某幾幀，在編碼器的實現中，可以采用非常靈活的前向預測結構，根據條件的不同，可以參考最近的前一幀(latest frame)，也可以選擇稍微遠一些的前向幀，利用long-term-reference技術，甚至可以選擇非常早的幀，編碼器的時間分級技術，本質上就是參考結構的選擇。靈活的前向參考結構，可以結合實際使用場景和擁塞控制算法，衍生出豐富的變化。

2. Pano Venus

Pano Venus是拍樂云基于AV1推出的實時通信視頻引擎，相比H.264碼率平均降低40%~70%，并且可以在主流手機端實時運行，這也是國內AV1在實時系統中的首次落地。

眾所周知AV1雖然性能好，但復雜度非常高，應用AV1對技術的挑戰非常大。那么Pano為什么會選擇AV1呢？早在我就職于思科時，曾經推動HEVC項目的落地，就遇到過這類問題，當時一位同學問我，基于H.264的系統運行的很好，還有必要做HEVC嗎。HEVC復雜度很高，很多設備可能無法落地?；贖.264的codebase，引入更復雜的算法和更高級的工具集也可以對性能進行優化提升，相比于做HEVC是不是更容易看到收益，更容易落地。當時我沒有能很好的回答這個問題，只是覺得擁抱新標準、新技術是理所當然的事。但現在想來，做新標準是一個具有挑戰性的長期過程，新的標準意味著能夠提升編碼器的性能上限，所有新標準的性能提升都是for future的，也許在當下無法立竿見影地得到收益，但在未來一定有無限可能。

由于AV1的復雜度很高，它在實時領域的應用一直受到很大限制。我們早期使用AOM做編碼的時候，在大分辨率下編1幀需要耗時好幾秒，遠遠沒有到產品化的條件，但是近幾年Google的AOM Codec經歷多次迭代后各方面性能都獲得了提升，這也推動了AV1的落地可能性。

Pano Venus的研發過程中面臨兩大挑戰：

1、低端設備：目前市面上有很多低端設備，比如IoT在設計低端設備時基于成本考慮會選擇廉價的CPU和內存等，在這些設備上不說AV1，就是264都無法跑起來，所以AV1在這些設備上運行時一定會遇到很大挑戰。

2、設備過熱：雖然手機CPU計算能力有了很大改進但依然面臨著嚴峻的手機發燙降頻問題，用戶手機上運行Codec的同時，還會運行美顏或其它高級算法，這些算法需要協同工作。AV1也是如此，即使在手機性能足以運行AV1時，依然可能會出現手機發燙降頻，影響AV1的最終體驗。所以我們在為AV1設定設備可以運行的條件時必須要考慮因長時間使用而出現的手機過熱問題。

3.?Complexity?Analysis

一個新的Codec和舊的Codec，比如AV1和H264相比，復雜度的提升至少來源于兩方面。一方面是AV1的coding tool，在AV1的標準中可以明顯發現它的復雜度高于264，但具體高了多少需要進行實際測試分析。另一方面是模式的選擇，新的Codec會增加很多可選模式，舉個例子，Intra編碼在H264中，16×16有4種預測模式，4×4有9種預測模式，而AV1有48種，可以想象在做最優選擇時復雜度將會上升很多。另外H264中最大塊是16×16，而AV1最大塊是128×128，其樹形分割比H264更復雜，綜合來看AV1的復雜度相較于H264高出非常非常多。所以如果H264在設備上運行都會出現性能問題，那么AV1的運行只會更加困難。

AV1有幾個非常好的Open source都可以作為我們的benchmark，如AOM的encoder、decoder、VideoLAN的Dav1d。

圖中是用AOM Encoder做的分析，編碼參數來自AV1 Team的工程師Jerome在LVS中分享的AV1在Real-time檔的性能，speed設置為9，是目前AOM Encoder實現的最快的一檔，codebase是它的3.1。

首先來看解碼器的復雜性測試，解碼器用的是Dav1d，我的設想是對編碼工具集的測試可以從解碼的復雜度中得到一定體現，它們的量級應該是相當的。測試設置為會議場景下的碼流，AV1的碼率大概是H264的60%。264的碼率由OpenH264編碼，AV1是由AOM Encoder編碼。720p時，用Dav1d解碼AV1需要230.94fps，用OpenH264解碼同樣場景的序列需要644.57fps；1080p時，Dav1d是63.61，OpenH264是160.54，對表中數據進行分析得到AV1解碼速度比H264慢了接近3倍，大致推測編碼工具的復雜度相比H.264大概上升了3倍左右，另一方面反映的問題是性能較差的設備甚至無法支持AV1的解碼。

編碼的復雜性測試中使用AOM和OpenH264進行對比。720p時，AOM在普通PC上的編碼速度是64.59fps，OpenH264是344.74fps，1080p時，AOM是19.75fps，OpenH264是82.19fps，數據顯示AV1編碼速度比H264慢了將近五倍。從這個測試結果來看， AOM Encoder各方面的優化已經相當出色，即使不做任何修改優化在某些設備上做Real time的應用也是完全OK的。由于測試在PC端進行，而測試結果中它的編碼速度比H264慢了5倍，所以AOM Encoder 在移動端落地是會有很大困難的。所以我們在自研Pano Venus編碼引擎時需要做的更好。

這是我們在做自研AV1編碼器時給自己定的目標，嚴格來說， 其實這是三個問題：

如果要提升速度，除了做優化之外的方法可能是對算法、編碼工具集做裁剪優化，而這些優化在提升速度的同時勢必會造成RD性能的損失。那么是否可以做一個基于AV1的語義做編碼速度和RD性能跟H.264相當的Codec？

如果對編碼器的速度有要求，比如希望在某一點的速度損失和H264相比是某個比例，那么在此要求下，RD性能可以做到多好？

能否實現可伸縮RD性能，如0~70%或更高，在此限制條件下，編碼器的速度能做多快？

如果大家熟悉優化理論的話，可以發現這個很像優化問題，在給了限制條件下能否求出最優解。但是無論是算法的選擇還是編碼工具的取舍都很難用簡單的數學模型來衡量。

最終我們還是落地了比較滿意的結果，在主流設備包括IOS、Android都可以運行AV1。

4.?System Design

基于以上角度的分析，可以看到AV1落地是非常有挑戰的。我們對于Venus的性能做了很多創新優化，但目前我們還無法將其優化到和H264一樣，AV1的性能和H264相比，復雜度有不少的提升。目前市場上存在海量的設備，設備間的性能差異性很大，部分設備即使支持H264都是吃力的，更何況支持AV1，我們對設備做了分類。

第一行是（Lowest）最差的設備，不能運行Video，只能運行Audio。第二行是舊SDK（Old SDK without AV1），第一版SDK上線的時候并沒有AV1，當時只有H264。第三檔（LOW）和第二檔類似，性能較弱，甚至不能支持AV1解碼，所以只能運行H.264。第四檔是舊SDK（Old SDK with AV1 Decoder），事實上在releaseAV1之前，我們已經release了AV1的decoder，所以早期版本中已經包含了一個decoder，這個版本可以和現在的SDK通信，新的SDK發送AV1到此版本，然后可以進行解碼，這檔設備性能還可以，能夠支持AV1decoder。第四檔（Medium）是中等復雜度，能支持H264的編解碼及AV1的解碼。第五檔（High）性能比較好的設備能夠支持AV1的收發，編解碼都能夠使用AV1。

對設備進行以上區分后， Pano Venus實現了在最大范圍的場景下支持AV1，基于Venus的極致性能優化，也實現了在主流設備上支持AV1。

5. AV1 Scalability

[L|S] [Number] [T] [Number] [h] [KEY] [SHIFT]用來描述Scalability。

[L|S]，“L”、“S”任選其一，代表空間分級，Special Scalability，“L”指空間分級包含不同空間層的預測，增強空間層可以預測基本空間層，“S”指不同空間層之間沒有任何預測。simulcast是這個結構中的子集，simulcast指不同空間層是完全獨立的。

[Number]，指空間層的層數，比如L2、S2代表只有兩個空間層。

[T]，代表時間分級。

[Number]，指時間層的層數。

[h]，常見的空間分級中兩個相鄰層的空間分辨率關系是1：2，比如基本層是180p，增強層是360p，而[h]代表關系從1：2變為1：1.5，基本層是180p，增強層是270p。

[KEY]，key frame相關。如果不同空間層中有層間預測，優點是在編碼增強層時可以參考基本層的信息，對編碼有所幫助，缺點在于解碼時需要基本層存在，而[KEY]是嘗試在兩者之間取一個平衡，key是在空間分級的時候，對是否要采用層間預測做了權衡，[KEY]表示只在key frame做層間預測。對key frame的編碼來說會帶來一些編碼增益，對下行來說非關鍵幀只需要接收增強層，而無需接收基本層， 僅在關鍵幀需要接受基本層。

[SHIFT]，和時間分級相關，通常出現在不同空間分級時。以L2T2為例，它有兩個空間分級，兩個時間分級，兩個空間分級上的時間分級關系一一對應，比如基本層是[T0]，增強層也會是[T0]，基本層是[T1]，增強層也是[T1]，但[SHIFT]會試圖改變這一情況，當使用[SHIFT]后，不同空間層的[T0]和[T1]會交錯。雖然有些奇怪，但標準決定技術時背后一定有理由，這個技術一定在某些場景下是有增益的。我個人認為對于SFU的Server有增益，當一個源是L2T2時，25%用戶訂閱L0T0，25%用戶訂閱L0T1，25%用戶訂閱L1T0，剩下25%用戶訂閱L1T1，結構如果沒有[SHIFT]，那么對所有用戶來說，處于T0時必須轉發所有數據，處于T1時會有50%用戶無需轉發數據，這樣Server的load是不均衡的，有的時間很忙，有的時間點很空。當有了[SHIFT]之后，它對不同時間分級進行交錯，最大限度balance了Server要轉發的數據量。

從上文的介紹可以看出，simulcast只是scalable的一種最簡單形式，未來scalable有很大機會，可以利用scalable更大的靈活性設計更能適應應用場景的技術。現在WebRTC也在實現這個技術。

以下是幾個實例。

這是一個L1T2的例子，它有一個空間層，兩個時間層，橫坐標的0指T0，1指T1。

這是L2T2的例子，L2T2h的示例也完全相同，可以看到兩個空間層都有向上的箭頭，這表示上面的是空間增強層，會參考下面的基本層。

這是S2T2的例子，和L2T2相比沒有箭頭，代表兩個空間層完全獨立。

這是L2T2 Key的例子，箭頭只存在key frame之間，當不是key frame時，不會使用層間預測技術。

這也是L2T2 Key的例子，和前一個例子差不多。

這是L2T2 Key Shift的例子，會更加復雜，在編碼的時候特已引入時間分級的交錯，使增強層的T0和基本層的T1處于同一條時間流。

以下列舉了關于AV1 Scalability的基本概念。

最重要的是Chain，視頻編碼存在幀間預測，Chain指解碼當前frame，這個frame會依賴前面的某一幀或某幾個幀，而被依賴的幀又會依賴它之前的幀，整個依賴關系連成Chain。

DTI（Decode target indication），scalability靈活的可伸縮結構可以引申出多種不同的訂閱如不同分辨率及不同幀率的訂閱，所以DTI能夠為單元場景增加更多分辨率或幀率的可伸縮性。

Switch indication指當切換DTI時，除了在關鍵幀進行切換，其它的某一幀上也可以完成切換，而這個幀在chain中，某個T0可能也是一個切換點。

Discardable indication，有些frame不在chain中，可被丟棄。

這是60fps，兩層的序列。它可以延伸出多種DTI。

這是一種DTI，只需要HD的15fps。

這是另一種DTI，需要SD的30fps。

這是第三個DTI，需要SD的60fps。

這是第四個DTI，所有幀都要，就需要HD的60fps。

6. Future?Work

Pano Venus已經正式上線，但是我們對它的期望不止于此，未來我們希望繼續提升它的性能：

• 更靈活的編碼復雜度伸縮方案， 覆蓋更多設備

• 主觀視覺編碼， 進一步提升編碼性能

• 支持桌面編碼工具集， 支持桌面編碼

• 并行編碼框架， 充分利用多核處理器的性能， 提升編碼效率

AV1技術雖然早已加入到WebRTC，但由于算法復雜度比H.264高很多倍，實時性一直是大家特別擔心的問題。拍樂云對AV1在實時通信方面做了積極的商業化探索，相信Pano Venus的落地應用能夠推進AV1在RTC領域的應用，進一步推進AV1生態發展。我們堅信技術的創新能為多媒體生態的發展創造更大的想象力。

這是參考文獻， 本文的大多數內容都來自這三篇文獻。

以上是本次分享的內容，謝謝大家！

---

講師招募

LiveVideoStackCon 2022 音視頻技術大會 上海站，正在面向社會公開招募講師，無論你所處的公司大小，title高低，老鳥還是菜鳥，只要你的內容對技術人有幫助，其他都是次要的。歡迎通過?speaker@livevideostack.com?提交個人資料及議題描述，我們將會在24小時內給予反饋。

喜歡我們的內容就點個“在看”吧！

總結

以上是生活随笔為你收集整理的拍乐云基于AV1的实时视频系统技术实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。