流媒体服务器

一、直播的技术架构：

直播视频采集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、音视频编解码；

2、流媒体协议；

3、音视频流推送到流媒体服务器；

4、流媒体网络分发；

5、用户播放器；

6、音视频同步；

7、网络延迟自适应；

8、需要录制，多种视频文件的格式和封装；

9、语言：C、C、html、php、mysql

10、开发环境：嵌入式，Linux，Windows，Web

还有就是视频播放解决方案（卡顿、延迟）：

1、CDN加速；

2、自己架服务器；

3、用别人的云服务。

用CDN加速，可以尽量减少延迟。目前业内水准来看，视频延迟都在3-6秒之间。也就是在视频直播时，你看到的是几秒以前的画面。

自己架服务器，如果部署的数据中心不够多，那么遇上跨网、跨省的传输，还是得用CDN加速。那么为了尽可能降低延迟，你就需要在全国各省市都部署数据中心，来解决跨网、跨省的传输。用云服务的话，就是别人把服务器给你架好了，你只要傻瓜式的用就行了。当然，不管用哪种方式，综合权衡利弊，找到适合的方案就是最好的方案。

开发视频直播的流程有哪些：

1、采集；

2、前期处理；

3、编码；

4、传输；

5、解码；

6、渲染。

采集：iOS是比较简单的，Android则要做些机型适配工作。PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。

前期处理：现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。算法设计好了还要优化，无论你打算用CPU还是GPU优化，算法优化本身也需要专业知识支持。GPU虽然性能好，但是也是有功耗的。GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧。而这一切都是需要经验支撑。

编码：如果你要上720p，肯定要采用硬编码。软编码720p完全没希望，硬件编码不灵活。兼容性也有问题。如何适应纷繁复杂的网络和纷繁复杂的上下行设备？安卓和芯片的坑，开发过的人都知道。那有人问，要求不高，上软编码低分辨率360p行不行？就算上低分辨率，软编码还是会让CPU发烫，CPU过热烫到摄像头，长期发烫不仅直接反应是费电。既然是手机直播，插着电源和充电器实在说不过去吧。还有，CPU发烫会降频，怎么办？这还是只说性能方面。和前处理只影响图像质量和功耗不同，视频编解码技术还关联成本计算和网络对抗。考虑性能、功耗、成本、网络这四个之后你编码的码率、帧率、分辨率。软硬件开发该如何选择？

传输：自己做不现实，交给第三方服务商吧。

解码：如果你用硬解码，一定要做容错处理，一定要做适配。突然一个crash导致手机重启不好吧。安卓的硬解码，不说了。如果你加了网络目前手机的硬解码还不一定支撑用软解码，功耗发热的问题又来了。

渲染：为什么手机明明解码出好多帧数据。就是渲染不出来。为什么画面就是不同步。

以上是媒体模块，还有信令控制，登录、鉴权、权限管理、状态管理等等，各种应用服务，消息推送，聊天，礼物系统，支付系统，运营支持系统，统计系统等。后台还有数据库，缓存，分布式文件存储，消息队列，运维系统等。

以上技术要点的小结，确实能说明开发一个能用于生产环境的实时视频直播平台确非易事，跟IM里传统的实时音视频一样，这样的技术都是音视频编解码网络传输技术的综合应用体。

一对一直播平台开发完成后，不可避免的要进行系统的搭建部署。此时，也需要根据当初源码开发时的功能，选择合理的服务器搭建部署方案。服务器架构方面通常要用到云存储服务器、流媒体服务器或CDN、socket集群、Redis集群和Mysql集群等。如果只是一对一直播平台，对整个服务器架构的要求不会太高。如果没有单独的传统直播版块，就不会存在让人头疼的高并发问题；如果没有小视频版块，对实际的云存储也不会要求太高。但是，现在绝大多数的一对一直播平台不会放弃这两个版块的，传统的视频直播间能够为平台和主播带来稳定的变现方式，而小视频功能则是当下火热的推广手段，同时在一对一直播平台上也很容易实现付费小视频营销。

一对一直播平台开发所遵循的直播流程，和传统直播系统流程的实现方式基本上是一致的。通过摄像头采集音视频流，进行编码，然后将音视频流进行推流，通过流媒体服务器（CDN）实现内容分发，用户再进行拉流，通过设备对音视频流解码进行观看。一对一直播平台的重点在于主播开播前的设置，即我们该如何以最佳的方式实现一对一直播。如果对一对多有一定的了解，一对一直播平台开发就很好解释。

随着社交媒体的普及，直播已经成为了一种非常流行的形式，而无人直播间的出现则让直播更加智能化和自动化。下面，我将为您介绍如何搭建无人直播间。

1选择直播平台

首先，选择一个适合自己的直播平台，例如国内比较流行的有斗鱼、虎牙、哔哩哔哩等。在选择平台时，需要考虑到平台的用户数量、直播体验、直播功能等因素。

2选择直播设备

搭建无人直播间需要用到摄像头、音频设备、云服务器等设备，需要选择质量稳定、品牌信誉好的设备。目前市面上有一些专门为直播设计的设备，可以根据自己的需求选择相应的设备。

3设置直播软件

选择一款适合自己的直播软件，例如OBS、XSplit等，然后安装并设置好软件。在设置时，需要设置摄像头、麦克风、直播画面等参数，以保证直播效果的稳定和流畅。

4设置云服务器

为了实现无人直播，需要使用云服务器来实现远程控制。可以选择一些云服务提供商，例如阿里云、腾讯云等，然后购买一些服务器资源。在设置云服务器时，需要设置远程连接、存储、带宽等参数。

5自动化控制

为了实现无人直播，需要编写一些自动化脚本或使用一些自动化控制软件。例如可以使用Python编写脚本，通过调用API来实现直播间的自动化控制。也可以使用一些自动化控制软件，例如自动化测试工具Selenium，来实现直播间的自动化控制。

总之，搭建无人直播间需要选择合适的直播平台、直播设备、直播软件和云服务器，并实现自动化控制。如果您对技术不是很熟悉，可以请专业的技术人员来帮助您搭建。搭建无人直播间可以让直播更加智能化和自动化，提高直播效率和直播体验，具有非常大的潜力和发展前

十几年前，WEB应用还没有崛起，大家还都在用＂美萍点播＂等CS架构来搭建点播平台，现如今是浏览器的天下了，能不用客户端就不用客户端，使用开源软件组合搭建点播＋直播平台的BS架构备受青睐。

点播平台

（1）简单应用

如果不需要多码率播放，视频加密的话，直接上传mp4（H264）格式的视频就可以了（绝大多数浏览器都能直接播放），做好视频的存储，一个简单的点播平台不过如此。

（2）高级应用

如果需要多码率播放，视频加密，视频水印的话，这个可以使用开源库 ffmpeg 库来完成，服务端运行，稳定高效，可以很好的实现自动化。

直播平台

直播需要推流和拉流，这个还是很有技术含量的，有一定的技术门槛，自己去实现的话是不现实的。

（1）利用 nginx + rtmp 推流模块，不过不太稳定，毕竟 nginx不是专业做流媒体服务器的。

（2）利用 livego 等专业开源直播项目搭建，go语言 做网络应用天生的优势， 稳定性有待考验。

系统整合

经过调研以及不懈的努力，我把开源的 酷瓜云课堂腾讯云版 做了大量移植修改（存储，点播，直播）替换成本地的了，去掉了局域网内用不到的支付等功能。

下面开始安装，虽然是局域网应用，但是安装是需要连接外网的哦（后面有时间了再出一个本地安装的包），先准备好一杯咖啡吧（网络不好的话会有点慢哦）

友情提示

请使用干净的系统执行安装，如有安装过 nginx，apache 之类的会造成 80 和 443 端口冲突

配置要求

操作系统：Ubuntu | Debain | Centos

系统内存：2G+

官方文档：点击访问

（1）下载安装脚本

cd ~ && curl http://downloadkooguacom/lan-edu/installsh -o installsh

（2）根据实际情况修改配置

nano installsh

（3）执行安装，快慢取决于网络，当有错误或者超时 请重试，请重试，请重试

bash installsh

（4）安装完成，请删除安装脚本

rm installsh