WebRTC 無疑推動和改變了互聯網視頻，而這僅僅是剛剛開始，除了大家熟悉的 WebRTC-PC、Simulcast 和 SVC，有太多的新技術和新架構出現在 WebRTC 新的標準中，比如 WebTransport、WebCodecs、AV1、E2EE、SFrame、ML 等等，這篇文章詳細介紹了未來的 WebRTC-NV，不容錯過。
說明：
WebRTC 標準現狀
Bernard: W3C WebRTC 工作組的主要工作包括以下三個方面：
目前最重要的工作，是完成 WebRTC Peer Connection (WebRTC-PC) 標準化，以及相關的標準比如 WebRTC-Stats。
Capture，Streams 和 Output 相關的標準，包括 Capture，Streams 和 Output 相關的標準，包括 Media Capture and Streams，Screen Capture，Media Capture from DOM Elements，MediaStream Image Capture，MediaStream Recording，Audio Output Devices，以及 Content-Hints。
下一代 WebRTC，也就是 WebRTC-NV。
Bernard: WebRTC-NV 的工作主要是四個方面。
第一類是對 WebRTC PeerConnection 的擴展。這包括 WebRTC Extensions, WebRTC-SVC, 以及 Insertable Streams。我特別強調這些工作都依賴於 “Unified Plan”，現在已經是默認的 SDP 規範了。例如，如果要使用 Insertable Streams 來支持 E2EE (End-to-End Encryption，端到端加密)，那麼首先要支持 “Unified Plan”。
第二類，WebRTC-PC 相比，還不夠成熟和完善，比如 WebRTC Identity，WebRTC Priority Control 和 WebRTC DSCP。
第三類是對 Capture 的擴展，比如 MediaStreamTrack Insertable Streams，Media Capture and Streams Extensions，和 MediaCapture Depth Stream Extensions。
第四類是獨立的標準，它們沒有必要依賴 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 測試結果。
Chad: WPT 是通用的功能測試，而 KITE 是 WebRTC 專門的互操作性測試。
Bernard: WebRTC 的 WPT 測試，只跑在單一的瀏覽器上；WebRTC 的 WPT 測試沒有針對服務器的測試，而 WebTransport 是有的。因此 WebRTC WPT 測試，無法驗證瀏覽器的互操作性，也無法驗證瀏覽器和服務器的互操作性；而 KITE 測試是覆蓋了這些方面。
Chad: 這實際上是 WebRTC 的特點，從一個瀏覽器發送媒體數據到另外一個瀏覽器。
Bernard: 爲了能更方便的看到 WPT 的測試覆蓋率，我們在規範中做了標記。所以除了測試結果，你還可以看到標準已經有多少被測試覆蓋和驗證了。
新冠對標準工作的影響
Bernard: 我們努力向 W3C 證明，我們已經準備好進入 PR 階段了。這是非常大的一步，但總體上還是因爲新冠導致進展變慢了。雖然我們取得了很大的進展，但是新冠讓大家都慢了下來。
Chad: 是因爲大家忙於支持自己暴增的業務，還是沒法把大家聚在一起工作？
Bernard: 新冠打亂了很多事情。例如 KITE 互操作性測試，是需要人工參與的，所以現在我們需要很費勁才能測試，因爲現在大家不能在一個地方工作，特別大家還是在全球各地；想象下如果按照其他人正常上班的時間，你可能要凌晨 3 點配合測試，這是多麼痛苦。
新冠不僅打亂了測試，也影響了代碼實現的進度，具體可以看下面的圖。目前幾乎所有 PR 中的功能，都已經在至少一個瀏覽器中實現了，但是之前我們預期是 2020 年秋季在兩個以上瀏覽器實現。所以目前測試和代碼實現都比我們預期的慢。
WebRTC 標準有多重要？
Bernard 認爲標準化不僅是寫文檔，更重要的是關於互操作性 (interoperability)。
Bernard: 標準主要關注測試和穩定性。WebRTC PC 最大的一個挑戰就是它包含了太多的能力，只要稍微看下它相關的主要的 Bug，就可以發現對它的覆蓋率遠遠不夠；即使我們不要求完整覆蓋，而只考慮 “可接受” 的覆蓋率，也非常的困難；比如在複用 (Multiplexing) 方面，我們有個 Bug 影響了線上服務，但是我們卻沒有覆蓋它。我們看到有很多 Bug 都是 WPT 覆蓋不到的，這些只有 KITE 這種互操作性測試才能覆蓋到，但是目前我們在 KITE 中還沒有達到 100% 覆蓋。
我在 RTC 領域中，碰到的最大的挑戰之一，就是海量的測試用例。Chad，想象下如果讓你去做測試，即使要達到 95% 的覆蓋也是非常的有挑戰的。當然完整的測試非常有幫助，我們當然也要考慮完整覆蓋帶來的巨大挑戰，真的非常的難。
WebRTC 擴展
Bernard: 有很多標準都依賴 RTCPeerConnection，例如 WebRTC extensions，還有比如，RTP header extension encryption，WebRTC SVC (Scalable Video Coding)。我認爲 Insertable Streams 也算 WebRTC PC 的擴展。一般情況下，都是假設使用 RTCPeerConnection 的前提下。
更安全的訪問媒體設備
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 的一些問題，比如都讓用戶選擇指定的設備了，那麼 Constraints 的意義在哪裏，如果不匹配呢？
Chad: 這是否意味着，關於設備 Picker 會有更多的標準出來？
Bernard: 嗯，是的。當然我們會不斷改進我們的模型，Jan-Ivar 會提交一個單獨的標準，解決所有這些問題。這裏麻煩的是，這是一個全新的模型，如何讓大家能使用起來，可能需要花很長時間。
TPAC slide on getBrowserContextMedia proposal. 來源: TPAC-2020-Meetings。
WebRTC 下一代標準
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 新的傳輸
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 支持可靠傳輸的流傳輸，也可以支持不可靠的數據報。
Bernard: 而且它是雙向的，一旦客戶端發起了 WebTransport，服務器也可以主動發起一路傳輸流。
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 一樣的能力，你可以發送和接收數據。
Bernard: 其實 WebTransport API 已經相當完善了，而且它已經完成了它的 Origin Trial 版本，在 M88 版本中。還有一些 Bug，有些部分還不能很好的工作，但是 API 基本比較穩定了；你可以寫比較複雜的用例了。我們很快會提供比較完整的例子，可以讓大家嘗試使用。
而在服務器端，還有一些 QUIC 的互操作性問題。現在使用較多的是 Python aioquic，當然你可以用 quiche，可惜我們沒有一個 Nodejs 版本。
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 是和這些協議複用的。
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 測試。
Bernard: 而這些 LoopBack 測試，沒有在所有瀏覽器通過。原因是因爲發送端是 RID，而接收端是 MID，比如發送了三條流，那麼每個流會有個不同的 MID；而 Firefox 不支持 RTP 頭中的 MID 擴展，所以導致了測試失敗。
我們也發現，只要我們開始測試，就能發現一些不對的地方。
再舉一個詭異的例子，我們開啓了硬件加速，發現它不僅僅是編碼速度加快，還改變了編碼的字節流，這就導致互操作性測試失敗了。有可能開啓 Simulcast 後，你的 SFU 就撲街了。我很想和相關朋友見面聊聊，也想做更多的 Simulcast 測試，就像 Dr. Alex 做的一樣，這樣可以更好知道目前的狀況。
如果大家都在推動和使用 Unified Plan 標準，那麼我們會越來越好。
Bernard: 如果大家都使用 Unified Plan，那麼互操作性會工作得很好；但我們離這個目標還差得挺遠。目前我們還只是支持了這個功能，而且測試覆蓋率在下滑，當然也不必所有瀏覽器都支持所有功能了才能商用，實際上很多商業應用，並不是要求支持所有的瀏覽器，而是支持某幾個常用的瀏覽器。
所以關注這個問題，比較好的辦法是看下測試矩陣，看主流的廠商和瀏覽器的運行結果，這樣能知道目前是在什麼狀態。
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 目前還沒有。
Bernard: 這個是個有趣的話題，因爲在雲遊戲或者電影，或者其他從雲端下載的流媒體場景中，你並不需要在瀏覽器上編碼，只需要解碼。因此這些場景並不需要 WebCodecs，只有在視頻上傳的場景中才需要編碼。如果你需要上傳視頻，那麼你可以用 WebCodecs，然後使用 WebTransport 發送，可以用可靠流也可以用 Datagrams，如果是 Datagrams 那就要自己做 FEC 了。
如果你不是很關心延遲，那麼用可靠流就很好了。只有在需要編碼的場景下，WebCodecs 才具備真正的優勢，不需要使用奇怪的技巧。
敢問路在何方？
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
Bernard: 這是 W3C 研討會上提出來的一個話題，出現了一個概念叫做 Web 神經網絡，目前已經有很多基於 WebGL 或者 WebGPU 的 TensorFlow 的庫了。如果仔細考慮，你會發現這不是高效的方式。實際上你需要的是一些基本操作，比如矩陣乘法的運算，用 WebGPU 或者 WebGL 來實現矩陣乘法這些基本操作不一定合理。所以 WebNN 從更高的層面來解決這個問題，讓矩陣乘法成爲一種基本運算。
這裏的關鍵，是協調這些 API 一起工作，把數據放到正確的地方，這樣才能避免拷貝。比如 WebCodecs 支持了 GPU 緩衝區，但目前這個緩衝區是隻讀的，如果你希望對 GPU 緩衝區的內容做 ML，這就不行了因爲無法修改它，你只能用拷貝實現。
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 年就可能上線了。所以走過路過千萬不要錯過，這不是未來，是很快到來的現在，好好把握機會。
全文完
本文分享自微信公衆號 - 音視頻開發進階（glumes_blog）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。