產品技術應用

從零開始,快速搭建自己的串流直播系統 (下)

上篇『從零開始快速搭建自己的串流直播系統 (上)』,討論了如何一步步的建立直播伺服器端,本篇則是介紹收看端如何在不同的三個平台上觀看 HLS 直播串流,這當中使用了現成的範例以簡化教學之複雜度。

閱讀全文 “從零開始,快速搭建自己的串流直播系統 (下)”

產品技術應用

從零開始,快速搭建自己的串流直播系統 (上)

目前市面上已經有許多直播平台,如 Twitch、YouTube 與 Facebook,當您在使用上述平台進行直播的同時,是否有想過其實自己也可以依樣畫葫蘆般搭建自己的小型直播串流系統?單純以技術的角度來看,搭建直播系統的難度並不是太高,特別是相關的開源軟體都可以使用的情況之下,所以本系列文將探討如何循序漸進、一步一步地來搭建屬於自己的直播系統。

此篇文章為上集,主要進行直播系統之簡介與伺服器端之手把手搭建;至於直播的收看端則留到下集介紹。 閱讀全文 “從零開始,快速搭建自己的串流直播系統 (上)”

產品技術應用

一次搞懂串流技術 : 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)