技术开发

我们在进行EasyCVR视频移动端进行播放测试时，iOS系统和Android系统都能够较好适应视频的播放，但是仍收到部分用户反馈称在苹果设备中无法播放的问题。

虽然在目前看来，企业直播已经得到了很大的提升，但其还有进一步的发展空间，而技术水平和稳定性是企业最看重的服务能力，同时，直播功能是否满足企业业务的需求也很重要，某些垂直领域的服务商在这方面更有优势。

EasyNTS有一个支持拉rtsp转推rtmp的功能，该功能需要使用cgo，因此需要构建对应的交叉编译环境。

可以看到提示aarch64，这与我们的软件是不匹配的，因此会出现无法运行的问题。该问题需要通过运行ARM版本的软件压缩包尝试解决。

我们是默认使用的是sqlite数据库，如果sqlite数据库不满足大家的使用需求，也是可以替换成Mysql数据库，之前我们分享过EasyGBS替换Mysql数据库的方式。

这种方式是服务器直接通过网络访问到摄像机来进行视频流的读取，拉取视频信息，从而以自身的流媒体来进行视频流的转换，从而进行视频的播放。

分布式SMS部署是指当用户开始播放流时，由底层负载均衡算法，将Invite请求发送给不同的SMS服务器。该架构理论上能够很大程度的减轻单一SMS播放的负载，提高播放流畅度。

python检查行人会一直往SQLite数据库中写信息，Go代码会每隔一段时间读数据库中的信息，这样SQLite可能相同的数据库会一边在写一边在读取数据，导致数据库出错，写和读都会失败。

uwb具有实时定位和精确定位的双重优势，并且定位的延迟时间较小，优于其他定位技术。但是uwb定位成本较高，目前采用该定位技术的项目较少，只有在对定位需求比较严苛的项目中才会采用该技术。

通过排查代码发现，是在设备播放来流数据的时候程序初始化启动了过多的级联转发程序。所以添加如下代码，只在程序初始化时创建级联初始化，而不是每次来了流数据之后都初始化。

FAST CACHE为存储系统提供Flash驱动器级别的性能，增加了IOPS处理能力的同时，仅将热点数据置于Flash盘内，降低成本。

在编译EasyRTC新版本时，我们采用了ProtocolBuffer(pb)实现部分功能，其中在EasyRTC视频通话接收消息时，由于发送文件buffer格式问题，传输的数据不能经过封装

现场接入数量较大，同时对方需要每个接入点都需要设置准确的经纬度。但一个一个通道的录入经纬度信息，耗时费力，且不能保证录入的准确性，因此需要一个批量导入通道经纬度信息的快捷方法。

人脸库已经部署在 3 个通道上，撤控的时候可对其部署通道的其中 2 个通道撤控，剩余一个通道保持原样。

用户也难免在使用过程中出现程序意外关闭、断流、崩溃等情况，这时用户可能无法及时知道服务是否正常运行，此时需要一个监控程序，定时去验证程序是否崩溃，再发送邮箱通知管理员。

代码中使用了opencv中cv2.VideoCapture的函数，从网上查找这个函数的用法得知，此函数是可以直接传入rtsp流地址的，所以问题解决就简单多了。

首先查看电脑有没有gpu。打开任务管理器，并点击性能，最下面有GPU的信息，如果电脑有GPU的话，说明电脑支持GPU。

将其配置降低，重启设备服务再播，发现虽然有了明显的改善，不会出现卡顿和中断的现象，但是起播还是有点慢。

进入系统硬件盒子，发现设备无法ping通演示网站域名，查看运行软件的服务是否可以直接访问到EasyDSS的服务器，发现ping服务器的IP是正常的，此时就需要查看是否有ping域名也是正常的。

当遇到项目现场有流量较大的情况，大多数用户都比较担心对CPU的占用过大。在EasyGBS的一个现场，客户采用了高码流的摄像头级联到 EasyGBS 中，在运行中发现内存占用非常高。