WebRTC開源專案現狀
作者:Tsahi Levent-Levi、Philipp Hancke
翻譯、編輯:Alex
技術審校:李忠
影音探索 #018#
WebRTC的開源環境混亂不堪。它需要成熟起來併成為重要的業務,或者獲得重要的支援。
本篇文章由我和Philipp Hancke[1]共同創作。我們一起合作了很多事,包括WebRTC課程[2](新課馬上要來了)和WebRTC洞察[3]等等。
WebRTC是免費的。今天,每個現代瀏覽器都包含了WebRTC。在這些瀏覽器中執行的基礎程式碼不僅開源且使用寬鬆的BSD許可證。在某種程度上,免費和開源被融合在一個不那麼愉快的組合中,而開發者以為WebRTC中的一切都應該免費。
結果呢?在WebRTC推出11年之後,我們發現它的處境悲慘。在今天這篇文章中,我們會詳述WebRTC開源生態的現狀,以及我們為什麼需要做出必要的改變以確保WebRTC在未來幾年能夠健康發展。
你的開源輔導筆記
我們將從你所需要了解的最重要的事情開始:
開源 !=免費
在深入研究之前,先讓我們快速瞭解一下開源。
到底什麼是開源?
開源專案是指在開源許可協議的規定下,一段被大眾公開使用的原始碼。來自同一家公司或者不同公司的某個人或者某個團隊“聯合起來”開發了一個發揮某種作用的軟體。他們將該軟體的原始碼公開,並貼上許可證,這就成了一個開源專案。
開源並不等於免費。開源同樣要在法律約束下進行,但這並不是本文的重點。實際上,使用開源並不是說你無需向任何人支付任何費用,它意味著不需要任何附加條件,你就可以獲得程式碼。
為什麼大家最終都願意為開源專案無償貢獻程式碼?這就要從開源專案的商業模式說起。
開源商業模式
目前存在多種形式的開源許可證[4]。每種開源許可證都有自身的規則,其中一些相對更寬鬆,對商業更加友好。有時許可證型別本身也會被用作商業模式,它通過雙重許可模式實現:一個免費但有限制條款的開源許可協議,同時提供一個商業許可協議。
在其他情況中,開源專案的商業模式圍繞提供專案支援、維護和定製專案。你可以免費獲得程式碼,但如果你需要幫助,你可以通過付費獲得支援。
有時,商業模式還圍繞著附加元件(比如,社群版和企業版在專案網頁作為選項彈出)。用於擴充套件系統的指令碼、監測模組或者其他操作和模組元件等作為商業產品受到保護。專案的開源部分使各家公司能夠使用它,並提升了專案的知名度,而商業部分是開放開源部分的原因。開發者以此為生甚至發家致富。
近些年,我們看到一些圍繞著託管服務的商業模式,其中的程式碼庫開源且免費,但如果你讓這些公司幫你託管並支付費用,那麼他們將為你解決所有維護和擴充套件問題。
有些人認為開源是真正免費的。Troy Hunt最近寫了一篇很棒的文章,你可以在這裡閱讀:http://www.troyhunt.com/if-youre-not-paying-for-the-product-you-are-possibly-just-consuming-goodwill-for-free/
“有一個建議是:我們這些開發軟體和服務的人必須以某種方式獲得收入。”
對此我想說的是:沒錯!
歸根結底,研究開源終為利。
為什麼這麼說?
-
如果你建立了一個廣受歡迎的開源專案,那麼你總是想搞清楚如何通過它獲得收入。通過開源專案,你能直接(參見上文例子)或間接地增加獲得高薪工作或者加入更加有趣專案的機會。
-
有時,研究開源是因為你對某一項技術十分感興趣。但最終結果是一樣的:或許你有時間搞開源,是因為你在其他公司可以獲得收入,只是把開源當作興趣;或許你任職的公司很高興你去研究開源(意味著你所做的事情能夠給公司帶來內在價值)。
-
也許你搞開源是為了磨練技術。但話說回來,你這麼做的原因還是為了成為一名更優秀的程式設計師……並最終被公司聘用。
如果你正在開發的專案對另外兩個人或者一家公司有意義,那麼就能獲得金錢上的收益。我們敢說,如果你沒有從這些收益中獲得任何好處(即使很少),那麼開源專案就沒有真正的未來,它也到了生死關頭。
多說幾句開源專案
在開始WebRTC開源王國之旅之前,讓我們先來了解一些事:
-
大部分開源專案只是一個將你的應用開發所需的某種效能抽象出來的API。在WebRTC中,我們會關注實現特定網路實體的此類抽象。我們稍後會詳細介紹。
-
當使用開源時,你通常對應用程式擁有更多控制權。這是因為你可以修改開源元件的原始碼,而不是在使用預編譯的庫時向廠商尋求幫助。
-
很多開源專案的文件都很糟糕。當它們缺乏可靠的商業模式時,更印證了這一事實:開發愛好者更喜歡寫程式碼,而不是解釋如何使用這些程式碼。
-
文件是開源專案商用很重要的一個方面。提供使其更易使用的清晰API外觀和示例程式碼的能力也很重要。
WebRTC開源一覽
新手的一個常見錯誤是:WebRTC是一種不需要編碼的解決方案。既然瀏覽器已經實現了它,就沒有其他事要做了。這與真相相去甚遠。WebRTC協議需要一組移動元件、客戶端和伺服器;它們一起實現了我們所看到的這一豐富的通訊解決方案。
上圖(來自高階WebRTC架構課程[5])顯示了典型WebRTC應用中的各種必需元件。
-
客戶端: 基於Web或者其他
-
Web瀏覽器客戶端作為瀏覽器的一部分“免費”獲得
-
其他則需要你自己探索
-
應用伺服器: 本文我們並不會介紹應用伺服器,因為任何型別的應用都具備這一通用元件,並非WebRTC專屬。
-
信令伺服器: 負責設定和協商WebRTC會話。
-
STUN/TURN 伺服器: 處理NAT穿越。幾乎所有部署都需要它。
-
媒體伺服器: 用於媒體處理任務繁重的工作。無論是群組通話、錄製,還是視訊渲染等,你都可以使用媒體伺服器。
對於每個元件,你都可以找到一個或者多個開源專案來實現它。其中一些更好用,但許多開源專案已被遺忘並逐漸棄用,而只有少數設計精妙,令人讚不絕口。
讓我們深入瞭解這些元件,並看看其中可使用的元件以及其所對應的開源社群正處於什麼樣的狀態。
WebRTC開源客戶端庫
首先是WebRTC開源客戶端庫,它們是WebRTC協議在使用者/裝置/客戶端層面的實現,可以將其視為WebRTC的底層API。
WebRTC曾經只有一個庫:libwebrtc。但漸漸地,更多的庫被推出並在生態中佔據了一席之地。
我們先從libwebrtc開始。
• libwebrtc
WebRTC中最主要的開源專案就是libwebrtc。為什麼?
-
它是第一個推出的開源專案。
-
Chrome將它用於其WebRTC實現。
-
Safari、Edge和Firefox也是如此:它們不同程度地整合和使用了libwebrtc。
-
許多native移動應用內部使用libwebrtc。
實際上,libwebrtc在WebRTC中無處不在。
這裡有幾個你需要知道的關於libwebrtc的知識點。
-
libwebrtc由谷歌唯一控制和維護。每個更改都需要谷歌同意。
-
Chromium和Chrome都相容了libwebrtc,意味著它可以觸達幾十億部裝置。
-
谷歌非常保護libwebrtc,所以向libwebrtc貢獻程式碼並非易事。
-
雖然一直有人向libwebrtc貢獻程式碼,但外部貢獻者少之又少。
-
記住,谷歌團隊之所以維護libwebrtc並不是出於公益目的,他們也是為了滿足自身需求,尤其體現在這些年的Google Meet。Google Meet的用例、使用場景、API和程式碼流程都很可能比libwebrtc的程式碼庫更安全、更穩定並做了深度優化。
-
值得一提的是,libwebrtc的全部構建系統是為了將其編譯進Chromium而非其他專案(比如你正在構建的那一個)。想了解更多,請觀看Philipp的Fosdem talk[6]。
-
它的一些介面(比如裝置獲取)測試比較少是因為Chrome覆蓋了這些介面,所以谷歌的重點是Chrome介面,而不是libwebrtc中實現的介面。
在過去的程式碼貢獻中,谷歌佔據了其中的90%。
可以看到,在2016年初達到頂峰之後,程式碼修改量之後逐年減少。在疫情期間,甚至降到了低於平均每月200個commit的低點。但即使程式碼量不斷減少,libwebrtc依然是WebRTC生態中最大以及最頻繁更新的專案。
libwebrtc的外部程式碼貢獻量相當低,不到總貢獻的10%, 對於WebRTC這一行業標準庫來說並不是一個好兆頭。如果谷歌可以開啟大門,放入一些改進WebRTC或使WebRTC更易使用的貢獻程式碼,那麼情況將會改善。
接下來我們將瞭解:libwebrtc的商業模式。
談錢時刻
如果有人決定使用libwebrtc並將它直接整合到自己的應用上怎麼辦?
-
沒有付費支援選項。
-
沒有真正的替代方案為定製化開發付費。
-
維護自己的fork分支,然後和開源upstream 版本保持同步是一件成本非常高的事情。
-
因此在大部分情況中,libwebrtc是最佳選擇。這是因為它準確支援你在Web瀏覽器中所遇到的各類實現,是最新的開源專案。
-
值得一提的是,libwebrtc是用C++實現的。有什麼關係嗎?我們接下來要介紹的Pion會解釋這一切。
• Pion
Pion[7]是WebRTC API的Go實現。Sean DuBois[8]是Pion專案背後的核心人物,他對Pion的熱情頗有感染力。
Tsahi認為,用Go來寫Pion是它成功的主要原因。這只是因為相對於C++,很多開發者更願意使用Go(現代、新穎且時髦)。不論什麼原因,Pion從一開始就發展良好,現在已經成為一個流行的WebRTC開源專案。它常用於嵌入式裝置、基於雲的視訊渲染和最近的SFU以及其他媒體伺服器實現。
談錢時刻
如果有人決定使用Pion並將它直接整合到自己的應用怎麼辦?
-
沒有付費支援選項。
-
沒有官方替代方案為定製化開發付費。
-
Pion有很多程式碼貢獻者,他們把這種貢獻當作正式工作。
• Python、Rust等
WebRTC還有其他語言的實現,其中比較有名的包括:
-
aiortc[9]:WebRTC的Python實現。
-
WebRTC.rs[10]:WebRTC的Rust實現,作為Pion的重寫(rewrite)被開發出來。
也許還有其他實現,但沒有那麼有名。
這裡我們就不介紹談錢時刻了。這些專案的規模太小,我們還沒有看到有很多服務在生產中大規模使用它們。
• GStreamer
GStreamer[11]是一個比WebRTC還老的開源媒體框架。它應用於使用WebRTC的應用和服務中,甚至沒有使用它的WebRTC能力(主要因為這些能力後面已經新增到了GStreamer中)。
我們看到,當廠商們需要進行實時的視訊內容轉碼時,就會使用GStreamer。比如:
-
獲取機器渲染(3D、投屏等)並將它們通過WebRTC傳遞給瀏覽器。
-
混合輸入資料,將它們合併為單個錄製檔案或者單個直播流。
-
在嵌入式平臺上收集媒體輸入資料,並將它們準備用於WebRTC會話。
由於WebRTC是GStreamer中所新增的另一個輸出型別,開發者可以直接將它作為廣播實體(broadcasting entity)使用,這是一個不消耗資料只生成資料的實體。
GStreamer是社群努力的成果,並使用C編寫。雖然許多應用都使用GStreamer,但它卻缺乏強健的商業模式。這意味著什麼?
談錢時刻
如果有人決定使用GStreamer並將它直接整合到自己的應用怎麼辦?
-
具備付費支援官方選項(by Centricular)。
-
你也可以直接向Centricular支付定製化的開發費用。
-
整個生態環境的規模已經足夠大,你可以很容易找到具備GStreamer知識的人。
開源TURN伺服器
使用TURN連線WebRTC來轉發訊息
接下來是TURN伺服器。這裡就變得“簡單”了,因為我們主要討論的是coturn[12]。雖然還有其他幾個選擇,但是coturn是目前最流行的TURN伺服器(開源或者其他)。
在很多方面,我們只需coturn即可,因為TURN很簡單,並可用於程式碼實現(Cloudflare正在或曾經想要通過他們的管理服務改變這一點[13])。
但是,凡事都有一個但是:coturn也需要不斷更新和改進。這是最近在coturn的github repo上釋出的一個問題[14]:這個專案死了嗎?
可以在註釋中的連結裡閱讀相關資訊,其中的回答很有趣。
coturn的維護者已經精疲力竭,又或者只是沒有時間來維護它(他們都有自己的日常工作)。對於這樣一個廣受歡迎的開源專案,最終結果就是一兩個志願者邊忙碌於自己的日常工作,邊貢獻程式碼。
接下來又到了:
談錢時刻
如果有人決定使用coturn並將它直接整合到自己的應用中怎麼辦?
-
沒有官方付費支援選項。
-
沒有官方替代方案支付定製化的開發費用。
-
整個生態環境的規模已經足夠大,你可以很容易找到具備coturn知識的人。
WebRTC的開源信令伺服器
信令伺服器是一個很不同的開源專案。WebRTC沒有準確定義它們,但是需要它們在參與者之間傳遞SDP資訊和其他訊號。對於WebRTC的開源信令解決方案,這裡有幾種替代方案。
值得注意的是,WebRTC中許多信令伺服器替代方案僅提供對等通訊效能,而無法與媒體伺服器互動。有些信令伺服器也將處理音訊和視訊流。它們對媒體或信令的注重程度決定了我們是將它們視為媒體伺服器還是信令伺服器。這一切都取決於它們的關注點以及最終所提供的功能。
信令需要兩個元件,分別是信令伺服器和客戶端庫(通常是輕量級的,但並不總是這樣)。
我們將從標準庫SIP和XMPP開始。
• SIP和XMPP
SIP和XMPP比WebRTC早出現了10年左右,擁有自己的開源專案生態、廠商和開發者。它們可用作成熟且可擴充套件的伺服器,有時通過擴充套件支援特定WebRTC應用場景,如為TURN建立驗證token[15]。
我們不會花時間一一解釋這些替代方案。
這裡值得一提的是MQTT。眾所周知,Facebook曾在Facebook Messenger中使用它傳送訊號(至少過去曾使用過,目前不確定是否還在使用)。
• PeerJS
PeerJS[16]的存在時間幾乎和WebRTC一樣長。在相當長的一段時間裡,其程式碼庫一直沒有得到維護或更新以適應所支援的瀏覽器。這種狀態似乎延續到了今天。
這個專案似乎專注於龐雜的單伺服器開發,而沒有考慮水平的分散式擴充套件。但對於大部分人來說,應該足夠了。
多年以來,PeerJS幾經易手並更換維護者,今年年初還在招募維護者[17]。
事不宜遲,讓我們開始談錢時刻吧!
談錢時刻
如果有人決定使用PeerJS並將它直接整合到自己的應用怎麼辦?
-
沒有官方付費支援選項。
-
沒有官方替代方案支付定製化的開發費用。
-
程式碼庫規模很小,所以如果你瞭解WebRTC,那麼這些挑戰就不是什麼大問題。
• simple-peer
Simple-Peer早期由Feross推動,它是另一個僅專注於P2P的“純WebRTC”庫。如果Simple-Peer適用於你的應用場景,非常好,它目前已經成熟並完善。大部分情況下,你的應用場景會隨著時間不斷髮展。
2022年,它只收到了少量維護commit[18],2021年收到的commit也不多。在使用PeerJS時需要注意的問題同樣適用於Simple-Peer。如果你要在二者之中選擇一個,選擇Simple-Peer吧,因為它的程式碼是更地道的JavaScript。
談錢時刻
可以閱讀PeerJS的談錢時刻,因為它們所遵循的規則是一樣的。
• Matrix
Matrix[19]是一個“用於安全、去中心化通訊的開放網路”。它具有開放標準,同時背後也有商業廠商支援(Element[20])
新穎時髦的Matrix試圖彌補SIP和XMPP的缺陷,但是它最主要的設計為客戶端和服務端的架構,且它的實現類似於把網路和UI包含在內的Slack。Matrix具有分散的架構和實現,從而更易擴充套件。
這裡產生了一些分歧。Tsahi認為Matrix是一個很棒的選擇,而Philipp卻沒那麼激動。Matrix從full mesh遷移到Jitsi[21],最近又遷移到原生SFU[22]。所以對於有些人來說,它的WebRTC歷程有些曲折。
Matrix背後有一家公司支援,但這家公司有自己的傾向(與Slack競爭的私心)。
談錢時刻
如果有人決定使用Matrix並將它直接整合到自己的應用怎麼辦?
-
沒有官方付費支援選項。
-
沒有官方替代方案支付定製化的開發費用。
-
儘管如此,Matrix上有一個Jobs Room[23],你可以在上面搜尋付費幫助。
• GitHub“叢林”中的其他專案
在創作這篇文章的時候,有26121個repository提到了WebRTC[24]。你在閱讀這篇文章時,這一數目還在增加。
在這些混亂的repository中,特別突出的並不是很多,所以很難弄清哪些專案更適合你,尤其當你的需求會持續下去的時候。如果你正在尋找獲得足夠支援並具備繁榮社群的專案,那更是難上加難。
WebRTC的SFU和媒體伺服器
媒體伺服器和SFU[25]是另一組重要的開源WebRTC專案。
信令伺服器處理設定實際會話的對等通訊,而媒體伺服器聚焦在通道——我們想要傳送的實際資料——音訊和視訊流,提供實時視訊流和處理。每當你需要群組會話、廣播或錄製(假設你希望在應用程式中加入視訊通話或視訊會議)時,你最後都會使用媒體伺服器。
下面是商業方面:
• Janus、Jitsi、mediasoup和Pion
我曾在《2022 WebRTC發展趨勢分析》中詳細介紹過這些專案,相關內容可以參見下圖。
Janus、Jitsi、mediasoup和Pion在商業解決方案中非常有用且流行。讓我們使用分析其他WebRTC開源專案的方法來分析它們。
• Janus
-
來自meetecho的官方付費支援。
-
你可以向meetecho支付諮詢和(付費)開發費用。從經驗來看,他們大部分人都很忙,這也意味著他們對最終合作的人選非常挑剔。
-
Janus生態規模足夠大,並且還有其他人為其提供開發服務。
• Jitsi
可以將Jitsi看作其自己的平臺:
-
Jitsi 的核心是Jitsi Videobridge,與周圍的其他元件共同組成了Jitsi Meet視訊聊天應用程式。
-
它還包括一個託管的CPaaS服務產品:8×8 JaaS[26]。
談錢時刻
-
幾年以前8×8收購了Jitsi,這也說明它沒有官方付費選項。
-
同樣,也無法進行付費的定製化開發。
-
Jitsi生態規模足夠大,並且還有其他人為其提供開發服務。
-
和Matrix(Element 提供付費託管)一樣,8×8 JaaS 為Jitsi(CPaaS)提供付費託管。還有Jitsi Meet,它本質上是建立在Jitsi之上的免費託管服務。
• mediasoup
-
mediasoup由在Around[27]工作的兩名開發人員維護,這也說明它沒有付費支援官方選項。
-
同樣,也無法使用定製化開發。
-
mediasoup的生態意味著你也可以找到它的開發人群。
• Pion
-
我們在上文介紹WebRTC客戶端時已經討論了Pion。
-
假設媒體伺服器也是如此。
-
你唯一頭疼的是選擇使用哪個基於Pion編寫的媒體伺服器。
需要明確的是,在上述的所有情況中,如果讓廠商幫助你解決那些無人維護的特定媒體伺服器程式碼庫問題,那就意味著實現質量方面的結果將非常不確定。也就是說,你很難搞清楚是在和誰合作。
• Kurento的失敗
Kurento媒體伺服器已經死了,連它背後的那群開發者都去開發OpenVidu(下文會介紹)了,並讓OpenVidu在mediasoup之上執行。
千萬別碰它。
Kurento已經沉寂多年,但有人依然想使用它。先去搞清楚它的狀況吧。
• 抽象概念的更高層次
更高層的概念開源專案努力成為某種平臺。在 WebRTC 生態系統中,它們最關注的是在開源媒體伺服器之上提供一層工具。OpenVidu和LiveKit很可能是其中最值得關注的兩個專案。
• OpenVidu
OpenVidu[28]是一種包括UI、實現了房間服務的抽象層。
Kurento被收購後,團隊剩下的人建立了OpenVidu。他們甚至逐漸採用mediasoup作為使用的媒體伺服器[29],而將Kurento置於一邊。
談錢時刻
和我們之前所看到的很多開源解決方案都不同,OpenVidu看似有其自己的商業模式:
-
具備官方商業支援。
-
提供託管商業計劃以及諮詢和開發工作。
• LiveKit
LiveKit[30]提供“開源WebRTC基礎設施”,即Pion SFU之上的管理層。
我一直不太理解LiveKit的商業模式。他們並不只是一個開源專案,還是一家公司。因此,他們需要收入維持下去。
也許他們從採用LiveKit的企業那裡獲取支援和開發收入,但很難從他們的網站看出來。
其他一些不太流行的WebRTC開源選擇
其他公司也提供商業解決方案(本質上為專用),有些人將它們作為本地替代方案:這些公司提供軟體和支援,但你需要部署和維護。
這種解決方案,或者非常合適,或者會帶來災難,尤其是當這樣的廠商決定轉移或者離開市場時。所以遇到這類解決方案一定要謹慎。
WebRTC開源是時候發展起來了嗎?
本文是一篇很長的WebRTC開源現狀概覽文章,我想我們可以達成一致的是:WebRTC開源目前的狀況不太妙。
-
WebRTC已經存在超過10年。
-
WebRTC開源專案不斷髮展。
-
技術愛好者和專業技術人員都在使用這些專案。
-
這些開源專案存在於為數百萬使用者的商業應用中。
-
但它們卻很少提供付費幫助支援。
-
不知何故,其市場並沒有在商業方面獲得發展。
我們認為WebRTC開源並沒有真正成長起來。我們希望看到更加成熟的市場,這樣才能為企業和企業家提供更多更好的商業解決方案。
參考文獻:
[1] http://twitter.com/hcornflower
[3] http://bloggeek.me/webrtc-insights/
[4] http://bloggeek.me/using-open-source-license/
[5] http://webrtccourse.com/developers/
[6] http://archive.fosdem.org/2021/schedule/event/webrtc_shipping/
[7] http://pion.ly/
[8] http://www.linkedin.com/in/sean-dubois/
[9] http://github.com/aiortc/aiortc
[10] http://github.com/webrtc-rs/webrtc
[11] http://gstreamer.freedesktop.org/
[12] http://github.com/coturn/coturn
[13] http://bloggeek.me/managed-webrtc-turn-speed/
[14] http://github.com/coturn/coturn/issues/915
[15] http://xmpp.org/extensions/xep-0215.html
[16] http://peerjs.com/
[17] http://github.com/peers/peerjs/issues/938
[18] http://github.com/feross/simple-peer/commits/master
[19] http://matrix.org/
[20] http://element.io/
[21] http://www.youtube.com/watch?v=tVh0vYnBM4k
[22] http://matrix.org/blog/2022/08/05/this-week-in-matrix-2022-08-05
[23] http://matrix.org/docs/guides/matrix-jobs-room
[24] http://github.com/search?q=webrtc
[25] http://bloggeek.me/webrtcglossary/sfu/
[26] http://jaas.8x8.vc/
[28] http://openvidu.io/
[30] http://livekit.io/
作者簡介:
Tsahi Levent-Levi:WebRTC專家,曾為testRTC的聯合創始人和CEO,現為Spearline公司testRTC的產品負責人。Tsahi擁有多年WebRTC技術培訓經驗,並擁有自己的技術部落格BlogGeek.Me,你可以到這裡(http://webrtccourse.com/)瞭解和學習他的課程。
致謝:
本文已獲得作者Tsahi Levent-Levi授權翻譯和釋出,特此感謝。
原文連結:
http://bloggeek.me/state-of-webrtc-open-source-projects/
- 揭祕HTTP/3優先順序
- 如何使用FFmpeg將AVI轉換為MP4(有損轉換和無損轉換)
- WebRTC開源專案現狀
- 端雲協同創新優化音視訊場景使用者體驗
- 2022容器格式全面指南
- 對話Robin Marx:HTTP/3和QUIC將帶來重大機遇和挑戰
- QUIC會成為網際網路傳輸的顛覆者嗎?
- RealNetworks vs. 微軟:早期流媒體行業之爭
- AVOD、SVOD、TVOD、PVOD:揭祕視訊點播商業模式
- 使用FFmpeg進行HLS打包——FFmpeg簡單學
- 關於GiF動圖你不知道的9件事
- 眾說元宇宙及其實現
- 公網傳輸技術之SRT協議解析(上)
- FFmpeg 5.0 正式釋出
- 對話Justin Uberti:RTC的過去、現在和未來
- 探討視訊雲與邊緣雲平臺的競爭力 ——基於Serverless的端邊雲一體化媒體網路
- 智慧視訊內容生產中專業視訊資料匯出工具的研發
- 追求極致,揭祕抖音背後的RTC技術
- 【專場福利Part2】從多維度出發 保障&提升實時音視訊質量
- 【聲入人心:音訊新體驗】