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)

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前给予充分的时间来找出最简答案。不求最高性能，最优雅，最牛逼，但求最简单易懂。

备注：概念完整性能够参考*s的相关文献，在宏观方面他仍是颇有造诣”

各个流媒体服务器性能对比：

源码：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

码农公寓

流媒体服务器调研

常见的流媒体协议

RTP