![]()
每年，我都會在IIT-RTC會議上與許多WebRTC標準人員進行交流，這場疫情顯然讓今年有所不同。雖然我們在今年的Kranky Geek會議上確實談到了標準化和“WebRTC的未來”，但我們沒有時間深入研究更多細節，所以我們將在這裏討論。
原文鏈接 / https://webrtchacks.com/webrtc-today-tomorrow-bernard-aboba-qa/
Bernard在實時通信領域有着長久而卓越的職業生涯。除了W3C WebRTCCo-Chair 的角色之外，他還是WEBTRANS和AVTCORE工作組的Co-Chair以及ORTC、WebRTC-SVC、WebRTC-NV Use Cases、WebRTC-ICE、WebTransport和WebRTC-QUIC文檔的編輯。不要忘記，WebRTC在IETF中也是部分標準化的，同時Bernard也是WEBTRANS和AVTCORE WGs的Co-Chair。在微軟，他是微軟團隊媒體組織的首席架構師，該組織名爲IC3，支持微軟團隊和基於團隊基礎設施的其他項目，如Azure通信服務(Gustavo在此發佈了相關信息)。
作爲W3C WebRTC工作組的Chair之一，Bernard是WebRTC標準化過程中的權威人物。我首先向他詢問了工作組目前的章程。
Bernard：
正如在2020年4月在W3C的演講中所討論的，WebRTC 工作組章程描述了三個領域的工作：
1. 完成第一優先的網絡實時通信對等連接（
WebRTC-PC
），以及網絡實時通信統計等相關規範，例如WebRTC-Stats。
2. 捕獲、流和輸出相關規範，包括媒體捕獲和流、屏幕捕獲、從DOM元素中捕獲媒體、媒體流圖像捕獲、媒體流錄製、音頻輸出設備和內容提示。
3. WebRTC-NV，WebRTC的“下一個版本”。
WebRTC-NV是WebRTC的“下一個版本”。這是當前1.0規範之後的內容。
Bernard：
WebRTC-NV的工作分爲四大類。
1. 一類是WebRTC對等連接的擴展。這包括
WebRTC擴展
，
WebRTC-SVC
和
可插入流
。我要提到的是，網絡實時傳輸中心建議和所有依賴於實時傳輸中心連接的工作都需要
RTCPeerConnection
“統一計劃”，這是所有瀏覽器中默認的SDP語言。例如，如果不首先支持“統一計劃”，就不可能利用可插入流在您的應用程序中支持端到端加密。
2. 第二類涉及不符合WebRTC-PC建議中包含的實施或成熟度要求的功能，如WebRTC Identity、WebRTC Priority Control和WebRTC DSCP。
3. 第三類是對Capture的擴展，如
MediaStreamTrack可插入流
，
Media Capture和Streams擴展
以及
MediaCapture深度流擴展
(最近恢復)。
4. 第四類是我所說的獨立規範，它不一定依賴於
RTCPeerConnection
或現有的Media Capture規範。WebRTC-ICE(目前已經作爲獨立的規範實現)屬於這一類，W3C WEBRTC工作組之外開發的API規範也屬於這一類，如WebTransport(W3C WebTransport工作組)、WebRTC-QUIC(ORTC工作組)和WebCodecades(WICG工作組)。
鑑於不同的工作類別，“NV”一詞有些模糊，可能會使人困惑。該術語最初指的是ORTC，但今天它通常指的是多個規範，而不是一個文件。在當前的用法中，有模糊之處，因爲“NV”可能指的是
RTCPeerConnection
和現有捕獲應用程序接口
的擴展，或者與
RTCPeerConnection
或現有捕獲應用程序接口無關的應用程序接口，如
WebTransport
和
WebCodecs
。因此，當有人提到“WebRTC-NV”時，通常有必要詢問後續問題，以瞭解他們想要的潛在含義。
WebRTC中使用的協議是由
IETF
定義的，而W3C定義了瀏覽器使用的API。W3C的正式標準化之路——以及關於應該包括什麼的爭論——有時是一個有爭議的話題。
Chad：
你能帶領我們的觀衆梳理一遍W3C規範階段嗎？
Bernard：
第一個標準化階段是CR-候選人推薦。候選人推薦意味着該規範已經過廣泛審查，符合工作組的要求，並且是可實施的。在CR，規範可能沒有完全實現(那裏可能存在“功能風險”)，瀏覽器之間可能存在互通性問題。
您在這（https://www.w3.org/2020/Process-20200915/）可以看到描述的全部過程細節。
Chad：
你說的最後一個CR，我猜是暗示可以有多個CR，或者說CR過程是一個多階段的事情？
Bernard：
還有一個新的W3C過程，在這個過程中，基本上你有實時的規範。我們只能說，在我們就這兩個問題提出建議之前，我們已經是最後一個了。
所以PR [Proposed Recommendation]是你試圖證明規範中的所有內容都已經實現並且通過了你的互通性標準的階段。然後是推薦，甚至更遠。下一步是PR，我們正在收集你需要的所有數據。在對等連接的情況下，這是大量的數據，因爲您需要所有的互操作測試，包括您的WPT測試結果，還可能包括您的KITE測試結果。
WPT是指Web平臺測試，這是W3C檢查API實現的一組測試。結果位於https://wpt.fyi。
KITE是一個開源的互通性測試項目，專門針對WebRTC。
Alex Gouaillard博士
在他的博客帖子《轉折點：SFU博客負載測試》中討論了這一點。
Chad：
WPT是
wpt.fyi
，這是一種通用的自動化特性測試，而KITE是WebRTC特定的互操作測試。
Bernard：
WPT網絡廣播公司的測試運行在單一的瀏覽器上。我們在WPT沒有針對網絡實時傳輸的服務器測試，但是有針對網絡傳輸的服務器測試。因此，WebRTC WPT測試沒有展示瀏覽器之間或瀏覽器和會議服務器之間的互操作性，而KITE測試是在瀏覽器和潛在的多個實體之間進行的。
Chad：
這是WebRTC特有的——你實際上是在向不同的瀏覽器發送媒體。
Bernard：
爲了理解WPT測試覆蓋率的水平，我們已經對規範進行了註釋。因此，除了測試結果之外，你還想知道測試實際覆蓋了多少規範。
WebRTC對WebRTC產生了一些有趣的影響。這讓我們WebRTC社區的所有人都忙得不可開交，更加關注所有新流量的可擴展性和可靠性。然而，這種焦點的改變會對現有的過程造成很大的破壞。這也適用於標準化工作嗎？
Bernard：
底線是，我們正在努力收集所有這些證據，我們將向W3C提交這些證據，以表明我們已經爲建議階段做好了準備。這是非常大的一步，但進展被病毒拖慢了。我的意思是，我們認爲我們會在實施過程中取得更大的進展，但病毒已經讓每個人都慢了下來。
Chad：
那是因爲人們忙於做支持他們產品的事情，還是因爲實際上你們不能經常聚在一起？
Bernard：
新冠疫情打亂了很多事情。例如，KITE互操作測試通常是在IETF活動中親自進行的，但是我們還沒有能夠親自參加IETF。我們一直在努力弄清楚如何才能完成測試，但如果沒有每個人都在同一個地方，這很難。如果你在世界各地，在同一時間同一地點組織每個人的能力真的很難。想象一下，現在是凌晨3點，你需要和世界另一端不同時區的人進行互操作性測試。
這場全球性的疫情不僅破壞了測試，而且還影響了實施計劃，如融合圖所示。雖然建議中的幾乎所有功能都已經在至少一個瀏覽器中實現，但我們最初認爲，到2020年秋季，我們將在兩個或多個瀏覽器代碼庫中實現更多功能。因此，實施進度和測試都不是我們所期望的。
https://docs.google.com/presentation/d/1WHocMl47fukck4YQ6RuPzfagAj6bW0SjUELzwguC3qs/edit#slide=id.ga427533723_4_218
在過去的幾年裏，幾乎每一個更新的Web瀏覽器都實現了WebRTC。WebRTC正在支持世界上很大一部分的IP語音(VoIP)流量。在這一點上，進入標準化的下一個階段是否重要？
Bernard指出，標準化不僅僅是編寫規範——它實際上是關於互操作性的。
Bernard：
標準化把注意力集中在測試和穩定性上。WebRTC對等連接的最大挑戰之一就是它的廣度。我們每天都只是從重要的bug中學習。我們發現我們的覆蓋面並不是我們理想中的樣子。我們還了解到，即使是我所說的可接受的測試覆蓋率，也是多麼困難。最近出現了一堆像複用這樣的問題，它們實際上對現有的服務有很大的影響，我們沒有對它們進行測試。我們在這些錯誤身上看到的是，它們不是WPT遇到的那種問題。本質上需要像KITE框架這樣的東西來做的事情，我們在KITE中還沒有達到百分之百的測試覆蓋率。
總的來說，我在實時通信和網絡其他方面經歷的最大區別之一是測試矩陣的巨大規模。如果我告訴你Chad，我想讓你去開發，得到95%的覆蓋率。我認爲通過測試的過程是有幫助的，但它也讓我們意識到真正涵蓋一切的挑戰的規模。這很艱難。
你可以用WebRTC做的事情越來越多。正如Bernard剛纔提到的，WebRTC 1.0正在通過標準過程，所以他們必須在某個地方添加新功能。正如Bernard將解釋的那樣，WebRTC擴展是一些沒有進入WebRTC 1.0的功能的家園。
Bernard：
有一系列的規範依賴於
RTCPeerConnection
。WebRTC擴展就是其中之一。這些是爲WebRTC PC增加功能的規範。這裏有很多東西，例如，實時傳輸協議報頭擴展加密。WebRTC SVC（可拓展視頻編碼）不在WebRTC擴展文檔中，但我認爲它是一個擴展。我認爲可插入流是WebRTC PC（其編碼版本）的擴展，它的編碼版本。這些都是在假設你有
RTCPeerConnection
的基礎上。
getCurrentBrowsingContextMedia
隨着視頻會議使用的增加，已經有幾個關於網絡攝像頭出錯和意外屏幕共享的高調故事。與此同時，快速訪問網絡攝像頭通常是WebRTC服務的一個問題。平衡訪問速度和隱私控制是一個難題。此外，使用
getMediaDevices
提供的媒體設備信息進行指紋識別一直是一項隱私挑戰。
getCurrentBrowsingContextMedia
提案是解決這些挑戰的一種嘗試。
Chad：
我們能報道一下
getCurrentBrowsingContextMedia
媒體提案嗎？
Bernard：
這真是一個擴展，我認爲這是對屏幕截圖的擴展。讓我來談談[媒體]的捕獲問題——捕獲的很多焦點都集中在隱私和安全上。我們發現媒體捕捉流對隱私並沒有什麼好處。假設你將爲應用程序提供設備上的所有信息，無論它們是否被選中，然後讓它創建自己的選擇器。這是指紋識別的一個真正問題，因爲現在我知道你機器上的所有設備。即使你不想用那個相機，但我知道它在那裏。因此，這真的有助於識別你的指紋，Jan-Ivar一直建議我們轉向另一種更類似於屏幕截圖的模型。
在屏幕捕捉中，你只能訪問用戶選擇的捕捉表面。所以，我不能訪問你所有的應用程序，我可以看到每個窗口，然後我決定作爲一個應用程序來購買我想看的東西。現在用戶選擇了源，您只能訪問它。這是Jan-Ivar提出的媒體捕捉和流模式。本質上，它將成爲瀏覽器選擇器的一部分。該應用程序只能訪問用戶選擇的設備上的信息。這是一個很大的變化。它也對媒體捕捉和screams的一些基礎提出了質疑。例如，如果用戶無論如何都要選擇，那麼約束的目的是什麼？
Chad：
這是否意味着更多關於設備選擇器的規範？
Bernard：
我認爲它的作用是。然而，我們已經決定將我們的模型進行或多或少改進。然後， Jan-Ivar 爲這個新模型創建了一個單獨的規範，可以解決所有這些問題。棘手的是，這是一個非常不同的模式。當人們習慣於應用選擇器時，如何過渡到新的模式？這可能從用戶習慣來看需要很長時間。
標準之爭的一個後果是不願意指定正式的版本名稱，因爲每個人對什麼是主要版本(即1.0、2.0)和次要版本(即1.1、1.2等)有不同的看法。曾經也有一個被稱爲ORTC的替代推薦，有時被定位爲WebRTC的繼任者，我們將在一個大型的。WebRTC 1.0圍繞我們討論的當前規範進行了整合。儘管如此，關於接下來會發生什麼仍有很多爭論。他們最終決定用一個非常溫和、不精確的術語來命名接下來的一切：“WebRTC下一個版本”或WebRTC-NV。
Chad：
我們談了一點關於我們將在“下一個版本”的WebRTC中看到什麼——我想我們不會稱之爲2.0，因爲1.0還沒有完成？
Bernard：
我想也許是時候我們應該考慮去掉整個NV這個術語了，因爲它實際上可以指兩種潛在的非常不同的東西。一個是我提到的對等連接的擴展——比如可插入流、WebRTC擴展、WebRTC SVC。我的想法是，當你把所有這些規格放在一起時，它們加起來的功能水平和ORTC一樣。因此，我們已經將大部分ORTC對象模型整合到了WebRTC PC中。
另一個非常獨立的軌道是我所說的獨立規格。這包括像網絡傳輸、WebCodecs、網絡實時通信等——這些都是完全獨立的東西，不依賴於
RTCPeerConnection
。所以這真的是下一代與現在的一種決裂。
顯然，還早着呢。WebTransport是一個原始試用版。WebCodecs是Chrome的原始試用版。現在，這是非常不同的，因爲你曾經作爲整體WebRTC PC的一部分獲得的許多東西現在必須用Web Assembly編寫。所以這是一個非常非常不同的開發模型。
有些東西不在那裏。例
如WebTransport現在本質上是客戶端服務器。我們已經編寫了一個對等擴展，不久前有一個最初的試用版，但是現在是客戶端服務器。因此，您不能只使用現有的WebCodecs和網絡傳輸來編寫完
整的WebRTC PC用例。
我要說的是，在WebRTC NV中發生的另一件事已經變得非常重要，那就是人們對機器學習和訪問原始媒體有了真正的關注。這是ORTC沒有提供的。在某種意義上，我想說的是，網絡傳輸或WebCodecs模型在這方面甚至比ORTC還低。ORTC沒有讓
你直接訪問
解碼器和編碼器。這就是你從WebCodecs中得到的。所以我認爲我們採納了ORTC的想法，並將其應用到更低的傳輸層。
對象實時傳輸控制(ORTC)是網絡實時傳輸控制的一個替代模型，它提供了不使用軟件開發平臺的低級控制。Bernard是它的作者之一，微軟在ORTC的支持下推出了最初的Edge。我們再也聽不到很多關於ORTC的事情了，那麼它發生了什麼？正如Bernard剛纔解釋的那樣，大部分內容都被吸收到了WebRTC的核心標準中。這是ORTC願景的失敗還是勝利？
Chad：
你是ORTC原始規範的作者之一。與您最初的ORTC願景相比，您認爲我們現在的狀況如何？
Bernard：
對象模型完全在Chromium瀏覽器中。因此，我們幾乎擁有了來自ORTC的所有對象——Ice Transport、DTLS Transport傳輸、SCTP Transport (來自數據通道)——所有這些對象現在都在WebRTC PC和Chromium瀏覽器中。
RTC也有先進的功能，如聯播和SVC，我們已經納入。此外，我們有比原始的ORTC通過端到端加密，可以通過可插入的流支持。因此，我們已經用對象模型和所有這些擴展將WebRTC PC等同於ORTC。
我們期待的場景是像物聯網這樣只關注數據傳輸的東西。您可以看到這反映在WebRTC和用例中——這些場景就像對等數據交換一樣。
WebTransport是W3C的另一個規範，有自己的工作組和規範。你會看到很多熟悉的涉及WebRTC 的名字，包括Bernard。
QUIC是一種改進的傳輸協議——有點像網絡傳輸可以使用的“TCP/2”。
Chad：那麼什麼是WebTransport，它是從哪裏來的，和WebRTC有什麼關係呢？
Bernard：
網絡傳輸既是一個API，又是W3C網絡傳輸組的成員。它也是IETF中的一系列協議——一系列傳輸。協議包括QUIC上的網絡傳輸，稱爲QUIC傳輸，也包括HTTP/3和潛在的HTTP/2上的網絡傳輸。所以W3C中的網絡傳輸API只適用於QUIC和HTTP/3。HTTP/2被認爲是一種故障轉移傳輸，它可能有一個單獨的API。那個API是客戶端服務器API。構造函數和一切都很像WebSocket。在構造函數網絡傳輸構造函數中，你給它一個網址，然後你會得到一個網絡傳輸。但是它是不同的，因爲您可以創建可靠的流和數據報。
Chad：數據包，就像UDP中用於快速但不可靠的傳輸一樣。
Bernard：
它是雙向的，也就是說，一旦網絡傳輸由客戶端發起，但是一旦連接建立，服務器可以向客戶端發起單向雙向流，數據報可以來回流動。
Bernard：WebSocket
實際上只是客戶端。WebSocket不能由服務器啓動，但網絡傳輸可以。在基於QUIC的網絡傳輸中，連接不是共享的。在針對HTTP/3的網絡傳輸中，它可以被彙集在一起——這創造了一系列非常有趣的場景，其中一些場景恢復了IETF BoF。考慮一下，你可以同時進行HTTP/3請求-響應和網絡傳輸，包括流，以及在同一個QIUC連接上的數據報。
這是Justin Uberti爲IETF的一個名爲RIPT BOF的項目設計的一個場景，讓人們大喫一驚。在這種情況下，你有一個來回的RPC-請求-響應，但RPC-導致從服務器到客戶端的流。所以把它想象成一個客戶說，我想播放這部電影，或者玩
這個遊戲，再或者參加這個視頻會議，然後一個可能是可靠的QUIC流的流，或者可能是一個來自服務器的數據報流。
我認爲WebTransport有潛力給網絡帶來革命性的變化。HTTP/3本身就是對Web的革命性改變。這場革命的大部分是在更復雜的版本中，即HTTP/3池傳輸。QUIC傳輸要簡單得多，它只給了我一個socket，我可以在上面來回發送東西。
Bernard：
我想說WebTransport API現在已經相當完善了，它剛剛完成它的原始測試，試用版本以M88結束。有幾個bug，有些東西不太好用，但是API比較打磨。您可以用它編寫一個相當複雜的示例代碼。我想這是因爲我們用實際代碼更新了規範。所以如果你讀了這個規範，你就可以用代碼來做這些事情了。希望我們很快會在那裏提供一個完整的例子，你可以嘗試一下。
在服務器端，仍然有一些QUIC互操作問題。所以我認爲人們使用的服務器是
aioquic（Python庫）
，你也可以使用quiche作爲服務器，但是它沒有集成到框架中。不幸的是，我們沒有Node.JS服務器，擁有它真的很好——那可能很遙遠。
Chad：正如Bernard所說，WebTransport是客戶端服務器，而不是像WebRTC那樣的對等(P2P)。然而，我們已經看到了P2P QUIC的預覽版。事實上，
Fippo
早在2019年2月就在QUIC數據頻道上寫了一篇文章。與這種新的網絡傳輸方法相比有何不同？
Bernard：
那是ORTC風格的。它不支持WHATWG/W3C流，也是基於gQUIC協議，而不是IETF的QUIC。WebTransport——代碼在Chrome中——基於WHATWG流，也基於IETF QUIC。所以
RTCQuicTransport
代碼非常過時，因爲它既是一箇舊的API，也是一箇舊的協議。那個代碼已經從Chromium中刪除了。
Chad：那麼，對於低延遲的場景，我們如何實現Peer-to-Peer WebTransport呢？
Bernard：
我們有一個小的擴展規範，它仍然在ORTC CG中。基本上認爲它只是一個WebTransport，但是你讓它運行在
RTCIceTransport
上，而不是一個URL上。所以要做構建，你不給它一個URL，而是給它一個ICE Transport。
你就是這麼構造的。有一些ORTC的東西基本上是從
RTCDtlsTransport
中提取的，你可以添加到對等的東西中。但是擴展規範只有幾頁。它非常非常小，就像95%的網絡傳輸規範完全一樣。
Bernard：
我們還沒有新的應用編程接口和新的QUIC庫的工作版本。沒有新東西的版本。
RTCQuicTransport
的一個特點是它是獨立的。今天Chromium中有一個代碼，叫做WebRTC ICE。想象一下從網絡實時傳輸中心到PC的洲際交易所傳輸——這是一個獨立的實時傳輸中心版本。當您從一個
RTCQuicTransport
構造一個
RTCQuicTransport
時，它不會與您的對等連接組件複用。
它在一個單獨的端口上。現在我們不得不在過去的
RTCQuicTransport
中這樣做，因爲gQUIC不能與RTP/RTCP STUN和TURN複用。IETF QUIC可以複用。
Chad：
gQUIC是來自谷歌的QUIC的原版。這聽起來可能會對IP端口的使用產生很大影響，捆綁有助於
通過防火牆
限制端口使用
。
Bernard：
開發人員會希望在同一個端口上使用QUIC作爲他們所有其他的音頻和視頻工具嗎？如今在WebRTC PC中，捆綁銷售非常非常流行。每個人都在同一個端口上把所有東西推在一起——這遠遠超過了WebRTC所有使用的99%。有人可能會認爲QUIC會有類似的需求。如果這是他們真正想要的，我們不想用ORTC風格化的交通工具來建造(快速傳輸)；你希望能夠從一個網絡傳輸中心的PC上構建它。
這有點奇怪，因爲現在你說部分網絡傳輸依賴於
RTCPeerConnection
。
RPC設置以通過WebTransport發送媒體。來源：IETF 107 – Justin Uberti，107-ript-rtc-implementation-experiences
（
https://www.ietf.org/proceedings/107/slides/slides-107-ript-rtc-implementation-experiences-00
）
WebTransport似乎是一種全新的潛在處理方式。但如今困擾WebRTC實現的一些棘手問題主要是，幾乎每一個主要的WebRTC視頻會議服務中都有Simulcast，參與者衆多，並且在標準化和互操作性方面一直處於掙扎狀態。
Bernard：
據稱，在Chromium中，所有編解碼器都支持with simulcast，或者至少是現在所有的編解碼器。因此，從理論上講，你應該能夠使用H.264，VP8和VP9做到這一點。
我們一直在尋找錯誤，也遇到過一些非常可怕的錯誤，例如H264無法正常工作。我們已經進行了完整的KITE測試，但是還需要一個簡單的回送測試測試基本操作，你可以在其中向自己發送Simulcast。最終Fippo編寫了回送測試。
如果你想查看該測試，在Fippo的“simulcast playground”（https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/）帖子中。
Bernard：
該測試並未在所有瀏覽器上通過。它之所以沒有通過，是因爲你發送了RID，被SDP欺騙了，並以MID的形式接收了它們。因此，從本質上講，如果你發送了三個流，則可以取回三個流，但是它們各自位於不同的MID上。
Firefox不支持MID RTP標頭擴展。所以，實際上該環回測試無效。
我們發現無論何時編寫測試，都會發現一些不太清楚的地方。
我再給你舉一個奇怪的例子，我們一直在進行硬件加速方面的工作。事實證明，當你使用硬件加速器時，可以獲得不同的比特流。它不僅使事情變得更快，實際上是改變了編解碼器的比特流，然後你就可以開始破壞互操作了。你進行了Simulcast測試，突然SFU無法處理即將發生的一切。我真的希望我們能夠在這些IETF會議之一中親自見面，進行另一次Simulcast測試，就像Alex博士能夠做的那樣，看看我們在哪裏。
Chad：統一計劃是一種新的、標準化的SDP格式，除其他外，它指定了應如何在SDP中處理聯播流。統一計劃不應該成爲節省一天的規範嗎？而我們爲什麼沒有這麼做？
Bernard：
如果每個人都對所有編解碼器都使用統一計劃，並且[互操作測試]都很高興，那麼你會知道一切正常。我們還不在附近。讓我這樣說–我們功能完善。我認爲這是事實，但是事情在測試範圍內不斷下滑。我不會說每個瀏覽器都具有發佈商業應用程序所需的所有功能。舉例來說，例如，我認爲確實有很多商業應用程序都在多個瀏覽器上發佈，但我認爲在所有瀏覽器上都發布的應用很少。
因此，考慮到這種情況的一種方法（可能比所有這些測試結果要容易一些）是，如果你對所有主要會議服務及其運行的所有瀏覽器以及所有不同的模式進行了矩陣分析，則可能會發現最好看看我們實際上在哪裏。
一直以來這都不是很令人鼓舞。多數服務都支持大多數瀏覽器是很好的，但是你經常會看到各種功能支持以及跨瀏覽器的稍微不同的體驗。
由於原文篇幅較長，爲保證讀者的閱讀體驗，本文後半部分內容將安排在下週發佈。
LiveVideoStackCon 2021 ShangHai
LiveVideoStackCon 2021 上海站
本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
