技术开发

我们之前大致给大家介绍了带宽的分类和计算方法，要保证视频传输的稳定，基础就是保证带宽足够，因此在项目开始前，需要对带宽做大致测算，根据带宽可以选择合适的视频传输质量。

BS和CS两种架构针对不同的场景有不同的应用需求，简单来说，BS主要支持浏览器的无插件直播，而CS主要是在客户端直播方面发挥作用。CS架构要先于BS架构出现，BS架构是CS架构的一种变化或者说是改进

WebRTC作为一个工具箱，相较于传统的视频会议有更好的安全性、良好的兼容性、增强网络的优势。webrtc主要是怎么使用这三大线程的，其实线程的使用主要还是在线程上执行代码和线程间的切换。

本文主要讲分享EasyNVR直播时实时录像调用的方法。调用开始录像之后，我们再调用停止录像的接口，会获得一个返回值，可以根据这个链接进行下载刚刚的实时录像。

因此如果网络不佳，频繁超时后台也不会做任何处理，设备会一直处于掉线状态。针对这种现象，我们对摄像头进行先禁用再启用的操作，随后则可以在初始化后拉到视频流。

除了平台本身的运行情况以外，我们最常关注的就是实际项目中EasyDSS所具备的承载量，如果设备过多，服务器承载又不足，则有可能造成系统运行的堵塞。

还有一点大家需注意，/api/v1/devices/stopchannelstream这个接口在接口文档里是没有的，如果需要调用该接口，可以在浏览器上进行调用。

网页对域名进行添加映射时，添加成功后会生成一个外网访问地址，在浏览器中输入外网访问地址，即可查看内网应用

https 由 http 协议和 tls 协议组成，其中 tls 在数据传递后，会使用对称密钥算法进行加密传输数据。使用的对称密钥算法，随着时间的过度，部分密钥算法被认证为非安全。

webrtc及时性、低延时的优势可以让视频输出行业达到一个新高度，本文我们主要是和大家分享一下开发过程中webrtc建立P2P的流程，流程主要分为两个部分，一个是发起端，一个是接收端，下面就这两个部分

视频采集后需要一台Nginx服务器来进行处理，采集视频录制端传输的视频流(H264/ACC编码)，由服务器端进行解析编码，推送RTMP/HLS格式视频流至视频播放端。

播放一个RTMP协议的流媒体需要经过以下几个步骤：握手，建立网络连接，建立网络流、播放。服务器和客户端之间只能建立一个网络连接，但是基于该连接可以创建很多网络流，这也是RTMP推流协议的一个特点。

除了录像方式可以自定义外，录像回看也可以根据日期来检索。但是在日常对EasyNVR的检查时，我们发现录像回看通过日期检索时，日期呈现灰色不可点击，需要日期切页才显示。

在我们遇到的某些项目现场上，用户接入设备数过多，会导致日志消息频繁打印，日志过大，出现无法打开日志的问题。

其实视频播放的卡顿问题我们说过很多遍，造成卡顿的原因有很多，摄像头码率、网络速率都会对视频播放的流畅度造成影响。

以上只是举个例子，实际上，软件的授权不会影响到软件的启动，成功启动软件后，页面右上角会出现对应的授权提示。

针对EasyDSS的精细优化，我们还在探索当中，但EasyDSS本身来说已经是一个非常完整的视频流媒体服务了，其现存的基本功能已经可以直接投入使用，比如在线教育、在线医疗等。如果后期有更新，我们也会及

EasyNVR可以输出RTSP、HLS、FLV等协议的视频流，并且还可以调用iframe地址进行第三方集成。

对于一个服务器接入大量的进程或者任务的用户来说，如果使用EasyNVR作为流媒体服务器，我们都会建议搭建多Nginx来实现分流，以此避免卡顿的情况。

近期我们在编译WebRTC时碰到了一些问题，通过C++编译WebRTC项目，获取sdp的数据为空。我们使用windows api调用go服务端接口，接收到的数据为空。