webrtc和MilliCast的AV1實時編碼

自2020年4月起，獨立的webrtc和MilliCast平臺中的AV1實時編碼已經(jīng)可用，正如我們在之前的文章中所述。然而，對于那些想在web應(yīng)用程序中單獨使用它的人來說，您必須重新編譯Chrome。雖然我們?yōu)樯鐓^(qū)提供了預(yù)編譯的二進制文件，也有少數(shù)勇敢的人早早地進行了測試，但這是單層實現(xiàn)，不支持SVC。

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

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

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

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

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

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

在不到兩周的時間里，下列三項主要技術(shù)已成為標準或可在Chrome中使用：

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

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

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

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

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

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

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

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

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

更快的適應(yīng)性

后端無媒體處理

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

2RTC創(chuàng)新軌跡

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

“史蒂夫·喬布斯曾經(jīng)說過：“我一直被更具革命性的變化所吸引。我不知道為什么。因為它們更難?！?/p>

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

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

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

3. AV1包含屏幕編碼工具作為基本功能，而不是像HEVC中的擴展。這是會議的主要競爭優(yōu)勢?！?/p>

A. 屏幕共享

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

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

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

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

B. 端到端加密

E2EE是下一件值得關(guān)注的問題。也許是因為這是webrtc最初許下的承諾之一。又或許是因為它成為了一個過度使用的營銷術(shù)語，而Zoom已經(jīng)變得遍體鱗傷。也許是因為大多數(shù)人仍然聲稱擁有它，實際上卻沒有。

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

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

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

WebRTC可通過插入流API方案來得到了廣泛的應(yīng)用，因為它可以用于很多方面。它是使您能夠訪問媒體的API，也是啟用E2EE的必要步驟。但是，它本身沒有加密功能或加密密鑰管理功能。

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

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

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

與協(xié)議無關(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提供的功能不僅僅是這些。

無需使用ABR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最終的目標是在解碼器上即時做出可破譯性決策！

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

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

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

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

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

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

3采納、性能和期望

A. 采納方面

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以現(xiàn)在，每個人的真正問題應(yīng)該是：什么時候?qū)崿F(xiàn)呢？

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

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