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

WebRTC 無疑推動和改變了互聯網視頻，而這僅僅是剛剛開始，除了大家熟悉的 WebRTC-PC、Simulcast 和 SVC，有太多的新技術和新架構出現在 WebRTC 新的標準中，比如 WebTransport、WebCodecs、AV1、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、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.264、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 作為一個編解碼器，并不像它的名字那樣有很大的變化，它更多是 VP8、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 年就可能上線了，所以走過路過千萬不要錯過，這不是未來，是很快到來的現在，好好把味訓會，

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

標籤：其他

上一篇：智慧校園網路架設GPS北斗時鐘同步系統

下一篇：影像的加密與解密