點(diǎn)擊上方“LiveVideoStack”關(guān)注我們

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

文 | 章琦

整理 | LiveVideoStack

? ? ?

我是章琦，英文名是Volvet，從事視頻開發(fā)20年了，目前就職于拍樂云，曾就職于Cisco WebEx和網(wǎng)易。拍樂云致力于提供音視頻的PaaS云服務(wù)，我們的核心團(tuán)隊(duì)主要來自Cisco WebEx。

今天的分享包括六個(gè)部分，第一部分簡(jiǎn)單介紹AV1的背景，包括視頻編解碼的歷史和編輯碼器最基礎(chǔ)的概念。第二部分介紹Pano Venus產(chǎn)品和我們?yōu)槭裁撮_發(fā)基于AV1的實(shí)時(shí)通訊系統(tǒng)。第三部分簡(jiǎn)單分析AV1的復(fù)雜度，AV1的復(fù)雜度非常高，這也就表示將AV1落地于實(shí)時(shí)系統(tǒng)的挑戰(zhàn)非常大，所以復(fù)雜度分析是設(shè)計(jì)AV1系統(tǒng)的基準(zhǔn)和前提。第四部分是基于復(fù)雜度分析介紹拍樂云的AV1實(shí)時(shí)系統(tǒng)設(shè)計(jì)。第五個(gè)部分介紹AV1 Scalability，視頻的可伸縮編碼是非常熱門的主題，但實(shí)際上可伸縮編碼一直沒有得到廣泛的應(yīng)用，借助于AV1，我認(rèn)為它會(huì)迎來自己的機(jī)會(huì)。最后一部分我會(huì)分享拍樂云基于AV1的后續(xù)計(jì)劃。

1. Introduction

視頻編碼標(biāo)準(zhǔn)的發(fā)展已經(jīng)有近40年的歷史了，在視頻編碼標(biāo)準(zhǔn)的發(fā)展中，國(guó)際電信聯(lián)盟(ITU)和運(yùn)動(dòng)圖像專家組(MPEG)這兩個(gè)組織具有舉足輕重的地位。

最早是視頻編碼標(biāo)準(zhǔn)H.120和H.261就是國(guó)際電信聯(lián)盟在上個(gè)世紀(jì)80年代所制定，然后運(yùn)動(dòng)圖像專家組制定了MPEG-1，MPEG-1是以VCD之名被大家所熟知的編碼標(biāo)準(zhǔn)。

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

后來國(guó)際電信聯(lián)盟又制定了H.263標(biāo)準(zhǔn)，運(yùn)動(dòng)圖像專家組制定了MPEG-4，這兩個(gè)標(biāo)準(zhǔn)都沒有取得像MPEG-2這樣的成功。然后兩大組織再次聯(lián)手（JVET）制定了H.264-AVC標(biāo)準(zhǔn)。H.264制定于二十一世紀(jì)初，到現(xiàn)在已經(jīng)近20年，卻依然在行業(yè)應(yīng)用占據(jù)了絕對(duì)的領(lǐng)先地位，獨(dú)領(lǐng)風(fēng)騷二十年。

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

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

除了上述三家標(biāo)準(zhǔn)組織，AVS也值得一提。AVS是我國(guó)自己的標(biāo)準(zhǔn)組織，它定義的AVS標(biāo)準(zhǔn)迄今已經(jīng)發(fā)展到AVS-3，從AVS分享的數(shù)據(jù)來看，AVS-3具備了優(yōu)秀的編碼性能，不過要建立AVS的生態(tài)，依然非常困難。

雖然編碼標(biāo)準(zhǔn)的發(fā)展經(jīng)歷了多個(gè)迭代，新的編碼工具令人眼花繚亂，不過編碼器的基本框架卻沒有大的變化。

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

所謂關(guān)鍵幀，就是它的塊預(yù)測(cè)僅使用幀內(nèi)預(yù)測(cè)(intra prediction)，這就意味著，關(guān)鍵幀并不依賴于它之前或者之后的幀，只需要關(guān)鍵幀的數(shù)據(jù)是完整的，就可以被正確解碼（這個(gè)描述忽略了SPS/PPS等參數(shù)集, 參數(shù)集的重要性可以被認(rèn)為是等同于關(guān)鍵幀），這就是在實(shí)時(shí)系統(tǒng)中，當(dāng)解碼遇到錯(cuò)誤的時(shí)候，會(huì)采用關(guān)鍵幀請(qǐng)求的技術(shù)來恢復(fù)解碼的原因。

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

2. Pano Venus

Pano Venus是拍樂云基于AV1推出的實(shí)時(shí)通信視頻引擎，相比H.264碼率平均降低40%~70%，并且可以在主流手機(jī)端實(shí)時(shí)運(yùn)行，這也是國(guó)內(nèi)AV1在實(shí)時(shí)系統(tǒng)中的首次落地。

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

由于AV1的復(fù)雜度很高，它在實(shí)時(shí)領(lǐng)域的應(yīng)用一直受到很大限制。我們?cè)缙谑褂肁OM做編碼的時(shí)候，在大分辨率下編1幀需要耗時(shí)好幾秒，遠(yuǎn)遠(yuǎn)沒有到產(chǎn)品化的條件，但是近幾年Google的AOM Codec經(jīng)歷多次迭代后各方面性能都獲得了提升，這也推動(dòng)了AV1的落地可能性。

Pano Venus的研發(fā)過程中面臨兩大挑戰(zhàn)：

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

2、設(shè)備過熱：雖然手機(jī)CPU計(jì)算能力有了很大改進(jìn)但依然面臨著嚴(yán)峻的手機(jī)發(fā)燙降頻問題，用戶手機(jī)上運(yùn)行Codec的同時(shí)，還會(huì)運(yùn)行美顏或其它高級(jí)算法，這些算法需要協(xié)同工作。AV1也是如此，即使在手機(jī)性能足以運(yùn)行AV1時(shí)，依然可能會(huì)出現(xiàn)手機(jī)發(fā)燙降頻，影響AV1的最終體驗(yàn)。所以我們?cè)跒锳V1設(shè)定設(shè)備可以運(yùn)行的條件時(shí)必須要考慮因長(zhǎng)時(shí)間使用而出現(xiàn)的手機(jī)過熱問題。

3.?Complexity?Analysis

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

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

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

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

編碼的復(fù)雜性測(cè)試中使用AOM和OpenH264進(jìn)行對(duì)比。720p時(shí)，AOM在普通PC上的編碼速度是64.59fps，OpenH264是344.74fps，1080p時(shí)，AOM是19.75fps，OpenH264是82.19fps，數(shù)據(jù)顯示AV1編碼速度比H264慢了將近五倍。從這個(gè)測(cè)試結(jié)果來看， AOM Encoder各方面的優(yōu)化已經(jīng)相當(dāng)出色，即使不做任何修改優(yōu)化在某些設(shè)備上做Real time的應(yīng)用也是完全OK的。由于測(cè)試在PC端進(jìn)行，而測(cè)試結(jié)果中它的編碼速度比H264慢了5倍，所以AOM Encoder 在移動(dòng)端落地是會(huì)有很大困難的。所以我們?cè)谧匝蠵ano Venus編碼引擎時(shí)需要做的更好。

這是我們?cè)谧鲎匝蠥V1編碼器時(shí)給自己定的目標(biāo)，嚴(yán)格來說， 其實(shí)這是三個(gè)問題：

如果要提升速度，除了做優(yōu)化之外的方法可能是對(duì)算法、編碼工具集做裁剪優(yōu)化，而這些優(yōu)化在提升速度的同時(shí)勢(shì)必會(huì)造成RD性能的損失。那么是否可以做一個(gè)基于AV1的語義做編碼速度和RD性能跟H.264相當(dāng)?shù)腃odec？

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

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

如果大家熟悉優(yōu)化理論的話，可以發(fā)現(xiàn)這個(gè)很像優(yōu)化問題，在給了限制條件下能否求出最優(yōu)解。但是無論是算法的選擇還是編碼工具的取舍都很難用簡(jiǎn)單的數(shù)學(xué)模型來衡量。

最終我們還是落地了比較滿意的結(jié)果，在主流設(shè)備包括IOS、Android都可以運(yùn)行AV1。

4.?System Design

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

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

對(duì)設(shè)備進(jìn)行以上區(qū)分后， Pano Venus實(shí)現(xiàn)了在最大范圍的場(chǎng)景下支持AV1，基于Venus的極致性能優(yōu)化，也實(shí)現(xiàn)了在主流設(shè)備上支持AV1。

5. AV1 Scalability

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

[L|S]，“L”、“S”任選其一，代表空間分級(jí)，Special Scalability，“L”指空間分級(jí)包含不同空間層的預(yù)測(cè)，增強(qiáng)空間層可以預(yù)測(cè)基本空間層，“S”指不同空間層之間沒有任何預(yù)測(cè)。simulcast是這個(gè)結(jié)構(gòu)中的子集，simulcast指不同空間層是完全獨(dú)立的。

[Number]，指空間層的層數(shù)，比如L2、S2代表只有兩個(gè)空間層。

[T]，代表時(shí)間分級(jí)。

[Number]，指時(shí)間層的層數(shù)。

[h]，常見的空間分級(jí)中兩個(gè)相鄰層的空間分辨率關(guān)系是1：2，比如基本層是180p，增強(qiáng)層是360p，而[h]代表關(guān)系從1：2變?yōu)?：1.5，基本層是180p，增強(qiáng)層是270p。

[KEY]，key frame相關(guān)。如果不同空間層中有層間預(yù)測(cè)，優(yōu)點(diǎn)是在編碼增強(qiáng)層時(shí)可以參考基本層的信息，對(duì)編碼有所幫助，缺點(diǎn)在于解碼時(shí)需要基本層存在，而[KEY]是嘗試在兩者之間取一個(gè)平衡，key是在空間分級(jí)的時(shí)候，對(duì)是否要采用層間預(yù)測(cè)做了權(quán)衡，[KEY]表示只在key frame做層間預(yù)測(cè)。對(duì)key frame的編碼來說會(huì)帶來一些編碼增益，對(duì)下行來說非關(guān)鍵幀只需要接收增強(qiáng)層，而無需接收基本層， 僅在關(guān)鍵幀需要接受基本層。

[SHIFT]，和時(shí)間分級(jí)相關(guān)，通常出現(xiàn)在不同空間分級(jí)時(shí)。以L2T2為例，它有兩個(gè)空間分級(jí)，兩個(gè)時(shí)間分級(jí)，兩個(gè)空間分級(jí)上的時(shí)間分級(jí)關(guān)系一一對(duì)應(yīng)，比如基本層是[T0]，增強(qiáng)層也會(huì)是[T0]，基本層是[T1]，增強(qiáng)層也是[T1]，但[SHIFT]會(huì)試圖改變這一情況，當(dāng)使用[SHIFT]后，不同空間層的[T0]和[T1]會(huì)交錯(cuò)。雖然有些奇怪，但標(biāo)準(zhǔn)決定技術(shù)時(shí)背后一定有理由，這個(gè)技術(shù)一定在某些場(chǎng)景下是有增益的。我個(gè)人認(rèn)為對(duì)于SFU的Server有增益，當(dāng)一個(gè)源是L2T2時(shí)，25%用戶訂閱L0T0，25%用戶訂閱L0T1，25%用戶訂閱L1T0，剩下25%用戶訂閱L1T1，結(jié)構(gòu)如果沒有[SHIFT]，那么對(duì)所有用戶來說，處于T0時(shí)必須轉(zhuǎn)發(fā)所有數(shù)據(jù)，處于T1時(shí)會(huì)有50%用戶無需轉(zhuǎn)發(fā)數(shù)據(jù)，這樣Server的load是不均衡的，有的時(shí)間很忙，有的時(shí)間點(diǎn)很空。當(dāng)有了[SHIFT]之后，它對(duì)不同時(shí)間分級(jí)進(jìn)行交錯(cuò)，最大限度balance了Server要轉(zhuǎn)發(fā)的數(shù)據(jù)量。

從上文的介紹可以看出，simulcast只是scalable的一種最簡(jiǎn)單形式，未來scalable有很大機(jī)會(huì)，可以利用scalable更大的靈活性設(shè)計(jì)更能適應(yīng)應(yīng)用場(chǎng)景的技術(shù)。現(xiàn)在WebRTC也在實(shí)現(xiàn)這個(gè)技術(shù)。

以下是幾個(gè)實(shí)例。

這是一個(gè)L1T2的例子，它有一個(gè)空間層，兩個(gè)時(shí)間層，橫坐標(biāo)的0指T0，1指T1。

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

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

這是L2T2 Key的例子，箭頭只存在key frame之間，當(dāng)不是key frame時(shí)，不會(huì)使用層間預(yù)測(cè)技術(shù)。

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

這是L2T2 Key Shift的例子，會(huì)更加復(fù)雜，在編碼的時(shí)候特已引入時(shí)間分級(jí)的交錯(cuò)，使增強(qiáng)層的T0和基本層的T1處于同一條時(shí)間流。

以下列舉了關(guān)于AV1 Scalability的基本概念。

最重要的是Chain，視頻編碼存在幀間預(yù)測(cè)，Chain指解碼當(dāng)前frame，這個(gè)frame會(huì)依賴前面的某一幀或某幾個(gè)幀，而被依賴的幀又會(huì)依賴它之前的幀，整個(gè)依賴關(guān)系連成Chain。

DTI（Decode target indication），scalability靈活的可伸縮結(jié)構(gòu)可以引申出多種不同的訂閱如不同分辨率及不同幀率的訂閱，所以DTI能夠?yàn)閱卧獔?chǎng)景增加更多分辨率或幀率的可伸縮性。

Switch indication指當(dāng)切換DTI時(shí)，除了在關(guān)鍵幀進(jìn)行切換，其它的某一幀上也可以完成切換，而這個(gè)幀在chain中，某個(gè)T0可能也是一個(gè)切換點(diǎn)。

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

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

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

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

這是第三個(gè)DTI，需要SD的60fps。

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

6. Future?Work

Pano Venus已經(jīng)正式上線，但是我們對(duì)它的期望不止于此，未來我們希望繼續(xù)提升它的性能：

• 更靈活的編碼復(fù)雜度伸縮方案， 覆蓋更多設(shè)備

• 主觀視覺編碼， 進(jìn)一步提升編碼性能

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

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

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

這是參考文獻(xiàn)， 本文的大多數(shù)內(nèi)容都來自這三篇文獻(xiàn)。

以上是本次分享的內(nèi)容，謝謝大家！

---

講師招募

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

喜歡我們的內(nèi)容就點(diǎn)個(gè)“在看”吧！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。