這篇文章主要向大家介紹流媒體(視頻)服務(wù)器調(diào)研,主要內(nèi)容包括基礎(chǔ)應(yīng)用、實(shí)用技巧、原理機(jī)制等方面，希望對大家有所幫助。

標(biāo)簽：javascriptphphtmljavapythonlinuxandroidnginxc++git

流媒體服務(wù)器調(diào)研

前言：因?yàn)橐饕恍┮曨l服務(wù)器相關(guān)的內(nèi)容，因此先對此部分進(jìn)行調(diào)研javascript

注：主要內(nèi)容來源于相關(guān)博客，參考文章和來源均已經(jīng)說明php

摘要：該部分主要涉及流媒體協(xié)議、流媒體服務(wù)器對比html

目錄java

流媒體服務(wù)器調(diào)研python

常見的流媒體協(xié)議linux

RTPandroid

RTCPnginx

SRTP & SRTCPc++

RTSPgit

RTSP 和RTP的關(guān)系

SDP

RTMP/RTMPS

mms

HLS

http-flv?

API- -? webRTC

主流的流媒體服務(wù)器

38款流媒體服務(wù)器開源軟件

red5

EasyDarwin

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

simple-rtmp-server

live555

CRTMPD

FMS

WOWZA

AMS

monibuca

總結(jié)分析

---

常見的流媒體協(xié)議

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

RTP

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

? ? ? ? ?Real-time Transport Protocol)是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸層協(xié)議。RTP協(xié)議詳細(xì)說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。RTP協(xié)議經(jīng)常使用于流媒體系統(tǒng)（配合RTCP協(xié)議），視頻會議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP），使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。RTP協(xié)議和RTP控制協(xié)議RTCP一塊兒使用，并且它是創(chuàng)建在UDP協(xié)議上的。?

? ? ? ? ?RTP 自己并無提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實(shí)現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送，也不肯定底層網(wǎng)絡(luò)的可靠性。 RTP 實(shí)行有序傳送， RTP 中的序列號容許接收方重組發(fā)送方的包序列，同時(shí)序列號也能用于決定適當(dāng)?shù)陌恢?#xff0c;例如：在視頻解碼中，就不須要順序解碼。

? ? ? RTP 由兩個(gè)緊密連接部分組成： RTP ― 傳送具備實(shí)時(shí)屬性的數(shù)據(jù)；RTP 控制協(xié)議（RTCP） ― 監(jiān)控服務(wù)質(zhì)量并傳送正在進(jìn)行的會話參與者的相關(guān)信息。

RTCP

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

SRTP & SRTCP

? ? ? ? 參考文檔?RFC3711

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

RTSP

? ? ? ?參考文檔?RFC2326

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

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

RTSP 和RTP的關(guān)系

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

? ? ? RTSP與RTP最大的區(qū)別在于：RTSP是一種雙向?qū)崟r(shí)數(shù)據(jù)傳輸協(xié)議，它容許客戶端向服務(wù)器端發(fā)送請求，如回放、快進(jìn)、倒退等操做。固然，RTSP可基于RTP來傳送數(shù)據(jù)，還能夠選擇TCP、UDP、組播UDP等通道來發(fā)送數(shù)據(jù)，具備很好的擴(kuò)展性。它時(shí)一種相似與http協(xié)議的網(wǎng)絡(luò)應(yīng)用層協(xié)議。目前碰到的一個(gè)應(yīng)用：服務(wù)器端實(shí)時(shí)采集、編碼并發(fā)送兩路視頻，客戶端接收并顯示兩路視頻。因?yàn)榭蛻舳藳]必要對視頻數(shù)據(jù)作任何回放、倒退等操做，可直接采用UDP+RTP+組播實(shí)現(xiàn)。

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

SDP

? ? ? ? 會話描述協(xié)議（SDP）為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。
? ? ? ?會話目錄用于協(xié)助多媒體會議的通告，并為會話參與者傳送相關(guān)設(shè)置信息。SDP 即用于將這種信息傳輸?shù)浇邮斩恕DP 徹底是一種會話描述格式 ― 它不屬于傳輸協(xié)議 ― 它只使用不一樣的適當(dāng)?shù)膫鬏攨f(xié)議，包括會話通知協(xié)議（SAP）、會話初始協(xié)議（SIP）、實(shí)時(shí)流協(xié)議（RTSP）、MIME 擴(kuò)展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTP）。

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

SDP 文本信息包括：

會話名稱和意圖；

會話持續(xù)時(shí)間；

構(gòu)成會話的媒體；

有關(guān)接收媒體的信息（地址等）。

協(xié)議結(jié)構(gòu)

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

一個(gè)或更多時(shí)間描述（以下所示）：
z = * （時(shí)間區(qū)域調(diào)整）
k = * （加密密鑰）
a = * （0 個(gè)或多個(gè)會話屬性行）
0個(gè)或多個(gè)媒體描述（以下所示）

時(shí)間描述
t = （會話活動(dòng)時(shí)間）
r = * （0或?qū)掖沃貜?fù)次數(shù)）

媒體描述
m = （媒體名稱和傳輸?shù)刂?#xff09;
i = * （媒體標(biāo)題）
c = * （鏈接信息 — 若是包含在會話層則該字段可選）
b = * （帶寬信息）
k = * （加密密鑰）

a = * （0 個(gè)或多個(gè)會話屬性行）

RTMP/RTMPS

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

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

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

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

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

? ? ? RTMP協(xié)議就像一個(gè)用來裝數(shù)據(jù)包的容器,這些數(shù)據(jù)既能夠是AMF格式的數(shù)據(jù),也能夠是FLV中的視/音頻數(shù)據(jù).一個(gè)單一的鏈接能夠經(jīng)過不一樣的通道傳輸多路網(wǎng)絡(luò)流.這些通道中的包都是按照固定大小的包傳輸?shù)?

mms

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

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

HLS

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

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

? ? ?根據(jù)以上的了解要實(shí)現(xiàn)HTTP Live Streaming直播，須要研究并實(shí)現(xiàn)如下技術(shù)關(guān)鍵點(diǎn)

采集視頻源和音頻源的數(shù)據(jù)

對原始數(shù)據(jù)進(jìn)行H264編碼和AAC編碼

視頻和音頻數(shù)據(jù)封裝為MPEG-TS包

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

HTTP傳輸協(xié)議

http-flv?

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

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

HttpFlv 就是 http+flv ，將音視頻數(shù)據(jù)封裝成FLV格式，而后經(jīng)過 HTTP 協(xié)議傳輸給客戶端。理解HttpFlv協(xié)議，這就話就是關(guān)鍵。

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

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

API- -? webRTC

這個(gè)并不是是流媒體協(xié)議，可是暫時(shí)放在此部分進(jìn)行說明。

此部分原文連接：參考網(wǎng)址

“WebRTC，名稱源自網(wǎng)頁即時(shí)通訊（英語：Web Real-Time Communication）的縮寫，是一個(gè)支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時(shí)語音對話或視頻對話的API。它于2011年6月1日開源并在Google、Mozilla、Opera支持下被歸入萬維網(wǎng)聯(lián)盟的W3C推薦標(biāo)準(zhǔn)。

WebRTC實(shí)現(xiàn)了基于網(wǎng)頁的視頻會議，標(biāo)準(zhǔn)是WHATWG 協(xié)議，目的是經(jīng)過瀏覽器提供簡單的javascript就能夠達(dá)到實(shí)時(shí)通信（Real-Time Communications (RTC)）能力。

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

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

主流的流媒體服務(wù)器

38款流媒體服務(wù)器開源軟件

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

?

• ！！！Flash流媒體服務(wù)器?Red5

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

  最近更新：?Red5 1.0.1 Final 發(fā)布，Flash流媒體服務(wù)器?發(fā)布于 12個(gè)月前

• 流媒體服務(wù)器?Open Streaming Server

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

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

  Live555 是一個(gè)為流媒體提供解決方案的跨平臺的C++開源項(xiàng)目，它實(shí)現(xiàn)了對標(biāo)準(zhǔn)流媒體傳輸協(xié)議如RTP/RTCP、RTSP、SIP等的支持。Live555實(shí)現(xiàn)了對多種音視頻編碼格式的音視頻數(shù)據(jù)的流化、接收和處理等支持，包括MPEG、H.263+、DV、JPEG視頻和多種音頻編碼。同時(shí)...? 更多l(xiāng)ive555信息

• ！！！Darwin Streaming Server

  Darwin Streaming Server 使用開放標(biāo)準(zhǔn)，讓你能夠透過互聯(lián)網(wǎng)實(shí)時(shí)傳送實(shí)況或預(yù)先錄制的內(nèi)容。在 Instant-On——蘋果電腦公司正在申請專利的一項(xiàng)創(chuàng)新流媒體播送技術(shù)的支持下，你的內(nèi)容將在點(diǎn)擊連接的同時(shí)開始播放，無需等待文件下載。...? 更多Darwin Streaming Server信息

• 【商業(yè)】流媒體服務(wù)器軟件?Helix Server

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

• 開源流媒體平臺?FreeCast

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

• MPEG4IP

  MPEG4IP提供一個(gè)端對端的系統(tǒng)來實(shí)現(xiàn)音視頻流的傳輸，支持包括MPEG4/H.261/MPEG2/H.263 MP3/AAC/AMR等不一樣編碼格式。 更多MPEG4IP信息

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

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

• 流媒體服務(wù)器?Yass

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

• 流媒體服務(wù)器?Flumotion

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

• Java實(shí)現(xiàn)的RTMP?Flazr

  Flazr 是一個(gè)實(shí)現(xiàn)了 RTMP 流媒體傳輸協(xié)議的 Java 類庫，該項(xiàng)目包含一個(gè)流媒體服務(wù)器和相關(guān)的工具。 ?更多Flazr信息

• 【商業(yè)】流媒體服務(wù)器?xmoovStream

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

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

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

• icecast

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

• RTMP流媒體服務(wù)器?crtmpserver

  crtmpserver又稱rtmpd是Evostream Media Server（www.evostream.com）的社區(qū)版本采用GPLV3受權(quán) 其主要做用為一個(gè)高性能的RTMP流媒體服務(wù)器，能夠?qū)崿F(xiàn)直播與點(diǎn)播功能多終端支持功能，在特定狀況下是FMS的良好替代品。 支持RTMP的一堆協(xié)議（RTMP,RTMPE, RTM...?更多crtmpserver信息

• Free UPnP Entertainment Service

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

• 流媒體服務(wù)器?Slyseal

  Slyseal 是一個(gè)使用python編寫的輕量級可擴(kuò)展的流媒體服務(wù)器，實(shí)現(xiàn)了Adobe RTMP?協(xié)議，支持h.264編碼的視頻。 這里是演示 http://www.orakili.org.?更多Slyseal信息

• 電視流媒體服務(wù)器?Tvheadend

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

• webcamFLV

  webcamFLV 是 Windows 下的攝像頭軟件，能夠?qū)⒁曨l和聲音數(shù)據(jù)流轉(zhuǎn)換為Flash FLV格式以便在 Web上發(fā)布，使用實(shí)時(shí)視頻編碼器ffMpeg進(jìn)行開發(fā)。 ??更多webcamFLV信息

• WEB自動(dòng)點(diǎn)唱機(jī)?netjukebox

  netjukebox是一個(gè)php開發(fā)的基于Web的自動(dòng)點(diǎn)唱機(jī)。 更多的屏幕截圖請看：http://www.netjukebox.nl/screenshot.php 演示地址：http://www.netjukebox.nl/demo.php? 更多netjukebox信息 ?

• Java流媒體服務(wù)器?JRoar

  JRoar 是一個(gè)純 Java 開發(fā)的Ogg 流媒體服務(wù)器。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 項(xiàng)目是免費(fèi)的開放源碼替代Macromedia的遠(yuǎn)程Java Flash. 這是由于可以提供做為應(yīng)用服務(wù),以Flash MX的大媒體的專有解決方案. 這個(gè)項(xiàng)目開始做為一個(gè)Java AMF-PHP接口.? 更多OpenAMF信息

• 多媒體傳輸協(xié)議庫?oRTP

  RTP（Real-timeTransportProtocol）是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議，作流媒體傳輸方面的應(yīng) 用離不開RTP協(xié)議的實(shí)現(xiàn)及使用，為了更加快速地在項(xiàng)目中應(yīng)用RTP協(xié)議實(shí)現(xiàn)流媒體的傳輸，咱們通常會選擇使用一些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信息

• 流媒體服務(wù)器?Tunapie

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

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

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

• 流媒體服務(wù)器?TivoServer

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

• Mobicents Multimedia Server

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

• m3w網(wǎng)站的流媒體服務(wù)器?m3w

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

• pulpTunes

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

• 音頻流記錄器?DarkIce

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

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

• Tin Can Jukebox

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

• RTMFP服務(wù)器腳本?CumulusServer

  openrtmfp又名Cumulus Server是一個(gè)徹底開源和跨平臺的可擴(kuò)展的RTMFP服務(wù)器腳本。Cumulus Server在GPL 框架下遵循速度、優(yōu)點(diǎn)、跨平臺、輕量和高質(zhì)量代碼。Cumulus Server的每個(gè)版本都是經(jīng)過嚴(yán)格測試和審核的。可經(jīng)過Cumulus官網(wǎng)費(fèi)下載源代碼并編譯安裝。...? 更多CumulusServer信息

• ！！！RTMP/HLS 直播服務(wù)器?simple-rtmp-server

  一個(gè)采用MIT協(xié)議受權(quán)的國產(chǎn)的簡單的RTMP/HLS 直播服務(wù)器，其核心的價(jià)值理念在于簡單高效。 使用方法： 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信息

• 開源流媒體服務(wù)器?Feng

  Feng是LSCUBE維護(hù)的開源流媒體服務(wù)器，兼容IETF標(biāo)準(zhǔn)，實(shí)現(xiàn)了RTSP、RTP/RTCP。 Feng支持的編碼標(biāo)準(zhǔn)： 音頻： 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 調(diào)制器?mptsd

  mptsd 從 UDP/多播 或者是 HTTP 接收 MPEGTS 流，并將這些數(shù)據(jù)庫合并到一個(gè)多程序流，特別適合輸出 DVB-C 調(diào)制器。 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信息

• 流媒體服務(wù)器?Babylon

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

• m9u

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

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

將oschina中的部分按照瀏覽數(shù)和收藏?cái)?shù)進(jìn)行排序，以下所示

瀏覽數(shù)排序：

收藏?cái)?shù)排序：

這里將選取一些主流的流媒體服務(wù)器進(jìn)行討論學(xué)習(xí)

red5

優(yōu)缺點(diǎn)明顯，來看oschina所給內(nèi)容

“Red5是一個(gè)采用Java開發(fā)開源的Flash流媒體服務(wù)器。它支持：把音頻（MP3）和視頻（FLV）轉(zhuǎn)換成播放流； 錄制客戶端播放流（只支持FLV）；共享對象；現(xiàn)場直播流發(fā)布；遠(yuǎn)程調(diào)用。Red5使用RTMP, RTMPT, RTMPS, 和RTMPE做為流媒體傳輸協(xié)議，在其自帶的一些示例中演示了在線錄制，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

額外插件能夠?qū)崿F(xiàn)“

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

EasyDarwin

oschina所給內(nèi)容

”EasyDarwin是由國內(nèi)開源流媒體團(tuán)隊(duì)維護(hù)和迭代的一整套開源流媒體視頻平臺框架，Golang開發(fā)，從2012年12月建立并發(fā)展至今，包含有單點(diǎn)服務(wù)的開源流媒體服務(wù)器，和擴(kuò)展后的流媒體云平臺架構(gòu)的開源框架，開辟了諸多的優(yōu)質(zhì)開源項(xiàng)目，能更好地幫助廣大流媒體開發(fā)者和創(chuàng)業(yè)型企業(yè)快速構(gòu)建流媒體服務(wù)平臺，更快、更簡單地實(shí)現(xiàn)最新的移動(dòng)互聯(lián)網(wǎng)(安卓、iOS、H五、微信)流媒體直播與點(diǎn)播的需求，尤為是安防行業(yè)與互聯(lián)網(wǎng)行業(yè)的銜接；

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

easydarwin的特色是支持平臺多、優(yōu)化好、支持RTSP協(xié)議、非徹底開源、安裝配置快

開源版本支持功能不如商業(yè)版，部分SDK是收費(fèi)的

安裝配置：參考文章

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

github連接

缺陷分析1

缺陷分析2

缺陷分析3

nginx-rtmp-module有這么差嗎？

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

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

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

補(bǔ)充一個(gè)圖：連接

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

“nginx-rtmp比SRS優(yōu)勢

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

SRS比nginx-rtmp優(yōu)勢

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

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

?

對比下代碼，響應(yīng)connect-app這個(gè)包的發(fā)送的代碼：

這個(gè)就是同步和異步socket的區(qū)別，以及問題的分解致使的一致性（組包和發(fā)包兩個(gè)層次，而不是nginx那樣設(shè)置數(shù)據(jù)，更改全局配置，調(diào)用發(fā)送函數(shù)），對象層次的互動(dòng)和數(shù)據(jù)操做（或者說數(shù)據(jù)隱藏和層次化，和數(shù)據(jù)結(jié)構(gòu)）這兩個(gè)編程方法的區(qū)別。”

simple-rtmp-server

參考文章：連接

“SRS定位是運(yùn)營級的互聯(lián)網(wǎng)直播服務(wù)器集群，追求更好的概念完整性和最簡單實(shí)現(xiàn)的代碼。

• 運(yùn)營級：商業(yè)運(yùn)營追求極高的穩(wěn)定性，良好的系統(tǒng)對接，以及錯(cuò)誤排查和處理機(jī)制。譬如日志文件格式，reload，系統(tǒng)HTTP接口，提供init.d腳本，轉(zhuǎn)發(fā)，轉(zhuǎn)碼，邊緣回多源站，都是根據(jù)CDN運(yùn)營經(jīng)驗(yàn)做為判斷這些功能做為核心的依據(jù)。

• 互聯(lián)網(wǎng)：互聯(lián)網(wǎng)最大的特征是變化，惟一不變的就是不斷變化的客戶要求，惟一不變的是基礎(chǔ)結(jié)構(gòu)的概念完整性和簡潔性。互聯(lián)網(wǎng)還意味著參與性，聽取用戶的需求和變動(dòng)，持續(xù)改進(jìn)和維護(hù)。

• 直播服務(wù)器：直播和點(diǎn)播這兩種大相徑庭的業(yè)務(wù)類型，致使架構(gòu)和目標(biāo)徹底不一致，從運(yùn)營的設(shè)備組，應(yīng)對的挑戰(zhàn)都徹底不一樣。兩種都支持只能說明沒有重心，或者低估了代價(jià)。

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

• 概念完整性：雖然代碼甚至結(jié)構(gòu)都在變化，可是結(jié)構(gòu)的概念完整性是一直追求的目標(biāo)。從SRS服務(wù)器，P2P，ARM監(jiān)控產(chǎn)業(yè)，MIPS路由器，服務(wù)器監(jiān)控管理，ARM智能手機(jī)，SRS的規(guī)模再也不是一個(gè)服務(wù)器而已。

• 簡單實(shí)現(xiàn)：對于過于復(fù)雜的實(shí)現(xiàn)，寧肯不加入這個(gè)功能，也不犧牲前面提到的要求。對于已經(jīng)實(shí)現(xiàn)的功能的代碼，總會在一個(gè)版本release前給予充分的時(shí)間來找出最簡答案。不求最高性能，最優(yōu)雅，最牛逼，但求最簡單易懂。

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

各個(gè)流媒體服務(wù)器性能對比：

源碼：gitee連接、github連接

live555

live555官網(wǎng)：連接

原文連接：oschina

“Live555 是一個(gè)為流媒體提供解決方案的跨平臺的C++開源項(xiàng)目，它實(shí)現(xiàn)了對標(biāo)準(zhǔn)流媒體傳輸協(xié)議如RTP/RTCP、RTSP、SIP等的支持。Live555實(shí)現(xiàn)了對多種音視頻編碼格式的音視頻數(shù)據(jù)的流化、接收和處理等支持，包括MPEG、H.263+、DV、JPEG視頻和多種音頻編碼。同時(shí)因?yàn)榱己玫脑O(shè)計(jì)，Live555很是容易擴(kuò)展對其余格式的支持。目前，Live555已經(jīng)被用于多款播放器的流媒體播放功能的實(shí)現(xiàn)，如VLC(VideoLan)、MPlayer。LIVE555媒體服務(wù)器”是完整的RTSP服務(wù)器應(yīng)用程序。”

特色：支持RTSP協(xié)議、網(wǎng)絡(luò)資源較少、官方說明文檔較少、支持多種音視頻編碼

CRTMPD

crtmpd PK SRS：原文連接

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

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

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

CRTMPD的注釋是15891行，占代碼總行數(shù)的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，這個(gè)是開源軟件的通病，喜歡什么都往里面加，竊覺得不可取。因此有人抱怨說crtmpd太大，是的，大得不得了。

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

FMS

FMS PK SRS：原文連接

“FMS是adobe的流媒體服務(wù)器，RTMP協(xié)議就是adobe提出來的，FMS必定是重量級的產(chǎn)品。

FMS比SRS優(yōu)勢

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

SRS比FMS優(yōu)勢

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

WOWZA

Wowza PK SRS：原文連接

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

Wowza比SRS優(yōu)勢

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

SRS比Wowza優(yōu)勢

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

AMS

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

原文就不搬運(yùn)了，簡單的歸納一下博主開源的這款產(chǎn)品的特色吧

特色：

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

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

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

這個(gè)產(chǎn)品優(yōu)勢是很明顯的，做為一個(gè)商業(yè)用產(chǎn)品再開源，其實(shí)用性和穩(wěn)定性應(yīng)該是能夠獲得保證的

可是我以為也有一些缺點(diǎn)，說一下本身的見解

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

monibuca

這個(gè)產(chǎn)品名字頗有意思，好像~monica就是monibuca，應(yīng)該是國人開發(fā)

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

較好的一點(diǎn)是使用模塊化來實(shí)現(xiàn)功能：plugins-monibuca

總結(jié)分析

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。