GB35114流处理

GB35114流处理

  • 以下内容为个人研究的一些结果,暂未得到实际验证,遇到一些问题,还请各位指导一下,指正其中的错误,谢谢。

1、基本情况

新NAL单元语法:

语法元素 位数 语义说明
forbidden_zero_bit 1 0表示视频流支持GB/T 25724-2010标准?默认为1表示支持SVAC标准
nal_ref_idc 1 1表示包含SPS/PPS/安全参数集/参考图像编码片
nal_unit_type 4 0-15 1-4表示VCL NAL单元,5可被丢弃
encryption_idc 1 1表示NAL单元中RBSP(原始字节序列负载)以安全参数集中指定加密方法加密,且RBSP最后一个字节不加密
authentication_idc 1 1表示NAL单元中RBSP以安全参数集中指定认证方法认证,此时编码比特流中必须携带绝对时间扩展信息,用于标识认证时间
payload_byte 8 多字节有序序列,payload_byte[i]等于rbsp_byte[j],包括一个RBSP(若加密,则为加密后的RBSP,RBSP包含SODB(数据比特串),后面添加rbsp_stop_one_bit=1最后一个字节不足填充0)
emulation_prevention_three_byte 8 0x03 解码过程丢弃,用于填充0x000000(0x000001,0x000002,0x000003)->0x00000300(0x00000301,0x00000302,0x00000303)

NAL单元类型及转换表:

nal_unit_type 语法结构 说明 原NALUHeader 新NALUHeader
0 保留 0 0(c0)1100 0000
1 tile_data_rbsp() 非IDR(即时解码刷新)图像编码片 1(61)0110 0001
1(41)0100 0001
1(c4)1100 0100
1(c7)1100 0111
2 tile_data_rbsp() IDR图像编码片 5(65)0110 0101 2(cb)1100 1011
3 tile_data_rbsp() 非IDR图像SVC(可伸缩性视频编码)增强层编码片 (<–丢弃) (–>丢弃)
4 tile_data_rbsp() IDR图像SVC增强层编码片 (<–丢弃) (–>丢弃)
5 surveillance_extension_rbsp() 监控扩展数据单元(也满足rbsp语法结构) (<–丢弃) 5(94)1001 0100(–>新加)
6 sei_rbsp() 补充增强信息 6(6)0000 0110 6(98)1001 1000
7 seq_parameter_set_rbsp() 序列参数集 7(67)0110 0111 7(dc)1101 1100
8 pic_parameter_set_rbsp() 图像参数集 8(68)0110 1000 8(e0)1110 0000
9 sec_parameter_set_rbsp() 安全参数集 (<–丢弃) 9(e4)1110 0100(–>新加)
10 authentication_data_rbsp() 认证数据 (<–丢弃) 10(e8)1110 1000(–>新加)
11 end_of_stream_rbsp() 流结尾 11(6b)0110 1011 11(ec)1110 1100
12 保留 -
13 编码器应用到 -
14 保留 -
15 pic_parameter_set_rbsp() SVC增强层图像参数集 -

原H264NALU type:

GB35114流处理

0 没有定义
1-23 NAL单元 单个 NAL 单元包
24 STAP-A 单一时间的组合包
25 STAP-B 单一时间的组合包
26 MTAP16 多个时间的组合包
27 MTAP24 多个时间的组合包
28 FU-A 分片的单元
29 FU-B 分片的单元
30-31 没有定义

0x67: 序列参数集SPS
0x68: 图像参数集PPS
0x41: 不分区、非IDR图像的片
0x65: IDR
0x61: non-IDR Slice
0x01: B Slice
0x06:补充增强信息单元SEI
0x09: 分界符AU Delimiter

原始数据流格式说明

I帧:(第一个ps包)

ps头 psSystem头 PSM pes of SPS pes of PPS pes of SEI pes of IDR
000001ba+xxx 000001bb+xxx 000001bc+xxx 000001e0+xxx+sps 000001e0+xxx+pps 000001e0+xxx+sei 000001e0+xxx+idr

现在观察到中星视频流加密或不加密的时候,在SPS后的的几个NALU的pes中没有出现000001e0+若干数据的情况,而在海康视频流(不加密)SPS后的几个NALU中都出现了000001e0+若干数据的情况

非I帧:

ps头 pes of P/B
000001ba+xxx 000001e0+xxx+非idr

以上多个ps包构成一个psgop

ps头固定长度最小为14,第14字节&07表示低三位为其后填充数据长,一般表示该帧序号

psStream、PSM、pes后两个字节为其后数据长度,注意字节序

000001c0音频数据

000001bd私钥协议数据

安全参数集分析

0000 0001 e4 + 加密flag(1b) + 验证flag(1b) + 加密算法(4b)+ vek flag(1b) + iv flag(1b)+ vek加密算法(4b)+ evek长度(8b)+ evek + vkek长度(8b)+ vkek + iv长度(8b)+ iv + hash type(2b) + hash图像类型(1b)+ 签名算法(2b)+ 签名图像个数(8b)+ 摄像机证书 序列号(19B)+ 摄像机ID(20B)

(1)
          0000 0001 e4c7 10f9 f5ea 5dde
f47a 9ea0 b88d 9162 4ef2 d382 6323 0323
02d3 1312 d303 9543 1343 a343 13a3 4368
c581 4745 bfbf d1b5 d1a1 70b9 6160 ce41
0434 d560 f496 e890 49f6 a3db 50f4 4434
9def d02f 200c 0000 0300 0003 0000 0300
0003 0000 0300 0003 0000 1a6b 917f d619
9a18 9818 1918 1818 1818 9999 1818 1818
1818 1ac0

00000001e4-c71-0f9f5ea5ddef47a9ea0b88d91624ef2d38-26323032302d31312d30395431343a34313a34368c5814745bfbfd1b5d1a170b96160ce410434d56-0f496e89049f6a3db50f444349defd02f2-00c00000300000300000300000300000300000300001a6b917fd6199a18981819181818181899991818181818181ac0

加密flag(1b) + 验证flag(1b) + 加密算法(4b)+ vek flag(1b) + iv flag(1b) + vek加密算法(4b):c71
evek长度(8b)+ evek : 0f-9f5ea5ddef47a9ea0b88d91624ef2d38
vkek长度(8b)+ vkek : 26-323032302d31312d30395431343a34313a3436-8c5814745bfbfd1b5d1a170b96160ce410434d56(2020-11-09T14:41:46,其后不知道是什么)
iv长度(8b)+ iv : 0f-496e89049f6a3db50f444349defd02f2

00c00000300000300000300000300000300000300001a6b917fd6199a18981819181818181899991818181818181ac0
转换为:(去除前五位加一个字节和最后一个字节的rbsp_trailing_bits(7b))
0000 0-000 1100 0-000 0000 0000 0000 0000 0011 0000 0000 0000 0000 0000 0011 0000 0000 0000 0000 0000 0011 0000 0000 0000 0000 0000 0011 0000 0000 0000 0000 0000 0011 0000 0000 0000 0000
00000011000000000000000000011010011010111001000101111111110101100-0011001100110100001100010011000000110000001100100011000000110000001100000011000000110001001100110011001000110000001100000011000000110000001100000011000000110101-1000000
->:000006000006-000006000006000006000006000034d722ffac-3334313030323030303031333230303030303035(从后往前分析得出,前6个字节不知道怎么多出来的)

hash type(2b) + hash图像类型(1b)+ 签名算法(2b)+ 签名图像个数(8b): 00000 18
摄像机证书 序列号(19B):000006000006000006000006000034d722ffac(34d722ffac,只有后5个字节表示证书序列号,前面怀疑是填充数据)
摄像机ID(20B):3334313030323030303031333230303030303035(34100200001320000005)
(2)
                    0000 0001 e4c7 10f2
5b41 6f29 5d27 69be e1d5 de6e 667d c3f9
7756 b103 8373 6393 8324 3314 1303 8303
3303 3377 06a6 79cd d453 f251 994c bbd3
df66 7d13 9771 e72c 871a 7776 9931 3f02
bf02 4124 63df f205 06b3 1c6a e841 876a
8299 161a 081d 63da 00ec 2ece cb7e 3d30
2879 5884 f2c0 21cf 8a31 6458 bfe4 57b0
c738 0a21 f188 7e93 dce4 81d9 e050 cf2c
eb15 4215 f0c6 79a8 0ef0 ea11 6e96 b21f
7d4a 60ef b8c5 8147 45bf bfd1 b5d1 a170
b961 60ce 4104 34d5 60f4 96e8 9049 f6a3
db50 f444 349d efd0 2f20 0c00 0003 0000
0300 0003 0000 0300 0003 0000 0300 001a
6b91 7fd6 199a 1898 1819 1818 1818 1899
9918 1818 1818 181a c0

00000001e4-c71-0f8f631c4355016b7c708aaeba570f1e89-97756b10383935433641453137303642333833387012b34dd0734e5741dba335e69be67c9e8dd2d7b1e3aff1434c74c7ce43205e464c5345930be1a1f5e1301f30005f3520c3dc53c6df45598b2336c09ef0eb130b05ddd6fbda406d484f7ffa6626b2d99e724a19dd0c88f09734f5938f8c7bb62ecc6a0937023f0fd100c2d0a46e026cc529ff29e0df8a727fcfc807db1fcfde7410434d56-0f496e89049f6a3db50f444349defd02f2-00c00000300000300000300000300000300000300001a6b917fd6199a18981819181818181899991818181818181ac0

加密flag(1b) + 验证flag(1b) + 加密算法(4b)+ vek flag(1b) + iv flag(1b) + vek加密算法(4b):c71
evek长度(8b)+ evek : 0f-8f631c4355016b7c708aaeba570f1e89
vkek长度(8b)+ vkek : 97-756b10383935433641453137303642333833387012b34dd0734e5741dba335e69be67c9e8dd2d7b1e3aff1434c74c7ce43205e464c5345930be1a1f5e1301f30005f3520c3dc53c6df45598b2336c09ef0eb130b05ddd6fbda406d484f7ffa6626b2d99e724a19dd0c88f09734f5938f8c7bb62ecc6a0937023f0fd100c2d0a46e026cc529ff29e0df8a727fcfc807db1fcfde7410434d56-0f496e89049f6a3db50f444349defd02f2(解析不出来)
iv长度(8b)+ iv : 0f-496e89049f6a3db50f444349defd02f2

00c00000300000300000300000300000300000300001a6b917fd6199a18981819181818181899991818181818181ac0(分析同上)
hash type(2b) + hash图像类型(1b)+ 签名算法(2b)+ 签名图像个数(8b): 00000 18
摄像机证书 序列号(19B):000006000006000006000006000034d722ffac(34d722ffac,只有后5个字节表示证书序列号,前面怀疑是填充数据)
摄像机ID(20B):3334313030323030303031333230303030303035(34100200001320000005)

认证签名数据分析

暂未找到 0000 0001 e8 NALU

监控扩展单元分析

0000 0001 94 + 扩展id(8b) + 长度(8b)+ 0x80(扩展结束)

  • 04 绝对时间
  • 10 地理扩展信息
  • 11 智能分析
  • 12 OSD信息
(1)04(绝对时间)
       00 0000 0194 0406 7b3a 1141 2969 
80

长度(8b):06
hour(5b)+minute(6b)+second(6b)+1/16384s(14b)+data_flag(1b):0111 1011 0011 1010 0001 0001 0100 0001
01111:011001:110100.00100010100000-1 
0f:19:34.08a0-1
15:25:52.134765625-1

年-2000(7b)+month(4b)+day(5b):0010 1001 0110 1001
0010100-1011-01001
14-b-9
2020-11-9
(2)12(OSD)                      
                      00 0000 0194 1220
2000 0030 0018 00c0 0313 0000 0300 3230
3230 2d31 312d 3039 2031 353a 3235 3a35
3280 


长度(8b):20
子类型(8b):20 (32时间OSD,33摄像机名称OSD,34地点标注OSD)
编码格式(8b):00, utf8
字符对齐格式(8b):00, 左对齐
字体大小(8b):30, 
字符格式(8b): 00, 白底黑边
上边界位置(16b): 0018
左边界位置(16b): 03c0
osd_data长(8b): 13
res(8b):00
osd_data: 000300-323032302d31312d30392031353a32353a3532(2020-11-09 15:25:52)


       00 0000 0194 1216 2100 0030 0008
0400 0009 0000 0300 e980 9ae9 8193 e4b8
8080

长度(8b):16
子类型(8b):21 (32时间OSD,33摄像机名称OSD,34地点标注OSD)
编码格式(8b):00, utf8
字符对齐格式(8b):00, 左对齐
字体大小(8b):30, 
字符格式(8b): 00, 白底黑边
上边界位置(16b): 0408
左边界位置(16b): 0000
osd_data长(8b): 09
res(8b):00
osd_data: 000300-e9809ae98193e4b880
		->%e9%80%9a%e9%81%93%e4%b8%80
		->通道一
		(http://stool.chinaz.com/hex)

2、上级(接收流)处理过程

此处为接收到35114经过签名或加密的流数据(经过PS打包后的h264),且数据中NALUheader已经被转换,需要对数据进行验证签名或解密处理

上级接收到数据流格式说明:(第一个ps包)

ps、psSystem、PSM、pes头部 安全参数集(I帧整数倍前) SPS PPS SEI IDR
000001ba+xxx+000001bb+xxx+000001bc+xxx+000001e0+xxx 00000001e4+xxx dc e0 98 cb

接收到的I帧中间不添加pes头(000001e0+xxx)处理,仅在ps包中第一个ps头后添加,(在处理完数据后转换为正常的H264数据时,是否需要在后面每个NAL前添加pes头?)

后续的ps包:

ps、pes头部 非IDR 认证数据
000001ba+xxx+000001e0+xxx c7 e8

以上多个ps包构成一个psgop

安全参数集出现在psgop整数倍中,(一个GOP分界线为ps头+SPS),安全参数集不加密

认证数据默认为在一个GOP尾输出一次

VEK随机生成,默认30或60个GOP生成一次,新VEK在下一个GOP中使用,当前GOP不变

编码片最后一个字节不加密

每个加密GOP中IV不同

处理过程

1、循环接收数据,以ps包为单位缓存,缓存一个ps包后,开始处理,检查到下一个ps包后发出前一个处理完的ps包;
2、每个GOP周期开始时,先是接收到I帧ps包头(xxbaxxbbxxbcxxe0),然后是安全参数集(用于更新iv,30或60个周期时更新vek),非I帧中没有安全参数集iv和vek不变;
 - 同时会随时接收到vkek变更通知,更新内存vkek
3、接收到安全参数集时,更新内存中安全参数集结构体变量;
4、接收到每个ps包时,解析出内部一个或多个NALU,先根据加密标识计算rbsp解密后值,后根据验证标识计算sm3值,解密后的值直接覆盖原rbsp数据(位数相等,且最后一个字节不加密),sm3缓存后直到最后一个NALU(紧接着是认证数据NALU和下一轮GOP)计算最终的签名值(再同认证数据单元NALU比较结果,并将结果回调给上层);
 - 解密:首先从安全参数集中获取vkek版本号,查找对应的vkek,使用vkek和sm4_ecb算法解密安全参数集中的evek得到vek,然后使用vek、iv和sm4_ofb算法解密NALU中rbsp(去掉最后一个字节)得到明文
 - 验证签名:直接使用sm3算法对rbsp计算,最终使用安全参数集中对方ID关联的证书进行sm2加密hash值,得到待验证的签名数据
5、中间会有监控扩展单元NALU,可以获取认证时间;
6、数据处理包括:解析安全参数集和认证数据NALU、解密、验证签名、计算监控扩展单元时间、转换NALU头为正常的H264NALU头。

3、下级(发送流)处理过程

此处为原始H264经过PS打包后的流,需要转换NALUheader,同时进行签名(添加安全参数集、监控扩展、签名认证数据NALU)或加密处理(添加安全参数集,并在原rbsp上加密)(若同时加密和签名可以合并成同一个安全参数集)

原先下级发出的流格式同H264原始数据流格式,当35114开关打开时,需要转换流格式,由于上级接收到流格式,同原始数据流格式(ps打包的h264格式)不同,因此,需要将GOP中第一个ps包I帧之间转换为没有000001e0+xxx的形式,因此需要修改ps头部的000001e0后长度值,并且删除后续sps、pps、idr等前的000001e0+xxx的pes头部数据

处理过程

1、循环发送数据,以ps包为单位缓存,缓存一个ps包后,开始处理,检查到下一个ps包后发出前一个处理完的ps包;
2、每个GOP周期开始时,先是发送I帧ps包头(xxbaxxbbxxbcxxe0,已经存在),然后是生成随机数创建iv或evk(使用vkek加密后得到evek), 封装成安全参数集;
 - 同时会周期性重新登录(或者主动变更vkek),接收到对方返回的新vkek后发送vkek变更通知对方,更新内存vkek
3、创建安全参数集时,根据实时签名或加密开关(由对方实时通知变更),控制其中验证标识和加密标识,并将自己ID和证书序列号封装进安全参数集,同时更新内存中安全参数集结构体变量;
4、处理每个ps包时,解析出内部一个或多个NALU,根据实时签名或加密开关,以及自主选择控制,控制每个NALU头部中验证标识和加密标识,并根据标识计算当前rbsp sm3值和加密后的值,当前NALU sm3缓存后直到最后一个NALU(紧接着是下一轮GOP)计算最终的签名值(再封装成认证数据NALU插入其后,同时需要加上一个监控扩展时间单元数据),加密后的值直接覆盖原rbsp数据(位数相等,且最后一个字节不加密);
 - 签名:使用sm3算法对rbsp计算,最终使用自己ID关联的证书进行sm2加密hash值,得到签名数据,封装进签名数据NALU中
 - 加密:使用创建的evk、iv和sm4_ofb算法对NALU中rbsp(去掉最后一个字节)加密得到密文,将vkek和sm4_ecb算法加密vek得到evek,最后将evek、iv、vkek版本号封装进安全参数集
5、数据处理包括:转换正常的H264NALU头为35114NALU头,插入安全参数集、认证数据、监控扩展时间信息NALU、加密数据、修改GOP第一个ps包I帧后面pes头长度,删除后面pes头(000001e0xxx)。

4、已发现问题(未解决)

1、新旧NALU头部转换是否正确?
2、中星和海康视频流结构不一致,海康视频流每个NALU都使用pes封装,而中星的第一个ps包中连续几个NALU使用一个pes封装,处理时需要做兼容?
3、暂时没有海康加密视频流,已有中星加密和未加密视频流文件,从中只找到部分NALU类型,未发现认证数据、流结尾NALU,监控扩展只发现两种类型;
4、安全参数集分析,解析vkek版本号、camera idc出现偏差?
5、国标文档中对签名验证定义较为模糊,签名为先计算杂凑值(sm3)再签名,验证却先解密再计算杂凑值比较?个人理解为第一种可能为先计算杂凑值(sm3)再加密(sm2),验证时先解密(sm2)再计算杂凑值比较,第二种可能为先计算杂凑值(sm3)再签名,验证时同样操作再比较,个人认为第一种可能性较大,反正文档中前后有一种描述错误;
6、上述上下级处理过程未经过测试,只是凭借相关文档及个人理解得出,是否存在偏差?
上一篇:js对flv提取h264、aac音视频流


下一篇:H264码流结构