告警录像服务开发工作量还是挺大的，初步统计，大约有10个接口需要开发，而且CMS服务相关接口也需要开发。

这里主要说一下告警视频的文件保存格式，本来想使用内存块的方式进行保存，但是考虑到这种作为逻辑比较复杂，对文件块的管理也很复杂，由于告警录像实际应用中，并不是太频繁。所以决定采用文件方式进行保存。

传统的文件方式保存，需要连个文件进行保存，一个是视频流的文件，一个是索引的文件，这样同步起来其实挺麻烦的。

由于告警录像普遍大小不大，所以这里采用一个文件进行保存，前面保存视频数据，写完之后，在写入rtp头的数据，最后写入rtp头的数量，最后写一个结束标识符，说明录像结束。

-------------------------2018--09-11修改-------------------

本来计划，来的数据就保存下来，然后rtp包存在后面，不就对rtp包进行合并整理了，现在发现存在一个很大的问题。

由于需要做码流的控制，即一秒发送25帧数据，但是如果按照原先的计划进行保存的话，如何进行流控，就成了一个很大的问题，

所以这里在读取到数据之后，需要做一些简单的处理工作。

对rtp包进行解析，把同一个帧的rtp包放到一个类里面，在判断这个类的类型，如果是视频就继续发送，一秒发送25个包，如果是音频，就不管这个约束。

另外，还需要开启两个线程，一个是解析线程，一个是发送线程。这里方式可以解决播放的问题，但是又出来一个新的问题：

当用户执行拖拽的时候，麻烦来了，非常难定位到从那里开始读取视频流，应为我们的视频流的保存rtp头里面只有这个rtp数据包的信息，很难执行快速拖拽，而且，这个需求感觉无法解决，必须要把每个rtp头的流的信息在文件的位置保存下来，不然快速拖放不可能实现。

解决方案：

不能把rtp包头直接存放这种偷工减料的方法，需要把文件的位置保存下来。

重新设计头信息：

决定在原先的rtp头的基础之上，增加一个相对于文件开头的位置信息，目前定义为4个字节

这样可以实现拖拽的操作控制了。好烦躁，解析rtp头在拼接不是人干的。

我还是决定一帧一帧的保存吧。

帧头信息需要保存下面信息：

decodeid 16 bit

framerealtime 8bit

m：8 bit

pt：8 bit

seekpos：32 bit

计划按照上述格式来写录像格式

欢迎使用...........................................................................................................................................2 1. 产品简介 ..................................................................................................................................6 2. 系统要求 ..................................................................................................................................6 2.1. 基本配置...............................................................................................................................6 2.2. 推荐配置...............................................................................................................................6 3. 软件安装与卸载.......................................................................................................................6 3.1. 软件安装...............................................................................................................................6 3.2. 软件卸载...............................................................................................................................7 4. 操作指南 ..................................................................................................................................8 4.1. 登陆界面...............................................................................................................................8 4.2. 系统界面...............................................................................................................................9 4.3. 主界面说明...........................................................................................................................9 4.4. 标题栏基本操作和功能.....................................................................................................11 4.5. 树形目录基本操作和功能.................................................................................................11 4.5.1. 添加网络............................................................... 之前就已经具备了本地回放、远程回放、设备播放3个模块，其中本地回放用来回放存储在软件本地电脑上的 视频 文件；远程回放需要通过调用厂家sdk或者GB28181（没实现，后期考虑增加）从NVR回放 视频 ；设备播放通过通用的rtsp规则 视频 流的形式调用nvr存储 录像 或者实时 录像 回放；近期增加了个图片回放模块，是用来回放图片文件夹中的图片文件的，排队绘制图片序列，看起来有点 视频 的感觉。 有一种场景是，用户自己的人工智能算法，能够拿到一堆图片序列，自定义规则存储，触发报警后也拿到一堆图片序列，这样可以通过这个模 hikali8787: 这个""在C++中相当于地址，指向包含该字符串的代码区，不可改变指向的值，所以只能被由const修饰的char*变量指向。举个例子：[code=cpp]const char* p = "asd";[/code]其中，"asd"这个字符串处于代码区，和你其他代码放在一起，而p处于栈区，p的值就是处于代码区的"asd"的地址。我们只能通过p获得字符串的值，但不能修改。这是加const的原因。至于空字符串，则可写作：[code=cpp]const char* p = "";[/code]最后这种表达方式：[code=cpp]const char* p = '\0';[/code]'\0'的ASCII码值就是0，所以你相当于把p赋成了0，即0x0，等价于NULL，而地址为NULL的内存空间处的字节刚好就是0x0，所以strlen出来就等于0了。 ffmpeg之H265解码 g0415shenw: 如果只是合并像素，简单呀，如果是还要去掉重复的部分，我就没搞过了。 ffmpeg之H265解码 大佬，请教一个问题：我获取8路摄像机的h264码流，调用海思的库进行解码，我想把解码后的8视频进行拼接成一路视频流，就有什么办法可以完成拼接。