這篇文章主要向大家介紹流媒體(視頻)服務器調研,主要內容包括基礎應用、實用技巧、原理機制等方面，希望對大家有所幫助。

標簽：javascriptphphtmljavapythonlinuxandroidnginxc++git

流媒體服務器調研

前言：因為要作一些視頻服務器相關的內容，因此先對此部分進行調研javascript

注：主要內容來源于相關博客，參考文章和來源均已經說明php

摘要：該部分主要涉及流媒體協議、流媒體服務器對比html

目錄java

流媒體服務器調研python

常見的流媒體協議linux

RTPandroid

RTCPnginx

SRTP & SRTCPc++

RTSPgit

RTSP 和RTP的關系

SDP

RTMP/RTMPS

mms

HLS

http-flv?

API- -? webRTC

主流的流媒體服務器

38款流媒體服務器開源軟件

red5

EasyDarwin

nginx-rtmp-module（nginx-http-flv-module)

simple-rtmp-server

live555

CRTMPD

FMS

WOWZA

AMS

monibuca

總結分析

---

常見的流媒體協議

此部分原文連接：參考文章

RTP

? ? ? ? ? 參考文檔??RFC3550/RFC3551

? ? ? ? ?Real-time Transport Protocol)是用于Internet上針對多媒體數據流的一種傳輸層協議。RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議經常使用于流媒體系統（配合RTCP協議），視頻會議和一鍵通（Push to Talk）系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一塊兒使用，并且它是創建在UDP協議上的。?

? ? ? ? ?RTP 自己并無提供按時發送機制或其它服務質量（QoS）保證，它依賴于低層服務去實現這一過程。 RTP 并不保證傳送或防止無序傳送，也不肯定底層網絡的可靠性。 RTP 實行有序傳送， RTP 中的序列號容許接收方重組發送方的包序列，同時序列號也能用于決定適當的包位置，例如：在視頻解碼中，就不須要順序解碼。

? ? ? RTP 由兩個緊密連接部分組成： RTP ― 傳送具備實時屬性的數據；RTP 控制協議（RTCP） ― 監控服務質量并傳送正在進行的會話參與者的相關信息。

RTCP

? ? ? ? 實時傳輸控制協議（Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）是實時傳輸協議（RTP）的一個姐妹協議。RTCP為RTP媒體流提供信道外（out-of-band）控制。RTCP自己并不傳輸數據，但和RTP一塊兒協做將多媒體數據打包和發送。RTCP按期在流多媒體會話參加者之間傳輸控制數據。RTCP的主要功能是為RTP所提供的服務質量（Quality of Service）提供反饋。
? ? ? ? RTCP收集相關媒體鏈接的統計信息，例如：傳輸字節數，傳輸分組數，丟失分組數，jitter，單向和雙向網絡延遲等等。網絡應用程序能夠利用RTCP所提供的信息試圖提升服務質量，好比限制信息流量或改用壓縮比較小的編解碼器。RTCP自己不提供數據加密或身份認證。SRTCP能夠用于此類用途。

SRTP & SRTCP

? ? ? ? 參考文檔?RFC3711

? ? ? ? 安全實時傳輸協議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協議（Real-time Transport Protocol或RTP）基礎上所定義的一個協議，旨在為單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發的，并最先由IETF于2004年3月做為RFC3711發布。
? ? ? ? 因為實時傳輸協議和能夠被用來控制實時傳輸協議的會話的實時傳輸控制協議（RTP Control Protocol或RTCP）有著緊密的聯系，安全實時傳輸協議一樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（Secure RTCP或SRTCP）；安全實時傳輸控制協議為實時傳輸控制協議提供相似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些同樣。
? ? ? ? 在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；但即便使用了安全實時傳輸協議或安全實時傳輸控制協議，全部它們提供的特性（如加密和認證）也都是可選的，這些特性能夠被獨立地使用或禁用。惟一的例外是在使用安全實時傳輸控制協議時，必需要用到其消息認證特性。

RTSP

? ? ? ?參考文檔?RFC2326

? ? ? ??是由Real Networks和Netscape共同提出的。該協議定義了一對多應用程序如何有效地經過IP網絡傳送多媒體數據。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成為可能。數據源包括現場數據與存儲在剪輯中的數據。該協議目的在于控制多個數據發送鏈接，為選擇發送通道，如UDP、多播UDP與TCP提供途徑，并為選擇基于RTP上發送機制提供方法。

? ? ? ? RTSP（Real Time Streaming Protocol）是用來控制聲音或影像的多媒體串流協議，并容許同時多個串流需求控制，傳輸時所用的網絡通信協定并不在其定義的范圍內，服務器端能夠自行選擇使用TCP或UDP來傳送串流內容，它的語法和運做跟HTTP 1.1相似，但并不特別強調時間同步，因此比較能容忍網絡延遲。而前面提到的容許同時多個串流需求控制（Multicast），除了能夠下降服務器端的網絡用量，更進而支持多方視訊會議（Video Conference）。 由于與HTTP1.1的運做方式類似，因此代理服務器《Proxy》的快取功能《Cache》也一樣適用于RTSP，并因RTSP具備從新導向功能，可視實際負載狀況來轉換提供服務的服務器，以免過大的負載集中于同一服務器而形成延遲。

RTSP 和RTP的關系

? ? ? ?RTP不象http和ftp可完整的下載整個影視文件，它是以固定的數據率在網絡上發送數據，客戶端也是按照這種速度觀看影視文件，當影視畫面播放事后，就不能夠再重復播放，除非從新向服務器端要求數據。

? ? ? RTSP與RTP最大的區別在于：RTSP是一種雙向實時數據傳輸協議，它容許客戶端向服務器端發送請求，如回放、快進、倒退等操做。固然，RTSP可基于RTP來傳送數據，還能夠選擇TCP、UDP、組播UDP等通道來發送數據，具備很好的擴展性。它時一種相似與http協議的網絡應用層協議。目前碰到的一個應用：服務器端實時采集、編碼并發送兩路視頻，客戶端接收并顯示兩路視頻。因為客戶端沒必要對視頻數據作任何回放、倒退等操做，可直接采用UDP+RTP+組播實現。

RTP：實時傳輸協議（Real-time Transport Protocol）?
RTP/RTCP是實際傳輸數據的協議?
RTP傳輸音頻/視頻數據，若是是PLAY，Server發送到Client端，若是是RECORD，能夠由Client發送到Server?
整個RTP協議由兩個密切相關的部分組成：RTP數據協議和RTP控制協議（即RTCP）?
RTSP：實時流協議（Real Time Streaming Protocol，RTSP）?
RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義能夠知道起對話和控制做用?
RTSP的對話過程當中SETUP能夠肯定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN能夠開始或者中止RTP的發送，等等?
RTCP：?
RTP/RTCP是實際傳輸數據的協議?
RTCP包括Sender Report和Receiver Report，用來進行音頻/視頻的同步以及其余用途，是一種控制協議

SDP

? ? ? ? 會話描述協議（SDP）為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。
? ? ? ?會話目錄用于協助多媒體會議的通告，并為會話參與者傳送相關設置信息。SDP 即用于將這種信息傳輸到接收端。SDP 徹底是一種會話描述格式 ― 它不屬于傳輸協議 ― 它只使用不一樣的適當的傳輸協議，包括會話通知協議（SAP）、會話初始協議（SIP）、實時流協議（RTSP）、MIME 擴展協議的電子郵件以及超文本傳輸協議（HTTP）。

? ? ? ? SDP 的設計宗旨是通用性，它能夠應用于大范圍的網絡環境和應用程序，而不只僅局限于組播會話目錄，但 SDP 不支持會話內容或媒體編碼的協商。
? ? ? ? 在因特網組播骨干網（Mbone）中，會話目錄工具被用于通告多媒體會議，并為參與者傳送會議地址和參與者所需的會議特定工具信息，這由 SDP 完成。SDP 鏈接好會話后，傳送足夠的信息給會話參與者。SDP 信息發送利用了會話通知協議（SAP），它周期性地組播通知數據包到已知組播地址和端口處。這些信息是 UDP 數據包，其中包含 SAP 協議頭和文本有效載荷（text payload）。這里文本有效載荷指的是 SDP 會話描述。此外信息也能夠經過電子郵件或 WWW （World Wide Web） 進行發送。

SDP 文本信息包括：

會話名稱和意圖；

會話持續時間；

構成會話的媒體；

有關接收媒體的信息（地址等）。

協議結構

SDP 信息是文本信息，采用 UTF-8 編 碼中的 ISO 10646 字符集。SDP 會話描述以下：（標注 * 符號的表示可選字段）：
v = （協議版本）
o = （全部者/建立者和會話標識符）
s = （會話名稱）
i = * （會話信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號碼）
c = * （鏈接信息 ― 若是包含在全部媒體中，則不須要該字段）
b = * （帶寬信息）

一個或更多時間描述（以下所示）：
z = * （時間區域調整）
k = * （加密密鑰）
a = * （0 個或多個會話屬性行）
0個或多個媒體描述（以下所示）

時間描述
t = （會話活動時間）
r = * （0或屢次重復次數）

媒體描述
m = （媒體名稱和傳輸地址）
i = * （媒體標題）
c = * （鏈接信息 — 若是包含在會話層則該字段可選）
b = * （帶寬信息）
k = * （加密密鑰）

a = * （0 個或多個會話屬性行）

RTMP/RTMPS

RTMP(Real Time Messaging Protocol)實時消息傳送協議是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議。
它有三種變種：

1)工做在TCP之上的明文協議，使用端口1935；

2)RTMPT封裝在HTTP請求之中，可穿越防火墻；

3)RTMPS相似RTMPT，但使用的是HTTPS鏈接；

? ? ? RTMP協議(Real Time Messaging Protocol)是被Flash用于對象,視頻,音頻的傳輸.這個協議創建在TCP協議或者輪詢HTTP協議之上.

? ? ? RTMP協議就像一個用來裝數據包的容器,這些數據既能夠是AMF格式的數據,也能夠是FLV中的視/音頻數據.一個單一的鏈接能夠經過不一樣的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸的.

mms

? ? ? ? MMS (Microsoft Media Server Protocol)，中文“微軟媒體服務器協議”，用來訪問并流式接收 Windows Media 服務器中 .asf 文件的一種協議。MMS 協議用于訪問 Windows Media 發布點上的單播內容。MMS 是鏈接 Windows Media 單播服務的默認方法。若觀眾在 Windows Media Player 中鍵入一個 URL 以鏈接內容，而不是經過超級連接訪問內容，則他們必須使用MMS 協議引用該流。MMS的預設埠（端口）是1755

? ? ? ??當使用 MMS 協議鏈接到發布點時，使用協議翻轉以得到最佳鏈接。“協議翻轉”始于試圖經過 MMSU 鏈接客戶端。 MMSU 是 MMS 協議結合 UDP 數據傳送。若是 MMSU 鏈接不成功，則服務器試圖使用 MMST。MMST 是 MMS 協議結合 TCP 數據傳送。
若是鏈接到編入索引的 .asf 文件，想要快進、后退、暫停、開始和中止流，則必須使用 MMS。不能用 UNC 路徑快進或后退。若您從獨立的 Windows Media Player 鏈接到發布點，則必須指定單播內容的 URL。若內容在主發布點點播發布，則 URL 由服務器名和 .asf 文件名組成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務器名，sample.asf 是您想要使之轉化為流的 .asf 文件名。
若您有實時內容要經過廣播單播發布，則該 URL 由服務器名和發布點別名組成。例如：mms://windows_media_server/LiveEvents。這里 windows_media_server 是 Windows Media 服務器名，而 LiveEvents 是發布點名

HLS

? ? ? HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基于HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用在iOS系統，為iOS設備（如iPhone、iPad）提供音視頻直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不一樣在于，它的分段很是小。

? ? ? ?相對于常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不一樣在于，直播客戶端獲取到的，并非一個完整的數據流。HLS協議在服務器端將直播數據流存儲為連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件，由于服務器端老是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。因而可知，基本上能夠認為，HLS是以點播的技術方式來實現直播。因為數據經過HTTP協議傳輸，因此徹底不用考慮防火墻或者代理的問題，并且分段文件的時長很短，客戶端能夠很快的選擇和切換碼率，以適應不一樣帶寬條件下的播放。不過HLS的這種技術特色，決定了它的延遲通常老是會高于普通的流媒體直播協議。　

? ? ?根據以上的了解要實現HTTP Live Streaming直播，須要研究并實現如下技術關鍵點

采集視頻源和音頻源的數據

對原始數據進行H264編碼和AAC編碼

視頻和音頻數據封裝為MPEG-TS包

HLS分段生成策略及m3u8索引文件

HTTP傳輸協議

http-flv?

此部分原文連接：參考文章

"HttpFlv的出現最先是2008年，從它的協議自己咱們能看到Adobe的影子，就是flv協議自己。也能夠說，httpflv是爭奪與放棄之間妥協的產物。人們不再愿意看到Adobe，但又不得不面對海量Flv歷史文檔。在仇恨與無奈的交織中，httpflv誕生了。

HttpFlv 就是 http+flv ，將音視頻數據封裝成FLV格式，而后經過 HTTP 協議傳輸給客戶端。理解HttpFlv協議，這就話就是關鍵。

但聰明地你立刻就會發現，雖然傳輸協議變了，但在flv數據格式下，脫離FlashPlayer仍是無稽之談。但在2016年，這一切都發生了改變，由于flv.js問世了！

Bilibili，也就是傳說中的B站，不只貢獻了彈幕，為咱們提供了另外一種觀影交互體驗。更重要的，Flv.js的誕生，讓咱們在視頻播放領域完全告別Adobe時代。一個全新、干凈的HTML5就這樣向咱們走來了。"

API- -? webRTC

這個并不是是流媒體協議，可是暫時放在此部分進行說明。

此部分原文連接：參考網址

“WebRTC，名稱源自網頁即時通訊（英語：Web Real-Time Communication）的縮寫，是一個支持網頁瀏覽器進行實時語音對話或視頻對話的API。它于2011年6月1日開源并在Google、Mozilla、Opera支持下被歸入萬維網聯盟的W3C推薦標準。

WebRTC實現了基于網頁的視頻會議，標準是WHATWG 協議，目的是經過瀏覽器提供簡單的javascript就能夠達到實時通信（Real-Time Communications (RTC)）能力。

WebRTC（Web Real-Time Communication）項目的最終目的主要是讓Web開發者可以基于瀏覽器（Chrome\FireFox\...）輕易快捷開發出豐富的實時多媒體應用，而無需下載安裝任何插件，Web開發者也無需關注多媒體的數字信號處理過程，只需編寫簡單的Javascript程序便可實現，W3C等組織正在制定Javascript 標準API，目前是WebRTC 1.0版本，Draft狀態；另外WebRTC還但愿可以創建一個多互聯網瀏覽器間健壯的實時通訊的平臺，造成開發者與瀏覽器廠商良好的生態環境。同時，Google也但愿和致力于讓WebRTC的技術成為HTML5標準之一，可見Google布局之深遠。

WebRTC提供了視頻會議的核心技術，包括音視頻的采集、編解碼、網絡傳輸、顯示等功能，而且還支持跨平臺：windows，linux，mac，android。”

主流的流媒體服務器

38款流媒體服務器開源軟件

此部分參考連接：參考文章1、參考文章2

?

• ！！！Flash流媒體服務器?Red5

  Red5是一個采用Java開發開源的Flash流媒體服務器。它支持：把音頻（MP3）和視頻（FLV）轉換成播放流； 錄制客戶端播放流（只支持FLV）；共享對象；現場直播流發布；遠程調用。Red5使用RSTP做為流媒體傳輸協議，在其自帶的一些示例中演示了在線錄制，flash... 更多Red5信息

  最近更新：?Red5 1.0.1 Final 發布，Flash流媒體服務器?發布于 12個月前

• 流媒體服務器?Open Streaming Server

  Open Streaming Server (Catra Streaming Platform) 是一個數字媒體傳送器，主要功能包括支持 mp四、3gp、WMF和qt文件格式；動態帶寬適配；負載均衡、內容分發技術。基于 C++、Java 和 CORBA 技術開發...? 更多Open Streaming Server信息

• ！！！流媒體解決方案?live555

  Live555 是一個為流媒體提供解決方案的跨平臺的C++開源項目，它實現了對標準流媒體傳輸協議如RTP/RTCP、RTSP、SIP等的支持。Live555實現了對多種音視頻編碼格式的音視頻數據的流化、接收和處理等支持，包括MPEG、H.263+、DV、JPEG視頻和多種音頻編碼。同時...? 更多live555信息

• ！！！Darwin Streaming Server

  Darwin Streaming Server 使用開放標準，讓你能夠透過互聯網實時傳送實況或預先錄制的內容。在 Instant-On——蘋果電腦公司正在申請專利的一項創新流媒體播送技術的支持下，你的內容將在點擊連接的同時開始播放，無需等待文件下載。...? 更多Darwin Streaming Server信息

• 【商業】流媒體服務器軟件?Helix Server

  Helix Server是由著名的流媒體技術服務商Real Networks公司提供的一種流媒體服務器軟件，利用它能夠在 網上提供Real Video和MMS格式文件的流媒體播放服務，配上相應設備后，還具備現場直播的功能。下面介紹一下有關Helix服務器的獲取、安裝、運行管理和使用...? 更多Helix Server信息

• 開源流媒體平臺?FreeCast

  FreeCast 是一個P2P的流媒體開源平臺,使用Java語言編寫。 更多FreeCast信息

• MPEG4IP

  MPEG4IP提供一個端對端的系統來實現音視頻流的傳輸，支持包括MPEG4/H.261/MPEG2/H.263 MP3/AAC/AMR等不一樣編碼格式。 更多MPEG4IP信息

• 開源流媒體平臺?Stream-2-Stream

  Stream-2-Stream 是一個用?Java?語言實現的 Multicast+ 下一代流媒體傳輸協議。與傳統的流媒體技術相比較，Multicast+ 具備更高效的傳輸效率和更少的帶寬占用。 主要特色： Integrated MP3, Ogg media player. No external media player needed to listen!...? 更多Stream-2-Stream信息

• 流媒體服務器?Yass

  Yass是一個基于Web的流媒體服務器(streaming server)，擁有一個相似于iTunes的界面。它可以共享你的MP3音樂庫，并經過Internet訪問。Yass利用JPA（openJpa）操 做數據，Spring控制事務。利用Apache Derby來存儲數據。經過JAX-RS與JAXB（Jersey）實現客戶端...? 更多Yass信息

• 流媒體服務器?Flumotion

  Flumotion 是一個前衛的(modern)的流媒體服務器，采用模塊化分布式的設計理念，提供您穩定及高質量的流媒體服務. Flumotion 支持 Ogg/Theora也支持 MPEG-4 等格式，使用者沒必要一次下載全部的文件就能在線觀看媒體播放的結果。 Flumotion 提供了一個基于 Ja...?更多Flumotion信息

• Java實現的RTMP?Flazr

  Flazr 是一個實現了 RTMP 流媒體傳輸協議的 Java 類庫，該項目包含一個流媒體服務器和相關的工具。 ?更多Flazr信息

• 【商業】流媒體服務器?xmoovStream

  xmoovStream是一個采用PHP開發的開源流媒體服務器，可以將視頻、圖片、音頻轉成能夠在網頁上播放的流媒體。這個服務器還自帶輕量級視頻播放 器和音頻播放器。 ?更多xmoovStream信息

• ！！！NGINX的流媒體插件?nginx-rtmp-module

  戰斗民族俄羅斯人民開發的一款NGINX的流媒體插件，除了直播發布音視頻流以外具有流媒體服務器的常見功能 好比推拉流媒體資源、 基于HTTP的FLV/MP4?VOD點播、?HLS?(HTTP Live Streaming)?M3U8的支持 、基于http的操做（發布、播放、錄制）、 能夠很好的協同現有的流...? 更多nginx-rtmp-module信息

• icecast

  icecast 是一套開放源碼?(Open Source) 的流媒體服務器軟件 (Streaming Server), 支持?MP3?與?Ogg Vorbis?流格式, 串流資料則由其余支援 icecast 的 Source Clients (或稱 Streamer) 提供. 例如: ices 將電腦中的 MP3 檔案轉成串流資料 darkice 將音效卡的...? 更多icecast信息

• RTMP流媒體服務器?crtmpserver

  crtmpserver又稱rtmpd是Evostream Media Server（www.evostream.com）的社區版本采用GPLV3受權 其主要做用為一個高性能的RTMP流媒體服務器，能夠實現直播與點播功能多終端支持功能，在特定狀況下是FMS的良好替代品。 支持RTMP的一堆協議（RTMP,RTMPE, RTM...?更多crtmpserver信息

• Free UPnP Entertainment Service

  這是一個開源的多平臺通用的即插即用的 音頻、視頻的媒體服務器，支持在線對 ogg/vorbis,musepack/mpc,FLAC 和 AAC/MP3 進行轉碼到 MP三、mp二、wav 或者 pcm，還包括圖片轉換、縮放等。?更多Free UPnP Entertainment Service信息

• 流媒體服務器?Slyseal

  Slyseal 是一個使用python編寫的輕量級可擴展的流媒體服務器，實現了Adobe RTMP?協議，支持h.264編碼的視頻。 這里是演示 http://www.orakili.org.?更多Slyseal信息

• 電視流媒體服務器?Tvheadend

  Combined DVB reciever, Digital Video Recorder and Showtime streaming server for Linux. Tvheadend 是一個流媒體服務器/中繼supporing多種渠道和多種輸出格式。它主要是用于接收電視（廣播，模擬IPTV ）和將其轉交使用了一些不一樣的輸出格式的用戶。加上...?更多Tvheadend信息

• webcamFLV

  webcamFLV 是 Windows 下的攝像頭軟件，能夠將視頻和聲音數據流轉換為Flash FLV格式以便在 Web上發布，使用實時視頻編碼器ffMpeg進行開發。 ??更多webcamFLV信息

• WEB自動點唱機?netjukebox

  netjukebox是一個php開發的基于Web的自動點唱機。 更多的屏幕截圖請看：http://www.netjukebox.nl/screenshot.php 演示地址：http://www.netjukebox.nl/demo.php? 更多netjukebox信息 ?

• Java流媒體服務器?JRoar

  JRoar 是一個純 Java 開發的Ogg 流媒體服務器。It casts live Ogg streams to Ogg Vorbis players as IceCast2 does and shouts live Ogg streams to IceCast2 and JRoar. JRoar also accepts live Ogg streams from Ices. The uniqueness of JRoar is tha...? 更多JRoar信息

• OpenAMF

  OpenAMF 項目是免費的開放源碼替代Macromedia的遠程Java Flash. 這是由于可以提供做為應用服務,以Flash MX的大媒體的專有解決方案. 這個項目開始做為一個Java AMF-PHP接口.? 更多OpenAMF信息

• 多媒體傳輸協議庫?oRTP

  RTP（Real-timeTransportProtocol）是用于Internet上針對多媒體數據流的一種傳輸協議，作流媒體傳輸方面的應 用離不開RTP協議的實現及使用，為了更加快速地在項目中應用RTP協議實現流媒體的傳輸，咱們通常會選擇使用一些RTP庫，例如使用c++語言編寫的 JRTP...? 更多oRTP信息

• Helix DNA Platform

  The Helix DNA Server is a universal delivery engine supporting the real time packetization and network transmission of any media type to any device. The Helix DNA Server is the industry's core media delivery engine and should be at the c...? 更多Helix DNA Platform信息

• 流媒體服務器?Tunapie

  Tunapie，一個能夠自動從網絡上下載網絡電臺和視頻流媒體的列表軟件。在Windows下用過WinAMP的用戶應該都有印象WinAMP有一個能夠從網絡更新列表，用戶能夠選擇電臺或視頻流媒體。Tunapie就是WinAMP這個功能的獨立軟件，固然是For Linux的。 要播放Tunapie... 更多Tunapie信息

• 家庭視頻直播和分享?xShow@Home

  注：xShow@Home 已經更名為?xDisplayAtHome ，項目頁面更改至?https://code.google.com/p/xdisplay/ xShow@Home 是我開發的視頻平臺xShow的一個分支，用于家庭視頻直播和分享，可將一個視頻（電影或攝像頭采集的視頻）在PC、Mac、Linux、Android上同時播... 1.執行xShow@Home.exe后啟動服務（Http和Rtmp） ? 2.修改和啟動 xRtmpClient.cmd 可編碼視頻到Rtmp。 3.打開瀏覽器，打開本機IP的80端口便可看到媒體，播放器能夠選擇拉伸、按比例縮放、靜音、全屏。 ? ? https://code.google.com/p/xinghestudio/downloads/list ?更多xShow@Home信息 最近更新：?xShow@Home v5.1.20120908 發布?發布于 1年前

• 流媒體服務器?TivoServer

  TivoServer 是一個經過家庭多媒體服務將 PC 中的視頻輸出到 Tivo 的解決方案，目前須要對 Tivo 進行破解，而且只支持那些先前從 Tivo 解壓出來的版本。? 更多TivoServer信息

• Mobicents Multimedia Server

  MMS (Mobicents Multimedia Server) 是一個基于?Java?開發的實時媒體服務器，提供流媒體、會議、錄制、回放、IVR、TTS?等多項多媒體功能，可經過 MGCP 或者媒體控制(JSR 309) 驅動進行訪問。 該項目繼承自 Mobicents Media Server...? 更多Mobicents Multimedia Server信息 最近更新：?Mobicents Multimedia Server 3.0 RC2 發布?發布于 10個月前

• m3w網站的流媒體服務器?m3w

  m3w 是 www.m3w.com 網站所使用的音樂流媒體服務器，經過捕捉來自聲卡的數據并轉換成流媒體進行播放，提供高質量、高可靠性和易用的流媒體工具。 更多m3w信息

• pulpTunes

  pulpTunes是一個為 iTunes 桌面軟件提供的一個 Web 服務器，經過它你能夠在 Web 上訪問 iTunes 中的音樂。采用 Java 開發，支持各類操做系統。你能夠安裝在你的機器上來訪問你的iTunes音樂庫，能夠在世界任何地方經過網絡瀏覽器,跟你的朋友和家人分享你的音... ?更多pulpTunes信息

• 音頻流記錄器?DarkIce

  DarkIce即是一個實時的音頻流記錄器。它支持從音頻接口，例如音效卡錄制音頻信息并進行編碼后將其發送到流媒體服務器。 DarkIce能夠記錄從OSS音頻設備，ALSA音頻設備，Solaris 音頻接口，和 Jack 音源。 DarkIce能夠編碼成MP3，MP2方法，Ogg Vorbis和AAC格...? 更多DarkIce信息

  最近更新：?DarkIce 1.2 發布，增長對 Ogg/Opus 的支持?發布于 5個月前

• Tin Can Jukebox

  Tin Can Jukebox 是一個快速、功能全面的基于Web的 jukebox ，可安全的輸出很大的 MP3 集合數據流。提供包括瀏覽模型、動態下載、播放列表、語言包、用戶訪問控制等功能。 在線演示： http://www.tincanjukebox.com/demo/index.php... ?更多Tin Can Jukebox信息

• RTMFP服務器腳本?CumulusServer

  openrtmfp又名Cumulus Server是一個徹底開源和跨平臺的可擴展的RTMFP服務器腳本。Cumulus Server在GPL 框架下遵循速度、優點、跨平臺、輕量和高質量代碼。Cumulus Server的每個版本都是經過嚴格測試和審核的。可經過Cumulus官網費下載源代碼并編譯安裝。...? 更多CumulusServer信息

• ！！！RTMP/HLS 直播服務器?simple-rtmp-server

  一個采用MIT協議受權的國產的簡單的RTMP/HLS 直播服務器，其核心的價值理念在于簡單高效。 使用方法： tep 1: build srs tar xf simple-rtmp-server-*.*.tar.gzcd simple-rtmp-server-*.*/trunk./configure --with-ssl --with-hlsmake step 2: start ...? 更多simple-rtmp-server信息

• 開源流媒體服務器?Feng

  Feng是LSCUBE維護的開源流媒體服務器，兼容IETF標準，實現了RTSP、RTP/RTCP。 Feng支持的編碼標準： 音頻： MPEG Audio (MPEG-1/2 Layer I/II/III) (rfc2250) Vorbis (draft) AAC (MPEG-4 Part 3) (rfc3640) 視頻： MPEG Video (MPEG-1/2) (rfc2250) MPEG...? 更多Feng信息

• DVB-C 調制器?mptsd

  mptsd 從 UDP/多播 或者是 HTTP 接收 MPEGTS 流，并將這些數據庫合并到一個多程序流，特別適合輸出 DVB-C 調制器。 It has been tested with the Dektec DTE-3114 Quad QAM Modulator and it is used in production in couple of small DVB-C networks....? 更多mptsd信息

• 流媒體服務器?Babylon

  babylon ======= 巴比倫流媒體服務器，目前只支持rtmp協議?#如何使用# ``` package main import ( ? ? "babylon/rtmp" log "github.com/cihub/seelog" "runtime" ) func main() { ? runtime.GOMAXPROCS(runtime.NumCPU()) ? l := ":1935" ? err := r... ?更多Babylon信息

• m9u

  m9u 是一個相似于 MPD 和 XMMS2 的音樂服務器軟件。 ?更多m9u信息

以上部分大部分來自于參考博客，并作整理

將oschina中的部分按照瀏覽數和收藏數進行排序，以下所示

瀏覽數排序：

收藏數排序：

這里將選取一些主流的流媒體服務器進行討論學習

red5

優缺點明顯，來看oschina所給內容

“Red5是一個采用Java開發開源的Flash流媒體服務器。它支持：把音頻（MP3）和視頻（FLV）轉換成播放流； 錄制客戶端播放流（只支持FLV）；共享對象；現場直播流發布；遠程調用。Red5使用RTMP, RTMPT, RTMPS, 和RTMPE做為流媒體傳輸協議，在其自帶的一些示例中演示了在線錄制，flash流媒體播放，在線聊天，視頻會議等一些基本功能。

Red5 is an Open Source Flash Server written in Java that supports:

• Streaming Video (FLV, F4V, MP4, 3GP)

• Streaming Audio (MP3, F4A, M4A, AAC)

• Recording Client Streams (FLV and AVC+AAC in FLV container)

• Shared Objects

• Live Stream Publishing

• Remoting

• Protocols: RTMP, RTMPT, RTMPS, and RTMPE

額外插件能夠實現“

從這里不難看出，特色是java開發開源、支持rtmp系列協議、flash流媒體播放，在如今各個瀏覽器都再也不支持flash的狀況下，red5值得權衡。

EasyDarwin

oschina所給內容

”EasyDarwin是由國內開源流媒體團隊維護和迭代的一整套開源流媒體視頻平臺框架，Golang開發，從2012年12月建立并發展至今，包含有單點服務的開源流媒體服務器，和擴展后的流媒體云平臺架構的開源框架，開辟了諸多的優質開源項目，能更好地幫助廣大流媒體開發者和創業型企業快速構建流媒體服務平臺，更快、更簡單地實現最新的移動互聯網(安卓、iOS、H五、微信)流媒體直播與點播的需求，尤為是安防行業與互聯網行業的銜接；

EasyDarwin云平臺是一套由EasyDarwin、EasyCMS、EasyCamera、EasyClient、nginx、redis構成的完整云平臺架構，支持分布式、跨平臺、多點部署，流媒體服務器支持負載均衡，按需直播，很是適用于互聯網化的安防、智能家居、幼教平臺、透明廚房、透明家裝等多個行業應用：“

easydarwin的特色是支持平臺多、優化好、支持RTSP協議、非徹底開源、安裝配置快

開源版本支持功能不如商業版，部分SDK是收費的

安裝配置：參考文章

nginx-rtmp-module（nginx-http-flv-module)

github連接

缺陷分析1

缺陷分析2

缺陷分析3

nginx-rtmp-module有這么差嗎？

其實并非，主流的方案是使用nginx-http-flv-module來替代nginx-rtmp-module

這里面有一部分是nginx-rtmp-module的緣由，另外一部分是由于flash的緣由

能夠但不必，因此擁抱nginx-http-flv-module是趨勢

補充一個圖：連接

在此基礎上，能夠看看nginx-rtmp-module和SRS的對比：原文連接

“nginx-rtmp比SRS優勢

• 做者牛逼：能在nginx上寫rtmp擴展的人，真心是牛逼。SRS做者之前作過相似的事情，不是在nginx上，是照著nginx的底層結構，用linux/epoll/多進程單線程/非阻塞異步socket實現RTMP協議，發現越到后面那個異步狀態處理越麻煩。不得不認可，nginx-rtmp做者能力比SRS做者能力高出N個數量級。
• 支持多進程：nginx的多進程是個硬指標。SRS有研發計劃，但目前尚未支持多進程（多進程不Simple），好消息是在不久未來，SRS就能夠在這點上不成為弱點了。

SRS比nginx-rtmp優勢

• 簡單：nginx高性能，緣由是直接使用異步非阻塞socket。SRS本質上也是，因此說和nginx同源架構，可是在另一個牛人的指點下，用了st這個庫，避免了異步socket那些狀態處理。因此SRS看起來的邏輯很簡單。我一直覺得，nginx-rtmp最大的挑戰就是不穩定，太復雜了，愈加展應該是越明顯，不過nginx-rtmp做者很強大，這個就很難估計了。
• Vhost：nginx-rtmp做者估計沒有用過FMS，由于FMS的Vhost在客戶較多時，會頗有用（是個必選），也多是支持vhost會致使RTMP狀態更多吧。總之，沒有vhost，對于CDN這種公司，有不少客戶用同一套流媒體時，是不行的（如何計費呢？）
• RTMP邊緣：或許nginx-rtmp的pull和push也算邊緣，可是實際上不徹底是，邊緣應該只須要知道源站的ip，全部信息都從源站取。這樣對于大規模部署很方便。另外和上面一點相關，配置應該基于vhost，而不是app，app是不須要配置的，只有vhost才須要，配置vhost后隨便客戶推什么流上來啦。
• 轉碼：nginx-rtmp其實也能夠用ffmpeg轉碼，也是用ffmpeg，不過稍微沒有往前走一步。nginx-rtmp的轉碼是經過事件，相似SRS的HTTP callback，在鏈接上來時轉碼。SRS往前走了一步，在配置文件里配置轉碼信息，SRS會自動管理進程，kill或者重啟。使用起來仍是方便很多的。
• 代碼少：nginx-rtmp是基于nginx的，nginx是web服務器，專業的牛逼的web服務器。因此nginx-rtmp的代碼總數是16萬行，而srs只有2萬行。若是要在arm上編譯，仍是srs稍微瘦一點。若是打算維護，仍是維護2萬行代碼的產品會好些。
• 中文文檔：SRS中文文檔基本覆蓋了SRS的功能，并且會根據你們的問題更新，仍是很適合中文水平不錯的人。同時，SRS也提供英文文檔。

我也fork了nginx-rtmp代碼，RTMP和HLS部分都是參考了nginx-rtmp，大牛仍是大牛啊。nginx-rtmp 1.1.4的一些提交，仍是在fix crash，直接異步的方式作RTMP仍是比較難的：

?

對比下代碼，響應connect-app這個包的發送的代碼：

這個就是同步和異步socket的區別，以及問題的分解致使的一致性（組包和發包兩個層次，而不是nginx那樣設置數據，更改全局配置，調用發送函數），對象層次的互動和數據操做（或者說數據隱藏和層次化，和數據結構）這兩個編程方法的區別。”

simple-rtmp-server

參考文章：連接

“SRS定位是運營級的互聯網直播服務器集群，追求更好的概念完整性和最簡單實現的代碼。

• 運營級：商業運營追求極高的穩定性，良好的系統對接，以及錯誤排查和處理機制。譬如日志文件格式，reload，系統HTTP接口，提供init.d腳本，轉發，轉碼，邊緣回多源站，都是根據CDN運營經驗做為判斷這些功能做為核心的依據。

• 互聯網：互聯網最大的特征是變化，惟一不變的就是不斷變化的客戶要求，惟一不變的是基礎結構的概念完整性和簡潔性。互聯網還意味著參與性，聽取用戶的需求和變動，持續改進和維護。

• 直播服務器：直播和點播這兩種大相徑庭的業務類型，致使架構和目標徹底不一致，從運營的設備組，應對的挑戰都徹底不一樣。兩種都支持只能說明沒有重心，或者低估了代價。

• 集群：FMS(AMS)的集群仍是很不錯的，雖然在運營容錯不好。SRS支持完善的直播集群，Vhost分為源站和邊緣，容錯支持多源站切換、測速、可追溯日志等。

• 概念完整性：雖然代碼甚至結構都在變化，可是結構的概念完整性是一直追求的目標。從SRS服務器，P2P，ARM監控產業，MIPS路由器，服務器監控管理，ARM智能手機，SRS的規模再也不是一個服務器而已。

• 簡單實現：對于過于復雜的實現，寧肯不加入這個功能，也不犧牲前面提到的要求。對于已經實現的功能的代碼，總會在一個版本release前給予充分的時間來找出最簡答案。不求最高性能，最優雅，最牛逼，但求最簡單易懂。

備注：概念完整性能夠參考Brooks的相關文獻，在宏觀方面他仍是頗有造詣”

各個流媒體服務器性能對比：

源碼：gitee連接、github連接

live555

live555官網：連接

原文連接：oschina

“Live555 是一個為流媒體提供解決方案的跨平臺的C++開源項目，它實現了對標準流媒體傳輸協議如RTP/RTCP、RTSP、SIP等的支持。Live555實現了對多種音視頻編碼格式的音視頻數據的流化、接收和處理等支持，包括MPEG、H.263+、DV、JPEG視頻和多種音頻編碼。同時因為良好的設計，Live555很是容易擴展對其余格式的支持。目前，Live555已經被用于多款播放器的流媒體播放功能的實現，如VLC(VideoLan)、MPlayer。LIVE555媒體服務器”是完整的RTSP服務器應用程序。”

特色：支持RTSP協議、網絡資源較少、官方說明文檔較少、支持多種音視頻編碼

CRTMPD

crtmpd PK SRS：原文連接

crtmpd（rtmpserver），c++的RTMP服務器，可是SRS也是C++的，私下覺得crtmpd是以c的思惟習慣來寫c++代碼，就像c++做者講的，拿著c++這個電鉆當鐵錘錘釘子————不只僅沒有效果，還可能會砸到本身的手。

crtmp(svnversion為811版本）的代碼行數是93450行代碼，是SRS(0.9.90 38518行，其中st有4839行)的2.426倍，功能不會比SRS多3倍吧？這就是ST強大的地方。

SRS的注釋（可以使用工具research/code-statistic/csr.py統計）是5944行，占總代碼行數的17.65%。ST的注釋是754行，占代碼總行數比例為15.58%。合在一塊兒是6698行，占總數的17.39%。

CRTMPD的注釋是15891行，占代碼總行數的17.00%。

# CRTMPD python ~/srs/research/code-statistic/csr.py ~/git/crtmpserver/sources/ *.h,*.cpp .svn,tests #total:93450 code:77559 comments:15891(17.00%) block:13123 line:2768 #NGINX1.5(event,core) python ~/srs/research/code-statistic/csr.py ~/tools/nginx-rtmp/nginx-1.5.7/src/ *.h,*.c http,mail,misc,os #total:37678 code:36034 comments:1644(4.36%) block:1644 line:0 #NGINX-RTMP1.1.4 python ~/srs/research/code-statistic/csr.py ~/tools/nginx-rtmp/nginx-rtmp-module-1.1.4/ *.h,*.c #total:30957 code:30011 comments:946(3.06%) block:946 line:0 # NGINX(event,core)+NGINX-RTMP python ~/srs/research/code-statistic/csr.py ~/tools/nginx-rtmp/mixed/ *.h,*.c #total:68883 code:66285 comments:2598(3.77%) block:2598 line:0 # ST python ~/srs/research/code-statistic/csr.py ~/srs/objs/st-1.9/ *.h,*.c examples,extensions,LINUX #total:4839 code:4085 comments:754(15.58%) block:754 line:0 # SRS python ~/srs/research/code-statistic/csr.py ~/srs/src *.*pp utest,upp #total:33679 code:27735 comments:5944(17.65%) block:4126 line:1818

并且，crtmpd還支持lua，這個是開源軟件的通病，喜歡什么都往里面加，竊覺得不可取。因此有人抱怨說crtmpd太大，是的，大得不得了。

我測試過crtmpd性能，仍是不錯的，應該和SRS差很少。惋惜crtmpd走的是單進程方向，各類擴展和協議，沒有支持多進程和邊緣集群方向，因此你們道不一樣不相為謀，也沒有什么比如較的了。

FMS

FMS PK SRS：原文連接

“FMS是adobe的流媒體服務器，RTMP協議就是adobe提出來的，FMS必定是重量級的產品。

FMS比SRS優勢

• 功能全面：支持RTMP/RTMPE/RTMPS/RTMPT/RTMFP流協議，AMF0/AMF3編碼，SharedObject協議，HLS/HDS協議，直播和點播，支持服務器腳本，支持多碼率，支持Windows和Linux平臺。能想到的好像都能支持。SRS呢？可憐兮兮的只有RTMP/AMF0/HLS/直播/linux。
• 研發資源充分：adobe作FMS的多少人，看那個樣子真是很多，還得不斷改進和推出新版本。這個也算一個優點，不過也難講，windows也很多人，對比起linux，服務器仍是比不事后者。

SRS比FMS優勢

• 簡單：SRS聚焦在更小的問題域上，而問題域是全部軟件復雜性的根本緣由之一（參考OOAD）。由于缺少研發資源，SRS只提供互聯網流媒體所使用最普遍的功能。由于，并且只由于簡化了問題域，SRS才如此簡單。
• 更高性能：FMS的性能不算瓶頸，不過FMS一個進程開啟246個線程的架構設計來看，FMS就是一個舊時代的產物。
• 不跨平臺：FMS支持跨平臺，在我看來不過是畫蛇添足，服務器為什么要跑在windows上面？大約只是為了自宮練寶典。正是SRS不跨平臺，才得以略去不少麻煩事。
• 配置簡單：FMS的配置巨麻煩無比，xml也是上一代技術的產物，真心xml做為配置是個很差用的東西。況且FMS的配置巨繁瑣，建立vhost還得建立一個目錄，拷貝配置，建立app也要創建目錄，且當心了，別改錯了。SRS呢？根本不用建立app，為何要建立app？！建立vhost只要在配置文件加一行就搞定。
• 支持Reload：FMS沒有Reload，因此某CDN公司的運維就很苦了，白天不能動FMS，不能加新客戶，那會致使FMS重啟。只能半夜三更起來，操做完了還要阿彌陀佛，由于研發通常這時候睡覺了，除了問題就只能自求多福。SRS呢？直接Reload就能生效，不影響在線用戶，想怎么改都行。
• 快速重啟：c/c++程序嘛，總會出問題，解決這種問題，簡單的方式就是看門狗重啟。FMS慘了，重啟要1分鐘，我去，1分鐘沒有流啊，客戶都要找上門賠錢了，不行的。SRS重啟多長時間？以毫秒計算。
• 可追溯日志：FMS的日志，就是沒有什么用的東西，想知道某個IP的客戶端為什么死活播放不了？想知道有哪些客戶端延遲較大？想知道目前服務器吞吐帶寬？作夢吧，adobe根本沒打算給出來，或許他們本身也不知道，哈哈。SRS呢？首先，記錄完整日志，都有錯誤碼，并且有client id，能夠查詢到某個客戶端的整個信息（要在那么多客戶端中找出一個，不簡單）。其次，使用pithy print，作到智能化打印，SRS的日志輸出仍是比較能給人看的，很少很多。最后，SRS提供cli，能吐出json數據，想查帶寬？想查流信息？cli均可以搞定，并且是json，現代系統標準接口。
• 支持熱備：FMS居然沒有熱備？是的，不是adobe不行，幾乎都不會考慮熱備。SRS邊緣能夠回多個源站，一個掛了切另一個。FMS如何作？得改配置，重啟，等等，重啟不是要一分鐘嗎？是的，簡單來說，FMS不支持熱備。
• 適應性強：FMS適應性如何不強？FMS4只能運行在Centos5 64位，FMS5要好點也好不到哪里去。SRS呢？估計linux-arm上都能跑，更別提什么linux發行版，什么機器，什么內存，都行！若是你有大量舊機器要跑流媒體？能夠，上SRS吧。
• url格式簡單：這個也算？我以為很算。看過FMS的RTMP對應的HDS/HLS流吧？多么長的地址，多么恐怖的adbevent！誰要是能立馬配置FMS的HLS，而后輸入地址播放，那真的是神。SRS呢？把rtmp換成http，后面加上.m3u8就是HLS，多么簡單！
• 支持轉碼：FMS沒法對直播流在服務器端轉碼。SRS使用ffmpeg作了支持。adobe是大公司，應該是沒有辦法使用ffmpeg轉碼。
• 支持錄制：FMS的錄制是在FMLE上有個DVR的按鈕，而后配置服務器端腳本實現，不靠譜。SRS的錄制和時移只會作一部分，可是也會比那種腳本方案要靠譜不少（腳本不可能不出問題，親身經歷）。
• 開源代碼：FMS最重要一點，不提供代碼，有bug？找adobe。想要定制？找adobe。那基本上就不要有那個念想了。SRS代碼都是開源的，SRS做者水平通常，因此寫出來代碼就須要很當心，盡可能寫得清楚，否則本身看不懂，哈哈。”

WOWZA

Wowza PK SRS：原文連接

Wowza也是個很了不得的產品，聽說公司快上市了，Wowza和SRS在功能上很像，不過wowza也是在功能方面比SRS多不少。

Wowza比SRS優勢

• 功能全面：和FMS相似，Wowza支持的功能不少，估計比FMS不會少。

SRS比Wowza優勢

• c++高性能：wowza是java的，想不通為什么用java作服務器，性能確定不高。不過實測發現沒有想象的那么低，固然比起NGINX仍是很低。低性能的問題就是延遲會大。不過不是全部流媒體客戶都關心延遲，因此Wowza這點不算硬傷。
• 部署簡單：wowza依賴于jdk，還得設置環境變量，我去。wowza的安裝包也很大，jdk的也很大，都在100MB+，真的不方便。SRS多大？3MB左右，不依賴與任何外部庫。一個srs，一個conf，就能跑起來了。wowza須要多少東西。。。
• 內存少：其實java都是這樣，內存居高不下，沒有辦法，gc確定沒有那么智能。wowza吃內存是以GB算的，SRS是以KB算的，在某些沒有10GB內存的服務器上，仍是不要跑wowza得好。雖然說內存便宜，若是內存無法那么大呢？譬如arm？
• 不跨平臺：wowza使用java跨平臺，技術就是這樣，有好處就會有代價。SRS打死也不會考慮作非linux平臺，目的就是簡單。
• 配置簡單：java的配置，xml，蛋疼，不喜歡全部java的配置，譬如tomcat之類。nginx的配置文件絕對是極品，是的，SRS就是抄襲的nginx的配置部分的代碼。
• 支持Reload：wowza也沒有據說過reload這回事吧，這個功能上用起來真是很重要，不知道為什么你們都不支持。一樣的，nginx的reload多么強大。reload也不是多么難的事情，srs也支持reload，這個不是從nginx抄襲的，本身寫額。
• 可追溯日志：商業軟件都是一副德行，生怕別人看懂日志，提供的接口也很封閉。SRS固然不會了，緣由是SRS沒有那么多精力作方案，只好提供接口給你們控制和使用。
• 支持熱備：wowza的熱備彷佛是個插件，也有可能沒有，這點不太肯定。不過SRS原生支持熱備，發生故障時切換時間以毫秒計算，也就是上層服務器沒有流了，立刻切換到其余服務器，用戶不會斷也不會有感受。
• 開源代碼：wowza也是沒有代碼的，比FMS好的是它提供了plugin方案。等等，plugin方案和nginx的模塊，哪一個好？固然是后者，后者直接編譯進去，接口均可見，甚至把nginx本身代碼改了均可以。SRS不支持nginx的模塊，緣由是以為那個太麻煩，自己代碼就沒有多少，不如直接改。

AMS

這個是一個以前的流媒體服務器提供商開源的方案，原文連接

原文就不搬運了，簡單的歸納一下博主開源的這款產品的特色吧

特色：

• 高并發、性能不錯-能夠超過CRtmpServer\FMS，與nginx-rtmp相近，比SRS使用方便。
• 能夠作集群.提供HTTP RTMP 協議, 支持HLS. ? rtmp協議作直播時能保證服務器產生的延遲不大于100毫秒
• Linux版本支持centos 6.5（7.0也能夠），其余系統版本未測試（須要本身進行嘗試）；Windows版本雖然有，可是不太行
• 直播支持http、rtmp；點播支持rtmp、http，點播只支持mp4
• 有一些其余的功能，如踢客戶端、踢端口、顯示流量等，主要是一些個性化功能

安裝配置使用再也不贅述，詳情參見上面給出的連接

簡單看了一下，其使用過程和指令與nginx-rtmp相似

這個產品優勢是很明顯的，做為一個商業用產品再開源，其實用性和穩定性應該是能夠獲得保證的

可是我以為也有一些缺點，說一下本身的見解

• 一我的維護的話，精力多是個大問題；出現bug能不能及時搞定，在哪里討論
• 該產品好像不支持定制化操做/二次開發，具體要看是否符合本身的需求
• 支持的協議和格式有一點少，可是仍是主要看我的，夠用就好

monibuca

這個產品名字頗有意思，好像~monica就是monibuca，應該是國人開發

產品徹底開源，使用開源go語言編寫，性能沒有測試，可是在github上比較活躍：github-monibuca

較好的一點是使用模塊化來實現功能：plugins-monibuca

總結分析

?

總結

以上是生活随笔為你收集整理的流媒体(视频)服务器调研的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。