微信如何实现小程序实时视频直播点播？有哪些难点？

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

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

那么现阶段的微信小程序能实现直播功能么？答案是：可以的。视频直播分为两种模式，一种是单向直播，通过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调用。提供播放鉴权、推流鉴权等安全保证。提供用户及相关权限管理配置。

拉流和推流的区别如下：

推流指的是把采集阶段封包好的内容传输到服务器的过程，而拉流是指服务器已有直播内容，用指定地址进行拉去的过程。

主流的推送协议和优缺点

RTMP

RTMP是Real Time Messaging Protocol（实时消息传输协议）的缩写，是Adobe公司为Flash/AIR平台和服务器之间音、视频及数据传输开发的实时消息传送协议。RTMP协议基于TCP，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。

HLS

Http Live Streaming是由Apple公司定义的基于HTTP的流媒体实时传输协议。它的原理是将整个流分为多个小的文件来下载，每次只下载若干个。服务器端会将最新的直播数据生成新的小文件，客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。

WebRTC

WebRTC（Web Real-Time Communication），即“源自网页即时通信”。WebRTC是一个支持浏览器进行实时语音、视频对话的开源协议。WebRTC的支持者甚多，Google、Mozilla、Opera推动其成为W3C推荐标准。