ClubHouse 上線支援Replay功能;WebOBS直播推流工具要流行起來了 |WebRTC風向標

語言: CN / TW / HK

ClubHouse 上線支援Replay功能

作為最火的音訊直播產品ClobHouse依舊保持比較快的迭代能力, 最近支援 Replay能力, 說的通俗一點就是支援直播的回放能力。ClobHouse在回放的能力之上又做了一些創新,可以讓房間建立者在直播結束之後看到誰在聽一個房間的回放,還可以讓他們與其他沒有實時收聽的使用者聯絡。回放能力雖然已經被應用的很多,但我比較好奇的是如果支援了回放能力就跟以前的部落格有什麼區別呢?這個問題可以延伸到直播和短影片的對比上,直播的創作成本很低,短影片的創作成本較高,但單位時間內資訊密度明顯直播小於短影片很多,目前短影片的消耗時長也明顯高於直播。

ClubHouse的音訊直播的空間有多大呢?我簡單的搜尋了一下Clubhouse的Google Trends,最近半年搜尋量是逐漸下降的,祝ClubHouse好運。

相關閱讀:

https://blog.clubhouse.com/clubhouse-replays-room-recording/

WebOBS直播推流工具要流行起來了?

OBS一直是企業直播/個人直播的主流的直播推流工具, StreamLab這家基於OBS開發直播工具的廠商也在19年被羅技以8900萬美元的現金收購。隨著Web端能力越來越強大, 比如WebGPU, WebCodecs,WebTransport,WebAssembly,這些技術的出現讓在Web端進行復雜的音影片處理,合流,美顏,人像分割等等成為了可能。

相關產品:

StreamYard : https://streamyard.com/ Melon : https://melonapp.com/ Welder : https://www.getwelder.com/streaming-software

騰訊雲 Penguins AI-Codec 超低位元速率高清語音編解碼解密

騰訊會議釋出的Penguins 音訊編解碼器,也與研發人員交流了行業情況。目前微軟的Satin 音訊編碼號稱在Teams中1v1通過場景中落地,Google 的SoundStream 還沒有看到具體的落地訊息。

很開心的是看到騰訊在這個方向其實走在了前列。

摘抄文中的一段話非常認可:

5G乃至未來更強的通訊技術發展會帶來更豐富的頻寬資源,但人們對實時音影片體驗的追求也是無止境的。我們不僅需要聽得清,還需要聽得真。對於實時的全頻帶音訊傳輸、空間音訊技術乃至聲場重建等技術,高效率編解碼器可以為這些技術帶來更可靠有效的基礎支援;而且在現實情況中總是會有弱網情況的出現,通過高效編解碼節省的資源可以用於抗性提升,保障實時通訊的穩定性。因此,Penguins及其未來演進版本的提出,將有非常廣闊的應用前景

相關閱讀: https://mp.weixin.qq.com/s/eauCoafH7xP5vUkI9rvuUg

Ringcentral:給你的會議增加AI能力

Ringcentral 近日更新了他們的會議產品,這次主打AI能力。這幾個能力包括:

1,自動跟隨能力。當你進行移動的時候你的採集畫面的焦點會跟追你的面部;

2,低光補償。當你在昏暗環境下開會的時候,AI演算法會自動進行燈光補償;

3,影片濾鏡。可以為你的畫面增加更有趣的效果。

無獨有偶的是Zoom 前一段時間剛增加了自動翻譯能力,Google Meet 前一段時間也增加了燈光自動補償等能力,Around 也增加了自動跟隨和智慧降噪等能力。在影片會議越來越同質化的現在,各家產品不得不開始進行微創新來增加使用者粘性。

相關閱讀:https://www.ringcentral.com/us/en/blog/ringcentral-mvp-meeting-ai/ 

WebRTC M96 即將釋出,將廢除Plan B

Plan-B是Chrome/Chromium 獨有的實現,Safari 和 Firefox一直支援Unified Plan, Chrome在M72 已經支援Unified Plan。從某種程度上說如果後續再開發WebRTC 可以不考慮Plan B的支援了,因為Unified Plan的支援已經非常好。

Plan-B 和 Unified Plan 各有優劣,在只有一路音訊和影片的時候這兩種方案並沒有什麼區別,在多路音影片的時候Unified Plan 每一路音影片都會有一個Mline,這樣就提供了很大的靈活性,可以針對每一路音影片協商不同的能力,比如我們有一路攝像頭和一個螢幕共享,就可以讓螢幕共享使用av1編碼,而攝像頭使用h264。

作為多年跟SDP打交道的開發者不得不說SDP Sucks,SDP真的是一個很糟糕的設計,它是一個標準但又是一個相對靈活的標準,每家的實現可能又不一樣,不得不花費很多精力進行SDP的適配,如果你還有沒有被SDP的適配困擾過某種意義上你可能還沒有完全瞭解WebRTC。但標準一旦確立,別人撼動它也很難,微軟曾經搞出來ORTC標準來遮蔽SDP的協商問題,最終也還是失敗了。

相關閱讀: https://www.chromestatus.com/roadmap

Unreal Engine 即將支援WebRTC 通過WHIP推流

Unreal Engine 較早就支援WebRTC,Unreal Engine 基於WebRTC開發了他們的Pixel Streaming服務,讓使用者可以在雲端伺服器上執行虛幻引擎應用程式,通過WebRTC將渲染的幀和音訊流送到瀏覽器和移動裝置上。場景非常像雲遊戲或者雲渲染。

國外有位開發者 Murillo (開源WebRTC媒體伺服器Meddoze的作者) 給Unreal Engine 增加了使用WebRTC 通過WHIP的支援。支援WHIP 標準之後,可以讓一些對WebRTC和音影片不熟悉的開發者也可以很方便的使用WebRTC推流,這將把雲遊戲/雲渲染的開發成本降低很多。期待這個PR可以早日合併。

另外需要說的是騰訊雲的快直播也已經支援WHIP協議推流,後面你可以很方便的從Unreal Engine 或者 Unity 中把渲染好的畫面推動到騰訊雲,並做到端到端幾百ms內的延遲觀看。

關於騰訊雲快直播的WHIP推流能力,我寫了一個demo放在github上,

https://github.com/Tencent-RTC/leb-whip-example

 

歡迎點選一鍵訂閱《雲薦大咖》專欄,獲取更多精品內容。

看雲端技術起落,聽大咖指點迷津。