嵌入式多媒体开发技能树

[hnsqlisai]

• 1、概述

涂鸦IPC，通常主码流为H.265，子码流为H.264。本文主要介绍H.264和H.265文件格式。

Code: Select all

H.264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC（或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC），在1998年起草，于2003年3月正式发布。

H.265是ITU-T VCEG继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。H.265的推出时间是2013年2月。标准全称为高效视频编码HEVC（High Efficiency Video Coding）。

H264的压缩比大概达到300₄₀₀:1。同样的画质和同样的码率，H.265比H2.64 占用的存储空间要少理论50%；

• 2、H.264

在H.264/AVC视频编码标准中，整个系统框架被分为了两个层面：视频编码层面（VCL）和网络抽象层面（NAL）。

2.1 VLC
VCL 数据即编码处理的输出，它表示被压缩编码后的视频数据序列。在 VCL 数据传输或存储之前，这些编码的 VCL 数据，先被映射或封装进 NAL 单元中。如上图。
2.2 NALU和NAL
每一帧就是一个NAL单元（NALU）。

NALU 通常由 3 部分组成：
标识码+NALU Header+有效载荷。
标识码：标识NULU的开始，必须是“0x00000001”或“0x000001”。
NALU Header：NALU类型(5bit)、重要性指示位(2bit)、禁止位(1bit)。
第 0 位禁⽌位，值为 1 表示语法出错 ；
第 1，2 位为参考级别；
低 5 位为 NALU Type；

Code: Select all

    NAL单元结构体如下：

Code: Select all

NALU Type  对照表：

2.3 SPS，PPS，I帧，P帧
SPS (Sequence Parameter Set)序列参数集,作用于一-串连续的视频图像。 如seq_ parameter_ set_ id、帧数及POC(picture order count)的约束、参考帧数目、解码图像尺寸和帧场编码模式选择标识等。

Code: Select all

PPS (Picture Parameter Set)图像参数集,作用于视频序列中的图像。如pic_ parameter_ set_ id、 熵编码模式选择标识、片组数目、初始量化参数和去方块滤波系数调整标识等。SPS和PPS是在IDR帧之前成对出现的。

Code: Select all

IDR，IDR帧属于I帧。视频中最关键的一些帧。

Code: Select all

P 帧，视频参考帧。

[hnsqlisai]

• 3 H.265

和H264/AVC结构类似，H265/HEVC也采用了视频编码层（video code layer ，简称VCL）和网络适配层（network abstract layer，简称NAL）.VCL层包含了视频压缩的数据， NAL主要负责对数据的压缩数据进行划分和封装，保证数据在磁盘上保存和网络上进行传输。

Code: Select all

和 H264 的码流结构一样，也是通过启始码（0x000001或者0x00000001）进行分割压缩数据，每一个称为NAL单元（NAL Unit，简称NALU）。NALU有不同的类型，主要是对数据内容进行区分。

对于一个码流文件来说，和H264一样，有一系列的NALU的类型定义，可以分为VPS,SPS,PPS,SEI,I帧,P帧 6种类型。码流结构如下所示：

Code: Select all

[i]启始码+VPS+启始码+SPS+启始码+PPS+启始码+SEI+启始码+I帧+启始码+P帧+启始码+P帧+.....[/i]

从上面可以看到[b][color=#FF0000] h265 比 h264 多了一个 VPS[/color][/b]，VPS 是视频参数集。

3.1单元NALU的结构
可以看到上面的数据和h264一样，H265的NALU的结构也是：启始码+ NALU头+NALU数据。如果NALU对应的Slice为一帧的开始（即视频流的首个NALU）就用0x00000001，否则就用0x000001。

启始码：是一个固定值4个字节00 00 00 01（十六进制）或者3个字节00 00 01（十六进制）
NALU的头大小为2个字节，第1为是0，第2-7位是NALU的类型，表示该NALU的数据内容是什么类型的，是VPS，SPS,PPS，SEI，I帧还是P帧。第8-15位是1。
NALU的数据就是编码器编出来的图像信息或者图像压缩数据了。

VPS（视频参数集）NALU的头值为0x4001（十六进制），取出2-7位（40 & 0x7E）>>1 =32(十进制)
SPS(序列参数集)NALU的头值为0x4201（十六进制），取出2-7位（42 & 0x7E）>>1 =33(十进制)
PPS(图像参数集)NALU的头值为0x4401（十六进制），取出2-7位（44 & 0x7E）>>1 =34(十进制)
SEI(补充增强信息)NALU的头值为0x4e01（十六进制），取出2-7位（4e & 0x7E）>>1 =39(十进制)
I帧 NALU的头值为0x2601（十六进制），取出2-7位（26 & 0x7E）>>1 =19(十进制)
P帧 NALU的头值为0x0201（十六进制），取出2-7位（02& 0x7E）>>1 =1(十进制)

Code: Select all

下图为FH8636平台的h265 数据排列，VPS等帧成员变量信息不再详细描述。

VPS， 0x4001：

Code: Select all

SPS，0x4201：

Code: Select all

PPS，0x4401：

Code: Select all

I帧，0x2601：

Code: Select all

P 帧，0x0201：

3.2 H265相比H264做了哪些改进
1、降码率

同样的画质和同样的码率，H.265比H2.64 占用的存储空间要少理论50%；

2、新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置；　　

3、采用了块的四叉树划分结构；

4、算法优化；

• 4、FAQ

1、如何区分NAL起始码与数据中的“0x00000001”？
（以下解释来自：《新一代视频压缩编码标准—H.264/AVC》，毕厚杰）

2、如何判断视频流是H264 或者H265？
每一个SPS、PPS、IDR都是一个NALU，正常情况NALU的格式都是 ： 开始码+NALU头+NALU数据。所以拿到流只需要解析出NALU以及能正常取到头部信息。开始码通常为00 00 01 或 00 00 00 01，NALU头数据可以用来判断是VPS、SPS、还是PPS。但是要注意的是h264头部长度和h265头部长度是不一样的。

• 5、参考

1）https://zhuanlan.zhihu.com/p/456929686

2） https://blog.csdn.net/u014470361/articl ... s/89541544 h265 Nalu类型详细解析

3） 《新一代视频压缩编码标准—H.264/AVC》，毕厚杰

[fallen-queen]

1. P2P传输
1.1 什么是P2P穿透？

由于NAT（网络地址转换）的存在，两个不同局域网下的设备，无法直接通过局域网ip直接实现通信。为实现这两台设备之间的通信，一种方式是借助公网的服务器，通过转发的方式，实现通信。然而，云端服务器转发的方式可能存在以下缺点：

• 音视频传输业务流量较大，服务器转发负载高；

• 转发相比于直连而言，受网络波动影响较大。

在这种情况下，P2P穿透应运而生。P2P穿透的思路比较简单，既然局域网ip不能进行直接通信，那如果拿到局域网下设备对应的公网ip地址，则可以尝试通过公网ip地址，实现直接通信。
通过STUN协议，可以获取局域网下设备的公网ip地址。局域网下的设备，向公网的STUN服务器发送Binding Request，STUN服务器向设备回复Binding Response报文，该报文中携带设备的公网ip信息。
1.2 实时P2P预览

涂鸦IPC的实时预览功能，基于P2P穿透技术，实现了音视频数据的传输。当用户在APP上点击视频预览时，主要发生了以下流程：

• APP端向设备端，发送offer信令，发起P2P会话请求；

• 设备端收到offer信令，回复answer信令；

• APP端和设备端，通过STUN协议，进行P2P穿透；

• 如果P2P穿透成功，则APP和设备，可以通过直连的方式，传输音视频数据；

• 如果P2P穿透失败，则通过TURN服务器进行数据转发；

• IPC设备，将音视频数据打包成RTP格式，通过P2P直连链路/TURN转发链路，发送给APP端。

2. WebRTC
2.1 什么是WebRTC？
WebRTC，即网页即时通信（Web Real-Time Coummunication），是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源，并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。
2.2 WebRTC历史
WebRTC作为一项音视频即使通信领域的新兴技术，逐渐受到越来越广泛的应用。

2.3 WebRTC交互模型

WebRTC交互主要分成三步：

• 通过ICE(STUN+TURN)实现P2P穿透，创建数据通信链路；

• 通过DTLS协议，协商出用于数据加密的密钥信息；

• 通过SRTP协议，在P2P链路上，对数据进行加密后传输。

涂鸦IPC SDK目前自带WebRTC功能，通过WebRTC协议，可以接入echoshow和chromecast设备。

3. 推流服务
对于第三方设备（echoshow和chromecast），早期echoshow只支持rtsp协议，chromecast只支持hls协议，不支持WebRTC协议，TUYA IPC无法通过WebRTC协议，接入到echoshow和chromecast。在这种情况下，TUYA在云端部署了推流网关服务，用于协议转换。

当echoshow通过RTSP协议接入时，由于RTSP协议本身的限制（RTSP client无法向RTSP Server发送音视频数据），echoshow无法将音频对讲数据发送给IPC，而WebRTC无此限制，支持语音双向对讲。

hls协议相比于WebRTC协议而言，需要缓存10秒左右的数据，会存在较大的延迟。

4. RTSP
4.1 RTSP简介
RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。该协议定义了一对多应用程序如何有效地通过IP网络传输多媒体数据。
4.2 RTSP报文结构
RTSP是一种基于文本的协议，使用CRLF作为一行的结束符。
请求报文

Code: Select all

METHOD  URL  \r\n        ->  请求行
HEADER_NAME: VALUE\r\n   ->  头部
HEADER_NAME: VALUE\r\n
\r\n
BODY                     ->  主体

METHOD

版本
RTSP/1.0

HEADER

回复报文

Code: Select all

版本  状态码  状态信息\r\n
HEADER_NAME: VALUE\r\n
HEADER_NAME: VALUE\r\n
\r\n
BODY

4.3 RTSP交互过程

RTSP交互过程可以分成两个阶段，第一阶段是RTSP的信令交互，第二阶段是将音视频数据进行RTP封包，然后发送给对端。RTSP信令交互主要过程如下：
（1）OPTIONS
Client->Server: 客户端向服务端查询，支持的方法（METHOD）
Server->Client: 服务端回复支持的所有方法，如OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
（2）DESCRIBE
Client->Server: 客户端向服务端查询sdp信息
Server->Client: 服务端回复sdp信息
（3）SETUP
Client->Server: 创建音频/视频会话
Server->Client: 服务端返回session id
（4）PLAY
Client->Server: 客户端请求播放
Server->Client: 服务端回复

在完成RTSP的信令交互之后，就可以进行RTP传输了。RTP既支持UDP传输，也支持TCP传输。当RTP使用UDP方式传输时，RTSP Server需要创建udp server，传输音视频数据；当RTP使用TCP方式传输时，RTP传输和RTSP信令通道复用同一条TCP连接。

[0x1abin]

1. 加密算法
在数字加密算法中，可以简单的划分为两种：
对称加密算法非对称加密算法
如何理解呢？

1.1 对称加密算法
对称加密算法，加密和解密的密钥使用的是同一个。
密钥只有一把，所以密钥的保存变得很重要。一旦密钥泄漏，密码也就被破解。

1.2 非对称加密算法
非对称加密算法需要两个密钥：公开密钥（简称：公钥）和私有密钥（简称：私钥），一般是公钥  加密，私钥解密，反之亦然。
公钥和私钥是一一对应的关系，有一把公钥就必然有一把与之对应的、独一无二的私钥，反之亦成  立。
所有的（公钥, 私钥）对都是不同的。
用公钥可以解开私钥加密的信息，反之亦成立。
同时生成公钥和私钥应该相对比较容易，但是从公钥推算出私钥，应该是很困难或者是不可能的。

1.3 对称加密 VS 非对称加密

几个概念：

用于对称加密算法的密钥：对称密钥；
用于非对称加密算法的密钥：非对称密钥；
启发：
利用对称加密算法和非对称加密算法的优点，我们可以有这个启发。
●用非对称密钥来加密传输对称密钥（利用了非对称加密算法传输安全的优势）
●用对称密钥来加密传输目标数据（利用了对称加密算法速度快的优势）
这其实就是 TLS 中最核心的部分。

1.4 扩展：摘要算法
摘要算法的特别的地方在于它是一种单向算法，用户可以通过摘要算法对目标信息生成一段特定长度的   唯一 hash 值，却不能通过这个 hash 值重新获得目标信息。因此摘要算法常用在不可还原的密码存储、信息完整性校验等。
常见的摘要算法：MD5、SHA1、SHA256等

2. 什么是 TLS ？
在上一个章节中，我们提到了通过利用对称加密算法和非对称加密算法的各自优点是 TLS 中最核心的部分，那什么是 TLS ？在说明什么是 TLS 之前，我们需要了解一下什么是 TCP/IP 网络模型。

2.1 TLS 在网络协议中的位置

从上图可以看出，其实 TLS 就是在传输层和应用层之前加了一个 SSL/TLS 的加密传输层，比如：
●HTTP 中加上 SSL/TLS 就是 HTTP over TLS ，其实就是我们通过所说的 HTTPS
●RTSP 中加上 SSL/TLS 就是 RTSP over TLS

那其实际效果是什么呢？

从图中可以看出，在不使用 SSL/TLS 的 HTTP 通信，随便使用一个抓包工具，就可以获取客户端和服务器的通信内容，这是不安全的。
不安全体现在以下 3 个方面：

●窃听风险：第三方可以获知通信内容；

而 SSL/TLS 协议就是为了解决上面提到的 3 个风险而设计的，希望能达到： 所有的消息都是加密传输的，第三方无法窃听；
●所有通信都具有校验机制，一旦被篡改，通信双方都能立刻发现；
●使用数字证书，防止身份被冒充。
●不可否认已经发生的行为

2.2 TLS 的握手过程
有了 SSL/TLS 协议，能保证数据在网络中安全的传输，下面我们以 HTTPS 通信为例，简要的说明 TLS
是如何保证安全的。一个 HTTPS 通信主要可以分成 4 个部分：

1. 三次握手（开始）
2. TLS 握手（协商“会话密钥”）
3. 加密数据传输（使用“会话密钥”传输数据）
4. 四次挥手（结束）
   注意：“会话密钥” 是通过 TLS 握手协商出来的对称密钥；
   下图是客户端和服务器的交互抓包，可以清晰的看到这四个部分。

   

   其中最终要的就是 TLS 的握手过程，TLS 握手过程可以简化为下图。

   

下面对流程进行详细说明：

2.2.1 第 1 次通信（客户端发出请求）
首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做 Client Hello 请求。在这一步，客户端主要向服务器提供以下信息。
（1） 支持的协议版本，比如 TLS 1.2 版。
（2） 一个客户端生成的随机数，稍后用于生成"会话密钥"。
（3） 支持的加密方法，比如 RSA 公钥加密。
（4） 支持的压缩方法。
（5） 扩展字段

Client Hello

2.2.2 第 2 次通信（服务器回应）
服务器收到客户端请求后，向客户端发出回应，这叫做 Sever Hello。服务器的回应包含以下内容。
（1） 确认使用的加密通信协议版本，比如 TLS 1.2 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
（2） 一个服务器生成的随机数，稍后用于生成"会话密钥"。
（3） 确认使用的加密方法，比如 RSA 公钥加密。
（4） 服务器证书。
（5） 服务器回复结束的通知

Server Hello

密钥加密套件的理解：基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」
至此客户端和服务器都拥有了两个随机数（随机数 1 + 随机数 2），这两个随机数会在后续生成“会话密钥”时用到。

Certificate

服务端会将自己的证书发给客户端，用于身份验证，验证成功后（关于证书的验证会在下个章节中详细  说明），可以从证书中获取到公钥，用于后面随机数 3 的加密。
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供"客户端  证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

[0x1abin]

Server Key Exchange

这个消息是用来发送密钥交换算法相关参数和数据的。这里要提一下，就是根据密钥交换算法的不同，  传递的参数也是不同的。
常用的密钥交换算法：RSA、DH（ Diffie-Hellman ）、ECDH（ Ellipticcurve Diffie–Hellman ）。

Server Hello Done

这个就是 Server 来表示自己说完了。类似电影里别人拿对讲机说完话最后会有一个“完毕”。

2.2.3 第 3 次通信（客户端回应）
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与  实际域名不一致、或者证书已经过期等，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
（1） 一个随机数（随机数 3）。该随机数用服务器公钥加密，防止被窃听。
（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内 容的 hash 值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第 3 个随机数，又称"pre master key"。有了它以后，客户端和服务器就同时有了 3 个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

Client Key Exchange

这个也是交换秘钥参数。到这边客户端会在生成一个随机数 3 。

Change Cipher Spec

编码改变通知。这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是  一条事件消息。

Finished

这一步对应的是 Client Finish 消息，客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致     的。

2.2.4 第 4 次通信（服务器的最后回应）
服务器收到客户端的第三个随机数pre master key之后，计算生成本次会话所用的"会话密钥"。然后， 向客户端最后发送下面信息。
（1） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2） 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内 容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

Change Cipher Spec

编码改变通知，这一步是服务端通知客户端后面再发送的消息都会使用加密，也是一条事件消息。

Finished
这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。到这里双方 SSL/TLS 握手完成。

4. TLS-PSK 模式
4.1 什么是 PSK
PSK(pre-shared key)，预共享密钥——就是通信双方使用提前部署好的预共享密钥(用于对称算法)建立 TLS 连接的机制。

PSK 的主要逻辑是：
1.分别在 client 和 server 部署相同的对称加密秘钥 (psk_key)；
2.每个 psk_key 对应有一个 psk_id， client 发送该 psk_id 给 server, server 通过 psk_id 查找对应的 psk_key，如果查到，就用该 psk_key 去直接加密后续的数据，不再进行非对称加密。

4.2 为什么使用 PSK 模式
但使用证书有几个问题：
1.证书需要非对称算法，在性能受限的嵌入式设备下，不管是 RSA 还是 ECC，加密相同强度都比对称算法慢；
2.认证过程需要发送证书，证书通常比较大，需要更大的 TLS buffer，需要传输时间比较长。

所以，PSK 就解决这样的问题：
1.PSK 可以只需要对称算法，不使用非对称算法，节约 CPU 计算资源；
2.认证时 PSK 可以传输较小的数据量，节约内存和带宽。

4.3 涂鸦 TLS-PSK 的密钥部署方式
涂鸦设备使用的 psk 由涂鸦生产系统统一生成管理，通常在模组生产时写入 pskkey，psk_id 由原有的授权信息上的 uuid 和 authkey 加盐生成。

4.4 TLS-PSK 的握手过程
完整握手流程如下：

主要步骤如下:
1.client 如果希望使用 PSK 进行握手，就在 CH 中加入 PSK 加密套件发送给server;
2.server 如果也希望使用 PSK，就在 SH 中回复相应的 PSK 加密套件；
3.server 不再发送 Certificate和CertificateRequest，因为这时候不需要证书了；
4.client 和 server 都可能有多组 psk_key，server 可以在 SKE 中发送一个 psk identity hint 的东西(类似索引之类的)帮助 client 去选择相应的 psk_key；如果没有 psk identity hint，就不发送 SKE 了；
5.client 把希望使用的 psk_key 对应的 psk_id 放到 CKE 中，发送给 server;
6.server 收到 CKE 后，根据其中的 psk_id 选择相应的 psk_key，然后将 psk_key 当做预主密钥 (pre master secret) 进行后续的秘钥推导；

[kervin]

本地存储，是IPC的基础功能，负责管理SD卡、将音视频和图片等数据按特定目录和文件结构存储到SD卡上的通用文件系统、并支持数据的各类操作（检索、回放、下载、删除等）。以下按照自底而上的顺序，介绍本地存储功能。

图 本地存储层次结构

一、SD卡管理
包括卡的热插拔监测、卡格式化、卡状态维护。
1.1、卡的热插拔监测，具体是在监测到SD卡插入时，识别文件系统并挂载，以供数据的读写；SD卡拔出时，停止数据的录像、回放等操作、并卸载文件系统。

1.2、卡格式化，由用户在手机APP上触发，会清空卡数据、使卡处于正常工作的状态。

1.3、卡状态，有卡不存在、卡正常工作、卡异常。卡异常，原因主要有无文件系统、文件系统不支持、文件系统损坏、坏卡等。
备注：为保证足够读写性能，建议选用主流品牌、class10以上的SD卡。

二、目录和文件结构
IPC本地存储，采用通用文件系统，以私有格式文件存储音视频和索引、jpg格式存储图片，按多级目录、特定文件名组织文件以加速检索。具体目录如下，

Code: Select all

DCIM           // 涂鸦存储目录，位于SD卡的文件系统的顶层目录

  ├── CHAN0  // 单通道IPC或多通道IPC的第一个通道的录像存储目录

  │   └── 2022

  │       └── 10

  │           └── 14

  │               ├── 1665732067_0014     // 事件文件夹，记录utc时间1610294375开始的录像，时长14秒

  │               │   ├── 0000.media      // 音视频文件，采用涂鸦私有格式，从第0秒开始

  │               │   ├── 0010.media      // 从第10秒

  │               │   ├── 1665732067.jpg  // 事件封面图

  │               │   └── .info           // 录像括视频格式、事件类型

  │               └── day_idx.bin         // .info文件的索引

  ├── CHAN1

  │           。。。                      //多通道IPC的第二个通道的录像存储目录，内部结构同CHAN0

  │   

​

  └── ipc_emergency_record    // 本地相册，相册名“ipc_emergency_record”

  ├── thumbnail           // 缩略图目录

  │   ├── xx1.jpg         // 视频源文件xx1的缩略图

  │   └── xx2.jpg         // 图片源xx2.jpg的缩略图

  ├── xx1.mp4             // 视频源文件

  └── xx2.jpg             // 图片源文件

目录分为录像、本地相册2大类，业务上彼此独立。
2.1、录像的目录，按年、月、日、事件文件夹、音视频文件的多级组织。音视频文件，采用涂鸦私有格式存储音视频数据，以.media作为后缀，单文件最多存储10s录像。事件文件夹，是对多个时间连续的音视频文件的包裹，最多包含600秒录像；事件录像模式下，一个事件文件夹一般对应一个事件持续期间的录像；连续录像模式下，事件文件夹多为600秒。
2.2、本地相册的目录，按相册名-源文件-缩略图的形式组织。

三、录像
3.1、录像记录
录像模式有3种：不录像（任何时候不录像）、连续录像（7*24小时持续录像）、事件录像（仅在有事件发生时录像，支持预录）。
预录，是指事件发生前N秒的视频，也能存到SD卡。N最大值受限于ringBuff时长，比如ringBuff有10s，N最大可为9s。
录像加密，是指对音视频数据加密后再存储，默认不启用。
循环覆盖，存储空间不足120MB时，程序自动删除时间最老的录像，为新录像腾出存储空间。每次删除一个事件文件夹。

3.2、录像检索
月历检索，检索该月哪些天有录像。
进度条检索，检索SD卡中某天的录像时间的分布。

3.3、录像回放
是指读取SD卡中的音视频数据，按照一定速率、有选择地传输给客户端做显示。录像回放，支持回放状态控制、进度条跳转、倍速等特性。
回放状态控制，有开始、暂停、恢复、结束。
倍速回放，加快或减慢数据读取和显示的速度，支持的倍速有0.5、2、4、8倍。

3.4、录像下载
读取SD卡中的音视频数据，尽量快地传给APP等客户端。

3.5、录像删除
按天删除，由用户在APP上触发，删除某一天的录像。

四、本地相册
借鉴手机的系统相册概念，由设备端实现的媒体文件存储，支持相关数据的检索、下载、删除等操作。
为支持不同业务场景，本地相册支持多个实例、以相册名进行区分，如行车记录仪的紧急录像、缩时录像等。

4.1、相册记录
新增数据流程为，存储源文件、存储缩略图、更新索引。
源文件：音视频录像、图片等，采用多媒体标准格式文件，便于客户端解析。
缩略图：本地相册提供缩略图文件。
索引：用于加速相册查询。

4.2、相册查询
查询目标相册的文件信息。

4.3、相册下载
下载目标相册的多个文件。不同于录像回放的交互，客户端下载到完整数据后，才能进行展示。客户端为提升交互（展示数据）的响应速度，可先下载缩略图、后下载源文件。

4.4、相册删除
删除目标相册的多个指定文件。

4.5、应用场景
缩时录像，是将长时间的视频缩短为短时间的录像。具体实现上，采用定时抓图的方案，将抓到的图片存储到“缩时录像相册”。
全景拼接，是将设备拍摄的不同角度的多张照片，用算法拼接成一张大图（全景图）。具体实现上，将一次全景拼接操作拍摄的多张照片的集合（文件夹），视为一个抽象的媒体文件，存储到“全景拼接相册”。