【无标题】

wesker-杨

已于 2023-06-02 11:36:48 修改

阅读量146

点赞数

文章标签： linux 运维服务器

于 2023-04-21 17:42:22 首次发布

本文链接：https://blog.csdn.net/weixin_48134886/article/details/130293965

版权

更新4月17日至4月21日

1、编译环境的建立

一、解压压缩包：后缀名为.tar。使用的tar -vxf解压，
	如果出现的是.tar.bz2,则采用tar -vxjf的方式，
	原因在于.tar只是进行了打包，并没有进行压缩。
二、环境变量设置：放置在config.mk中。
	里面有7个环境变量参数，其中四个需要设置。

如下：

export PROJECT_CUR_NAME=V8
export CUSTOMER_CUR_NAME=
export PROJECT_SDK=""
export PROJECT_CHIP_NAME=""
export PROJECT_CROSS_DIR=/home/wangyp/project/dtcwyp/opt/vtcs_toolchain/vienna/usr/
export PROJECT_NFS_DIR=/home/wangyp/nfs/V8
export PATH=$PATH:${PROJECT_CROSS_DIR}/bin

PROJECT_CUR_NAME 为工程名字
CUSTOMER_CUR_NAME 库名称？不清楚
PROJECT_SDK 不清楚
PROJECT_CHIP_NAME 不清楚
PROJECT_CROSS_DIR ：编译需要的库，头文件到这个目录下去找
PROJECT_NFS_DIR：项目代码的nfs路径？
PATH 路径下为编译工具链地址

三、对cmake进行配置，如跳过可能会忽略需要编译的部分
如下：编译的模块为"Y"，没有进行编译的模块为"N"

配置完成以后就可以进行编译了。
CMakeLists.txt文件在CMake作用下生成Makefile文件。

2、计划录像中app的连续录像和事件录像的功能实现

两者关系是事件录像存在于连续录像中，
而连续录像包含事件录像。
并且两者同一时间属于互斥关系。
而两者又由一个计划录像的开关进行控制。
且可以设置三段时间，时间重叠部为和集。

		而当时间的开始时间大于结束时间，
		则为第二天的时间
三、必须在上开启录像计划前随便上报一个选项，
	否则在app上无法开启，提示网络错误。

如上图，录像计划将无法开启，所以先要随便上报一个。

四、这里的下发时间和需要设置的时间格式不同，一直设置不对，
	挨个打印变量才发现了区别。

3、扇区

磁盘分了扇区，存放uboot，系统，软件等
如下图：共分了11个扇区

app就是从0x7a0000写入。

图一

图二

图三

由图三知道，id在fixedParam.Other中获得，在图二中，fixedParam.Other来自m_FixedParam。
在图一中得知，m_FixedParam存在于第九扇区，
结合最开始的图得知文件按存放在0xfd0000-0xfe0000中。
所以写入id文件就要从这个地址写。

问题解决：
up里放置了一些版本信息，当版本信息与要升级的一致时，
就不会升级，当不一致时，会启动升级。
param放置了一些参数信息。
pbak放置了一些备份信息。

CUSTOMER_CUR_NAME 表示客户定制的，工程名字。
PROJECT_SDK 表示sdk的名字。一般在服务器上会有比如富瀚的sdk，编译的时候
PROJECT_CUR_NAME 表示工程名。写了以后会单独创建一个文件夹，
放置工程的代码。
PROJECT_CHIP_NAME表示一个芯片可以运行很多ic，
写了这里，会自动找到相应的ic进行编译。
PROJECT_CROSS_DIR：编译需要的库，头文件到这个目录下去找
PROJECT_NFS_DIR：	编译出来将可执行文件放到nfs可以进行网络调试

4月24日至4月30日更新

1、研究Iptool的内容

1-1、initIptool

按程序运行顺序首先执行initIptool
逻辑上是：
	首先进入后对initIptool（）有一个标志，这部分只在程序启动后运行一次。
用了一个全局静态的结构体保存有无线和有线两种方式。
然后从paramHdCuFun中判断硬件是否带有这两个功能，
两个都没有会出错。
paramHdCuFun保存的是客户需要的功能，有的功能在这里需要开启。

1-2、dv_task_create_join

这里的pthread_attr_setdetachstate跟pthread_detach区别在于：
1.pthread_attr_setdetachstate 要在线程创建之前执行，
对一个pthread_attr_t 类型的数据对象进行修改，
之后将这个对象作为第二个参数应用在pthread_create。	
（注意这个对象需要先初始化，并在用完后销毁，分别对应函数）。
相当于在线程出生之前就定制好属性。

2.pthread_detach是在线程创建之后执行，
需要线程号作为输入参数。
可在线程存在的任意时间执行，
也可在线程内部执行，如：
pthread_detach(pthread_self());

这样做的缺点是：
线程创建之后再来修改属性，
可能会来不及。
优点是可以在任意时间执行，
比如线程在某个条件下或者某个时间才设置为分离状态，
它的父线程可以在某些条件下不等待。

1-3、 iptool_param_monitor

进入iptool_param_monitor后，获取到wif信息，
这里有疑问

按道理进入iptool_thread_recv_proc线程绑定数据报套接字发送的数据是一模一样的，是不是重复了，后面还没有继续研究。

2、报错[H265Enc][Error]: VIDEO_CHANGE_H265_ENC_VUI_BUFFER fail : RETCODE_FAILURE

新写入程序后运行后报[H265Enc][Error]: VIDEO_CHANGE_H265_ENC_VUI_BUFFER fail : RETCODE_FAILURE 错误，
使用重启，重新写入程序也不行，怀疑是程序问题，
写入之前能运行的程序，发现也是同样的问题，
思考了内存中，每次写入的app只擦除了存放app的扇区，其他的扇区没有做更改，
所以想到的解决办法是擦除其他扇区的参数，
保留uboot，内核，根文件系统，环境变量，设备树，其他的擦除
然后重新写入程序，程序重新运行正常

3、osd的显示

是跟随着帧在变动，osd显示不正常，卡顿，查看大华后端的时候，
认为只要出图没有网络中断就正常了，
而实际还是要注意画面是否流畅，
我误把单帧画面认为是出图。

4、.ini文件

作用是在程序发布以后还可以对程序进行修改，
避免了每次修改参数都要去修改代码，
ini的后缀名也可以并不一定是ini，
也可以是.conf 、.cfg

格式：

ini文件由节、键、值三者组成
[节]
	[section]
参数（键 = 值）
	name = value
注解 使用;号，一直到句尾。

所有的参数都是以节为单位结合在一起。
所有的节名字都单独占一行，
并且被[ ]包裹，在后面的所有参数都属于节，
直到下一个节出现，或者所有内容结束

5、rtsp报文分析

rtsp承载与rtp和rtcp之上，
rtsp并不会发送媒体数据，
而是使用rtp协议传输。
rtp并没有规定发送方式，
可以选择udp发送或者tcp发送。

5-1、一次基本的RTSP操作过程:

首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。
流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，
RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。
流媒体连接建	立完成后，
客户端发送一个播放命令(PLAY)，
服务器就开始在UDP上传送媒体流（RTP包）到客户端。
在播放过程中客户端还可以向服务器发送命令来控制快进、
快退和暂停等。
最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。

5-2、抓包解读

5-2-1、OPTIONS

OPTIONS rtsp://192.168.8.12:554/MainStream RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)

OPTIONS 获取服务端可用的操作方法
CSeq为rtsp请求必定包含的序列号，
请求带有的序列号，
回复带有的序列号也与请求带的序列号相同。

User-Agent表示客户端使用的播放器型号，版本。
比如我用的时vlc播放器，这里显示的就是vlc的播放器的信息。

RTSP/1.0 200 OK
CSeq: 2
Date: Thu, Apr 27 2023 02:25:39 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

对OPTIONS 的回复
最开始第一字段为rtsp版本，现在版本是RTSP/1.0，
CSeq与上面对请求操作时一样的，所以时回复上面的请求操作。
Public为回复OPTIONS支持的操作。

5-2-2、DESCRIBE

DESCRIBE rtsp://192.168.8.12:554/MainStream RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

RTSP/1.0 401 Unauthorized
CSeq: 3
WWW-Authenticate: Digest realm="TL-RTSP1.0", nonce="988FD8EAF5BFD7B4CE653D3C9334CEA5", stale="FALSE"

获取rtsp的描述，这里失败了
凡时4开头，都是解析失败了，
查阅得知因为客户端发的请求没有鉴权信息，
回复WWW-Authenticate: Digest realm="TL-RTSP1.0", nonce="988FD8EAF5BFD7B4CE653D3C9334CEA5", stale="FALSE"
要求发带有鉴权信息的请求。
所以后面重发了一次带有鉴权信息的请求。


DESCRIBE rtsp://192.168.8.12:554/MainStream RTSP/1.0
CSeq: 4
Authorization: Digest username="admin", realm="TL-RTSP1.0", nonce="988FD8EAF5BFD7B4CE653D3C9334CEA5", uri="rtsp://192.168.8.12:554/MainStream", response="a68d0f1a2ae6fdaef85c17d1613411ab"
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 4
Content-Type: application/sdp
Content-Length: 796
Content-Base: rtsp://192.168.8.12:554/MainStream/

v=0
o=- 1109168256234182 1109168256234192 IN IP4 x.y.z.w
s=RTSP/RTP stream from camera ipc
e=NONE
c=IN IP4 0.0.0.0
a=tool:LIVE555 Streaming Media v2011.05.25 Neek@vizolink.com
t=0 0
a=range:npt=0-
a=control:*
m=video 0 RTP/AVP 96
a=rtpmap:96 H265/90000
a=control:trackID=0
a=fmtp:96 packetization-mode=0;profile-space=0;profile-id=1;tier-flag=0;level-id=150;interop-constraints=000000000000;sprop-vps=QAEMAf//AWAAAAMAAAMAAAMAAAMAlqwJ;sprop-sps=QgEBAWAAAAMAAAMAAAMAAAMAlqAB4CACHFlrkkya5Zk=;sprop-pps=RAHgdrAmQA==
a=x-dimensions: 3840, 2160
a=x-framerate: 12
m=audio 0 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/8000/1
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588;c=IN IP4 0.0.0.0
b=AS:128
a=control:trackID=1
a=appversion:1.0

这里的请求带上了鉴权信息，
Authorization: Digest username="admin", realm="TL-RTSP1.0", 
nonce="988FD8EAF5BFD7B4CE653D3C9334CEA5", 	uri="rtsp://192.168.8.12:554/MainStream/",	
就是鉴权信息。

会话描述：
v=<version> //指定协议版本号；
o=<username> <session id> <version> <network type> <address type> <address> //Origin，
指定媒体源服务器网络会话信息；
s=<session name> //会话名称；
i=<session information> //会话信息；
u=<URI> //统一资源标识符；
e=<email address> //邮件地址；
p=<phone number> //手机号码；
c=<network type> <address type> <connection address> //Connection，连接数据；
b=<modifier>:<bandwidth-value> //带宽信息；
z=<adjustment time> <offset> <adjustment time> <offset>… //时区调整；
k=<method>:<encryption key> //加密密钥；
a=<attribute>/<attribute>:<value> //附加属性行；

时间描述：
t=<start time> <stop time> //会话的起始和结束时间；
r=<repeat interval> <active duration> <list of offsets from start- time> //session的有效、持续、重复时间；

媒体描述：
m=<media> <port> <transport> <fmt list> //第一个参数media可取值"audio"、"video"、
"application"、"data"、“control”，第三个参数指定使用的传输协议，第四个	参数指定媒体格式类型；

5-2-3、SETUP

SETUP rtsp://192.168.8.12:554/MainStream/trackID=0 RTSP/1.0
CSeq: 5
Authorization: Digest username="admin", realm="TL-RTSP1.0", nonce="988FD8EAF5BFD7B4CE653D3C9334CEA5", uri="rtsp://192.168.8.12:554/MainStream/", response="9a1020f5d5b0b183d934eee011af5c9a"
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=56054-56055

RTSP/1.0 200 OK
CSeq: 5
Session: 12aac1f0
Transport: RTP/AVP;unicast;client_port=56054-56055;server_port=20016-20017;ssrc=12aac1f0

RTP/AVP：表示RTP通过UDP发送，
如果是RTP/AVP/TCP则表示RTP通过TCP发送。
unicast：表示单播，如果是multicast则表示组播。
client_port=56054-56055：由于这里希望采用的是RTP OVER UDP，
所以客户端发送了两个用于传输数据的端口，
客户端已经将这两个端口绑定到两个udp套接字上，56054表示是RTP端口，
56055表示RTCP端口(RTP端口为某个偶数，RTCP端口为RTP端口+1)。
Session为连接的id。
server_port=20016-20017设备服务器端他也创建了两个端口，
一个传输RTP，一个RTCP。
服务端会从这两个端口走数据。

5-2-4、PLAY 与TEARDOWN

PLAY rtsp://192.168.8.12:554/MainStream/ RTSP/1.0
CSeq: 7
Authorization: Digest username="admin", realm="TL-RTSP1.0", nonce="988FD8EAF5BFD7B4CE653D3C9334CEA5", uri="rtsp://192.168.8.12:554/MainStream/", response="4a9c680c482143d5cabed41b8ea548ba"
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Session: 12aac1f0
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 7
Session: 12aac1f0
Range: npt=0.000-
RTP-Info: url=trackID=0;seq=3248;rtptime=2948763998;ssrc=12AAC1F0,url=trackID=1;seq=8192;rtptime=71225120;ssrc=12AB2360

TEARDOWN rtsp://192.168.8.12:554/MainStream/ RTSP/1.0
CSeq: 8
Authorization: Digest username="admin", realm="TL-RTSP1.0", nonce="988FD8EAF5BFD7B4CE653D3C9334CEA5", uri="rtsp://192.168.8.12:554/MainStream/", response="0478b2fb2e0cbe52855848edbfe1c617"
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Session: 12aac1f0

总体就是，rtsp控制播放，暂停等控制，
				RTP进行视频传输，
				RTCP进行视频质量的控制，
				个人理解		
				相关还有一个rtmp，查阅得知rtmp比rtsp简单，rtsp较为复杂。

5-3、分析的资料来源：

			https://zhuanlan.zhihu.com/p/478736595
			https://blog.csdn.net/bytxl/article/details/50400987
			https://blog.csdn.net/weixin_30536513/article/details/94809009
			https://zhuanlan.zhihu.com/p/608285373
			https://blog.csdn.net/luyumiao1990/article/details/106093001

5-4、附关键字段表

更新5月4日至5月6日

之前提到的rtsp的权鉴信息可以在服务端去掉，这是非必要的。
我们目前用到的身份加密的方式是用md5算法进行加密。

1、md5

md5用于提供消息的完整性保护，md5的长度为128bit，
也就是16字节，通常用16进制的来输出它。
特点：
一、长度固定
	无论输入多少个字节，输出总为16个字节
二、不可逆
	从结果无法反推原始数据，
	因为中间过程丢弃了一些信息，
	无论输入多少长度的信息，
	输出总为16字节。
三、高度离散型
	输出的数据没有任何规律可言，
	哪怕只改变一个bit，
	输出的结果也毫无规律可言。

应用
	场景一：
	一般用在密码保护，
	系统记录md5的结果，
	就是用户在输入密码后，
	将密码转化为md5，
	与系统记录的md5进行比对校验，
	校验时，只要密码正确，
	md5结果时一样的。在此过程中，
	只有用户自己知道密码明文。
	
	场景二：
	文件完整性校验，
	比如传输一个非常大的文件，
	由于网络传输的不可靠的因素，
	可能使传输的不完整，
	这样我们可以通过在文件的传输端计算一次md5，
	接收端计算一次md5，
	只要两次的md5不一样则表示传输不完整。

	场景三：
	数字签名，比如发布了一个程序，同时计算md5，
	因为修改者只要修改了数据，
	得到的md5肯定不会与原来的相同。
	
	场景四：
	云盘秒传，原理也是通过计算要上传的md5，
	然后在数据库中搜索这个md5，如果存在就不同传了。

1-1、原理：

	第一步补位，原始数据后第一位补1，后面补0，使长度变成N*512 + 448，如下图

即使是原始数据除以512余数为448，也要补上512位，
长度变为（	N+1 ）* 512 + 448
最后有64位组成原始数据的长度

长度变为512的整数倍，也就是M*64字节大小

第二步	进行计算

公式中的a,b,c,d是四个标准幻数，
从上面的公式可以看出，
输入7个参数，保存修改了第一个参数。
先分析s，ac两个参数是一些固定参数。
0x01234567，0x89abcdef，0xfedcba98，0x76543210，
如果是大端存储就是这样的。

将上面的M*64字节的原始数据取出一个64字节，
总共512位，分成16份，每组32位，
比如x[0]的值是第一份，
这32位数据按字节或运算，得到的值就是x[0]的值，
x[1]就是第二份，后面同理。
得到x值，套入公式，
每个公式计算16次，四组公式计算64次，
总共计算次数就是m*64次，
计算下组64字节数据时，要将上一组保存的a,b,c,d数据加到本组运算后的a,b,c,d相加，
后面也是一样的，
最终计算完得到最终的a,b,c,d，
将a,b,c,d,按照顺序输出就是最终结果。

1-2、代码实现

正在研究。。。

2、I帧，P帧，B帧概念

I帧表示关键帧，保存有画面完整信息，
解码此帧就能够得到完整画面和画面的信息，

P帧表示的是此帧跟之前的一个I帧（或P帧）的差别，
解码时需要用之前缓存的画面叠加上本帧定义的差别，
生成最终画面。
（也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据）

B帧是双向差别帧，
也就是B帧记录的是此帧与前后帧的差别（具体比较复杂，有4种情况），
换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，
通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高。

3、sps问题分析

在这里插入图片描述

用vlc转码分析，操作步骤为媒体->网络->转码->配置参数中视频选择保持原轨视频
用vlc转码分辨率在4k下，别人的解码后i帧分析得45字节，
我们的32字节，解码前，我们与别人的相比，sps有缺失，
现在需要分析编码前和编码后在什么地方导致了缺失。
以间隔00 00 00 01为开头。其他的正在总结中。

更新2023.5.8至2023.5.14

1、sps问题

vlc有时候无法播放问题，
抓包得知，
在获取的sps信息不对，
或者缺失时，
会解码失败。

2、视频编码分析

Nalu type类型判断方式：
    00 00 00 01 40 01  的nuh_unit_type的值为 32， 语义为视频参数集        VPS
   00 00 00 01 42 01  的nuh_unit_type的值为 33， 语义为序列参数集         SPS
   00 00 00 01 44 01  的nuh_unit_type的值为 34， 语义为图像参数集         PPS
   00 00 00 01 4E 01  的nuh_unit_type的值为 39， 语义为补充增强信息       SEI
   00 00 00 01 26 01  的nuh_unit_type的值为 19， 语义为可能有RADL图像的IDR图像的SS编码数据   IDR
   00 00 00 01 02 01  的nuh_unit_type的值为1， 语义为被参考的后置图像，且非TSA、非STSA的SS编码数据
	而 00 00 00 01 02 01存在再p帧当中，前五个在同一帧中。		
	SEI为非必要，VPS,SPS,PPS必须存在。

2-1、什么是编码

视频不经过编码，产生的数据流是非常大的。
为了存储方便和传输方便，所以有了编码处理。

2-2、都有那些编码方式

现在主流的是最主流的有H.264/AVC编码,
以及新一代的H.265/HEVC编码，
H.265旨在在有限带宽下传输更高质量的网络视频，
仅需原先的一半带宽即可播放相同质量的视频。
所以在传输4k至4k以上视频时，
使用的时H.265。
两者在I帧上的区别在于：
H.264少了一个vps。

2-3、VPS

VPS用于传送应用于多层和子层视频编码所需的信息，
提供了整个视频序列的全局性信息。
一个给定的视频序列的每一层都参考同一个VPS，
无论它们SPS是否相同。
查阅资料，
得知vps就是将出现在PPS、SPS、SEI重复的信息放到VPS中。

2-4、IDR

IDR属于I帧，而I帧不一定是IDR帧，
IDR帧前的画面到此与IDR后的无关，
对于IDR后出现的任何B，
P帧都不会参考IDR之前的数据，
它们已经被丢弃。
这样就形成了一个个片段。
 作用是放置错误扩大。
 这里的B帧，P帧是可以参考多帧的
 如果出现错误，出现在I帧前，
 那么错误可能会延续，
 但是有了IDR，P，B帧无法越过IDR帧。

2-5、SPS

SPS用于保存下列信息
① 图像格式的信息。
包括采样格式、图像分辨率、量化深度、解码图像是否需要裁剪输出以及相关的裁剪参数。
② 编码参数信息。（帧内，间隙）
③ 与参考图像相关的信息。
包括短期参考图像的设置，长期参考图像的使用和数目，
长期参考图像的POC和其能否作为当前图像的参考图像。
④ 其他信息。
包括当前SPS引用的VPS编号、SPS标识号和SPS扩展信息。

问题:
	sps的内容跟分辨率有关，
	那sps长度是否和分辨率等图像参数相关，
	这个方面网上没有相关回答，
	而V8现在的sps和I帧都不对，
	无法验证，
	用V8验证之后，
	发现无变化。
猜测
	猜测长度是固定的。
	不相关。

2-6、PPS

对于PPS，只要被I帧内激活，
便会在后面的P，B帧中引用。
描述的是单帧画面的信息。
对于层，编码块等概念没有往下看

3、ioctl(sockfd, SIOCGIFADDR, &ifr)

使用ioctl(sockfd, SIOCGIFADDR, &ifr)可以进行网路信息获取或者配置，

在V8中，如果没有关闭，或者没有使用wifi，
将会在这里
问题1：配置曝光出现
AVMsgManage.cpp:setAVCaramParam:305]cmdBuf=/usr/local/app/vienna/asc_msg_sender -a 4 -s 1000
[streamer_msg] msg_callback() msg_context->pszHost=asc_host, msg_context->pszCmd=asc_set
[05-17 12:20:01 AVstream.cpp:AVStreamThread:1265]Stream len is too big=0,2,317604
[05-17 12:20:01 AVstream.cpp:AVStreamThread:1269]Stream len is too big=1,2,109603
[05-17 12:20:01 ParamFileOperation.cpp:writeParamToFlash:265]write ok, path=/dev/mtdblock6 , len=5064, crc=56
INT_BIT_BIT_BUF_FULL
dtc[SignalHander][2768]signal =11
[streamer] receive SIGNAL: 11
[streamer] run FocusOSD Process, set enable = 0
[streamer] release stream 0
[05-17 12:20:02 ParamFileOperation.cpp:writeParamToFlash:265]write ok, path=/dev/mtdblock7 , len=5064, crc=56
[streamer] release stream 0
[05-17 12:20:08 AVstream.cpp:AVStreamThread:1361]Bitrate2: 1 kB/s,freamNum=79

[05-17 15:06:09 AVMsgManage.cpp:setAVCaramParam:305]cmdBuf=/usr/local/app/vienna/asc_msg_sender -a 4 -s 1000
[streamer_msg] msg_callback() msg_context->pszHost=asc_host, msg_context->pszCmd=asc_set
[05-17 15:06:10 AVstream.cpp:AVStreamThread:1188]index = 0,dwFourCC = 892744264,bIskeyFrame = 1,dwBateBytes = 6814
[05-17 15:06:10 AVstream.cpp:AVMDThread:811]MD Macro start
INT_BIT_BIT_BUF_FULL
dtc[SignalHander][2768]signal =11
[streamer] receive SIGNAL: 11
[streamer] run FocusOSD Process, set enable = 0
[streamer] release stream 0
[05-17 15:06:11 ParamFileOperation.cpp:writeParamToFlash:265]write ok, path=/dev/mtdblock6 , len=3728, crc=83
[05-17 15:06:11 ParamFileOperation.cpp:writeParamToFlash:265]write ok, path=/dev/mtdblock7 , len=3728, crc=83
[streamer] release stream 0
E/[VMF_VENC] VMF_VENC_Stop() invalid handle.
[Encoder] VMF_VENC_Stop faild, ret = -1
E/[VMF_VENC] VMF_VENC_Release() invalid handle.
[Encoder] VMF_VENC_Release faild, ret = -1
[streamer] release stream 1

当执行asc_msg_sender -a 4 -s 进行曝光设置时有时候会将码流关掉，不会再开启

触发信号11，segv，通过网上查阅得知，触发这个信号有三种情况，空指针、越界访问内存、
访问已经释放的内存，考虑到这个问题有偶发性，所以最大可能是越界访问内存，手动输入几个参数验证发现是正常的，貌似这个信号没什么用，思路断了。

突然发现在保存上一次数据时，长度是按照旧有的参数长度保存的，貌似找到了问题原因，这个信号因该是来自于这里，保存的长度按照旧的保存，一旦新的长度小于旧的，立刻就会内存越界，这个只有当访问这个越界地址时才会报错，非法访问了不属于它的地址，所以按照新参数数据长度保存。

程序改过编译运行，曝光不出图问题解决，问题原因果然在这里，没有这个信号了。
就是容易报malloc内存申请错误，改动应该不相干才对。

问题2：后端不出图问题
对照输入参数进行设置，没有什么问题。

拿到了steramer的代码，编译完成后，挂载发现除了steramer和steramer_msg都能挂载上，猜测可能是程序运行中，终止掉steramer -D也还是无法实现。然后自己写了一个挂在在其他目录下，又可以了，花了很长时间想不到什么原因了。

由于挂在问题，先对steramer_msg进行验证，发现没有问题，确定了问题在steramer上。

挂在不上的问题找到了，没有注意过路径，编译的时候，文件放到了v8下，v8目录下的app有一个vienna，我自己写的时候挂在了v8下，教训就是要精雕细琢，不能放过了任何细节，细节出错都不行。

对steramer进行验证，本来猜测对编码器进行设置时，在设置期间，应该暂停编码，设置完成后在继续

但是上面代码只设置里osd的字体参数，就继续进行编码，在加上改动分辨率的时候会有一段正确的sps，所以猜测可能时在设置时继续编码导致的错误，验证后发现不是，而是只要运行了暂停，继续，就会导致
Sps的长度不正确，注释掉后端能出图，能正确的修改参数，
次码流测试，结果也时一样的

发现这个暂停继续无论放置在哪，只要运行过，sps都会不正确，如果有其他命令调动了这个函数，如果被执行了。估计也时无法出图。是个隐患。
总感觉是用的问题。猜测时会不会在暂停后开始，没有了IDR或这I帧不正确，由之前了解到的，IDR在每次画面一开始的第一帧就要有，要是能强制继续编码后的第一帧为I帧，能否解决这个问题。
测试后没用。IDR为每个分段的开始，第一个错误并不影响后续。