win7旗舰版 能否 搭建流媒体服务器

这两天我就在试玩Adobe Media Server 5 extend，流媒体服务所用的环境就是一台win7 64位旗舰版的i5 24GHz、4G内存Dell笔记本，3个独立IP的测试发布终端（Wirecast、Adobe live media encoder、Matrox MonarchHD）都以RTMP协议往服务器中发布直播流，除了MonarchHD因为只具有有线接入外，全部设备包括AMS所在的笔记本都用无线AP接入一个局域小网。其中MonarchHD publish给笔记本中安装的AMS推送一个2M码流的1920x1080 i50 H264直播流，用各种接收终端接收流都很清晰流畅

用Helix Server做流媒体服务器，搭建过程先参考下http://wenkubaiducom/linkurl=uWcq__lG3WALYryGPuIftqmt1scFXNJzV4Jlu5L5J31tGD9EPHwSrr8DEcTL2upUyd6TMGvOvT_pCSdVUi2NKEoVsK6aiDaiaWvWpB3pM4e，如果不成功，后期我会在csdn上写篇博客，到时候把链接发给你。我搭过很多流媒体服务器，这个就是专门支持rtsp协议的，视频格式为rmvb或rm，音频格式为ra，就是用helix server做流媒体服务器，helix producer plus做视音频编码器，realplayer做客户端播放器，这三个组合起来使用，配置通畅就好了，那么都和你说了用哪些软件了，其实网上都能搜到相关软件的使用说明了，不懂的再问我吧！

一个视频直播系统开发平台的技术搭建，按照程序开发的顺序，直播系统搭建过程如下：

1、采集端：

视频直播系统通过摄像头拍摄直播画面并录制声音做架构时一定要注意多终端适配，另外，离线采集技术，人工聚焦等都会影响用户体验

2、前处理：

视频直播系统开发最重要的部分是实时GPU渲染美感。实时美颜的算法本身，就相当考验APP厂商的技术经济实力；如何发展能够充分利用能力有限的GPU资源管理进行美颜处理，也是我们一个很关键的点。国内研究很多网络直播系统产品迭代都比较快，所以没有直接影响后果就是信息技术适配做得差，很多常见的机型都会闪退和骤停。前处理中还要去除是水印、时间戳等，因为现在很多小平台，会互相偷链，恶性竞争，这是必要的防范措施。

3、 编码：

我们都知道，视频直播系统上传到视频网站就是源码的过程，现场也如此。但是，前者依靠云计算，这是由手机本身的CPU性能编码。考虑到大量的网络流量的现状有一个编码的流程，以及适应当地网络速度后，一次上传编码就完成有点不现实。

在有的问题是发热程度，因为CPU和GPU同时在用于在没有很好地优化条件很长的时间全部容量。这会带来双重问题，一个是用户体验差，二是电力消耗很快。

4、算法：

一方面要减小CPU的使用率，另一重要方面我们又要进行控制码率更低。如果你自己企业或者网络服务商的编码技术标准问题不是H264或者H265，基本上就可以一票否决了。

5、传输：

视频直播系统开发重点是推流：因为如果传输路径上只有一个点有故障，只有一些人看不到，但如果推出问题，所有的人都看不到。 而且，移动直播平台的竞争非常激烈，如果技术不通过，一旦停机影响用户体验，后果将非常严重。

这是一种实时传输技术。这样基本上最成熟的国内直播平台，都选择把专业的CDN供应商去做。毕竟，能源初创公司通常专注于自己的业务，甚至许多非技术操作人员和维修人员不理解，再加上服务器，带宽成本等，做它自己非常困难的。这涉及到一个CDN的选择。

6、CDN节点：

视频直播系统开发最核心的资源比拼就是研究内容分发节点，但是我们如果没有涉及到直播的话，流传输的技术管理架构也同样具有重要。

一般是搭建FMS流媒体服务器。

传输的格式一般是 rtmp://wwwabccom/live/streamname

rtmp://wwwabccom/live/ 这是发布地址

streamname这是流名，流名自定义。

采集端一般叫编码器，或者是通过电脑端采集，需要采集终端软件。

一视音频的采集和编码技术

编码技术不仅包括算法实现，还涉及到通过是通过x86平台实现还是通过嵌入式方式实现。

二视音频的流媒体传输技术。目前通常使用的方式主要包括：

1通过HTTP协议传输，需要通过技术开发来实现高性能的HTTP流媒体服务器；

2通过RTMP协议传输，需要通过技术开发来实现高性能的RTMP流媒体服务器；

3通过UDP协议传输，这种方式通常用于大规模的可控网络中，比如IPTV电视直播应用，通过交换机即可支持这种传输方式；

4通过P2P方式传输，P2P方式所用的传输协议可以由用户自主定义，并且可以基于UDP或TCP来实现，这种方式通常也是用于

超大规模组网环境中。

三CDN内容分发技术。

需要自主开发实现支持流媒体的CDN内容分发软件平台，来完成内容从源站节点到各边缘节点服务器的调度。

这方面的技术已经很成熟，目前有多家这类产品提供商，也有多家CDN服务提供商（软件平台、硬件服务器、出口带宽整体租用）。

四终端解码技术。

解码技术主要根据终端的类型分为如下几类：

1PC端解码技术

比如当前视频网站采用的H264视频解码技术（AdobeFlashPlayer）、VLC和FFMPEG这种桌面客户端软件（可支持H264、H265等大部分视音频格式的解码）

2移动终端解码技术

目前主要分为Android和iOS量大阵营，两大移动平台的视音频解码实现方式也主要分为两种，一种是通过设备自带的GPU硬件解码，另一种是通过软件方式调用中央处理器来解码。

一、直播的技术架构：

直播视频采集SDK（PC/IOS/Anddroid）——直播CDN

（直播流分发加速）——直播视频播放器SDK（PC/IOS/Android）

二、音视频处理的一般流程：

数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示

1、数据采集：

摄像机及拾音器收集视频及音频数据，此时得到的为原始数据

涉及技术或协议：

摄像机：CCD、CMOS

拾音器：声电转换装置（咪头）、音频放大电路

2、数据编码：

使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如音视频混合、打包封装等），得到可用的音视频数据

涉及技术或协议：

编码方式：CBR、VBR

编码格式

视频：H265、H264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等

音频：G711μ、AAC、Opus等，封装有MP3、OGG、AAC等

3、数据传输：

将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输

涉及技术或协议：

传输协议：RTP与RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等

控制信令：SIP和SDP、SNMP等

4、解码数据：

使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音

涉及技术或协议：

一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等

5、播放显示：

在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音

涉及技术或协议：

显示器、扬声器、3D眼镜等

三、常见的视频直播相关协议：

1、RTMP(Real Time Messaging Protocol，实时消息传送协议)

RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：

1）、工作在TCP之上的明文协议，使用端口1935；

2）、RTMPT封装在HTTP请求之中，可穿越防火墙；

3）、RTMPS类似RTMPT，但使用的是HTTPS连接；

RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。

2、RTSP(Real Time Streaming Protocol，实时流传输协议)

RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。

RTSP语法和运作跟HTTP/11类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

3、RTP(Real-time Transport Protocol，实时传输协议)

RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H323或SIP），使它成为IP电话产业的技术基础。

RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。

RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。

4、RTCP(Real-time Transport Control Protocol，实时传输控制协议）

RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。

RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。

比特捷通过对已有的流媒体行业客户的了解发现，大部分流媒体运营公司起初会优先考虑自行采购海外服务器资源的方式，而这种方式却会存在一些潜在的问题：

1、 单一服务器无法承担大量并发数据流的负载。流媒体是一个特殊的网络应用系统，它与一般Web应用不同，其最大特点就是需要高速处理并发视频流数据。流媒体系统对服务器I/O通道吞吐率要求是极为严格的，其数据流量是非常巨大的。流媒体系统对于视频点播并发流的负载要求非常强大，单一服务器无法承担大量并发数据流的负载。

2、 备份服务器资源未能充分利用，导致浪费。与传统的文件数据不同，媒体数据流一旦开始传输，就必须以稳定的速率传送到客户端，以保证其平滑地回放，视频、音频数据流都不能有停滞和间断。鉴于流媒体服务以上特性，服务器稳定性尤为重要。单台服务器的设置，不可避免会出现“单点故障”，需要进行服务器“容错”。为实现容错，往往在主服务器旁安置一台或多台备份服务器。但这样做，平时只有一台服务器工作，其他服务器处于空闲状态，无法利用所有服务器的处理资源，投资得不到充分利用。

3、 扩容性低，系统性能无法保障。随着业务的发展，服务器上所要处理的数据量不断增大，同时并发连接数量会越来越多。若处理资源不够，在未超出系统容量时，往往是客户的请求回应越来越慢，可容纳的同时连接数量逐渐减小，系统性能严重下降。当超出系统容量后，系统出现故障导致服务中断。为应对日益增多的业务量，系统的可扩展性尤为重要。

网络直播平台的实现技术，归纳起来主要有如下这些：

一、视音频的采集和编码技术，当前主流的主要是H264、H265这种视频编码技术和AAC、MP3这种音频编码技术。

二、视音频的流媒体传输技术。

三、CDN内容分发技术。

四、终端解码技术。

架构方面，如果要做运营级的服务平台，需要采用分布式的架构方式，不仅包括各个功能模块的分布式部署，还包括各种应用服务器的分布式部署。

流媒体传输技术通常使用的方式主要包括：

1、通过HTTP协议传输，需要通过技术开发来实现高性能的HTTP流媒体服务器；

2、通过RTMP协议传输，需要通过技术开发来实现高性能的RTMP流媒体服务器；

3、通过UDP协议传输，这种方式通常用于大规模的可控网络中，比如IPTV电视直播应用，通过交换机即可支持这种传输方式；

4、通过P2P方式传输，P2P方式所用的传输协议可以由用户自主定义，并且可以基于UDP或TCP来实现，这种方式通常也是用于超大规模组网环境中。