技术开发

后来通过分析版本功能，联想到新旧数据库所有的表结构不一样，于是重新部署了完整的集群版本，添加一个设备后，将新旧数据库拿出来做对比，发现Device这张表的表结构不一样。

当前项目使用了多个平台及设备以实现视频直播、录播、存储、屏幕共享等教学功能，存在设备集中管理困难、视频资源无法统一汇聚管理，多个系统与平台共存，数据互通难。

如果视频源流原始数据包卡顿，就会出现在平台播放时，花屏播不出的现象。于是对接用户，让其排查下级平台是否存在网络异常问题。经排查，原来是网络故障，重新接入后将该问题解决了。

添加如下代码，可将Ehome协议接入的设备查询出来的设备录像，在播放时传入对应的文件名称给设备，根据回调出来的流数据，推送给对应的内核地址，最后将回看的播放地址返回给前端。

将设备接入到EasyGBS平台后，发现拉取实时流总是超时。排查时发现，设备没有发流数据，于是替换为接入EasyCVR平台做对比测试，此时拉取实时流视频可以正常播放。

GB28181协议会话通道使用的是SIP协议，实时音视频点播采用SIP协议中的INVITE方法实现会话连接，采用RTP/RTCP协议(IETF RFC3550)实现媒体传输。

在项目应用中，有用户需要记录每个接口调用的具体IP和url路径参数，因此我们在EasyCVR平台中加入了路由日志功能。

发现用户设置的默认播放协议为WS_FLV。但是，FLV协议在iOS端是无法播放的。iOS端目前只支持WebRTC和HLS两种协议。

在排查过程中发现，对应的图片组件创建了两次，对raw格式的图片解码了四次，出现了重复调用的情况。在当前页面进行解码，避免重复解码、重复调用。

登录设备进行观察，设备端的平台能正常观看。测试使用RTSP、SDK协议接入EasyCVR，并无上述问题出现。通过这些测试，我们排除了设备和平台方面的故障。

在发送SYN的时候，一直报端口占用（如下图）错误，于是我们分析是在发送SYN之前，程序已经对本次的拉流端口进行监听了。

在创建播放器时，对m3u8地址进行一次监测，如果地址为404，则延迟2.5后再次检测，直到m3u8地址返回200，才进行正常播放操作。这样可以实现以最快的速度起播，避免15s等待时间。

通过查看接口日志发现，用户的EasyCVR平台各个时间段都有人在调用接口，现场设备码流都很大，导致消耗的流量过高。

通过抓一段时间的包，然后将数据包拷贝出来，用wireshark打开后筛选http，这样也可以查看到详细的接口调用。

首先将视频正常打开后，切换到FLV码流，复制流地址，通过VLC播放。如果VLC断开，则表示流断开。观察一段时间后，出现断流情况，于是我们迅速利用wireshark进行抓包，并进行拉流操作，然而此时并没

首先找到对应对讲时间代码，经排查发现打开麦克风的api无效，修改对应的打开麦克风的api。最后将修改后的发布在HTTPS上测试，成功实现与摄像头的对讲功能。

现场使用的为公网地址，但在配置中心没有配置公网ip，导致在使用推流的过程中设备一直是往内网ip进行推流，所以平台一直没有接收到视频流。需要在配置中心进行更改。

FFmpeg具有非常强大的功能，包括视频采集、视频格式转换、视频抓图、给视频加水印等，同时还能兼容多个操作系统，比如Windows、Linux、Mac。ffmpeg可以在任意采样率之间进行转换

上级平台不支持将密码设置为空。将修改后重新编译的版本提交用户。显示能够正常级联，上级也可正常查看级联设备。

在回复上级invite请求的200OK消息中，需要在connect字段里带上下级平台的公网地址，这样上级平台才会发送ACK消息到下级平台，进而才能正常播放。