EasyGBS的博客

前端设备依据EasyGBS平台的SIP信息、服务器IP、SIP端口和密码接入，如果某项有改动，可在平台【配置中心】-【基础配置】里修改，并在前端设备同步。

注册时平台返回白名单权限问题。查看配置文件发现白名单现场是开启的

随着经济的不断发展，对应急救援越来越重视，要求越来越高，但是应急救援信息化建设相对滞后，信息化管理水平有待提高。为进一步全面提升应急救援能力，强化科技在安全生产工作中的先导支撑作用，推进安全生产信息化水平走上新台阶，亟待整合全区安全生产信息资源，加强各部门之间协同工作，逐步形成上行与国家应急部、省应急管理厅、市应急管理局的应急指挥平台，平行与市各行政区应急局及有关职能部门的应急指挥平台，下行与各有关企业安全生产监督平台互联互通，接口开放，协同工作的安全生产综合监管与应急指挥信息平台体系。二、需求

首先，使用navicat工具将EasyGBS根目录easygbs.db打开，找到数据表t_channels。

修改该模块代码的逻辑，在后端增加后端解码，再用ffmpeg转码成base64，最后转给前端返回。重新部署版本后，在相应的配置文件改成后端解码，此时快照已经可以正常显示了。

将上级平台的传输协议改为UDP，此时视频就可以正常打开了。

里面的接口信息没有与token信息校验返回对应数据。所以需要重写接口并将所有的接口token都代入进去。

因为ps文件的特殊性，很多播放器都不支持，所以需要将ps文件转换成mp4文件，方便用户进行播放。

注意：封装方法需要知道每个参数的意义，“暂停和恢复播放”参数都是一样的；用户登录的标识（也就是句柄）和播放的通道编码，所以需要定义以下封装接口。

在进行多录像查询时，由于上一个录像查询没有完成，就进行下一个查询操作，这样会导致只有一个查询录像会有失败的情况。

让下级平台修改收到的catalog消息后回复通道信息，即解决问题。

首先通过抓包分析，发现第一次发送时，上下级平台的音频一致，但是第二次上级平台发送的是新采集的音频，下级平台向设备发送的却是上次的音频

在写入temp文件时，使用绝对路径，让temp.ini文件与easygbs.ini文件处在同一目录下，这样就可以成功修改文件名。

正式开始下载时，需要一个下载时间进度的SDK（IMOS_GetDownloadTime）来查看下载进度，其计算的进度是：当前下载录像的进度 = （当前下载录像文件时间 - 下载开始时间） / （下载结束时间 - 下载开始时间）。由此方法可以算出下载的进度值（范围值：[0:1]）。...

由于在代码中使用的是字符串转换为时间格式（struct tm），是通过strptime函数转换成时间struct tm，而strptime主要用于将字符串格式分解成时间格式（获取每个年、月、日、时、分、钟和秒等），都是位于time.h的头文件中。......

当码率比较大，则会出跳帧、卡顿的现象，实际上视频流并未丢包，这是由于前端播放器遇到高码率H.265时，解码能力不足导致。

在获取播放地址时，根据每一次的请求ip，重新拼接流地址返回给前端。

在使用tcpdump抓包发现，设备录像的列表SumNum值有异常，下级添加的SumNum一直是0。

出现上述现象的原因在于播放器快照未能消失，占据了播放器，导致播放器点击事件异常。通过降低快照层级，即可将该问题修复。

，EasyGBS在调用转码库后，未调用释放转码句柄，导致内存一直得不到释放，所以服务器内存一直升高。该问题解决起来较为简单，我们需要在关闭拉流后，调用资源释放方法即可。

SIP消息中都会生成一个流媒体命令序列号SN，而在大量的SIP消息并发下获取SN号时，可能会出现SN重复的情况，就会导致出现SIP消息回复串了，所以在获取SN的时候，需要加锁处理。

注释掉会出现设置成功没有回复sip消息，所以还需要在回放倍数加上sip消息的回复。

在接口请求时加载loading，接口请求完后loading消失，开始加载播放器。

在RTP收流时，增加RTP排序即可。

需要在切换画面的时候释放通道资源（IMOS_FreeChannelCode）接口调用流程。

使用Wireshark抓包，找到倍数的值，从下图可以看到有个Scale是设置倍数的值。

在配置文件easygbs.ini中，修改参数to_jpg=true。

EasyGBS作为安防市场的主流视频平台，还可同时平稳接入成千上万路的设备。今天小编就和大家科普一下如何在接入大量设备时备份数据库。

启动后，提示使用127.0.0.1不能连接到mysql的数据库，查看mysql数据库是否有skip-name-resolve参数，所以才导致无法启动。

单独启动数据库会显示报错，所以需要修改数据库的配置文件并查看是否有bind-address的参数进行影响。

首先，在调阅实时录像接口前，先调阅开始直播的接口来获取stream id。

在服务器上抓包，通过抓包可以看到，平台已经发送了订阅告警的消息，由于设备端给平台返回400 bad request，才导致无法上传告警信息。

删除这行代码，这代表只是在点开消息和初次加载系统时才调用此方法，从而解决上述的卡顿问题。

检查元素发现，在播放时加载的快照样式被设置成display:none，因此导致播放器出现黑屏现象。于是优化此处的代码。

对弹框样式进行优化，将弹框移到右上角，并增加可以关闭操作的按钮。

在调用RTMP推流库推流的地方打断点调试，发现每过几秒就会重复调用推流。进一步排查发现，代码中存在定时任务检测录像是否开启。如果开启了录像，但是不在推流就会重新推流，但是实际场景中设备一直都在推流。...

开启转码后判断视频流的编码方式，如果是H.265则需要转码，将H.265数据转为H.264数据，再判断是否为I帧，如果为I帧则设置并更新mediaInfo信息，最后推送转换后的H.264视频数据。

决定在上图红框处不做数据选择功能，因为选择功能和右上角加号选择设备功能冲突。从而决定，只在有设备分配加号处选择设备，再将选择的设备显示在红框列表处，以此来解决此处因为设备过多而导致崩溃的问题。......

使用TCP协议播放时，EasyGBS向设备发送invite消息后，设备回复了200OK，但是设备端没向对应的端口发流。

首先查看日志，在查看日志时出现以下的日志信息。开始播放流未完成，就立刻停止播放此句柄。