视频监控之告警录像

 告警录像服务开发工作量还是挺大的，初步统计，大约有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

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