单播断流,单播内容无法收看

我们EasyDSS流媒体服务器是一套集流媒体点播、转码、管理、直播、录像、检索、时移回看于一体的一套完整的流媒体服务器解决方案。
最近我们的研发在测试新版本的流媒体直播服务器的时候，发现了一个新问题，就是我们的虚拟直播的直播状态显示不正常，在直播已经开启的情况下却显示“尚未直播”。研发跟我说这个困扰的时候都面露难色，不过很快他就调整好了心态继续排查问题。
我们首先查看了直播代码，但并无所获，因为代码都是正确的；随后我们又进入视频直播的界面查看了直播的编辑页面，才发现了问题所在，是此处的推流时间到期了：
我们当初研发的时候设置了这个推流有效期，是为了更便捷用户的使用，在不需要进行直播的时候能自动断流，当输入有效期之后，直播就会在这个有效期之内进行，当有效期为空的时候，直播就会一直有效。各位开发者在使用的时候可以注意一下这个有效期的设定。
所以各位开发者或者用户如果发现有类似的问题，首先排查这个有效期是否有修改，如果这里没有问题，再排查代码是否有错误，自己解决有难度的话也可以联系我们解决。

这个sh是它的服务启动脚本。也就是说，你下载下来传到linux后，解压出来它里面会有一个文件叫做startsh，切换到这个目录下，使用命令 sh startsh 或者 /startsh就能运行了。

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

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

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

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

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

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

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

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

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

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

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

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

视频直播点播服务器EasyDSS流媒体服务器能够提供一站式的转码、点播、直播、时移回放服务，极大地简化了开发和集成的工作。点播功能主要包含：上传、转码、分发。直播功能，主要包含：直播、录像，直播支持RTMP输入，RTMP/HLS/>