Claire's Blog

網路串流服務介紹

近年來影音相關的服務越來越火紅，許多的社交軟體都用直播影片來取代舊有的圖文內容。雖然網路影音服務在2000年左右就已經出現，但由於當時的移動設備和網路頻寬的限制，使得網路影音的發展受到很多限制。而在2013年後網路直播開始爆發，進入了直播影片的年代，一開始的網路直播以PC為主，而在移動設備普及後，各種社群媒體的APP更是紛紛支援直播串流功能。因為直播串流的普及、電腦設備及網路速度的進步下，也新興了如了Youtuber、實況主、直播主等這種專門經營此區塊的行業，可謂是非常火紅且受到矚目的一個領域。近年來，通信行業也更多的走向網路化，通訊軟體如Line、Facetime等，漸漸取代了過去的電話、簡訊。最近因5G和IoT的發展，未來應有更多的領域會走向網際網路化。

所有網路影音相關的服務，大致分為『點播』、『直播』和『錄播』。

1. 所謂點播，其英文為Video On Demand，簡稱VOD。其中Demand意為需求，從字面上理解點播，指的是使用者點選想要看的影片，並將該影片使用實時串流的方式播放出來。相關的服務如:Netflix、Apple TV、HBO等…
   

2. 直播的英文為Live broadcast，則是直播音視頻會以媒體流的形式推到服務器上（推流）。如果有觀眾收看直播，服務器收到用戶的請求後，會把視頻傳輸到網站、APP、客戶端的播放器，即時播放串流影片。相關的服務平台有Youtube、Facebook Live、Twitch等…
   

3. 錄播: 一個完整的錄播系統包含了錄製剪輯、直播推送、影片處理等核心功能，配備了相關的軟體和硬體。能夠按照標準產出比較高質量的影片內容，較多使用在線上教學系統上。
   

直播服務的原理

而這30天的系列文章，我們主要會著重在直播的研究，一個完整的直播服務會牽涉到非常多面項領域的技術，從視頻/音頻處理，圖形處理，視頻/音頻壓縮，CDN分發，即時通訊等技術等，每個項目都有很深的技術背景，都需要以年來計算的去鑽研，因此許多部份只會提及基本概念(但光概念就有一大堆艱深知識了…XD…推薦這個系列文，把許多概念知識都整理的很清楚: 30天之即時網路影音開發攻略(小白本))

本系列文主要介紹的重點會放在開源串流伺服器SRS的架設與影片品質調校上(以及相關必要知識)的介紹。

一般來說，一個影片的直播流程要經過以下環節:
採集影像 —> 影像處理 —> 編碼 —> 封裝 —> 推流 —> 串流伺服器 —> 拉流 —> 解封裝 —> 解碼 —> 播放
各個環節都有相關的技術或現成可使用的軟體，如下圖為以SRS伺服器的流程為例：

其中，上述的事情發生在三個端點: 直播主的電腦、串流伺服器、觀眾的電腦，各個事件發生的地點如下圖:

1. 採集: 從系統的採集設備中獲取原始音視頻數據，將其輸出到下一個環節。一個影片的採集涉及兩方面數據的採集：音頻採集和影像採集，它們分別對應兩種完全不同的輸入源和數據格式。

2. 編碼與封裝: 對於視訊資料而言，視訊編碼的最主要目的是資料壓縮。因為動態影像的畫素形式，資料量極為巨大，儲存空間和傳輸頻寬完全無法滿足儲存和傳輸的需求。舉例來說，若影像的每個畫素的三個顏色RGB各需要一個位元組儲存，每一個畫素需要3位元組，解析度1280×720的影像的大小為2.76M位元組，若每秒FPS為25偵，所需的位元率會達到553Mb/s。這樣的資料量無論是儲存或傳輸都不可能，因此編碼非常重要，編碼性能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的用戶體驗和傳輸成本。這一部份之後會有各別的文章去介紹。

視訊資訊之所以存在大量可以被壓縮的空間，是因為其中本身就存在大量的資料冗餘。其主要型別有：

1. 時間冗餘：視訊相鄰的兩幀之間內容相似，存在運動關係
2. 空間冗餘：視訊的某一幀內部的相鄰畫素存在相似性
3. 編碼冗餘：視訊中不同資料出現的概率不同
4. 視覺冗餘：觀眾的視覺系統對視訊中不同的部分敏感度不同
   來源: https://www.itread01.com/content/1547220622.html

3. 推流： 推流是影響整個直播串流能不能順暢播放的最根本因素，若是步驟2的影片編碼的編碼器效能不好、網路速度不夠，或者編碼的壓縮品質不佳，那麼後面的串流服務再怎麼好，使用者的影片觀看體驗和順暢度也不會好。因此步驟2的編碼，會連帶影響到步驟3的推流的順暢度。因此，像一些推流軟體如OBS，會自動偵測直播主的電腦配備和網路頻寬，去選擇適合的影片壓縮位元率（影響影片的品質）、編碼格式（VP9、MPEG或H.264）、編碼工具(如Quick Sync H.264或x264），以及設定適合的buffer，來達到讓推流能夠順暢的目的。
   現有推流最廣泛被使用的通訊協定為RTMP(Real Time Messaging Protocol)，大部份的推流軟體都使用這個協定去做推流。
   
   圖片: FME推流介面

4. 串流伺服器: 主要的工作為接收推流、轉發給拉流客戶端。現在的直播服務由於需要支援行動設備，隨著flash從網頁裡被淘汰，網頁端多已不能支持rtmp流協定的播放。但因推流的協定仍多為RTMP，因此大多需要經過轉碼的動作，轉為HLS或HTTP-FLV的格式，以支援行動端的播放。這部份伺服器的轉碼工作也會影響到直播的延遲時間。
   所謂『延遲』(latency)就是從直播端到播放端的時間差，造成延遲的原因有很多，因使用網路傳輸，影像串流需要經過編解碼並即時於使用者端播放。考量到網路狀況可能不穩定，又需顧及影片播放的順暢性，客戶端播放器的緩衝設定以及其解碼的速度，也是造成延遲的一大主因。不同傳輸方式其搭配的容器格式亦會影響到延遲的時間，一般來說RTMP的延遲時間約為0.3-1秒間，HTTP-FLV約1-3秒，而HLS則需要至少10秒以上的延遲(以最佳狀況來說)。
   目前市面上較受歡迎的串流伺服器有:
   *FMS: FMS是adobe的流媒體服務器，RTMP協議就是adobe提出來的，FMS一定是重量級的產品。
   *WOWZA: 由Wowza Media Systems開發的串流媒體服務器軟體
   *SRS: 本系列文主要探討的串流伺服器，產品定位是商用互動式社群直播伺服器叢集，支持K8S。
   *NGINX RTMP: 現在非常火紅並且被廣泛使用的開源伺服器
   *CRTMPD: 使用單線程異步socket，在當時處於領先水平，但是當NGINX出現後就漸漸淡出大眾視野了

5. 拉流: 拉流是指伺服器已有直播內容，根據協議類型（如RTMP、RTP、RTSP、HTTP等），與伺服器建立連接並接收數據，進行拉取的過程。因為RTMP的協定較容易被防火牆檔掉，因此主要移動端的播放都採用HTTP的網路協定去做拉流，包括常見的HTTP-FLV與HLS。

6. 解碼與播放: 其實所有的串流都會包括音視頻兩個部份，在解碼時會分別解碼音頻和視頻，並且將兩個搭配起來。在這邊播放會遇到的挑戰，很重要的部份就是buffer的設製，buffer會影響到三個點:『首屏』、『延遲』、『卡頓』。首屏指的是點擊畫面後到第一個畫面出來的時間、延遲是指與直播端的時間差、而卡頓則是影片播放時畫面不順暢的次數或時間。一般來說，若觀看端的buffer時間較長，從點擊到看到第一個畫面的時間也會較長、總延遲時間也會變長，但可以在網路狀況較不穩定下仍能維持一定的播放品質。另外若buffer設定的過短，機器的解碼的速度在電腦lag時短暫趕不上，就有可能會出現跳屏的狀況(ex: 從1秒直接跳到3秒)，因此這部份也需要經過仔細的調校和設定。

各種傳輸協定比較表

一般來說，在架設串流伺服器時，應考量用途和需求，去決定要使用那一種直播協議，每一種格式都有其優缺點，這邊有相關的比較文章:RTMP、HTTP-FLV、HLS，你了解常見的三大直播協議嗎

參考資料

• 直播理论
• 直播系統搭建所用到的技術原理
• 技術人員看過來！詳細的直播原理介紹！
• CDN直播系统的优化
• 網絡視頻直播的原理是什麼？
• 录播、点播、直播傻傻分不清楚？1篇文章帮你搞定