自2020年4月起，獨(dú)立的webrtc和MilliCast平臺(tái)中的AV1實(shí)時(shí)編碼已經(jīng)可用，正如我們?cè)谥暗奈恼轮兴觥Ｈ欢瑢?duì)于那些想在web應(yīng)用程序中單獨(dú)使用它的人來(lái)說，您必須重新編譯Chrome。雖然我們?yōu)樯鐓^(qū)提供了預(yù)編譯的二進(jìn)制文件，也有少數(shù)勇敢的人早早地進(jìn)行了測(cè)試，但這是單層實(shí)現(xiàn)，不支持SVC。

隨著編解碼器的使用從閉路和專用線路發(fā)展到越來(lái)越多地在公共互聯(lián)網(wǎng)上使用，編解碼器自身也在不斷發(fā)展，并采用一些功能來(lái)改善公共互聯(lián)網(wǎng)上的媒體體驗(yàn)。作為H264（附錄G）的最新附錄，SVC已經(jīng)發(fā)展成為任何現(xiàn)代編解碼器必須具備的功能。在默認(rèn)情況下，AV1是第一個(gè)支持SVC的編解碼器。對(duì)于那些對(duì)關(guān)于SVC是如何發(fā)揮作用的更多細(xì)節(jié)感興趣的人，Alex E.博士在2016年寫了一篇很好的解釋性博文。寫的是關(guān)于VP9，大多數(shù)點(diǎn)對(duì)AV1有效的內(nèi)容。

在過去的一整年中，AOMEDIA的實(shí)時(shí)組（代碼組的一部分）都在努力完成RTP有效負(fù)載規(guī)范，該規(guī)范允許RTP端點(diǎn)利用所有編解碼器SVC功能，但也可用于中間SFU變得更好、更強(qiáng)、更快。Cosmo軟件率先實(shí)現(xiàn)了所有測(cè)試和參考SFU。現(xiàn)在，AV1RTP的有效載荷規(guī)格現(xiàn)在幾乎可以被認(rèn)為是最終的版本，經(jīng)過了高達(dá)95%+的測(cè)試。

現(xiàn)在是一個(gè)很好的時(shí)機(jī)來(lái)回顧為什么AV1對(duì)于實(shí)時(shí)媒體來(lái)說比僅僅提高效率更重要。與此同時(shí)，我們還將提供有關(guān)性能預(yù)期的詳細(xì)信息。

1創(chuàng)新不會(huì)在隔絕的真空中發(fā)生

在我們這個(gè)快節(jié)奏的世界中，太容易把注意力放在小事上，而忽視大局。但是，沒有創(chuàng)新會(huì)在像是隔絕的真空中發(fā)生的，而對(duì)趨勢(shì)進(jìn)行分析并對(duì)其軌跡進(jìn)行分析，則更加令人著迷。

Alex Eleftheriadis博士（又名Alex博士）在他最近的一篇文章中非常完美地記錄了整個(gè)通信系統(tǒng)的發(fā)展。它寫的很好，被一個(gè)不僅從內(nèi)部經(jīng)歷了進(jìn)化，而且還不得不教給大學(xué)生的人記錄得非常好，他創(chuàng)建了這個(gè)領(lǐng)域中技術(shù)上最有創(chuàng)造力的公司之一：Vidyo。我強(qiáng)烈建議您可以讀一讀。

在不到兩周的時(shí)間里，下列三項(xiàng)主要技術(shù)已成為標(biāo)準(zhǔn)或可在Chrome中使用：

1月20日（星期三），所有IETF RTCWEB草案最終都成為標(biāo)準(zhǔn)（或參考性文獻(xiàn)）并獲得了一個(gè)RFC編號(hào)。這代表了十多年的工作，由全世界一百多位最聰明的人都在研究用作WebRTC基礎(chǔ)的協(xié)議。辛勤工作中產(chǎn)生的數(shù)十個(gè)新標(biāo)準(zhǔn)已經(jīng)公開，可以通過Web平臺(tái)獲得！

1月26日，W3C宣布Webrtc 1.0作為一個(gè)標(biāo)準(zhǔn)使用，它鞏固了該標(biāo)準(zhǔn)，使人們可以安全地加入并可以開始實(shí)施它。1月21日，Google終于在Chrome中啟用了AV1 SVC實(shí)時(shí)編碼，幾個(gè)小時(shí)或幾天后，該功能便會(huì)在Canary版本中可以使用了。

1月21日，Google終于在Chrome中啟用了AV1 SVC實(shí)時(shí)編碼，幾小時(shí)或幾天后，該功能就在Canary版本中可以使用了。

這不是偶然。實(shí)時(shí)媒體需要整合多個(gè)元素才能正常工作，所有這些元素都是并行工作和發(fā)展的：

具有SVC（可伸縮視頻編碼）的編解碼器

媒體引擎（編解碼器，媒體和網(wǎng)絡(luò)傳輸?shù)?a href="http://www.xsypw.cn/tags/耦合/" target="_blank">耦合）

SFUs（選擇性轉(zhuǎn)發(fā)單元），代替MCU（多點(diǎn)會(huì)議單元）

這是整體的典例，說明整體大于部分的總和。并行使用這些技術(shù)還會(huì)具有驚人的優(yōu)勢(shì)：

更好的網(wǎng)絡(luò)彈性

更快的適應(yīng)性

后端無(wú)媒體處理

支持下一代新功能，例如端到端加密。

2RTC創(chuàng)新軌跡

微軟首席架構(gòu)師伯納德·阿波巴（Bernard Aboba）曾經(jīng)寫過有關(guān)AV1的文章（我們添加的鏈接）：

“史蒂夫·喬布斯曾經(jīng)說過：“我一直被更具革命性的變化所吸引。我不知道為什么。因?yàn)樗鼈兏y。”

AV1旨在與下一波WebRTC視頻創(chuàng)新集成：端到端加密，SVC和獨(dú)立于編解碼器的轉(zhuǎn)發(fā)。因此，這與視頻編解碼器無(wú)關(guān)，而與下一代架構(gòu)有關(guān)。

1. 隨著WebRTC現(xiàn)在通過可插入流（和SFrame）合并了E2E加密，并且NSA現(xiàn)在推薦E2E安全性，由于有效負(fù)載可能是不透明的，因此會(huì)議系統(tǒng)需要RTP標(biāo)頭擴(kuò)展來(lái)轉(zhuǎn)發(fā)數(shù)據(jù)包。因此，如果瀏覽器和編解碼器不支持可插入流或與下一代編解碼器集成的轉(zhuǎn)發(fā)頭擴(kuò)展名，則將無(wú)法滿足NSA的要求，并且會(huì)議供應(yīng)商將無(wú)法提供完整的功能。

2. SVC支持對(duì)于會(huì)議很重要。AV1內(nèi)置了SVC；在HEVC中，它是一個(gè)擴(kuò)展。Dependency Descriptor（在AV1 RTP有效負(fù)載規(guī)范中定義）優(yōu)于用于空間可伸縮性模式的Framemarking RTP標(biāo)頭擴(kuò)展。如果瀏覽器（和下一代編解碼器）不支持帶有轉(zhuǎn)發(fā)頭擴(kuò)展名的SVC，那么它就沒有競(jìng)爭(zhēng)力。

3. AV1包含屏幕編碼工具作為基本功能，而不是像HEVC中的擴(kuò)展。這是會(huì)議的主要競(jìng)爭(zhēng)優(yōu)勢(shì)。”

A. 屏幕共享

對(duì)于文本內(nèi)容以及超高動(dòng)態(tài)內(nèi)容，在對(duì)屏幕內(nèi)容進(jìn)行編碼時(shí)，AV1都非常高效。實(shí)際上，AV1實(shí)時(shí)的性能非常優(yōu)越，以至于像Cisco在Webex中所做的那樣，AV1實(shí)時(shí)可能只部署在單個(gè)使用案例中。

在共享屏幕或應(yīng)用程序時(shí)，如果選擇了“優(yōu)化運(yùn)動(dòng)和視頻”，并且您所在的機(jī)器至少有四個(gè)內(nèi)核，則支持傳輸AV1。任何至少有兩個(gè)內(nèi)核的機(jī)器都支持接收AV1。只要會(huì)議的所有參與者都支持AV1，AV1就會(huì)自動(dòng)用于共享此類屏幕內(nèi)容，否則它將自動(dòng)恢復(fù)為H.264。

有趣的是，這里分別提到了4和2個(gè)內(nèi)核的約束條件。思科在2019年6月的大蘋果大會(huì)上進(jìn)行現(xiàn)場(chǎng)演示時(shí)也發(fā)表了同樣的觀點(diǎn)。

我們將在下一個(gè)部分中繼續(xù)討論性能的問題，但是為了提供相關(guān)的背景信息，MacBook Air自2008年以來(lái)一直使用具有2個(gè)內(nèi)核的Intel core-2芯片，并且自2011年以來(lái)在MacBook Pro中具有4個(gè)或更多內(nèi)核的Intel i7或更高版本。就筆記本電腦和臺(tái)式機(jī)而言，預(yù)計(jì)擁有4個(gè)內(nèi)核并不是一個(gè)大問題。

B. 端到端加密

E2EE是下一件值得關(guān)注的問題。也許是因?yàn)檫@是webrtc最初許下的承諾之一。又或許是因?yàn)樗蔀榱艘粋€(gè)過度使用的營(yíng)銷術(shù)語(yǔ)，而Zoom已經(jīng)變得遍體鱗傷。也許是因?yàn)榇蠖鄶?shù)人仍然聲稱擁有它，實(shí)際上卻沒有。

關(guān)于E2EE，對(duì)這個(gè)問題最好的回應(yīng)之一是Emil Ivov的這篇演講。

雖然許多人認(rèn)為E2EE加密只是一種視頻會(huì)議或聊天應(yīng)用程序功能，但它在整個(gè)媒體行業(yè)中都以縮寫“DRM”（數(shù)字版權(quán)管理）的形式使用。然而，傳統(tǒng)的DRM在瀏覽器和媒體播放器中的實(shí)現(xiàn)并不是真正的端到端的，只涵蓋了交付這一模塊。當(dāng)人們上傳他們的內(nèi)容到一個(gè)平臺(tái)時(shí)仍然需要信任這個(gè)平臺(tái)（以及任何可以合法訪問或不合法訪問該平臺(tái)的人）與他們的原始內(nèi)容。

真正的E2EE要求在對(duì)媒體進(jìn)行編碼時(shí)在源處對(duì)媒體進(jìn)行加密，并且僅在播放時(shí)對(duì)其進(jìn)行解密。它允許內(nèi)容提供商不信任該平臺(tái)。

WebRTC可通過插入流API方案來(lái)得到了廣泛的應(yīng)用，因?yàn)樗梢杂糜诤芏喾矫妗Ｋ鞘鼓軌蛟L問媒體的API，也是啟用E2EE的必要步驟。但是，它本身沒有加密功能或加密密鑰管理功能。

最接近WebRTC兼容的E2EE媒體加密的是提議的IETF SFrame標(biāo)準(zhǔn)。它仍然需要一個(gè)外部系統(tǒng)來(lái)提供安全的外部密鑰管理。至此，蘋果公司報(bào)告稱，在1月18日召開的每月WebRTC臨時(shí)會(huì)議上，他們?cè)赟afari中添加了SFrame的初版安全實(shí)現(xiàn)。這得到了Firefox的良好反饋，F(xiàn)irefox的團(tuán)隊(duì)通常非常重視安全功能和保護(hù)互聯(lián)網(wǎng)用戶。網(wǎng)絡(luò)平臺(tái)方面也在取得進(jìn)展。

這里微妙之處在于SFrame的設(shè)計(jì)是具有前瞻性的。在其前身PERC迫使用戶進(jìn)入舊版RTP媒體傳輸并且僅限于視頻會(huì)議用例的情況下，SFrame設(shè)計(jì)為：

不區(qū)分用例（即可用于流媒體）

與協(xié)議無(wú)關(guān)（今天RTP，明天QUIC）

使用更少的帶寬開銷（比SRTP或PERC）

SVC編解碼器兼容。

C. 具有SFUs和現(xiàn)代媒體基礎(chǔ)設(shè)施的SVC

大多數(shù)人關(guān)注新編解碼器的編碼效率：

使用新的編解碼器導(dǎo)致帶寬使用減少

使用相同的輸入，可以在查看器端產(chǎn)生相同的質(zhì)量。

在下一代媒體體系結(jié)構(gòu)中使用的SVC提供的功能不僅僅是這些。

無(wú)需使用ABR

SVC提供了從單個(gè)編碼器在單個(gè)比特流中生成多層次分辨率的能力。換言之，SVC使得服務(wù)器端轉(zhuǎn)碼和ABR過時(shí)了（盡管仍然有其他原因需要為VOD轉(zhuǎn)碼服務(wù)器端）。

由于低分辨率內(nèi)容只編碼一次，因此編碼一層比特流也比目前同播或ABR那樣的3、5或7層獨(dú)立比特流更有效。在以適應(yīng)為準(zhǔn)則的現(xiàn)代媒體傳播系統(tǒng)中，它對(duì)底線產(chǎn)生了巨大的影響。

更好的網(wǎng)絡(luò)彈性

對(duì)于那些不熟悉媒體傳輸和部分可靠性概念的人，我們建議閱讀我們之前關(guān)于該主題的文章。

處理網(wǎng)絡(luò)故障的方法主要有三種：重傳、冗余和前向糾錯(cuò)。每一種都是一種相對(duì)折中的方案：

1. 重新傳輸假設(shè)您有時(shí)間再次發(fā)送數(shù)據(jù)包，并假設(shè)您為每個(gè)正在進(jìn)行的流，保留一個(gè)數(shù)據(jù)包緩存。好處是它實(shí)際上很容易實(shí)現(xiàn)。

2. 冗余假定您有能力使用更多的帶寬。如果您的數(shù)據(jù)包丟失是由于擁塞（數(shù)量問題）而不是質(zhì)量問題引起的，那將無(wú)濟(jì)于事。

3. FEC可以減少帶寬開銷，而不必等待重傳。但是，這將增加發(fā)送方和接收方的復(fù)雜性。

在分層編解碼器中，只有基本層對(duì)呼叫至關(guān)重要，丟失其他層只會(huì)降低接收端單個(gè)幀的分辨率。

因此，您不必保護(hù)整個(gè)流，而只需保護(hù)底層。這使得FEC變得更加有趣，因?yàn)閺?fù)雜性會(huì)自動(dòng)降低。如果在所有數(shù)據(jù)包上使用RED或FEC，則相對(duì)帶寬開銷也只是它的一小部分。

而且，基本層數(shù)據(jù)包的時(shí)間頻率是流時(shí)間頻率的一小部分，這意味著您有更多的時(shí)間來(lái)處理丟失的數(shù)據(jù)包。這也使得RTX更具吸引力。

無(wú)論您采用哪種網(wǎng)絡(luò)彈性方法，SVC都只會(huì)使其更加高效。

更快（比光）適應(yīng)

同樣，SFU的作用相對(duì)簡(jiǎn)單：要獲取傳入的數(shù)據(jù)包，需要檢查哪個(gè)數(shù)據(jù)包應(yīng)該被代理到給定的目的地，然后推送到該目的地。要決定哪個(gè)包應(yīng)該代理到特定的目的地，首先需要決定代理哪個(gè)分辨率/層，然后執(zhí)行更改。

這個(gè)決定通常是根據(jù)一些啟示方法做出的，這些啟示方法部分地基于觀看者帶寬容量、屏幕大小和執(zhí)行分辨率/層變化的設(shè)備硬件所引起的。

如果使用聯(lián)播，可以根據(jù)流的源ID（SSRC）來(lái)確定流的分辨率。提供streamID《=》分辨率映射后，SFU決定停止發(fā)送給定的流，并以不同的分辨率發(fā)送另一個(gè)具有相同內(nèi)容的流。為了使查看器解碼器能夠在沒有偽影的情況下跟蹤更改，它需要在切換之前等待一整幀。

SVC編解碼器有一種稱為可伸縮性結(jié)構(gòu)的特殊結(jié)構(gòu)，它定義了不同層之間的依賴關(guān)系。這是一個(gè)編解碼器和位流功能。在過去的幾年中，一項(xiàng)非常明智的進(jìn)步是在媒體傳輸級(jí)別復(fù)制并擴(kuò)展了這種可伸縮性結(jié)構(gòu)。

最終的目標(biāo)是在解碼器上即時(shí)做出可破譯性決策！

由于這些額外的結(jié)構(gòu)，SFU可以在給定目標(biāo)解碼分辨率的情況下，決定接收任何數(shù)據(jù)包時(shí)是否應(yīng)該丟棄該數(shù)據(jù)包。這是一個(gè)非常強(qiáng)大的功能：

通過不發(fā)送非關(guān)鍵數(shù)據(jù)包的NACK，減少與發(fā)送方的帶寬使用反饋

通過不發(fā)送解碼器最終會(huì)丟棄的多余數(shù)據(jù)包來(lái)減少前向媒體帶寬的使用

將分辨率從一個(gè)數(shù)據(jù)包更改為下一個(gè)數(shù)據(jù)包（在單位毫秒范圍內(nèi)），而不是等待全幀

老實(shí)說，這是迄今為止SVC編解碼器帶來(lái)的最有趣的功能。Emil Ivov（again）和他的團(tuán)隊(duì)的這個(gè)演示演示了一種非常直觀的方式來(lái)理解它在用戶體驗(yàn)方面提供的優(yōu)勢(shì)。

這是一項(xiàng)技術(shù)性很強(qiáng)的新功能，在此，我不再贅述技術(shù)細(xì)節(jié)。你可以參考我們的媒體服務(wù)器技術(shù)負(fù)責(zé)人Sergio的帖子了解技術(shù)細(xì)節(jié)。

3采納、性能和期望

A. 采納方面

AV1作為編解碼器并不是在技術(shù)上非常新鮮的一件事了。它于2018年4月宣布。此解碼器自那時(shí)以來(lái)就一直可在臺(tái)式機(jī)和筆記本電腦上使用。

Netflix和YouTube都采用了這一技術(shù)，甚至在2020年初在其移動(dòng)客戶端上啟用了AV1播放。

LG和三星在2020年宣布在其智能電視中支持解碼器，而索尼剛剛宣布在2021種電視型號(hào)中支持AV1。

從2021年3月開始，所有Android TV設(shè)備默認(rèn)都必須支持AV1。

支持AV1 10位HDR的硬件解碼器現(xiàn)已批量生產(chǎn)并提供dongle大小！

許多GPU供應(yīng)商和OS供應(yīng)商一直在添加AV1的解碼支持。

直到如今，現(xiàn)有的新功能包括了可以快速、良好地在Chrome中運(yùn)行的ENCODER軟件，以及支持編解碼器所有可擴(kuò)展性模式的RTP有效負(fù)載。

B. AV1編解碼器在實(shí)時(shí)模式下的性能

在2020年中期，我們進(jìn)行了一項(xiàng)針對(duì)實(shí)時(shí)編解碼器的研究，該研究表明，即使在非常有限的硬件上，AV1 RT的性能和速度也足夠好，并且在相同條件下肯定比其前代產(chǎn)品好。它經(jīng)過同行評(píng)審并發(fā)布在IEEE會(huì)議上，并且在ArXiv上提供了擴(kuò)展版本。本著可重現(xiàn)科學(xué)和開放數(shù)據(jù)的精神，下面的鏈接中提供了用于測(cè)試每個(gè)編碼器的命令行，供大家自己進(jìn)行測(cè)試。

據(jù)我們所知，這是在其實(shí)時(shí)配置和實(shí)時(shí)設(shè)置（定速輸入）中使用的編解碼器的唯一基準(zhǔn)測(cè)試和比較。Phoronix有一個(gè)測(cè)試套件，似乎可以以6和8的速度測(cè)試libaom實(shí)時(shí)模式，但是我們還沒有確切檢查使用了哪些命令行（例如，有多少個(gè)內(nèi)核，多線程等），以及輸入是否調(diào)速或加速?gòu)奈募x取。如果從文件中讀取，結(jié)果會(huì)比在真實(shí)環(huán)境中人為地要快。

C. AV1實(shí)時(shí)編解碼在Chrome瀏覽器中的性能

根據(jù)google的說法，chrome的性能目標(biāo)是720p，每秒30幀對(duì)于普通臺(tái)式機(jī)/筆記本電腦，速度為2 Mbps。libwebrtc中編碼器的速度配置是根據(jù)輸入分辨率和內(nèi)核數(shù)來(lái)選擇的。它使用與Cisco相同的閾值：2個(gè)內(nèi)核為最小可接受值，4個(gè)內(nèi)核為最大值。實(shí)際上，僅使用4個(gè)內(nèi)核，我們就能獲得比720p更高的分辨率。

對(duì)于google來(lái)說，選擇覆蓋Real Time Media網(wǎng)絡(luò)用例的絕大多數(shù)（在數(shù)量上）的目標(biāo)是有意義的。它還符合他們的目標(biāo)，為下一個(gè)10億互聯(lián)網(wǎng)用戶提供更好的體驗(yàn)，在這些用戶無(wú)法訪問超過2Mbps的帶寬的情況下。

對(duì)于像MilliCast這樣的實(shí)時(shí)流媒體平臺(tái)，在分辨率，幀頻，位深等方面沒有任何限制，本機(jī)應(yīng)用會(huì)替換Chrome以提供不同的操作點(diǎn)，例如廣播質(zhì)量（顏色分級(jí)）要求。

正如預(yù)期的那樣，SVC模式將占用更多資源（現(xiàn)下主要取決于所選的可伸縮性模式，目前占用的資源介于30％到40％之間），還有一些性能缺陷需要通過SVC支持解決。Google正在開發(fā)的WebRTC中的libaom多線程代碼中存在一個(gè)已知的回歸。我們提供了一些補(bǔ)丁，對(duì)于m90的一切都應(yīng)該是準(zhǔn)時(shí)的

所以現(xiàn)在，每個(gè)人的真正問題應(yīng)該是：什么時(shí)候?qū)?huì)實(shí)現(xiàn)呢？

它應(yīng)該已經(jīng)在Chrome Canary中了，您可以開始使用它并報(bào)告錯(cuò)誤（如果有）。不幸的是，提交錯(cuò)過了m89刪減，所以除非他們將其移植到m89（非常罕見，但正在討論中），否則它應(yīng)該只能在m90穩(wěn)定版中使用。

Webrtc系統(tǒng)：現(xiàn)在更難，更好，更快，更強(qiáng)大
編輯：lyn