WebRTC 的現狀和將來：專訪 W3C WebRTC Chair Bernard Aboba

WebRTC 無疑推進和改變了互聯網視頻，而這僅僅是剛剛開始，除了你們熟悉的 WebRTC-PC、Simulcast 和 SVC，有太多的新技術和新架構出如今 WebRTC 新的標準中，好比 WebTransport、WebCodecs、AV一、E2EE、SFrame、ML 等等，這篇文章詳細介紹了將來的 WebRTC-NV，不容錯過。

說明：
本文爲阿里雲視頻雲翻譯的技術文章
原文標題：WebRTC Today & Tomorrow: Interview with W3C WebRTC Chair Bernard Aboba
原文連接：https://webrtchacks.com/webrtc-today-tomorrow-bernard-aboba-qa/
做者：乍得・哈特（Chad Hart）
翻譯：忘籬、致凡、開視、仲才、海華

Bernard 是一直聚焦在 RTC 領域的專家，W3C WebRTC 聯席 Chair，WEBTRANS 和 AVTCORE 的聯席 Chair，ORTC、WebRTC-SVC、WebRTC-NV 用例、WebRTC-ICE、WebTransport 和 WebRTC-QUIC 等文檔的主編，微軟 Teams 媒體組的首席架構師。

WebRTC 標準現狀

做爲 W3C WebRTC 工做組的 Chair 之一，Bernard 是 WebRTC 標準的權威人物，因此咱們從工做組的章程開始聊起。

Bernard: W3C WebRTC 工做組的主要工做包括如下三個方面：

1. 目前最重要的工做，是完成 WebRTC Peer Connection (WebRTC-PC) 標準化，以及相關的標準好比 WebRTC-Stats。
2. Capture，Streams 和 Output 相關的標準，包括 Media Capture and Streams，Screen Capture，Media Capture from DOM Elements，MediaStream Image Capture，MediaStream Recording，Audio Output Devices，以及 Content-Hints。
3. 下一代 WebRTC，也就是 WebRTC-NV。

WebRTC-NV 是下一代 WebRTC，在當前 WebRTC 1.0 以後的標準。

Bernard: WebRTC-NV 的工做主要是四個方面。

1. 第一類是對 WebRTC PeerConnection 的擴展。這包括 WebRTC Extensions, WebRTC-SVC, 以及 Insertable Streams。我特別強調這些工做都依賴於 「Unified Plan」，如今已是默認的 SDP 規範了。例如，若是要使用 Insertable Streams 來支持 E2EE (End-to-End Encryption，端到端加密)，那麼首先要支持 「Unified Plan」。
2. 第二類，和 WebRTC-PC 相比，還不夠成熟和完善，好比 WebRTC Identity，WebRTC Priority Control 和 WebRTC DSCP。
3. 第三類是對 Capture 的擴展，好比 MediaStreamTrack Insertable Streams，Media Capture and Streams Extensions，和 MediaCapture Depth Stream Extensions。
4. 第四類是獨立的標準，它們沒有必要依賴 RTCPeerConnection 或者 Media Capture。好比 WebRTC-ICE，目前就是獨立的標準。有些標準不是 W3C WebRTC 小組定義的，好比 WebTransport，由 W3C WebTransport 小組定義；WebRTC-QUIC，由 ORTC 小組定義；WebCodecs，由 WICG 定義。

有時候 「NV」 很含糊並且挺使人迷惑的，它最初是指 ORTC，但今天它主要是指多個標準，而不是某一個單一的標準。目前 「NV」 比較含糊，有時候指的是 RTCPeerConnection 的擴展，或者 Capture APIs，或者其餘的 API 好比 WebTransport 和 WebCodecs，因此當提到 「WebRTC-NV」 時，最好能確認下究竟是指什麼。

WebRTC 標準的流程
WebRTC 的協議由 IETF 定義，而瀏覽器相關的 API 則由 W3C 定義。在標準化的過程當中，是存在一些爭議的。
Bernard 介紹了標準化過程的一些背景。

Chad: 能介紹下 W3C 標準制定的階段嗎？
Bernard: 第一個階段是 CR，Candidate Recommendation。CR 意味着被普遍 Review 過了，符合標準工做組的要求，而且是能夠實現的。在 CR 階段，標準可能還未被徹底實現，可能存在一些有風險的功能，或者瀏覽器之間的互操做性（interoperability）問題。

完整流程能夠看這個連接。

Chad: 您剛纔提到最後一個 CR 階段，請問這意味着在整個 W3C 的 specification 流程中會有多個 CR 階段，仍是整個 CR 階段內還有多個子階段？
Bernard：如今 W3C 有新的流程，適用於討論定稿的活躍標準。無論是上述哪一種狀況，咱們討論的是在進入 PR 階段前的最後一次 CR 階段。
在 PR (Proposed Recommendation) 這個階段時，標準中的內容都已經被實現，而且經過了互操做性測試。PR 時會收集足夠須要的數據，例如 Peer Connection 涉及到了海量的數據，包括 WPT 測試結果，以及 KITE 測試結果。

WPT 是指 web-platform-tests，屬於 W3C 實現的 API 的功能性驗證測試，能夠參考 https://wpt.fyi
KITE 是一個開源項目，屬於 WebRTC 專門的互操做性測試。Dr. Alex Gouaillard 在這篇文章中有詳細討論 Breaking Point: WebRTC SFU Load Testing。

Chad: WPT 是通用的功能測試，而 KITE 是 WebRTC 專門的互操做性測試。
Bernard: WebRTC 的 WPT 測試，只跑在單一的瀏覽器上；WebRTC 的 WPT 測試沒有針對服務器的測試，而 WebTransport 是有的。所以 WebRTC WPT 測試，沒法驗證瀏覽器的互操做性，也沒法驗證瀏覽器和服務器的互操做性；而 KITE 測試是覆蓋了這些方面。
Chad: 這其實是 WebRTC 的特色，從一個瀏覽器發送媒體數據到另一個瀏覽器。
Bernard: 爲了能更方便的看到 WPT 的測試覆蓋率，咱們在規範中作了標記。因此除了測試結果，你還能夠看到標準已經有多少被測試覆蓋和驗證了。

新冠對標準工做的影響
新冠對 WebRTC 產生了有趣的影響。一方面，新冠致使 WebRTC 使用量劇增，讓整個社區很繁忙，也更關注擴展性和可靠性。另外，對現有的工做流程也有打斷，這是否也影響到了 W3C 標準化工做？

Bernard: 咱們努力向 W3C 證實，咱們已經準備好進入 PR 階段了。這是很是大的一步，但整體上仍是由於新冠致使進展變慢了。雖然咱們取得了很大的進展，可是新冠讓你們都慢了下來。
Chad: 是由於你們忙於支持本身暴增的業務，仍是無法把你們聚在一塊兒工做？
Bernard: 新冠打亂了不少事情。例如 KITE 互操做性測試，是須要人工參與的，因此如今咱們須要很費勁才能測試，由於如今你們不能在一個地方工做，特別你們仍是在全球各地；想象下若是按照其餘人正常上班的時間，你可能要凌晨 3 點配合測試，這是多麼痛苦。
新冠不只打亂了測試，也影響了代碼實現的進度，具體能夠看下面的圖。目前幾乎全部 PR 中的功能，都已經在至少一個瀏覽器中實現了，可是以前咱們預期是 2020 年秋季在兩個以上瀏覽器實現。因此目前測試和代碼實現都比咱們預期的慢。

來源：TPAC-2020-Meetings

WebRTC 標準有多重要？
WebRTC 目前在主流的瀏覽器中都已經支持，如今 WebRTC 承載了世界上主要的 VoIP 的流量，這個節點上開始下一階段的標準化工做是否很重要？
Bernard 認爲標準化不只是寫文檔，更重要的是關於互操做性 (interoperability)。

Bernard: 標準主要關注測試和穩定性。WebRTC PC 最大的一個挑戰就是它包含了太多的能力，只要稍微看下它相關的主要的 Bug，就能夠發現對它的覆蓋率遠遠不夠；即便咱們不要求完整覆蓋，而只考慮 「可接受」 的覆蓋率，也很是的困難；好比在複用 (Multiplexing) 方面，咱們有個 Bug 影響了線上服務，可是咱們卻沒有覆蓋它。咱們看到有不少 Bug 都是 WPT 覆蓋不到的，這些只有 KITE 這種互操做性測試才能覆蓋到，可是目前咱們在 KITE 中尚未達到 100% 覆蓋。
我在 RTC 領域中，碰到的最大的挑戰之一，就是海量的測試用例。Chad，想象下若是讓你去作測試，即便要達到 95% 的覆蓋也是很是的有挑戰的。固然完整的測試很是有幫助，咱們固然也要考慮完整覆蓋帶來的巨大挑戰，真的很是的難。

WebRTC 擴展

WebRTC 正在***愈來愈多的行業和場景。WebRTC 1.0 還在標準化的過程當中，因此必需要想清楚如何添加新的功能。正如 Bernard 解釋的，WebRTC Extensions 包含了不少沒有添加到 WebRTC 1.0 的功能。

Bernard: 有不少標準都依賴 RTCPeerConnection，例如 WebRTC extensions，還有好比，RTP header extension encryption，WebRTC SVC (Scalable Video Coding)。我認爲 Insertable Streams 也算 WebRTC PC 的擴展。通常狀況下，都是假設使用 RTCPeerConnection 的前提下。

更安全的訪問媒體設備

隨着視頻會議的普遍使用，出現了攝像頭被錯誤使用，以及意外的屏幕共享等問題。另外，通常來講，在 WebRTC 服務中如何快捷訪問攝像頭一般是一個問題，如何平衡好隱私問題和便捷性是一個難題。此外，媒體設備可能會被惡意標識和得到我的身份信息 (fingerprinting)，這對隱私保護形成很大的挑戰。
而 getCurrentBrowsingContextMedia，是嘗試解決這個難題的提案之一。

Chad: 是否能聊聊 getCurrentBrowsingContextMedia 提案？
Bernard: 這個是一個擴展標準，我認爲它是 Screen Capture 的擴展。讓咱們先看看 Media Capture 的問題吧，主要是關於隱私和安全方面的問題。咱們發現 Media Capturing Streams 對隱私很不友好；假設你把全部的媒體設備信息都給了應用，包括你沒選中的設備，那麼這就會形成身份信息的一個隱私問題，由於我知道了你全部的設備信息，儘管你可能不想使用的某個涉及隱私的攝像頭，我也知道你有這個攝像頭了。這些設備能幫助得到和標識我的身份信息 (fingerprinting)，因此 Jan-Ivar 提交了一個提案，設計了和 Screen Capture 很相似的一個模型。
在 Screen Capture 共享屏幕時，應用只有獲取用戶選中的 Surfaces 的權限，用戶沒有選中的沒有權限。因此並非我能獲取你打開的全部頁面的權限，否則就可能看到你的一些隱私頁面，好比正在購買的東西等。只有當用戶選擇某個頁面後，應用才能獲取權限並啓動 Screen Capture，這就是 Jan-Ivar 提案的模型。它也會成爲瀏覽器 Picker 的一部分，應用只能獲取用戶選中的頁面的權限。這是個很大的變化，也引入了 Media Capture 和 Media Streams 的一些問題，好比都讓用戶選擇指定的設備了，那麼 Constrains 的意義在哪裏，若是不匹配呢？
Chad: 這是否意味着，關於設備 Picker 會有更多的標準出來？
Bernard: 嗯，是的。固然咱們會不斷改進咱們的模型，Jan-Ivar 會提交一個單獨的標準，解決全部這些問題。這裏麻煩的是，這是一個全新的模型，如何讓你們能使用起來，可能須要花很長時間。

TPAC slide on getBrowserContextMedia proposal. 來源: TPAC-2020-Meetings

WebRTC 下一代標準

標準之爭的結果之一，就是不肯給出版本號，由於你們可能會有分歧，好比應該用大版本（1.0、20），仍是小版本（1.一、1.2）。曾經有段時間 ORTC 是做爲 WebRTC 的候選標準。WebRTC 1.0 整合了不少咱們討論到的內容。關於後續版本，最終仍是使用了一個溫和和不肯定的名字：「WebRTC Next Version」，或 「WebRTC-NV」。
Bernard 解釋了這究竟是什麼意思。

Chad: 咱們聊到 WebRTC 的 「Next Version」，但不是 WebRTC 2.0，是由於 WebRTC 1.0 還沒完成嗎？
Bernard: 咱們是時候考慮不用 NV 這個詞了，由於它表明兩個徹底不一樣的東西。其一，NV 是隻 Peer Connection 的擴展，好比 Insertable Streams、WebRTC Extensions、WebRTC SVC 等，這些差很少就是 ORTC 定義的東西，不過已經整合到了 WebRTC-PC 中了。
其二，NV 指的是前面我提到的獨立的標準，好比 WebTransport、WebCodecs、WebRTC ICE，這些徹底是獨立的，並不依賴 RTCPeerConnection。因此這確實是一個很大差別的版本，和以前很不同，能夠稱爲 「下一代」 的東西。
固然如今屬於很早的階段，WebTransport 仍是 Origin Trial，WebCodecs 也是同樣。之前都在 WebRTC PC 這個單體 (monolithic) 中，而如今你須要用 Web Assembly 本身實現，因此這個是很是很是不一樣的開發模型。
有些尚未加進去，例如 WebTransport 目前仍是 client-server 模型，咱們正在寫一個 peer-to-peer 模型，不久就會進入到 Origin Trial 版本。因此，目前只使用 WebCodec 和 WebTransport，還沒法實現 WebRTC-PC 對應的用例。
如今你們愈來愈關注 Machine Learning，因此須要訪問 RAW Media，這是 WebRTC NV 很重要的場景，而 ORTC 沒有提供這個能力。某種意義上說，WebTransport 和 WebCodecs 比 ORTC 提供了更底層的訪問能力，好比 ORTC 不支持直接訪問 Decoders 和 Encoders，而 WebCodecs 能夠作到。我想咱們已經採納了 ORTC 的想法，並將這個想法帶到了更底層的傳輸層。

咱們將會繼續討論 ML 和 WebRTC，但先讓咱們繼續聊聊 ORTC。
ORTC 咋樣了？
Object RTC (ORTC) 是 WebRTC 的一個替代模型，它不依賴 SDP，提供更底層的組件和控制能力。Bernard 是做者之一，Microsoft 在最初的 Edge 瀏覽器中，支持了 ORTC，而如今卻沒什麼聲音了，那麼 ORTC 發生了什麼？Bernard 一個月前解釋過，ORTC 不少能力，都吸取到了 WebRTC 的標準中。

Chad: 你是 ORTC 標準的做者之一，ORTC 如今是否達到了它的願景？
Bernard: Object Model 存在於 Chromium 瀏覽器中，因此咱們有大部分 ORTC 定義的對象，好比 Ice Transport、DTLS Transport、SCTP Transport，全部這些都在 WebRTC PC 和 Chromium 中。
ORTC 還有高級功能也被採納了，好比 Simulcast 和 SVC，咱們還實現過原始版本的 E2EE。因此目前而言，WebRTC PC 能夠等價於 ORTC，加上對象模型和這些擴展。
咱們也在關注一些新場景的應用，好比 IoT 的數據傳輸的部分，這在 WebRTC 中也有體現，好比 P2P 的數據交換。

WebTransport 新的傳輸

WebTransport 是由 W3C 一個專門的工做組定義的，固然和 WebRTC 有很緊密的關係。
QUIC 是一種改進的傳輸協議，有點像 WebTransport 可使用的 「TCP/2」。
那麼什麼是 WebTransport，它是從哪裏演化來的，和 WebRTC 又是什麼關係？

Bernard: WebTransport 是一組 API，由 W3C WebTransport 組定義的；同時，WebTransport 也是一系列的協議，由 IETF 定義的。這些協議包括 WebTransport over QUIC，簡稱 QUIC Transport；也包括 WebTransport over HTTP/3，也可能 HTTP/2。所以，WebTransport 的 API 不只僅支持 QUIC，也支持 HTTP/3，以及 HTTP/2（主要考慮 Fail-over 的回退）。
WebTransport 的 API 是一個 CS 模型的 API，構造和函數都很像 WebSocket。在 WebTransport 的構造函數中，你須要指定一個 URL。可是和 WebSocket 不一樣的是，WebTransport 支持可靠傳輸的流傳輸，也能夠支持不可靠的數據報。

數據報，例如 UDP，應用在快速可是非可靠的傳輸場景中。

Bernard: 並且它是雙向的，一旦客戶端發起了 WebTransport，服務器也能夠主動發起一路傳輸流。

雙向的？好比像 WebSocket？

Bernard: WebScoket 只是客戶端發起的，不能由服務器發起；而 WebTransport 能夠由服務器發起。另外，WebTransport over QUIC 時鏈接是非 Pooled，而 WebTransport over HTTP/3 是 Pooled，這創造了一些新的應用場景，有些在 IETF BoFs 中由提到過。這意味着，在同一個 QUIC 鏈接中，你能夠傳輸不少內容，好比 HTTP/3 請求和響應、WebTransport、Streams 和 Datagrams。
Justin Uberti 提出過一個標準 IETF RIPT BOF，就是將這些不一樣的東西放在了一塊兒。在這個場景下，有來回的 RPC 請求，也包括服務器主動發起的請求。好比一個客戶端，發出請求說要播放一個電影，或者進入一個遊戲，或者加入視頻會議，而後服務器就開始主動發起多路不一樣的視頻流的傳輸了。
我認爲 WebTransport 有可能會給 Web 帶來革命性的變化，HTTP/3 自己就是對 Web 的一種革命。而這些關鍵變化，是 HTTP/3 Pooled Transport；相比之下，QUIC 就更簡單了，它只是給了一個 Socket 同樣的能力，你能夠發送和接收數據。

WebTransport 還有多久纔會上？

Bernard: 其實 WebTransport API 已經至關完善了，並且它已經完成了它的 Origin Trial 版本，在 M88 版本中。還有一些 Bug，有些部分還不能很好的工做，可是 API 基本比較穩定了；你能夠寫比較複雜的用例了。咱們很快會提供比較完整的例子，可讓你們嘗試使用。
而在服務器端，還有一些 QUIC 的互操做性問題。如今使用較多的是 Python aioquic，固然你能夠用 quiche，惋惜咱們沒有一個 Nodejs 版本。

正如 Bernard 提到的，WebTransport 是客戶端服務器模型，而不是 WebRTC 這種 P2P 模型。不過，咱們看到有個 P2P QUIC 的預覽版了。實際上 Flippo 早在 2019 年，實現過一個 QUIC DataChannels，這個和 WebTransport 的差異是什麼？

Bernard: Flippo 實現的 RTCQuicTransport，是用的 ORTC 版本，不支持 W3C Streams，用的也是 gQUIC 協議，而不是 IETF QUIC 協議。WebTransport 是基於 W3C Streams，使用的是 IETF QUIC 協議。因此，RTCQuicTransport 是過期的代碼，它是老的 API 和老的協議，這部分代碼已經從 Chromium 中移除了。

那麼在實時場景下，咱們如今如何使用 P2P WebTransport？

Bernard: 咱們有個擴展標準，依然在 ORTC 工做組中。大概你能夠認爲是 WebTransport，不過它是用 RTCIceTransport 構造，而不是一個 URL。固然在構造函數中，須要傳遞一個 ICE Transport，而不是傳 URL。
關於 P2P 部分，基本能夠從 RTCDtlsTransport 抄過來，並且這個擴展規範自己很少，差很少 95% 的東西和 WebTransport 規範自己是同樣的。
Chad: 有人這麼作過嗎？
Bernard: 咱們目前尚未能夠工做的新版本 API 和新的 QUIC 庫。RTCQuicTransport 是獨立的，如今 WebRTC ICE 也是獨立的，不依賴 WebRTC PC；當使用 RTCIceTransport 構造 RTCQuicTransport 時，它們不會和 PC 複用。
在過去，RTCIceTransport 必須使用獨立的端口，由於 gQUIC 沒有複用 RTP/RTCP、STUN 和 TURN，而如今 IETF QUIC 是和這些協議複用的。

gQUIC 是 Google 的 QUIC 版本。
gQUIC 不復用端口，看起來會對端口使用，以及穿越防火牆，產生比較大的影響。

Bernard: 開發者是否想讓 QUIC 和其餘媒體複用一樣的端口？今天在 WebRTC PC 中，Bunding 是很是很是常見的，基本上 99% 的狀況下都是複用一個端口。那麼 QUIC 也應該同樣支持端口複用，那麼咱們就不該該使用以前的 API 從 URL 構造 RTCQuicTransport，而應該使用 RTCIceTransport 構造它。
這變得有點奇怪了，由於如今部分的 WebTransport 開始依賴 RTCPeerConnection。

RPC setup to send media via WebTransport. Source: IETF 107 – Justin Uberti, 107-ript-rtc-implementation-experiences

Simulcast 多播

WebTransport 看起來確實挺有潛力的。另外，幾乎主流的會議服務廠家，都使用了 Simulcast，而 Simulcast 是困擾 WebRTC 的棘手問題之一，在標準和互操做性上也一直在掙扎和擠牙膏狀態。

Chad: Simulcast 如今是什麼狀況？
Bernard: 目前已經支持了，Chromium 支持的編解碼器都已經支持了 Simulcast，至少目前存在於 Chromium 中的編解碼器已經支持了。因此理論上，無論是 H.26四、VP8 和 VP9，都是能夠用 Simulcast 的。
咱們正在找 Bug，也遇到了一些比較難搞的 Bug，例如 H.264 沒法正常工做。除了 KITE 全量測試以外，咱們還創建了 LoopBack 測試，能夠快速測試基本的能力，因此 Fippo 寫了 LoopBack 測試。

若是你感興趣，Fippo 寫的關於 「Simulcast Playground」 的文章在這裏。

Bernard: 而這些 LoopBack 測試，沒有在全部瀏覽器經過。緣由是由於發送端是 RID，而接收端是 MID，好比發送了三條流，那麼每一個流會有個不一樣的 MID；而 Firefox 不支持 RTP 頭中的 MID 擴展，因此致使了測試失敗。
咱們也發現，只要咱們開始測試，就能發現一些不對的地方。
再舉一個詭異的例子，咱們開啓了硬件加速，發現它不只僅是編碼速度加快，還改變了編碼的字節流，這就致使互操做性測試失敗了。有可能開啓 Simulcast 後，你的 SFU 就撲街了。我很想和相關朋友見面聊聊，也想作更多的 Simulcast 測試，就像 Dr. Alex 作的同樣，這樣能夠更好知道目前的情況。
若是你們都在推進和使用 Unified Plan 標準，那麼咱們會愈來愈好。

Unified Plan 是一個新的 SDP 標準，在 SDP 中定義瞭如何支持 Simulcast。Unified Plan 就是咱們的康莊大道啊。如今狀況怎樣？

Bernard: 若是你們都使用 Unified Plan，那麼互操做性會工做得很好；但咱們離這個目標還差得挺遠。目前咱們還只是支持了這個功能，並且測試覆蓋率在下滑，固然也沒必要全部瀏覽器都支持全部功能了才能商用，實際上不少商業應用，並非要求支持全部的瀏覽器，而是支持某幾個經常使用的瀏覽器。
因此關注這個問題，比較好的辦法是看下測試矩陣，看主流的廠商和瀏覽器的運行結果，這樣能知道目前是在什麼狀態。

固然這不是使人振奮的消息，在絕大多數瀏覽器上都支持固然是更好的了，不過有時候就是這樣，有些功能在不一樣的瀏覽器上支持是不太同樣的。

SVC 可伸縮編碼

在發送方和接收方各類限制不一樣的場景中，SVC（Scalable Video Coding）被認爲是一種比較好的方式，好比發送方發送 「多」 流，而接收方每一個條件不一樣，有些接收高碼率有些低碼率。它也帶來了複雜性，Sergio & Gustavo 這篇文章討論了這個話題。
若是 Simulcast 沒有準備好，咱們是否能用 SVC？

Bernard: SVC 某種程度上比 Simulcast 稍微簡單點，目前 Chromium 中 SVC 是實驗性的功能，叫 Temporal Scalability。另外，PlanB 也支持 Temporal Scalability。因此 SVC 目前是支持的，並且也有會議服務器支持這個特性。因此對於不少會議服務商，要想達到一樣的效果，SVC 其實是更容易實現的一種方式，比支持 RID 和 MID 容易。
MID 是 SDP 中的 Media Identifier，參考 SDP Anatomy，而 RID (Restriction Identifier) 是新增的一個標準，用來表達獨立的流。這部分從略，請你們本身瞭解相關的文檔。
不少會議服務器支持 RID 和 MID，我認爲 Medooze 和 Janus 都支持。而 VP8 和 VP9 是默認都支持的，解碼器必須支持它，所以不用協商。固然 SFU 也能夠不丟棄 SVC 的某些層，固然若是某些場景下丟棄某些層，效果確定會比較好。

AV1 新編解碼器

Chris Wendt 在好久之前寫過一篇文章，關於 H.26X 和 VPX 的編解碼之爭，以及是否會出現一個統一的編解碼器一統天下。今天，這個統一的編解碼器就叫 AV1。
WebRTC 計劃何時支持 AV1？

Bernard: 當前尚未不少設備能支持較高分辨率的 AV1 編碼，所以目前 AV1 面對的挑戰，是如何在這種狀況下讓 AV1 用起來。
Chad: 我應該向你們解釋下，AV1 是下一代、開源的、免費的編解碼器。
Bernard: 支持 AV1 並不會改變 WebRTC PeerConnection，反過來也是。可是 AV1 支持了不少有用的新的 Scalability 能力，若是要用到這些新能力，就是咱們以前提到的 SVC 的內容了。
另外，AV1 有一個很是高效的屏幕編碼（Screen Content Coding）算法，你們可能想開啓它。因此咱們增長了 Content Hints 的功能，這樣 AV1 的屏幕編碼才能用起來。
Florent Castelli 提交過一個提案，關於混合編碼的 Simulcast。這個提案容許不一樣層（Simulcast Layer）使用不一樣編碼；好比你能夠在低碼率層用 AV1 編碼，分辨率 360p 或 720p，能夠用軟件編碼，也不用硬件加速；而高分辨率層，你能夠用另外的編碼器，好比 VP8 或 VP9。
這個提案，容許你部分使用 AV1，而不是全用或全不用；這樣就能夠在 WebRTC PC 中，很快就能夠用 AV1。我想你們不是很在乎用的是不是 AV1，而是很在乎 AV1 提供的這些新的能力，以及更小的 API 變化。咱們的目標就是儘快讓它用起來。
咱們離 AV1 用起來也不遠了，編碼器和解碼器庫都已經準備好了，並無特別難的問題。Dr. Alex 正在寫測試用例。RTP 封裝支持 AV1 也不難，這些都很簡單。

那麼，最難的是什麼呢？

Bernard: 難點是在 RTP 擴展頭的描述，通常用在 SFU 轉發中，這是會議服務器中支持 AV1 最棘手的部分。另一個難點，是 AV1 天生就支持 E2EE（端到端加密），它是基於 Insertable Streams 實現的。
AV1 做爲一個編解碼器，並不像它的名字那樣有很大的變化。它更可能是 VP八、VP9 的繼續演進版本。它有 H.264 那樣的 NALU 語法，因此它有點像 VP9 和 H.264 之間的過渡。
若是從會議服務器的角度看，因爲天生支持 E2EE，AV1 是很是不同的。所以，SFU 沒法解析 AV1 OBU，SFU 只能依據以前的描述來作判斷。本質上說，SFU 已經進入了下一個模型，在這模型中是和編解碼器不相關的，SFU 獨立於編解碼器。

SFrame 和 E2EE

Insertable Streams 是和 E2EE（端到端加密）直接相關，和編解碼器相對獨立的話題。實際上咱們發表過相關的文章。Emil Ivov 在 Kranky Geek 深刻探討過 e2ee。
我想和 Bernard 探討下 Insertable Streams API。

Slide on insertable streams from TPAC. Source: TPAC-2020-Meetings
Bernard: E2EE 不僅是一個簡單的使用場景，Insertable Streams 其實是提供了你訪問 Frame 的能力。你能夠對 Frame 作一些修改，可是你不能修改 RTP 頭或擴展或相似的東西。固然你也不能大幅改變 Frame 的尺寸，好比不能添加大量的 Metadata 到 Frame。你能夠修改 Frame，而後把它打包併發送。
提供 Frame 級別的操做能力的 API，主要是 WebCodecs 和 Insertable Streams。能夠認爲它們是對 MediaStreamTrack 的擴展，由於它們不依賴 RTCPeerConnection。在這些 API 中，你能夠獲取一個原始的 Frame，或者一個編碼過的 Frame，而後作一些修改後，打包併發送。
目前還有一些 Bug，VP8 和 VP9 工做良好，可是 H.264 估計還不支持。
E2EE 的關鍵想法，是不限制開發者使用什麼 Key Management。咱們正在制定 E2EE 相關的標準，就是 SFrame（Secure Frame）；目前尚未在 Key Management 上達成一致。事實證實，不一樣場景下須要不一樣的 Key Management。

SFrame 是一個新的標準提案，容許經過 SFU 轉發 E2EE 的媒體；E2EE 的加密是在 Frame 上，而不是在 Packet 上。因爲每一個 Frame 可能會被分紅多個 Packet，因此這樣也很高效。

Source: IETF Secure Frame (SFrame) proposal
Bernard: SFrame 在 Frame 上加密，比在 Packet 上加密更靈活。好比若是要對 Frame 作簽名，只須要簽名一次；而對每一個 Packet 簽名是不可行的，好比對於關鍵幀，就須要簽名不少個 Packet，而 SFrame 則只須要一次簽名。
因此這也意味着減小了不少簽名的開銷，這樣就能夠作到 Origin Authentication，能夠知道這個包是誰發出來的，而基於 Packet 的簽名沒法作到這點。
看起來每一個人都贊成，只須要一種 SFrame 的格式，可是對於 Key Management 會很麻煩。咱們在 TPAC 上討論過，是否能在瀏覽器中實現 SFrame，在 Key Management 上還未達成一致，這可能會致使出現多種 Key Management。

WebCodecs 新編解碼能力

WebCodecs 給了開發者更底層的訪問能力。

Bernard: WebCodecs 是開放給了開發者更底層的能力，這些能力已經在瀏覽器中了。WebCodecs 和 Insertable Streams 相似，都是 Frame 級別的操做。好比，你能夠操做一個編碼後的 Frame，或者你能夠輸入一個未編碼的 Frame 而後拿到一個編碼後的 Frame。
Chad: 因此，這是一個更底層的能力，包括編碼器和解碼器？
Bernard: 是的，解碼器這部分，和 MSE 很相似。
Chad: MSE，Media Source Extensions?

Media Source Extensions，以及 Media Source API，主要是替代 Flash 的媒體能力，能夠用標準 JS 代替 Flash。MSE 容許開發者輸入一個封裝好的媒體，好比 fMP4 切片，也支持 DRM，詳細參考這裏。
那麼 WebCodecs 和 MSE 的區別是什麼呢？

Bernard: WebCodecs 解碼部分和 MSE 很相似，不過輸入的是編碼後的 Frame，而沒有外層的封裝。
有朋友問，「這些東西該如何配合使用？」，我舉個例子，若是你要作流媒體視頻或遊戲業務，你可使用 WebTransport 接收編碼好的媒體數據，而後你可使用 MSE 或者 WebCodecs 解碼和渲染。MSE 的輸入是封裝好的數據，而 WebCodecs 是編碼好的 Frame。MSE 支持 DRM，而 WebCodecs 目前尚未。

那麼在編碼方面，MSE 和 WebCodecs 的差異呢？

Bernard: 這個是個有趣的話題，由於在雲遊戲或者電影，或者其餘從雲端下載的流媒體場景中，你並不須要在瀏覽器上編碼，只須要解碼。所以這些場景並不須要 WebCodecs，只有在視頻上傳的場景中才須要編碼。若是你須要上傳視頻，那麼你能夠用 WebCodecs，而後使用 WebTransport 發送，能夠用可靠流也能夠用 Datagrams，若是是 Datagrams 那就要本身作 FEC 了。
若是你不是很關心延遲，那麼用可靠流就很好了。只有在須要編碼的場景下，WebCodecs 才具有真正的優點，不須要使用奇怪的技巧。

敢問路在何方？

發送視頻是 WebRTC 很重要的能力，是否這個能力能夠被 WebCodec 和 WebTransport 或者 WASM 取代呢？實際上，Zoom 就是這麼作的。
Zoom 的方案是更好的方案嗎？是不是將來的趨勢？

Chad: 這是咱們須要搞清楚的方向嗎？仍是這些方案都會同時存在？
Bernard: 嗯這確實是一個問題。若是端到端都是你本身的應用，那麼你能夠隨意選擇。但今天，有不少人但願使用開源的 SFU 服務器，這就必須使用標準接入了，不能隨意發送任何媒體格式給 SFU。若是隻是簡單的視頻上傳的場景，可能也問題不大；不過在會議場景中，涉及的網元和終端可能會不少，保持標準接入老是一個好事情。
除了 SFU，性能也是很是關鍵的因素。我知道有些朋友用 WebTransport 實現會議能力，但我對這個方案表示懷疑，由於目前會議的與會者愈來愈多了，好比 7x7，甚至 11x11。
彷佛需求永遠不會被知足，好比在線課堂中，老師但願看到班上的每一個人，而一個班的人數可能遠不止 11 人。在這種場景下，流的數目會很是的多，並且不少都是高清流，這時候性能就真的是一個很大的問題了。WASM 或者 WebTransport 這種方式，內部有不少內存拷貝，好比在 WebTransport 中有兩份拷貝，傳給 WASM 時又須要拷貝一次，它們可能還不在一個線程中，這對性能優化有很是大的挑戰。
Chad: 我想在這種場景下如何優化資源的使用，仍是能夠作不少事情的。
Bernard: 嗯沒錯，雖然人們老是抱怨 WebRTC 是單體應用，可是另一方面，單體應用相對很容易作性能優化。而在 WebTransport+WebCodecs+WASM 這種模型中，很難避免大量的拷貝，也很難作深度的性能優化。

ML 機器學習

ML 是如今計算機科學界很廣泛的話題，幾年前甚至 Kranky Geek 2018 的主題都是 RTC AI。如今也看到 JS ML 有了很大進展，好比 Don’t Touch Your Face，以及各類 WebRTC 應用中的虛擬背景。然而 WebRTC 底層卻沒有太多和 ML 相關的內容，我請教了 Bernard 這個問題。

Bernard: 咱們在 WebRTC-NV 的用例中，討論你們正在嘗試的熱度很高的事情。咱們發現，除了 E2EE（端到端加密）以外，你們最熱衷作的事情就是訪問 RAW 媒體，這也給 ML 打開了大門。
Chad: 我也要確認下，訪問 RAW 媒體，是爲了獲取更低延遲嗎？我作了一些嘗試，發現當整個調用 Stack 很深時，很難作到低延遲。
Bernard: 不少場景都涉及到了客戶端處理，好比，你獲取了媒體幀，你但願先對媒體幀作一些改變，而後再發送出去。在 Snapchat 中不少特效，都是這種方式實現的，好比戴上一個虛擬的帽子或其餘東西。另一個很受歡迎的功能，就是虛擬背景，或者相似的東西。
固然，不少 ML 是在 Cloud 運行的，好比語音轉換或者翻譯。我不知道是否客戶端也能作到這點，但目前主要是發送到 Cloud 處理。可能客戶端能完成的，主要是面部識別和身體姿態識別。
長期的目標，是 Native 能實現的，均可以在 Web 實現。這不只僅是訪問 RAW 媒體，並且是要實現高效的訪問。好比，在 Native 方案中，咱們常常發現媒體內容只停留在 GPU，而不須要額外拷貝；目前 Web 還作不到這一點，仍是存在不少拷貝。

Source: Kranky Geek Virtual 2020 – Google WebRTC project update https://youtu.be/-THOaymtjp8?t=704

在 Kranky Geek 的活動中，Google 提到了如何實現 GPU 零拷貝。

Bernard: 這是 W3C 研討會上提出來的一個話題，出現了一個概念叫作 Web 神經網絡，目前已經有不少基於 WebGL 或者 WebGPU 的 TensorFlow 的庫了。若是仔細考慮，你會發現這不是高效的方式。實際上你須要的是一些基本操做，好比矩陣乘法的運算，用 WebGPU 或者 WebGL 來實現矩陣乘法這些基本操做不必定合理。因此 WebNN 從更高的層面來解決這個問題，讓矩陣乘法成爲一種基本運算。
這裏的關鍵，是協調這些 API 一塊兒工做，把數據放到正確的地方，這樣才能避免拷貝。好比 WebCodecs 支持了 GPU 緩衝區，但目前這個緩衝區是隻讀的，若是你但願對 GPU 緩衝區的內容作 ML，這就不行了由於沒法修改它，你只能用拷貝實現。

2020 年 NVIDIA 的一個產品引發了個人注意，NVIDIA 使用運行在 GPU 上的 GAN，捕獲關鍵幀的面部信息。而後它將面部信息和關鍵幀結合起來，重構了整個流。這樣就只須要傳遞面部特徵信息，這能夠節約不少帶寬，NVIDIA 聲稱能夠作到 H.264 碼率的 1/10。這個模型還能夠用在超分（辨率），面部調整，或者是模擬表情等。
這彷佛是 ML 在 RTC 的革命性的應用。是否有相關的標準？

Bernard: 若是你正關注下一代編解碼器的相關研究，不少都是和 ML 相關的。
新冠致使了周圍發生了不少變化，包括娛樂和會議的結合。不少電視節目，包括《Saturday Night Live right》，製做過程使用了會議技術。我注意到有些劇院，已經開始使用虛擬背景。而會議自己也有不少變化，好比 Microsoft Teams 推出的 Tegother 模式，將用戶從視頻中摳出來放到虛擬的會議室中。在體育運動中，運動員和球都是真實的，而觀衆席上的觀衆是虛擬的或遠程的。
那麼實際上咱們涉及到了 AR 或 VR 的範疇，從新構造了環境。我看到了娛樂和 RTC 在不少場景下的融合，這反映在了 WebTransport 或者 WebCodecs 這種工具中，它既能夠用在流媒體傳輸中，也能夠用在 RTC 中。
ML 也能夠是導演，它也能夠是攝影師，還能夠是編輯，它能夠把全部這些事情串聯在一塊兒。實際上每一個方面都將能夠受到 ML 的影響。
我不認爲這隻影響到了傳統流媒體，我也不認爲咱們要繼續使用老的 RTC 的 API。在現有 RTC 系統中，要用新的 API 重寫部分服務，估計沒人有動力肝這事，可是，我仍是認爲 WebRTC 新的 API，將開啓一個流媒體和 RTC 融合的新時代，這裏面有不少新東西可能咱們今天都沒法想象到，不少都和 AR/VR 相關。

將來已來

Chad: 最後想和你們說點啥？
Bernard: 咱們聊到的不少新技術，都已經有了 Origin Trial，你們能夠獲取到。把它們串起來使用，很是具備啓發性；固然也會發現不少不足。我並非說它們一致性很好，實際上不是，可是能給你一個印象，那就是將來你大概能作什麼。這些技術會很快面世，這會大大超過你們的預期。甚至使用這些技術的商業應用，在 2021 年就可能上線了。因此走過路過千萬不要錯過，這不是將來，是很快到來的如今，好好把握機會。

「視頻雲技術」你最值得關注的音視頻技術公衆號，每週推送來自阿里雲一線的實踐技術文章，在這裏與音視頻領域一流工程師交流切磋。