直播小程序源码的开发原理？

主播端使用 <live-pusher>，它在微信小程序的内乎森部是一个推流迹前引擎，它负责对手机摄像头和麦克风的数据进行采集和编码，并通过 url 参数指定的 rtmp 推流地址上传到云端。

云端的作用类似信号放大器，它负责将来自主播端的一路音视频流数据进行放大，将数据实时并且无差异的负责并扩散到全国各地。观众端使用 <live-player>进行播放，它在小程序的内部是一个在线播放器，负责从云端实时拉取音视频数据并进行解码和渲染岁州亩。

流媒体服务器的未来将伴随着宽带应用和网络发展的总趋势，毕竟科技改变生活，未来流媒体也将占据网络的主流，视频流媒体服务器的功能和作用也将越来越丰富。

在未来，流媒体服务器将转向高度分布式的系统结构，这种体系结构在地理上是分布的，但逻辑上是单一的系统映像。在未来，一方面会有高性能的网络存储设备，另一方面会有高度智能化的协议控制和处理设备。这将是未来流媒体服务器扩展的极好方向，而微信也是一个非常有发展潜力的平台，尤其是微信小程序的直播开发。

那么现阶段的微信小程序能实现直播功能么？答案是：可以的。视频直播分为两种模式，一种是单向直播，通过CDN分发，成本低，延迟1~3秒，小程序通过Live模式搞定。另外一种是互动直播（连麦），需要比较低的延迟，要500ms以内，小程序通过RTC模式搞定。

但实际上小程序实现直播功能还有几个点需要克服：

第一个是延迟要足够低。如果单向延迟不能低于500毫秒的话，视频通话的互动体验就无法保障。

第二个是回声消除。因为用户A和用户B之间进行视频通话时，用户A的声音在传到用户B端时被采集并反馈回来，用户A在一定的延迟后会听到回声，这个对通话的体验十分有影响，因此必须做回声消除。

第三个是要流畅不卡顿。为什么流畅性很必要呢？因为有超低延迟的要求，流畅和延迟本身就是一对相互矛盾的技术要求，如果延迟足够低的话就要求抖动缓冲区足够的小，这样网络抖动就很容易显现出来，导致出现画面过快、过慢，或者卡顿的情况。

那我们一起来看看上面三个技术难点分别在哪些环节：

1)低延迟，基本上引入延迟的有三类环节：采集和渲染、编解码、网络传输。第一类是采集和渲染环节，带来的延迟比较大，尤其是渲染，几乎没有任何移动端系统可以保证百分之百做到50毫秒的延迟，这是一些硬件上的限制造成的。第二类是编解码环节，特别是音频编解码器是往前编码的，这个本身就会带来延迟，甚至有些音频编解码器能带来200毫秒的延迟。第三类是网络传输，在即构科技的实时传输网络里，往返的传输延迟分别都可以做到50毫秒以下。其中，采集尺数和渲染、编解码都是在终端实现的。

2)回声消除，属于语音前处理3A，需要在前处理环节进行，也就是在终端实现的。

3)抖动缓冲，是在接收端实现的，通过接收端的抖动缓冲来决定发送端要以多大的时间间隔来发送数据包。

综上所述，刚才说的三个技术难点都是在终端实陵迅首现的，因此昌历终端非常重要。我们EasyDSS流媒体服务器就能够集成在微信小程序用于直播，同时也很好避免了高延迟以及回声的情况出现，适用于小程序进行课堂直播以及安防行业等场景。

视频直播点播服务器EasyDSS流媒体服务器能够提供一站式的转码、点播、直播、时移回放服务，极大地简化了开发和集成的工作。点播功能主要包含：上传、转码、分发。直播功能，主要包含：直播、录像，直播支持RTMP输入，RTMP/HLS/HTTP-FLV的分发输出；录像支持自定义保存时长、检索及下载。提供丰富的二次开发接口，基于JSON的封装及HTTP调用。提供播放鉴权、推流鉴权等安全保证。提供用户及相关权限管理配置。

---