正文字數：6285 ?閱讀時長：9分鐘

每年，我都會在IIT-RTC會議上與許多WebRTC標準人員進行交流，這場疫情顯然讓今年有所不同。雖然我們在今年的Kranky Geek會議上確實談到了標準化和“WebRTC的未來”，但我們沒有時間深入研究更多細節，所以我們將在這里討論。

作者 /?Chad Hart

原文鏈接 / https://webrtchacks.com/webrtc-today-tomorrow-bernard-aboba-qa/

可擴展視頻編碼

可拓展視頻編碼（SVC）可以說是處理來自同一發送者的多個媒體流以處理組呼叫中每個接收者的不同條件的更好方法。在許多方面，它也被認為更復雜。Sergio＆Gustavo對此主題發表了精彩的文章。

Chad：如果還沒有Simulcast，那SVC在哪里呢？

Bernard：在某些方面，SVC比Simulcast容易一些。今天，它在Chromium中作為時間可伸縮性的實驗性實現。在計劃B中，還支持時間可伸縮性-因此實際上已經存在，并且會議服務器都支持它。因此，對于大多數會議服務而言，從某些方面來說，這實際上是一個更輕松的進步，例如，同時支持RID和MID。

MID是SDP媒體標識符，RID?是用于限制單個流的較新的限制標識符。我將它留給讀者查看各種SDP規范，以獲取有關這些規范的更多信息。

我認為許多會議服務都支持RID和MID，Medooze和Janus都支持。關于SVC的理解之一是，在VP8和VP9中都是必需的-解碼器必須支持這一點。因此，沒有什么可以談判的。編碼器可以將其推出。如果不希望，SFU甚至不必丟棄[SVC層]，但這顯然更好。

AV1

很久以前，Chris Wendt在這里寫了一篇文章，內容涉及?H.26X和VPX陣營之間的編解碼器之戰，以及一個編解碼器統治它們的潛力。今天，該編解碼器已經存在，它被稱為AV1。

WebRTC何時將AV1作為標準？

?

Bernard：??[使用AV1]面臨的挑戰是設法在大量設備支持全分辨率編碼之前弄清楚如何使其有用和可用。

Chad：?我應該向聽眾解釋說AV1是下一代的開源免費編碼解碼器。

Bernard：? AV1本身不需要對WebRTC PeerConnection進行任何更改。但是作為示例，AV1支持許多新的可伸縮性模式。因此，你需要該控件，這就是WebRTC SVC的用武之地。

另一件事是AV1具有非常有效的屏幕內容編碼工具，你希望能夠將其打開。因此，我們添加了一個稱為內容提示的內容?，可能會導致AV1內容編碼器工具打開。

Floren?t [Castelli]提出了一種混合編解碼器Simulcasts。這樣做的想法是，例如，如果你想執行360P或720P之類的操作，并且你擁有可以做到的機器，則可以以較低的比特率對AV1進行編碼。你可以在軟件中做到這一點，不需要硬件加速。然后，在較高分辨率下，你將使用另一個編解碼器。例如，你可以使用VP8或VP9。

這樣一來，你就可以立即引入AV1編碼，而不必強制將其全部或全部刪除。隨著混合編解碼器Simulcasts和內容提示基本上只要AV1編碼器和解碼器進入的WebRTC PC，也就是時候了。我認為人們對AV1的考慮不多，但是通過這些擴展（對API的調整很少），我們的目標是立即使它可用。

我們距離這個目標不遠了。Alex博士正在編寫測試套件。編碼器和解碼器庫在那里，因此并不特別復雜。RTP封裝也不是特別復雜，它非常非常簡單。

Chad：那么，是什么讓它變得困難呢？

Bernard：訣竅在于我們所謂的依賴描述符頭擴展，它是SFU用來轉發的。它的棘手之處在于將支持構建到會議服務器中。AV1生來就允許端到端加密[e2ee]，這是可插入的流切入的地方。

實際上，AV1作為編解碼器在[編解碼器]方面并沒有太大的區別。我認為它是VP8 VP9譜系的下一個分支。它具有某種H.264類型的MAL單元語義，因此有點像H.264和VP9之間的交叉。

但是從會議服務器的總體使用模型的角度來看，它非常獨特，因為你具有端到端加密，因此，例如，你不應該解析AV1 OBU。SFU應該純粹基于對描述的依賴來做出前向決策，以允許端到端加密。因此，從本質上講，你已經進入了下一個模型，在此模型中，SFU現在可能可以獨立于編解碼器。

可插入的流和SFrame

可插入的流是與編解碼器獨立性松散相關并且與端到端加密（e2ee）直接相關的一個主題。實際上，我們已經在該主題上發表了文章，?而Emil Ivov幾周前在Kranky Geek上深入探討了e2ee??。

我將讓Berard談談可插入流API的應用。

在TPAC的可插入流上滑動。資料來源：TPAC-2020-Meetings（https://docs.google.com/presentation/d/1WHocMl47fukck4YQ6RuPzfagAj6bW0SjUELzwguC3qs/edit#slide=id.ga3f86d16f9_4_0）

Bernard：端到端加密不僅僅是一個簡單的用例。可插入流實際上是這個想法，在可插入流API模型中，一種思考方法是你可以訪問框架。你可以對框架執行操作，但是你無法訪問RTP標頭或RTP標頭擴展或類似內容。你不應明顯地改變框架的大小。因此，你無法向其中添加大量元數據。你應該在幀上進行操作，然后將其實質上返回給打包器，然后打包器將其打包為RTP并發送出去。因此它與RTP有一定聯系。

還有其他正在開發的API也可以按照為你提供視頻幀的相同思想進行操作。

其中最突出的是WebCodecs以及用于原始媒體的可插入流。考慮這一點的方法是對媒體流跟蹤的擴展，因為可插入流，原始媒體不依賴RTCPeerConnection，而可插入流和編碼媒體則依賴。在所有這些API中，你都可以訪問視頻幀（原始幀或編碼幀），然后可以對其執行操作，此后，你也必不可少地要將其返回。在插入流的情況下，它被分組并通過網絡發送。

有一些棘手的方面，有些bug已經被歸檔了。它現在可以適用于VP8和VP9。但它不能與H264一起使用，我不確定這一部分，但是我們有一個仍在處理的錯誤。

這里同樣重要的想法是，我們不會試圖告訴開發人員如何進行他們的加密或使用哪種密鑰管理方案。我們正在開發端到端加密格式的標準，即SFrame，并在那里進行IETF標準化工作。我們還沒有就密鑰管理計劃達成完全一致。事實證明，有多種場景可能需要不同的密鑰管理。

安全幀或SFrame是一種較新的提議，用于通過對整個媒體幀進行加密而不是對單個數據包進行加密來允許通過SFU的端到端媒體。由于每幀可以有多個數據包，因此可以更有效地運行。

來源：IETF Secure Frame (SFrame) proposal

（https://datatracker.ietf.org/doc/draft-omara-sframe）

Bernard：讓SFrame更具可擴展性的一個很酷的事情是，你是在一個完整的框架上操作，而不是在數據包上。這意味著，如果你做一個標記，你就在整個框架上做一次。對每個包進行數字標記被認為是不可行的。例如，對于一個關鍵幀，這意味著您可以為許多數據包簽名。但是對于SFrame，您只對每一幀進行標記。

因此，它實際上導致標記的工作量大幅減少。因此，現在實際上可以進行基本的原始身份驗證——知道每個幀來自誰，這在每個數據包模型中是不可能的。

每個人似乎都同意只需要一種SFrame格式，但對于密鑰管理來說，這是一件更棘手的事情。我們已經在TPAC討論過在瀏覽器中構建sfame的可能性——擁有Sfame的本地實現。我們還沒有達到我們認為可以擁有本機密鑰管理的程度。這是一件非常棘手的事情，因為你最終可能會在瀏覽器中使用五個密鑰管理方案。

WebCodecs

WebCodecs的主題是給開發人員更深的訪問權限和對實時傳輸控制堆棧的更多控制。我會讓Bernard解釋那是什么：

Bernard：WebCodecs的作用是讓你在較低的層次上訪問已經在瀏覽器中的編碼解碼器。所以本質上你要考慮的是它與可插入流有相似之處你可以訪問一個幀。例如，您可以訪問一個編碼幀，或者您可以輸入一個原始幀并獲得一個編碼幀。

Chad：好吧，那么它更低級別，直接訪問另一端的編碼器和解碼器？

Bernard：是的。在解碼端，類似于我們所說的均方誤差（MSE）。

Chad：媒體來源擴展？

媒體源擴展和媒體源API取代了Flash在標準化的JavaScript中為流媒體所做的大部分工作。它允許開發人員向瀏覽器播放任何容器化媒體，即使它有DRM內容保護。這里有一個MDN鏈接可以了解更多信息。

https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API

那么這與MSE相比如何呢？

Bernard：在解碼端把它看作WebCodecs的方式類似于MSE，只不過媒體不是容器化的，它會在編碼視頻幀中，所以它們在這點上是相似的。

當別人問我“這些東西怎么一起用？”例如，如果你想要制作游戲流媒體或電影流媒體，你可以連接WebTransport來接收編碼媒體。然后你可以用MSE渲染它，或者你可以用WebCodecs渲染它。中小企業的不同之處在于，你必須傳輸容器化的媒體。有了WebCodecs，它就不會被封裝，而是被打包，所以有一點點不同。在MSE的功能中，您實際上可以獲得內容保護支持。而在WebCodecs中，至少在今天，你不會獲得內容保護支持。

Chad：在編碼方面，MSE與WebCodecs有什么不同？

Bernard：這很有趣，因為如果你仔細想想，如果這是一個云游戲或電影或從云上下來的東西，你永遠不會在瀏覽器上編碼，只會解碼。因此，這種情況實際上不需要WebCodecs來編碼任何東西。例如，編碼場景可以是視頻上傳。因此，如果你想上傳視頻，你可以用WebCodecs編碼視頻，然后通過網絡傳輸發送。您可以使用可靠的流來發送它，也可以用數據報來發送。如果你用數據報來做，那么你就必須做你自己的重傳和你自己的前向糾錯。

如果您不太關心視頻上傳的延遲控制，您可以只使用可靠的流。因此，這是一個使用WebCodecs作為編碼器的場景，我認為這個場景或用例是一個WebCodecs具有真正優勢的場景，因為您不必做任何奇怪的技巧，比如把它放在白板上什么的，或者做任何事情。

面對這些替代品，WebRTC還有前景嗎？

發視頻是WebRTC做的一件大事。使用其他API如網絡編碼解碼器或在WASM建立自己的編碼解碼器的網絡傳輸會取代網絡實時傳輸嗎？事實上，這就是Zoom所做的(正如我們已經討論過的)，谷歌Chrome團隊的一些成員甚至在上一次網絡直播中推廣了這一點。

Chad：方向是讓人們自己去思考和做那些事情嗎？或者你認為還會有一個平行的軌道來標準化這些機制嗎？

Bernard：這是個真正的問題。從某種意義上說，你可以自由地做任何你想做的事情，如果你的世界里一切都是端到端的，那也沒關系。舉個例子，今天許多人想使用開源的SFU。你不能只是把你想要的任何東西發送到一個開源的SFU——它對它將要得到的東西有期望。就像視頻上傳之類的簡單的場景中這可能并不重要，但在會議服務之類的場景中就很重要，最重要的是你需要有一個標準來了解所期望的內容。

現在，要考慮的另一件事是性能，因為我知道人們已經提出了嘗試使用WebTransport制作會議服務器的可能性。我對此深感憂慮，因為特別是今天，如果你看看會議服務，對越來越多的人數有巨大的需求，比如7乘7，或者誰知道它們會有多大。

因此，學生們的需求似乎無法滿足——老師們希望每個人都能來上課，而這個班級可能非常龐大。因此，在這種情況下，您會看到數量驚人的流，可能是高清的。在這種情況下，性能實際上非常重要。因因此，對于這種分解模型，很多代碼都在WASM中運行，它是否會將所有東西復制無數次，這是一個真正的問題。這就是它今天的運作方式。例如，在WebTransport中，您在接收時有兩份副本。無論何時你把任何東西發送到WASM，你都有一份副本。并不是所有內容都轉移到單獨的線程中。

Chad：我想資源的低效利用有很大的潛力——瀏覽器要管理所有這些資源還有很多工作要做。

Bernard：對。因此，人們確實抱怨WebRTC是單一的，但另一方面，當它是一個單一的代碼庫，其中沒有運行所有的JavaScript時，有巨大的優化機會。你可以消除分類模型中可能存在的大量副本。

機器學習

ML是計算機科學中普遍存在的一個話題。幾年前，我們甚至在RTC舉辦了2018年的Kranky Geek活動。我們已經看到了在JavaScript內部的ML的改進，比如我的“不要碰你的臉”實驗，以及在各種WebRTC應用程序的后臺刪除/替換的進展。這些大部分都是圍繞著WebRTC運行的，而不是直接使用它。事實上，ML在較低層次的WebRTC中似乎明顯不存在。這件事我問過Bernard。

Bernard：當我們在WebRTC-NV上開始討論時，我們做的一件事是做NV用例，并嘗試評估人們熱衷于做什么。事實證明，除了端到端加密之外，人們最感興趣的事情之一是訪問原始媒體，因為這打開了機器學習的整個世界。

Chad：讓我也澄清一下——訪問原始媒體只是為了降低延遲？在我的實驗中，我發現當堆棧中存在大量固有延遲時，很難讓這些東西實時運行。

Bernard：我們看到的很多場景都涉及到本地處理。舉個例子，你有一個捕獲媒體，你想在發送之前在捕獲的媒體上做一些事情。例如，Snapchat中的許多效果都是這樣做的。這就是我們所說的滑稽帽子，你觀察面部位置，然后戴上帽子什么的。一個非常受歡迎的特性是定制背景，在這里你可以檢測背景并以某種方式改變它——有動態背景，等等。

今天，機器學習在許多方面都是在云端完成的。例如，通常語音轉錄或翻譯。所以你把它發送到云端，我不知道我們是否能在本地做到這一點，更不用說在Web瀏覽器中了。還有其他的一些事情是可以在本地完成，比如面部定位和身體姿勢之類的事情。

長期的總體目標是能夠做任何您可以在本地完成的、也可以在web上完成的事情。這不僅需要訪問原始媒體，還需要以高效的方式訪問。例如，在本地實現中，我們經常看到所有東西都留在GPU上所有操作都在那里完成。我們還沒到那一步。要做到這一點，我們需要捕獲GPU而不需要復制，然后允許機器學習操作在不將其復制回主存、上傳和下載的情況下完成。

來源：Kranky Geek Virtual 2020 – Google WebRTC項目更新https://youtu.be/-THOaymtjp8?t=704

背景有點不同，谷歌實際上提到了“零復制視頻捕獲”來保持GPU幀：

Bernard：這是W3C研討會上提出的一個話題。出現的概念之一是網絡神經網絡API。之前你看到的是很多像TensorFlow這樣的庫使用了像WebGL或者WebGPU這樣的東西。但是如果你仔細想想，這并不是一個完全有效的方法。實際上，你要做的是讓矩陣乘法這樣的基本操作高效運行，僅僅給它WebGPU或WebGL操作并不一定是這樣做的。因此，WebNN實際上試圖在更高的層次上處理這些操作——比如矩陣乘法器的操作。

這里的一個關鍵是所有的API必須協同工作，這樣它們就可以將數據傳遞到正確的地方，而不必復制到另一個API。舉個例子，你會發現WebCodecs確實支持GPU緩沖區的概念，但是有一些限制，因為很多時候那些GPU緩沖區是不可寫的——它們是只讀的。所以如果你的目標是做機器學習和改變，GPU緩存里的東西，你不可能在沒有副本的情況下做到這一點，但也許你會嘗試獲得盡可能多的性能。

2020年一個真正引起我注意的產品是英偉達的Maxine。英偉達在其圖形處理器上使用生成對抗網絡(GAN)來抓取少量關鍵幀，然后連續提取面部關鍵點，將關鍵幀數據與面部關鍵點相結合來重建面部。英偉達聲稱，這種方法使用的帶寬只有H.264的十分之一。它還提供了新的功能，因為重建模型可以調整做一些事情，如超分辨率，面部重新排列，或模擬化身。

Chad：這似乎是ML對RTC更具革命性的使用。這也是標準的方向嗎？

Bernard：如果你著眼于下一代編解碼器的研究，現在有大量的研究是用機器學習完成的——這只是從編解碼器的角度來看。我的思考方式是疫情期間觀察你的周圍，我們看到的是娛樂和實時會議的融合。所以你會看到你的許多節目——周六夜現場——都是通過視頻會議制作的。我看的戲劇，里面的角色都有自己的背景。我們甚至看到了一些結合了會議技術的電影。從微軟團隊中，我們已經看到了我們所說的“協同模式”，它本質上是從會議服務中獲取用戶輸入，并將其傳輸到一個完全合成的新事件中。籃球運動員是真實的，但它把比賽和實際上不在那里的球迷結合在一起。所以你構建了環境——增強現實/虛擬現實。我看到了娛樂和實時場景的融合。這反映在網絡傳輸和WebCodecs等工具中。既有RTC又有流媒體。所有這些場景都是相同的。

機器學習可以是導演，可以是攝影師，可以是編輯，它可以把整個事情聯系在一起。它的每個方面都可能受到機器學習的影響。

我不認為這只是一種傳統媒體。我認為我們不應該認為這些只是試圖用新的API做與之前同樣的會議。這對于任何人來說都沒有多大的激勵作用，只是用這套全新的東西來重寫你的會議服務。但我認為它實現了一套全新的娛樂和會議組合場景，這是我們今天甚至無法想象的。很多好像都有AR/VR的味道在里面。

Chad：好吧，那么會有更多的由人工智能控制的實時媒體類型的融合。

現在該做什么?

Chad：在我們結束之前，你還有什么想說的嗎？

Bernard：關于這項新技術，有很多在原始試驗中是可行的。使用它是很有啟發性的，試著把東西放在一起看看它是如何工作的，因為你肯定會發現很多缺點。我不是說所有這些API在任何意義上都是一致的——它們不是。但我認為這會讓你感覺到外面有什么是可能的，你能做什么。人們會對其中一些技術的問世速度感到驚訝。我想說，到2021年，這些東西很可能會開始上市，你會在商業應用中看到一些。所以人們經常把它當作今天不存在的東西，或者我不需要去想它，我認為他們是錯的，那些這樣想的人最終會感到非常驚訝。

LiveVideoStackCon 2021 ShangHai

我們準備好全新的內容

在上海歡迎您的到來

LiveVideoStackCon 2021?上海站

北京時間：2021年4月16日-4月17日

點擊【閱讀原文】了解大會詳情

總結

以上是生活随笔為你收集整理的WebRTC的现状和未来：专访W3C WebRTC Chair Bernard Aboba（下）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。