作者 / 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的用武之地。

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

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

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

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

實際上，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的端到端媒體。由於每幀可以有多個數據包，因此可以更有效地執行。

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

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

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

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

WebCodecs

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

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

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

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

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還有前景嗎？

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。

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

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

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

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

背景有點不同，谷歌實際上提到了“零複製影片捕獲”來保持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年，這些東西很可能會開始上市，你會在商業應用中看到一些。所以人們經常把它當作今天不存在的東西，或者我不需要去想它，我認為他們是錯的，那些這樣想的人最終會感到非常驚訝。