流媒体(视频)服务器调研

流媒体服务器调研

前言：由于要做一些视频服务器相关的内容，所以先对此部分进行调研

注：主要内容来源于相关博客，参考文章和来源均已经说明

摘要：该部分主要涉及流媒体协议、流媒体服务器对比

目录

流媒体服务器调研

常见的流媒体协议

RTP

RTCP

SRTP & SRTCP

RTSP

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 文本信息包括：

1. 会话名称和意图；
2. 会话持续时间；
3. 构成会话的媒体；
4. 有关接收媒体的信息（地址等）。
5. 协议结构

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直播，需要研究并实现以下技术关键点

1. 采集视频源和音频源的数据
2. 对原始数据进行H264编码和AAC编码
3. 视频和音频数据封装为MPEG-TS包
4. HLS分段生成策略及m3u8索引文件
5. 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) 是一个数字媒体传送器，主要功能包括支持 mp4、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 进行转码到 MP3、mp2、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、H5、微信)流媒体直播与点播的需求，尤其是安防行业与互联网行业的衔接；

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

总结分析