正文字數(shù)：4001 ?閱讀時長：6分鐘

當問到直播視頻時使用低延遲HLS還是WebRTC，WebRTC顯然是贏家。

作者 /?Red5 Pro

原文鏈接 / https://www.red5pro.com/blog/5-factors-in-choosing-low-latency-hls-vs-webrtc/

在低延遲HLS或是WebRTC之間做選擇時，哪種協(xié)議能夠帶來最佳的實時流體驗？因為協(xié)議決定了編碼視頻數(shù)據(jù)通過網(wǎng)絡連接傳輸?shù)乃俣?#xff0c;所以在兩者之間做出選擇是非常重要的。

Wowza最近發(fā)表了一篇包含關于WebRTC和低延遲HLS錯誤信息的文章。盡管正確地說明了WebRTC是提供實時延遲的唯一辦法，它們還是重復了一些很普遍的誤解，特別是一個經(jīng)常被提及的神話：WebRTC沒有擴展性。該說法也被Red5 Pro以及其他人完全否定了。

進一步的分析之后，在Red5 Pro的調(diào)查者提出了選擇協(xié)議時我們需要考慮的五個主要因素。這些因素也正好是Wowza大部分搞錯的。它們包括：延遲、可擴展性、多設備兼容性、較差直播條件下的性能，以及安全性。讓我們從實時流中最重要的延遲這一方面來深入討論這些因素的細節(jié)。

1

延遲

延遲對于實時流來說至關重要。從簡單直接的視頻對話到更精確的事情，例如控制無人機，這些實時用例只能允許500毫秒的延遲。任何高于500毫秒的延遲都難以被接受。正如Wowza所說的：“低延遲非常重要。[…] WebRTC的構建采用了雙向實時通信，使其成為了市場上最快的協(xié)議。”這也是我們所同意的地方。WebRTC確實是現(xiàn)今最快的、得到最廣泛支持的協(xié)議。

HLS基于長期建立并且根深蒂固的HTTP基礎結構，導致其當前得到了廣泛的使用。這種老式的基礎結構也解釋了為什么HLS會有10-40秒的延遲。

然而，有一些方法可以修改HLS來達到降低延遲的目的。Apple公司有自己的Apple Low Latency HLS （LL-HLS）工具，類似于開源的Low-Latency HLS（LHLS）。它們都能夠將延遲降低到2到3秒左右。雖然它們降低了延遲，但是他們都沒有辦法享受標準HLS的廣泛兼容性。

為了提高LLHLS的兼容性，Apple在2020年初宣布廢除超文本傳輸協(xié)議第2版（HTTP/2） 推送要求。這樣的話，看起來整個HLS規(guī)范將最終達到3秒左右的延遲。盡管這已然不是完全實時的，但肯定比40秒的延遲要好。

作為一個基于UDP，并且為完全適應現(xiàn)代互聯(lián)網(wǎng)所搭建的協(xié)議，WebRTP支持500毫秒的實時延遲。這也意味著它是現(xiàn)今唯一收到廣泛支持，并且能夠能夠提供實時延遲的協(xié)議。

2

可拓展性

WebRTC比HLS難擴展得多。但是這并不意味著它沒有擴展性，特別是考慮到它已經(jīng)被實現(xiàn)過。

微軟就是一個擴展WebRTC的成功案例。2016年八月，微軟收購了Beam。Beam是一個基于WebRTC的實時游戲直播方法，旨在解決直播延遲問題并且在Twitch平臺上提供更好的體驗。一年之后，微軟將Beam改名為Mixer。盡管他們最終關閉了Mixer游戲直播平臺，但這只是因為無法吸引足夠多的用戶，而不是沒有能力支持大量用戶。一位受歡迎的，名叫Ninja的游戲主播在Mixer上主持的直播吸引了85000名觀眾同時觀看，并在8.5小時內(nèi)吸引了總共220萬觀眾。

根據(jù)Wowza所說，“如果您需要將觀眾規(guī)模擴大到50以上，則需要三思而后行。”他們還聲稱，在最好的情況下，Wowza流媒體引擎能夠擴展到多達300個基于WebRTC的觀眾。使用他們的系統(tǒng)時，如果超過了這個范圍，就需要將WebRTC轉為HLS或者DASH，導致延遲增加。

Wowza在擴展中遇到的困難是來自他們對WebRTC的實現(xiàn)，而不是協(xié)議本身。在這種情況下，Wowza的流媒體引擎本質(zhì)上充當了一個單一服務器的SFU。其實，它只使用了一臺機器來處理所有的工作，這意味著他在連接、RAM以及CPU等方面不能超出單一服務器可以處理的范圍。廣播或發(fā)布流會被傳到一個單一的SFU服務器，所以一旦該SFU中所有的資源都被消耗掉時，它就不能再增加任何信息了。

無論使用什么協(xié)議，應用程序的擴展都會增加其消耗的CPU和RAM。當您的主機提供商使用固定的數(shù)據(jù)中心（如CDN）時，實現(xiàn)這種增加的需求代表著增加額外的服務器或者增加服務器容量。如果需求高于預期，或者僅僅是需要一點額外的容量，都可能成為一個問題，因為您最終可能會支付比您需要的大得多的服務器。當然，對于使用CDN服務的開發(fā)者來說，這一切都是抽象的，這也是為什么使用這類設置如此吸引人的原因。問題是，如果CDNS使用HTTP來擴展，會帶來巨大的延遲。

這就是為什么您需要以WebRTC為協(xié)議的集群解決方案。如果它能根據(jù)云基礎設施進行自動擴展就更好了。這類的自我擴展方案，涉及到從基于數(shù)據(jù)中心的靜態(tài)CDN模型轉變?yōu)橐粋€基于云的更加靈活的模型。當網(wǎng)絡流量增加，服務器集群可以被設置為動態(tài)地旋轉新的服務器。當不再需要它們時，可以將這些服務器旋轉回來。這種方法緩解了很多支付不需要的服務器容量的問題。

3

多設備兼容性

確保您的應用能在各種設備上運行當然是非常重要的。無論是移動設備、筆記本還是平板電腦，您都需要完整的瀏覽器和平臺支持。

它唯一支持的本地桌面瀏覽器是Safari。其他所有的瀏覽器都需要使用JavaScript編寫的自定義播放器。雖然有像JWPlayer這樣的商業(yè)產(chǎn)品作為選擇，開源的hls.js也是一個可選的解決方案。然而，目前為止，只有很少的播放器已經(jīng)更新支持蘋果新推出的低延遲HLS協(xié)議。

作為一種新的網(wǎng)絡標準，WebRTC被所有主流瀏覽器的最新版本完全支持。其中包括Chrome、Safari、Firefox、Edge還有Opera。不僅如此，它還可以在本地瀏覽器中運行，并不需要插件的幫助。這其中包括了為IOS和Android設計的移動瀏覽器。當然，利用移動SDK創(chuàng)建專門的應用也是沒有問題的。

就像其他事一樣，所有瀏覽器的實現(xiàn)都會略有差別，但沒有一樣差別會完全阻止其兼容性。Wowza并沒有想辦法創(chuàng)造跨瀏覽器的兼容性，而是簡單地指責了Safari的不穩(wěn)定性。作為WebRTC的提供者，我們有責任去想辦法讓跨瀏覽器的兼容性發(fā)揮作用。完全兼容是絕對可能的，因為包括在Red5 Pro在內(nèi)的其他組都能夠完全支持Safari。我們同意，在保持完整規(guī)范的條件下與多種瀏覽器實現(xiàn)兼容性是很困難的，但這并不意味著做不到。

4

惡劣直播條件下的性能

在質(zhì)量和性能方面，LL-HLS和WebRTC具有相似的特點，因為他們都支持轉碼和自適應比特率（ABR）。

ABR允許客戶端請求一個更適合他們當時所經(jīng)歷的連接環(huán)境的較低比特率。這樣做可以確保在連接不良的狀態(tài)下保持順利連接。HLS和他的新“表兄”LL-HLS在規(guī)范中內(nèi)置了ABR。這是由一個包含了變量的主清單文件來實現(xiàn)的。當播放器檢測到視頻傳輸速度不夠快，從而檢測到帶寬不足時，它可以很容易地請求清單中的某個低流變量。接著，它就可以以比較低的比特率下載新的視頻片段。

對于WebRTC來說，情況就大不一樣了。在WebRTC中，您會有一個單一的UDP連接，并且視頻的傳輸是通過SRTP進行的。這就代表您不能請求不同的段文件，因為一開始并沒有任何段文件。相反地，我們的方法是在邊緣服務器上提供多種比特率，這樣可以允許客戶端請求正確的視頻質(zhì)量。該請求本身是通過RTCP通道，一個用于發(fā)送WebRTC會話中每個對等體實時狀態(tài)信息的雙向控制通道。我們接受的具體信息是REMB，其中包含了對等體（在這種情況下是用戶客戶端）請求的推薦帶寬。根據(jù)該信息，邊緣服務器節(jié)點就可以做出響應，轉而提供帶寬需求的最佳流。

作為補充，HLS和WebRTC都可以依靠流媒體的事實轉碼來生成這些多比特率變體。轉碼將流媒體分成了不同的質(zhì)量等級（例如高、中、低），這樣允許了支持最高質(zhì)量的用戶訂閱該媒體，并且連接較差的用戶也仍然可以觀看。

雖然HLS僅限于ABR，但WebRTC還有能夠提高質(zhì)量和性能的其他功能。

鑒于WebRTC是一個基于UDP的協(xié)議，其最關鍵的功能之一就是NACK，它是一種重新發(fā)送關鍵數(shù)據(jù)包的方法。不好的網(wǎng)絡連接很有可能導致客戶端丟包。NACK并不會一直嘗試重新發(fā)送每一個數(shù)據(jù)包，而是識別出最重要的數(shù)據(jù)包并試圖重新發(fā)送。這可以防止因過多請求而導致的網(wǎng)絡超載。這種方法會幫助保持流的流動，即使在惡劣的網(wǎng)絡條件下也能保持良好的狀態(tài)，并且也不會被基于TCP系統(tǒng)中數(shù)據(jù)包備份的缺點所影響。而且，和REMB一樣，ACK也是一種通過RTCP通道發(fā)送到邊緣服務器的消息類型。邊緣服務器也會負責重新發(fā)送這些重要的數(shù)據(jù)包。WebRTC還支持許多其他策略來保持高視頻質(zhì)量并且確保視頻高效傳輸。FEC、FIR和PLI這樣的策略也正好可以通過RTCP通道工作。

WebRTC是一個復雜的規(guī)范，它擁有很多的移動部分。這也可能是為什么Wowza在他們關于ABR如何在WebRTC上工作的帖子中弄錯了很多東西。具體來講，我們參考以下內(nèi)容：

另一方面，WebRTC在建設時沒有考慮到質(zhì)量的問題。WebRTC的首要任務一直是點對點瀏覽器連接的實時延遲。傳統(tǒng)來講，質(zhì)量問題是次要的。您可能會對WebRTC支持ABR感到驚訝，但有一個警告。俗話說：“鏈條的強度取決于它最薄弱的一環(huán)。”而這一點對于WebRTC的質(zhì)量也是一樣。WebRTC內(nèi)置的ABR只在訂閱用戶端。如果有多個訂閱用戶，那么就會產(chǎn)生問題。您可能會遇到其中一個訂閱用戶網(wǎng)絡連接不良的狀況。這將迫使發(fā)布者切換到較低質(zhì)量的流媒體，導致每個訂閱用戶都只能以低質(zhì)量觀看。”

Wowza似乎并沒有理解點對點視頻會議的場景，這種情況下，擁有最低帶寬的人將決定了所有用戶的觀看質(zhì)量。當然，這種設定和可擴展的源服務器-邊緣服務器集群模型有很大的不同。邊緣服務器節(jié)點處理每個客戶端的唯一對等連接。其實，在Wowza的SFU案例中，他們也有這類情況。從我們的閱讀以及其他人的說法來看，Wowza其實根本沒有針對WebRTC的ABR策略。

5

安全性

確保您的數(shù)據(jù)和流被保護也是非常重要的。防止未經(jīng)授權的用戶創(chuàng)建流并對它進行加密，使其無法被攔截，以確保敏感的信息不會被泄露。

就像之前所說，LL-HLS將被納入HLS規(guī)范。這也意味著LL-HLS的安全功能，如DRM、令牌認證以及密鑰輪換等功能都將被實現(xiàn)。但是，這些額外的功能只能等到供應商可以在系統(tǒng)中配置他們之后才能實現(xiàn)。等待別人為您提供安全服務可能是一個問題。

HLS有一個很突出的安全特性，那就是它可以被加密。WebRTC是默認加密的，這代表了您的流媒體不會被黑客非法訪問。除此之外，用戶認證、文件認真以及往返認證等功能能進一步保護流媒體的安全。

關于DRM系統(tǒng)，很多情況下，WebRTC提供的基本安全性足以保護您的數(shù)據(jù)。意為，內(nèi)容所有者和發(fā)行商在有法律權限的條件下，都可以放心地省去簽訂DRM合同的成本和麻煩。

WebRTC還享有很強大的安全功能，內(nèi)置的設備兼容性，以及無論網(wǎng)絡強度如何都能保持高質(zhì)量的性能。當然，必須承認的是，WebRTC是將實時延遲控制在500ms以內(nèi)的唯一方式。

當問到直播視頻時使用低延遲HLS還是WebRTC，WebRTC顯然是贏家。

LiveVideoStackCon 2020 SFO（線上峰會）

看WebRTC商業(yè)版大佬

如何在Wowza流媒體引擎服務器實現(xiàn)HLS標準

LiveVideoStackCon 2020?美國舊金山站

北京時間：2020年12月11日-12月13日

點擊【閱讀原文】訪問直播頁面

總結

以上是生活随笔為你收集整理的选择HLS或WebRTC需要考虑的五个因素的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。