產品技術應用

關於 WebRTC,你所需要知道的幾件事

1. 什麼是 WebRTC?

WebRTC 是 Web Real-Time Communication 的縮寫,可以讓瀏覽器上不同的使用者在不需要安裝瀏覽器 plugin 的前提下進行點對點 (peer-to-peer) 的語音, 視訊通話以及資料傳輸。截至目前為止,已經有越來越多的瀏覽器紛紛都加入支援 WebRTC 的行列,包含蘋果的 Safari 以及微軟的 Edge:


Browsers support RTCPeerConnection API [1]

 

另外由於其 open source 的特性以及相關社群的蓬勃發展,有不少的公司已經使用 WebRTC 平台來客製化自己的企業溝通及社群通訊應用。

Companies use WebRTC  [2]

 

2. 支援行動平台嗎?

支援主流的 Android 及 iOS 的原生開發平台,行動開發者可以使用類似 Web 平台的 PeerConnection API 搭配官方範例進行開發。其中 WebRTC 官方在 2017 年秋季之後,開始不定期釋出這兩個平台的 prebuilt 版本(google-webrtc, GoogleWebRTC),更加節省開發者的 WebRTC 環境建置時間。

 

3. 使用 WebRTC 需要收費嗎?

WebRTC 程式碼本身就是 open source,任何人都可用來開發自己的多媒體通訊應用,而且 Google 預設使用 VP8 視訊和 iLBC 語音編解碼器,所以可以視為 Google 並沒有透過 WebRTC 的任何元件或者是相關編解碼器來跟開發者收取任何使用或專利授權費用; 除非開發者有一定得使用其他需要專利授權費用的編解碼器之需求(如: H.264),不然一般來說,是不需要支付任何費用的。

 

4. 支援群組會議嗎?

WebRTC 平台以支援 peer-to-peer 的安全傳輸溝通, 多平台開發為主要賣點,但是並沒有定義到信號交換的協定規範以及伺服器架構設計這一個層級。以官方版的範例程式 AppRTC 為例,這個範例展示了兩個 peer 利用了 AppRTC 自定義的信號交換與信號伺服器來完成這整個 WebRTC 所需的 ICE Negotiation 流程,信號伺服器只扮演了信號交換的角色,不牽涉到多媒體串流的中繼。所以如果是要支援多人視訊通話的話,就需要自行尋找相容於 WebRTC 的第三方 framework 來擴充信號以及多媒體串流伺服器端的需求。

 

5. 身為 WebRTC 的開發者,一定要懂的技術關鍵字:

WebRTC Architecture [3]

 

從上面的架構圖來看,會看到跟 WebRTC 實際開發相關的幾個關鍵字:

  • P2P (peer-to-peer) 相關,STUN, TURN, ICE:

WebRTC 是透過點對點的 UDP 來傳送串流資料,因此具有接近超低延遲的優勢(real-time),但是由於每個 peer 可能是位於防火牆或者是 NAT 架構之下,所以需要一套可以穿透 NAT 的協定來協調並保證端點間具有一定的網路穿透性,目前 WebRTC 用的是 ICE,算是把 STUN 跟 TURN 結合起來,然後根據不同的環境下,選擇相對適合的協定。其中 STUN 可以簡單想成是一種 NAT 的 UDP 打洞機制,TURN 則是當成多媒體串流的中繼伺服器機制,主要是當前者失效時的一種備援機制。但即使有了上述協定,WebRTC 還是沒辦法滿足 100% 的網路穿透性,跟一般走 HTTP 的協定(e.x. HLS)還要差,而且也缺少 CDN 的支援[4]。

  • RTCPeerConnection

WebRTC 開發者最常面對的 API,簡單的來說,開發者需要操作此 API 來將 AudioTrack/VideoTrack 加進 RTCPeerConnection instance 內藉此將本地端的串流傳至遠端,同樣地藉由 RTCPeerConnection 此一介面取出遠端的串流資訊,並播放/顯示在本地端。WebRTC 使用了 SDP (Session Description Protocol) 此一格式來識別端點間的資訊與多媒體能力並且進一步完成信號(Signaling)資料交換與 ICE Neogiation 流程,相關細節可參考 [5]。

可進一步參考 [6] 以獲得更多 WebRTC 關鍵字相關的資訊。

 

6. WebRTC 不適合用來做什麼?

直播平台,尤其是直接使用原生 P2P 架構。由於 WebRTC 支援 P2P 的雙向多媒體串流,所以如果沒有中繼多媒體串流伺服器介入的話,整個 WebRTC 系統的擴充性應該會限制在不超過十人左右,跟實際直播應用的破萬以上的規模有著不小的差距。而且就算投入多媒體串流伺服當做中繼伺服器,但以現行 CDN 對於 WebRTC 的低支援度,要單純使用 WebRTC 來支援大規模的多媒體應用還是相當不適合 [4]。

 

參考資料

  1. Can I Use webrtc
  2. WEBRTC_FOR_BUSINESS_PEOPLE
  3. WebRTC 官網
  4. 低延遲戰場-最新影音串流技術盤點
  5. Signaling and video calling
  6. Webrtcglossary

 

產品技術應用

一次搞懂串流技術 : 10個不可不知的網路影音名詞解釋

談到網路影音不可不知的10個名詞:

1. OTT

OTT服務是指「over-the-top」服務,通常是指內容或服務建構在網路基礎服務之上,而不需要電信運營商額外的支援。在影音產業中泛指透過網路提供隨選視訊(VoD)的影音平台。

2. VoD

VoD (Video On Demand) 隨選視訊是一套可以讓使用者透過網路選擇自己想要看的視訊內容的系統。用戶選定內容後,VOD系統可以用串流媒體的方式進行即時播放,也可以將內容完全下載後再進行播放。台灣常見的OTT服務包括:Netflix, KKTV, LineTV, Catchplay…等

3. Live streaming

Live streaming 中譯為「直播串流」或「網路直播」,是指隨著線上影音平台的興起,在網際網路上公開播出即時影像的娛樂形式。

在 VoD 與 Live Streaming 的應用,常見的影音編碼格式包括MPEG-4, H.264, H.265,而常見的協定包括 HLS, RTMP, WebRTC。

4. HLS

HTTP Live Streaming(縮寫是HLS)是一個由蘋果公司提出的基於HTTP的流媒體網絡傳輸協議。HLS只請求基本的HTTP報文,與實時傳輸協議(RTP)不同,HLS可以穿過任何允許HTTP數據通過的防火牆或者代理伺服器。它也很容易使用內容分發網絡來傳輸媒體流。

5. RTMP

實時訊息協定(英語:Real-Time Messaging Protocol,縮寫RTMP)也稱實時訊息傳輸協定,是最初由Macromedia為通過網際網路在Flash播放器與一個伺服器之間傳輸串流媒體音訊、影片和資料而開發的一個專有協定。

6. WebRTC

網頁即時通訊(英語:Web Real-Time Communication),是一個支援網頁瀏覽器進行實時語音對話或影片對話的API。它於2011年6月1日開源並在Google、Mozilla、Opera支援下被納入全球資訊網協會的W3C推薦標準。

以上三種常見的協定提供技術協定讓各類型廠商可以依據自身的需求選擇不同的協定進行傳輸,而不同的傳輸協定也有各自的優缺點。例如:講求高穩定度,可以接受較長延遲時,就可以選擇 HLS 協定;但對於極低延遲(Ultra Low latency) 的需求來說,就必須選擇 WebRTC 才有可能辦到。

對於不同的延遲,業界有一些基礎的定義。

7. Latency

延遲是指做出觸發動作與得到回應之間的時間間隔。在網路直播的產業中,泛指從直播主端畫面傳送到觀看者端之間的秒差。以 HLS 的協定而言,一般落在 20 秒左右的延遲時間。

7.1 Low latency

低延遲泛指 3 ~ 6 秒之間的直播延遲時間,可能的實作方式包含 RTMP 協定及特殊的 HLS 協定。

7.2 Ultra low latency

極低延遲泛指小於一秒(毫秒等級)的直播延遲時間,應用的場景多為網路即時通訊或特定產業領域。常見的實作方式為技術商專有軟體,例如 Skype protocol;或者是選擇公開的 WebRTC 協定。

除了延遲是一個重要的影響因素之外,影音傳輸的成本也是一個在考量影音平台架構時,必須嚴格看待的一個問題,其中對成本影響較大的包含以下幾點:

8. FPS

影格率測量單位(英語:frames per second):每秒顯示幀數 或者 每秒顯示張數。有時也以「Hz」頻率代稱,例如 1080p30,最後的數字30代表30Hz也就是每秒30幀的意思。

9. Resolution

解析度 泛指量測或顯示系統對細節的分辨能力。網路影音常見的解析度規格包含 Full-HD (1080p)、HD (720p)、480p、360p。其代表的意思是一個圖片的水平掃描線超過1080條。

10. Bitrate

位元速率是單位時間內傳輸送或處理的位元的數量,其單位為 kbps 或 bps。。在網路影音領域中,Bitrate通常與影像品質高低相關,越大的 Bitrate 代表每一個像素點所涵蓋的位元越多,影像就會越清楚、銳利;反之亦然。

 

所以,當有你要跟其他人聊網路影音技術時,HLS、RTMP、WebRTC 都是網路協定的一種,影響的是延遲及觀影的品質。而最重要的成本問題,別忘了考量影音的FPS、Resolution、Bitrate,當然還有觀影時間囉!

產品技術應用

低延遲戰場 : 最新影音串流技術盤點

最近許多影音串流應用,例如遊戲直播、博弈直播等,都要求較高的互動性,因此產生了低延遲串流的需求。以下整理了目前在低延遲表現效能上,幾個應用的主要串流技術。

 

服務端(媒體伺服器)–觀眾端

HLS/DASH 分段延遲 : 目前主流標準,使用現有HTTP基礎建設(CDN)支持大量觀眾

目前最普遍的串流技術是HLS/DASH,主要是將串流分段成多個小檔,讓影片可以透過現有的HTTP基礎建設(CDN)傳遞給大量觀眾,但也因此產生了分段的延遲現象。為了降低分段延遲,可以直接把分段的長度降低,但卻會犧牲影片的壓縮效率,換句話說,也就是相同畫質的影片,需要比較高的流量。

LHLS/CMAF 超低延遲: 分塊編碼(Chunked transfer encoding),主動推送分段訊息

新的低延遲串流LHLS/Low latency CMAF,是將每一分段切成更小的切片,原本是要等一整個分段完成後,撥放器才下載來撥放,現在改成每一小切片(例如 0.2秒的影片)就推送給撥放器,因而降低分段的延遲。不同於HLS/DASH是定期拉分段下來,而LHLS/Low latency CMAF是以主動推送的方式,每當產生一個切片,就馬上推送給撥放器。為了支援推送,傳輸方式改成透過 HTTP Chunked transfer encoding。

WebRTC 傳輸: 可以做到一秒內延遲,但容易被防火牆阻擋、技術難度較高

除了HTTP協定的串流技術,另一個選擇是WebRTC。雖然WebRTC一般是用於兩人或多人的雙向視訊,但也可用在單向一對多的直播場景。WebRTC是透過UDP連續傳輸,並沒有分段衍生的延遲,就裝置的支援度來講,各大瀏覽器都支援WebRTC,iOS也在iOS 11開始支援。 目前大規模使用WebRTC於直播串流的有Mixer,主要應用於遊戲直播。

雖然WebRTC可以提供非常低的延遲(<1 秒), 但在其他方面有些缺點。在網路的穿透性上,因為WebRTC是透過UDP傳送,較容易被NAT或防火牆擋住,穿透性會比走HTTP的HLS/DASH來的差;在系統擴展性上,由於目前支援WebRTC的CDN不多,沒法透過CDN支援大量觀眾, 相對於簡單的HTTP協定,WebRTC是一個複雜的協定,有較高的技術挑戰。

 

串流技術比較表 (串流服務端到觀眾)

 

 

 

 

 

訊號源 (影音採集)–服務端

RTMP 目前最普遍,FTL/WebRTC 支援 Adaptive Bitrate

前面提到的都是服務端到觀眾這一段的串流,而訊號源到服務端這一段也許還有降低延遲的空間。現行最普遍的串流協定是RTMP,其他的替代方案有由Mixer開發的FTL和WebRTC,這兩者可以做到更低的延遲效果,並且都支援 Adaptive Bitrate,但訊號源普遍不支援。

 

串流技術比較表 (訊號源到串流服務端)

參考資料 : 

  1. Introducing LHLS Media Streaming
  2. Low Latency HLS – LHLS
  3. FTL (Faster Than Light Streaming Protocol)