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

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

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

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

1創新不會在隔絕的真空中發生

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

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

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

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

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

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

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

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

媒體引擎（編解碼器，媒體和網絡傳輸的耦合）

SFUs（選擇性轉發單元），代替MCU（多點會議單元）

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

更好的網絡彈性

更快的適應性

后端無媒體處理

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

2RTC創新軌跡

微軟首席架構師伯納德·阿波巴（Bernard Aboba）曾經寫過有關AV1的文章（我們添加的鏈接）：

“史蒂夫·喬布斯曾經說過：“我一直被更具革命性的變化所吸引。我不知道為什么。因為它們更難。”

AV1旨在與下一波WebRTC視頻創新集成：端到端加密，SVC和獨立于編解碼器的轉發。因此，這與視頻編解碼器無關，而與下一代架構有關。

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

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

3. AV1包含屏幕編碼工具作為基本功能，而不是像HEVC中的擴展。這是會議的主要競爭優勢。”

A. 屏幕共享

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

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

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

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

B. 端到端加密

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

關于E2EE，對這個問題最好的回應之一是Emil Ivov的這篇演講。

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

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

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

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

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

不區分用例（即可用于流媒體）

與協議無關（今天RTP，明天QUIC）

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

SVC編解碼器兼容。

C. 具有SFUs和現代媒體基礎設施的SVC

大多數人關注新編解碼器的編碼效率：

使用新的編解碼器導致帶寬使用減少

使用相同的輸入，可以在查看器端產生相同的質量。

在下一代媒體體系結構中使用的SVC提供的功能不僅僅是這些。

無需使用ABR

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

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

更好的網絡彈性

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

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

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

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

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

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

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

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

無論您采用哪種網絡彈性方法，SVC都只會使其更加高效。

更快（比光）適應

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

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

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

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

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

由于這些額外的結構，SFU可以在給定目標解碼分辨率的情況下，決定接收任何數據包時是否應該丟棄該數據包。這是一個非常強大的功能：

通過不發送非關鍵數據包的NACK，減少與發送方的帶寬使用反饋

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

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

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

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

3采納、性能和期望

A. 采納方面

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

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

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

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

支持AV1 10位HDR的硬件解碼器現已批量生產并提供dongle大小！

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

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

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

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

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

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

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

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

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

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

所以現在，每個人的真正問題應該是：什么時候將會實現呢？

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

Webrtc系統：現在更難，更好，更快，更強大
編輯：lyn