關於視頻流媒體服務器的學習記錄

關於視頻流媒體服務器的學習記錄

前言

​ 由於有時候做的小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 機器各主流系統上部署，操作簡單

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二次開發的流媒體服務器，有中文支持網站。

具體實現

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

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

相關技術內容了解

一、基於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+、多進程、轉推、回源以及集群化部署方面的技術實現細節。

文章鏈接：//cloud.tencent.com/developer/article/1609679?from=article.detail.1182120

最後

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

Tags:

VirMach 便宜 VPS

QNews

QNews