關於視訊流媒體伺服器的學習記錄

關於視訊流媒體伺服器的學習記錄

前言

​ 由於有時候做的小demo裡面會有視訊功能的實現，而且基本是藉助阿里雲和七牛雲等等這種第三方平臺來實現和管理視訊功能，但是隻知道用第三方平臺是遠遠不夠的。畢竟也是計算機行業的一員，雖然比較菜，但正因為菜才要去不斷的學習。

​ 那今天就稍微對這方面的點做一個總結記錄，文章中大部分是網上我所找到的內容。其次，這些觀點以及解釋肯定有不完善的地方，所以還請一些大佬看到後可以及時指正，畢竟我是初學者，非常感謝！

---

關於兩者的區別

網上普遍的回答

流媒體伺服器

流媒體是指以流的方式在網路中傳送音訊、視訊和多媒體檔案的媒體形式。

而相對於以前由於網速問題，下載後觀看的網路播放形式而言，流媒體的典型特徵是把連續的音訊和視訊資訊壓縮後放到網路伺服器上，使用者邊下載邊觀看，而不必等待整個檔案下載完畢。

由於流媒體技術的優越性，該技術廣泛應用於視訊點播、視訊會議、遠端教育、遠端醫療和線上直播系統中。流媒體伺服器是流媒體系統的核心組成，是向使用者提供視訊服務的關鍵平臺。

其主要功能是連線端到端，對媒體內容進行採集、推流、轉碼、傳輸和分發，流媒體應用系統的主要效能體現都取決於媒體伺服器的配置和部署

視訊伺服器

視訊伺服器是對視音訊資料進行壓縮、儲存及處理的專用嵌入式裝置.

視訊伺服器採用MPEG4或MPEG2等壓縮格式，在符合技術指標的情況下對視訊資料進行壓縮編碼，以滿足儲存和傳輸的要求。

視訊伺服器可以對視音訊資料進行壓縮、儲存及處理，以滿足儲存和傳輸的要求，它在遠端監控及視訊等方面都有廣泛的應用。

主要是對音視訊的編解碼處理，所以很多視訊伺服器產品也叫做視訊編解碼器

---

關於需要了解的相關問題

一、流式傳輸

是連續傳送視/音訊訊號，當流媒體在客戶機播放時其餘部分在後臺繼續下載。

二、流式傳輸分類

有順序流式傳輸(Progressive Streaming)和實時流式傳輸(Realtime Streaming)兩種方式。實時流式傳輸是實時傳送，特別適合現場事件，實時流式傳輸必須匹配連線頻寬，這意味著影像質量會因網路速度降低而變差,以 減少對傳輸頻寬的需求。“實時”的概念是指在一個應用中資料的交付必須與資料的產生保持精確的時間關係

三、軟體

​ 播放器（Player），用來播放流媒體的軟體。

　　伺服器（Server），用來向使用者傳送流媒體的軟體。

　　編碼器（Encode），用來將原始的音訊視訊轉化為流媒體格式的軟體

四、協議

既然有了視訊這種流資料在網路上的傳輸，那就必定有網路協議去規範它

• RTP（Realtime Transport Protocol）實時傳輸協議：是針對Internet上多媒體資料流的一個傳輸協議, 由IETF(Internet工程任務組)作為RFC1889釋出。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間資訊和實現流同 步。RTP的典型應用建立在UDP上，但也可以在TCP或ATM等其他協議之上工作。RTP本身只保證實時資料的傳輸，並不能為按順序傳送資料包提供可靠 的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。
• RTCP（Realtime Transport Control Protocol）實時傳輸控制協議：是實時傳輸協議（RTP）的一個姐妹協議，負責管理傳輸質量在當前應用程式之間交換控制資訊。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已傳送的資料包的數 量、丟失的資料包的數量等統計資料，因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷型別。RTP和RTCP配合使用，能以有效的反饋 和最小的開銷使傳輸效率最佳化，故特別適合傳送網上的實時資料。
• RTSP（Real Time Streaming Protocol）實時流協議：專為娛樂和通訊系統的使用，以控制流媒體伺服器。該協議用於建立和控制終端之間的媒體會話。媒體伺服器的客戶端釋出VCR命令，例如播放，錄製和暫停，以便於實時控制從伺服器到客戶端（視訊點播）或從客戶端到伺服器（語音錄音）的媒體流。流資料本身的傳輸不是RTSP的任務。大多數RTSP伺服器使用實時傳輸協議（RTP）和實時傳輸控制協議（RTCP）結合媒體流傳輸
• RTMP是Real Time Messaging Protocol（實時訊息傳輸協議）：是最初由Macromedia為通過網際網路在Flash播放器與一個伺服器之間傳輸流媒體音訊、視訊和資料而開發的一個專有協議。
  • 預設使用TCP埠1935的純粹（plain）協議。
  • RTMPS，通過一個TLS/SSL連線傳輸RTMP。
  • RTMPE，使用Adobe自有安全機制加密的RTMP。雖然實現的細節為專有，但該機制使用行業標準的密碼學原函式。
  • RTMPT，用HTTP封裝以穿透防火牆。RTMPT通常在TCP埠80和443上使用明文請求來繞過大多數的公司流量過濾。封裝的會話中可能攜帶純粹的RTMP、RTMPS或RTMPE資料包。
  • RTMFP, 使用UDP而非TCP的RTMP，取代RTMP Chunk Stream。Adobe Systems開發了安全的實時媒體流協議包，可以讓終端使用者直接地相互連線（P2P）。雖然RTMP的主要動機是成為一個播放Flash視訊的協議，但它也用於其他一些應用程式，如Adobe LiveCycle Data Services ES
• HLS （Http Live Strea m ing）是由Apple公司定義的用於實時流傳輸的協議，它的工作原理是把整個流分成一個個小的基於HTTP的檔案來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的資料速率。在開始一個流媒體會話時，客戶端會下載一個包含後設資料的擴充套件 M3U (m3u8) 播放列表檔案，用於尋找可用的媒體流。HLS只請求基本的HTTP報文，與實時傳輸協議（RTP）不同，HLS可以穿過任何允許HTTP資料通過的防火牆或者代理伺服器。它也很容易使用內容分發網路來傳輸媒體流

---

如何實現

一種是直接使用第三方的流媒體伺服器，另一種就是自己直接搭建一個這樣的伺服器

---

相關實現技術

SRS（Simple RTMP Server）：SRS定位是運營級的網際網路直播伺服器叢集，追求更好的概念完整性和最簡單實現的程式碼。SRS提供了豐富的接入方案將RTMP流接入SRS，包括推送RTMP到SRS、推送RTSP/UDP/FLV到SRS、拉取流到SRS。SRS還支援將接入的RTMP流進行各種變換，譬如將RTMP流轉碼、流截圖、轉發給其他伺服器、轉封裝成HTTP-FLV流、轉封裝成HLS、轉封裝成HDS、錄製成FLV。SRS包含支大規模叢集如CDN業務的關鍵特性，譬如RTMP多級叢集、源站叢集、VHOST虛擬伺服器、無中斷服務Reload、HTTP-FLV叢集、Kafka對接。此外，SRS還提供豐富的應用介面，包括HTTP回撥、安全策略Security、HTTP API介面、RTMP測速。

SRS在源站和CDN叢集中都得到了廣泛的應用Applications是國產優秀流媒體伺服器，在Github上開源， 可在 Linux 機器各主流系統上部署，操作簡單

• 相關官網內容：
  • 介紹：https://github.com/ossrs/srs/wiki/v3_CN_Home
  • demo部署：https://github.com/ossrs/srs/wiki/v1_CN_SampleDemo

WebRTC：名稱源自網頁即時通訊（英語：Web Real-Time Communication）的縮寫，是一個支援網頁瀏覽器進行實時語音對話或視訊對話的API。

FFmpeg：是一個開放原始碼的自由軟體，可以執行音訊和視訊多種格式的錄影、轉換、流功能[1]，包含了libavcodec——這是一個用於多個專案中音訊和視訊的解碼器庫，以及libavformat——一個音訊與視訊格式轉換庫。

RED5：Red5是一個採用Java開發開源的Flash流媒體伺服器。它支援：把音訊（MP3）和視訊（FLV）轉換成播放流； 錄製客戶端播放流（只支援FLV）；共享物件；現場直播流釋出；遠端呼叫。Red5使用RSTP作為流媒體傳輸協議，在其自帶的一些示例中演示了線上錄製，flash流媒體播放，線上聊天，視訊會議等一些基本功能。
開源地址：

Darwin Streaming Server：為蘋果公司視訊流解決方案的開源版本。

easyDarwin：國內基於Darwin Streaming Server二次開發的流媒體伺服器，有中文支援網站。

---

具體實現

以下完全沒有打廣告的嫌疑，純屬個人瀏覽到的文章。

• 目標用於搭建內網流媒體伺服器支援視訊的點播：[https://www.cnblogs.com/shenfeng/p/nginx_rtmp_streaming_server.html]

• Nginx流媒體伺服器搭建:[https://cloud.tencent.com/developer/article/1763519?from=article.detail.1609679]

• CentOS7下搭建Jellyfin個人流媒體伺服器：【https://cloud.tencent.com/developer/article/1695210?from=article.detail.1763519】

• 一個關於做這方面技術的博主【https://www.cnblogs.com/EasyNVR/】

• 【Nginx】如何使用Nginx搭建流媒體伺服器實現直播？

• 搭建一個點播跟直播流媒體伺服器玩玩 (juejin.cn)

我個人是並沒有去具體實現，所以尚未對分享的文章可靠性做具體預估，但個人覺得應該不會存在很大的問題，而且網上一搜基本是這幾種方式。

相關技術內容瞭解

一、基於HTTP方式的FLV直播

​ 近幾年直播行業火爆，開源的直播軟體解決方案有SRS（Simple-RTMP-Server）和nginx-rtmp-module，前者是國人發起的一個優秀的開源專案，目前國內很多公司都使用它作為直播解決方案，由C++編寫；後者依賴Nginx，以第三方模組的方式提供直播功能，由C編寫。SRS採用多執行緒方式，效能優秀，經受住了眾多場景的考驗，但是SRS3已經閉源（更正：是有一段時間閉源了，現在又開源了）；nginx-rtmp-module是採用多程式方式，Nginx的效能優秀，但是據網友測試，nginx-rtmp-module的效能不如SRS，並且nginx-rtmp-module的作者已經很久沒有更新版本了，支援的功能也有限，例如不支援HTTP方式的FLV直播，而這是國內直播行業普遍採用的方式；再如推流不支援upstream，無法分散式部署功能；還有飽受詬病的播放響應延遲時間很長的問題（即俗稱的不能秒播）等。

​ 我在nginx-rtmp-module的基礎上實現了基於HTTP方式的FLV直播功能，支援GOP快取，減少播放響應延遲時間；支援流式和Transfer-Encoding: chunked兩種HTTP響應格式；修復nginx-rtmp-module沒有listen配置項時，推流失敗的問題；解決nginx-rtmp-module已知的bug，見nginx-http-flv-module，歡迎下載測試和修復bug。有問題或者建議，可以加Q群：711969608詳聊。目前已經有廠商準備將本模組商用，目前已知有6家，其中一家是華為，目前都還在測試中，有廠商陸續反饋過不少bug，修復後功能已經越來越穩定，在此表示感謝。目前還存在的問題是高併發情況下，群斷連線會造成Nginx崩潰和無規律的CPU使用率暴增，最近加班比較多，來不及修復這些問題，後續會不定時更新github。

二、基於Nginx的媒體伺服器技術

國內應用比較多的開源流媒體伺服器nginx-rtmp-module一直存在功能少、叢集化難度大等問題。在LiveVideoStack線上分享中，PingOS 開源專案組開發工程師、UCloud RTC研發工程師朱建平詳細介紹了基於nginx-rtmp-module的PingOS流媒體伺服器在http-flv、http-ts、hls+、多程式、轉推、回源以及叢集化部署方面的技術實現細節。

文章連結：https://cloud.tencent.com/developer/article/1609679?from=article.detail.1182120

最後

​ 這是一次簡單的技術內容瞭解，希望以後可以更進一步去看到更加準確，更加優秀，更加方便的技術，也希望自己可以在閒餘時間嘗試一些關於這方面技術的實現。