Russell Traffor-Jones在直播環(huán)境下對 WebRTC 的使用方式做了很好的介紹。

WebRTC現(xiàn)在已經(jīng)成為了W3C的正式標準，提供具有NAT遍歷功能的次秒級的點對點視頻和音頻流。次秒級延遲已經(jīng)被廣泛應用于視頻會議之中，也一直是視頻流公司的焦點，如Millicast和Limelight（僅舉兩個例子），這些公司旨在將這種點對點技術(shù)交付給成千上萬的人。在不到一秒鐘的時間內(nèi)便實現(xiàn)了交互式視頻、游戲流、拍賣和超低延遲的體育運動。

針對直接使用其他流媒體協(xié)議的用戶，Pion的創(chuàng)建者肖恩?杜布瓦（Sean DuBois）在SF Video Tech上談到了WebRTC帶來的RTMP、SRT和RIST等協(xié)議。它的核心是WebRTC（如SRT和RIST）創(chuàng)建一個連接，通過它可以發(fā)送各種數(shù)據(jù)。雖然我們期望媒體被發(fā)送，但是實際上，文件傳輸可以很容易地被實現(xiàn)——讓我們不要忘記整個SRT是建立在UDT之上的，而UDT是一個專門用于文件傳輸?shù)膶嵱贸绦?。在可以實現(xiàn)文件傳輸?shù)牡胤剑瑢崟r數(shù)據(jù)和元數(shù)據(jù)傳輸也可以實現(xiàn)。

Sean很快將WebRTC概括為（典型）瀏覽器之間的協(xié)議，這是一種點對點的安全連接，多個音頻和視頻流可以在其連接上流動。與RIST和其他最新的協(xié)議一樣，它基于許多已有的協(xié)議：SRTP、DTLS、ICE和SDP等技術(shù)來提供信令、連接管理、加密和通信。

對于RTMP非常長的改進列表，它們都在視頻中被簡明扼要地展現(xiàn)出來了，所以我們在這里只突出幾個要點。重要的是，低延遲是其中的關(guān)鍵。RTMP在當時是屬于低延遲的，但并不是以今天的低延遲標準。Sean解釋說，谷歌的Stadia可以為按鍵提供125毫秒的視頻延遲。DTLS和SRTP對于安全性來說是必不可少的，但是它們是眾所周知便于理解和可靠的保護數(shù)據(jù)的方法。DTLS與TLS幾乎完全相同，TLS保護您的銀行轉(zhuǎn)賬，只是將其改為UDP而不是TCP中。但是，WebRTC可以通過交換“指紋”（DTLS-SRTP）而不是支持web上TLS的完全可信的證書基礎(chǔ)結(jié)構(gòu)來工作。只要您有信心可以提前安全地交換指紋，那么取消對證書的要求對于靈活性和敏捷性是一個很大的提升。

NAT遍歷也是一大福音，即使兩個端點都在防火墻后面，端點也總能找到通信的方法，盡管這確實意味著需要ICE服務器來促進連接。然而，在廣播中，你更有可能控制一端，這樣就不太需要這樣做了。Sean強調(diào)了使用WebRTC的“同步廣播”功能在同一流中發(fā)送多個質(zhì)量級別的能力。

之后Sean著眼于SRT和RIST。這兩種協(xié)議都是低延遲流協(xié)議，它們都可以提供次秒級的流傳輸，以實現(xiàn)RTT相對較低的良好連接。Sean強調(diào)了SRT和RIST在協(xié)商使用中的編解碼器及其可選安全性方面的不足。由于更注重提供貢獻源，它們往往具有更靜態(tài)的配置，通常是在測試程序之后創(chuàng)建的，以確保其質(zhì)量能夠被廣播商/流媒體提供商所接受。

最后，Sean重點介紹了WebRTC的一系列有趣的創(chuàng)新用途，從非正式的群組流媒體到無人機、共享在線游戲到文件傳輸?shù)鹊取?/p>

現(xiàn)在就來看看吧！

責任編輯：lq