WebRTC影音探索

2020年，Adobe宣布停止對 Flash播放器的支持。Flash歷經(jīng)多年終于走向終結，雖然是眾望所歸，但它的退出卻對存在于許多流媒體工作流程中的一項重要技術——RTMP（ Real-Time Messaging Protocol）影響重大。RTMP最初設計用于向Adobe Flash播放器傳輸音頻、視頻和其他數(shù)據(jù)。在全盛時期，RTMP曾是互聯(lián)網(wǎng)上傳輸視頻的最主要技術。它可以用于端到端，并能確保快速的實時傳輸。然而與過去相比，現(xiàn)在越來越多的設備和瀏覽器都不再支持RTMP。

雖然在編碼器和服務器之間傳輸視頻方面，RTMP仍然是一個可靠的視頻傳輸協(xié)議，但是對基于RTMP的播放來說，卻并非如此。Adobe也表示[1]：”鼓勵直播廠商將現(xiàn)有的Flash內(nèi)容遷移到新的開放格式中去。”

在2020年的Streaming Media的一期雜志中，Robert Reinhard（流媒體視頻顧問）曾警告：“如果你正在使用Flash進行低延時實時流媒體傳輸，那么你還有一年的時間（或者更短）將其遷移到WebRTC上。這意味著什么？意味著你在基于Flash的媒體服務器上所使用的的任何代碼都需要遷移到WebRTC（而非RTMP）上。”

然而，許多內(nèi)容發(fā)行商仍然在竭力將RTMP替換為用于視頻播放的實時格式。為什么？因為雖然HLS和MPEG-DASH支持不同設備的高質(zhì)量流媒體傳輸，但是延遲超過30秒是這些基于HTTP技術的標準。確實存在這些協(xié)議的低延遲擴展（LL-HLS和DASH的LL-CMAF），但是它們都無法達到很多公司追求的次秒級傳輸速度。除此之外，播放器、CDN和各種設備對于LL-HLS和LL-CMAF（用于DASH）的支持還處于早期階段。

對于實時視頻傳輸來說，WebRTC是你的唯一選擇，這也是它在最近幾年備受關注的原因。這項基于HTML5的技術為互聯(lián)網(wǎng)上的實時視頻傳輸提供了最快的方法。更重要的是，像RTMP在其全盛時期一樣，WebRTC也可以端到端使用。

但是WebRTC也有自己的局限，它被設計用于基于瀏覽器的編碼和小規(guī)模的流媒體傳輸，而這兩個特點都使它無法適用于某些直播場景。

WebRTC會是替代RTMP的最佳方案嗎？在開發(fā)者中，這句話已經(jīng)成為了流行語。正如我將在下文所解釋的那樣，它取決于你所使用的支持部署的技術和你想達成的目標。

RTMP vs. WebRTC: 對比

對比RTMP，WebRTC有以下幾個優(yōu)勢：其一，它是一種新型、由IETF和W3C進行標準化的開源技術。所有的主流瀏覽器無需插件即可支持WebRTC，消除了由專有流媒體技術所帶來的互操作上的挑戰(zhàn)。除此之外，軟件開發(fā)者社區(qū)不斷為WebRTC的開發(fā)貢獻代碼，也使它受益匪淺。

其次，在傳輸速度低于500毫秒的情況下，WebRTC是目前延遲最低的協(xié)議。它也由此成為創(chuàng)建交互式視頻體驗（從實時拍賣到直播購物）的首選解決方案，同時對于那些想要超越競爭對手的體育直播廠商來說，它也是一個非常具有吸引力的選擇。

向數(shù)目眾多的觀眾進行大規(guī)模直播對于WebRTC來說還存在困難。視頻聊天框架本來就不是為規(guī)模化而設計的。幸運的是，我們已經(jīng)開發(fā)了一種解決方案來克服這種局限，我將在下文詳述。

在視頻生產(chǎn)方面，WebRTC僅使用Web瀏覽器就可以進行簡單的直播，但是對于希望使用硬件或者軟件解決方案控制編碼設置的直播廠商來說，基于瀏覽器的編碼并不理想。同樣，當涉及到使用定時元數(shù)據(jù)的字幕和廣告標記等功能時，RTMP也比WebRTC更具優(yōu)勢。

WebRTC工作流程

所以，當涉及到實時視頻流媒體傳輸時，RTMP到底在哪里可以替換成WebRTC? 作為一種端到端技術，WebRTC可分別用于推流、拉流或同時用于推、拉流。下面讓我們看下WebRTC工作流程兩端的優(yōu)勢，以及它是如何在確保規(guī)模化的同時應用于編碼到傳輸?shù)恼麄€過程。

WebRTC在推流時替換RTMP

RTMP仍然是第一英里視頻貢獻的標準，這其中有以下幾個原因。第一，RTMP獲得了來自直播編碼軟件和硬件的廣泛支持，同時許多社交媒體平臺也在使用它。編碼廠商已經(jīng)開始向SRT等開源協(xié)議添加支持，但是WebRTC一直僅限于基于瀏覽器的內(nèi)容發(fā)布。對于任何想要使用Web攝像頭和麥克風直接在瀏覽器上進行直播的人來說，WebRTC非常有用。但是對于想要使用專業(yè)編碼器進行實時流媒體內(nèi)容傳輸?shù)膬?nèi)容發(fā)行商來說，就無法使用WebRTC推流。

因此Millicast的技術團隊設計了WHIP（WebRTC HTTP Ingest Protocol）來解決這個難題。在與媒體服務器通信時，WHIP提供了使用標準信令協(xié)議的編碼軟件和硬件，這樣就可以實現(xiàn)跨廠商的WebRTC推流。WHIP在實現(xiàn)WebRTC推流的同時，還保留了WebRTC的低延遲優(yōu)勢（與RTMP相比），同時移除了編碼器和媒體服務器之間的連接障礙。

當用于推流時，WebRTC可以確保低延遲、強制加密并提供對于Opus和VP9等高級編解碼器的支持。因為有了WHIP，WebRTC也正在成為一種可用于硬件和軟件編碼的格式。直播流程對編碼設置（包括碼率、編解碼器和編解碼器參數(shù)等）有更多的控制需求，而WHIP的出現(xiàn)使WebRTC可以直接和RTMP競爭。

WebRTC在拉流時替換RTMP

瀏覽器不再支持RTMP導致播放端無法再使用它。當今大部分直播廠商都在使用HLS進行“最后一英里”的交付，但HLS的延遲要超過30秒。

目前你在傳輸視頻時正在使用哪些流媒體格式？

來源：Wowza的2021視頻流延遲報告[3]

當涉及低延遲協(xié)議的替代方案，WebRTC是眾多協(xié)議中傳輸速度最快的。因此，如果你需要真正的交互（我們這里討論的是用于緊急響應和遠程監(jiān)控等場景的低于一秒的視頻傳輸），那么WebRTC將是你的最佳選擇。LL-HLS和用于DASH的LL-CMAF同樣也是不錯的選擇，但是它們無法實現(xiàn)像WebRTC一樣的實時傳輸。

也就是說，WebRTC最初并不是為大規(guī)模直播場景設計的。我們過去曾鼓勵內(nèi)容發(fā)行商在向大量觀眾直播交互性內(nèi)容時使用調(diào)整后的HLS或者LL-HLS，但現(xiàn)在我們?yōu)榱私鉀Q這個問題，已經(jīng)改進了產(chǎn)品。

具體來說，我們開發(fā)了一個新的特性：該特性可以在自定義的CDN上部署WebRTC，從而提供近于無限的規(guī)模。這個解決方案可以實現(xiàn)面向全球大規(guī)模觀眾的次秒級視頻傳輸[2]。

如圖中所示，當以這種方式傳輸視頻時，WebRTC可用于廣泛的工作流程中，包括WebRTC端到端，或者從RTMP到WebRTC。

在實現(xiàn)WebRTC時需要考慮的事

如果你正在考慮使用WebRTC代替RTMP，你需要將如下問題納入考量：

1. 你是否需要雙向視頻或?qū)崟r交互？

交互式實時流媒體解決方案和WebRTC密不可分，缺一不可。只要你使用WebRTC進行內(nèi)容發(fā)布和播放，就能實現(xiàn)低于500毫秒的流媒體傳輸。更重要的是，使用次秒級流媒體傳輸?shù)膽脠鼍斑€可以利用RTMP到WebRTC的工作流程。同時還存在混合模型，其中交互視頻參與者可以觀看WebRTC視頻流，而被動觀眾可以觀看由HLS傳輸?shù)木哂懈哐舆t的視頻流。

2. 你希望視頻內(nèi)容獲得大范圍傳播嗎？

所有的內(nèi)容發(fā)行商都希望他們的流媒體應用大獲成功，擁有成千上萬或者數(shù)百萬的觀眾。然而，過多用戶可能使你的基礎設施不堪重負。傳統(tǒng)的WebRTC部署因無法利用自定義創(chuàng)建的CDN而限制了它的擴展能力。所以如果你的目標是觸達大量觀眾，一定要確保擁有穩(wěn)健的基礎設施。

結語

由于WebRTC被設計用于視頻聊天應用，所以有兩個障礙阻礙了它在實時直播工作流程中的廣泛采用：

基于瀏覽器編碼的限制，以及在編碼軟件和硬件中缺少WebRTC能力。

規(guī)模化的挑戰(zhàn)：導致WebRTC在向成千上萬（或更多）觀眾直播時很難使用。

幸運的是，行業(yè)已經(jīng)為以上問題找到了解決方法，使WebRTC成為了RTMP的強大替代方案（無論是在推流時還是在播放端）。

在我們的2021視頻流延遲報告中，我們發(fā)現(xiàn)WebRTC已成為用于推流的第二流行的格式，用于傳輸?shù)牡谌餍懈袷健Ｔ诟鲝S商為實現(xiàn)實時視頻直播而努力提高WebRTC可用性的前提下，我預計WebRTC的采用率將繼續(xù)增長。

審核編輯 ：李倩