ps流来封装h.264数据

7816使用ps流来封装h.264数据,这里使用的解码器无法识别ps流,因此需要将h264数据从ps流里提取出来

对于ps流的规定可以参考13818-1文档

这里从7816里获取到一些数据取样

00 00 01 BA 44 73 26 B8 34 01 00 00 03 FE FF FF 00 00 00 0100 00 01 BC00 5A E0 FF 00 24 40 0E 48 4B 00 01 0D AF C5 D3 E0 07 FF FF FF FF 41 12 48 4B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C 1B E0 00 10 42 0E 00 00 A0 21 02 C0 02 40 12 1F FF 00 1C 21 91 C0 00 0C 43 0A 00 00 FE 00 7D 03 03 E8 03 FF BD BD 00 00 BF BF 00 00 00 00 00 0000 00 01 E0 00 1A 8C 80 0A 21 1C C9 AE 0D FF FF FF FF FC 00 00 00 01 67 42 00 1E 95 A8 2C 04 99 00 00 01 E0 00 0E 8C 0003 FF FF FC 00 00 00 01 68 CE 3C 80 00 00 01 E0 13 FA 8C 00 02 FF FD 。。。

如上是一个i帧的数据的开始部分,如下是一个非i帧的数据的开始部分

00 00 01 BA 44 73 27 99 34 01 00 00 03 FE FF FF 00 00 00 03 00 00 01 E0 07 12 8C 80 0A 21 1C C9 E6 4D FF FF FF FF F8。。。

可见都是以00 00 01 BA开头,这是ps的包头(Program Stream pack header),其中00 00 01是pack_start_code,是一个数据包的开始标识,接下来的1byte(BA)是流标识(stream_id),在文档13818-1的Table 2-33和2.5.3.4节有Program Stream pack header的描述。

这里把上面i帧的的(Program Stream pack header列出来

00 00 01 BA 44 73 26 B8 34 01 00 00 03 FE FF FF 00 00 00 01

根据文档描述包头最少有14个字节,第14个字节的最后3bit说明了包头14字节后填充数据的长度,这里是pack_stuffing_length=FE&0x07=6,有6byte的填充数据,既是FF FF 00 00 00 01,海康7816使用这部分填充数据来说明每帧的序号,01说明是第1帧数据。

要注意的是包头可能还有系统标题头,id为bb,他也是包头的一部分,并且,他的长度并未算在pack_stufing_length里,比如:

00 00 01 BB 00 0C 80 CC F5 04 E1 7F E0 E0 E8 C0 C0 20

这里起始码后的 00 0C 说明了其后数据的长度,这里是12个字节

接在Program Stream pack header后的是以00 00 01 BC开始的一个包,00 00 01是pack_start_code,BC是stream_id流标识,说明跟在Program Stream pack header后的是Program Stream map。文档13818-1的Table 2-35和2.5.4.2节有Program Stream pack header的描述。

跟在00 00 01 BC后的两位是说明了Program Stream map,他也是pes包的一种,包的长度program_stream_map_length,这里是00 5A,说明跟在其后的数据长度为90,跳过这其后的90byte数据是以00 00 01 E0开始的包,E表示是GB/TXXXX.2或GB/TAAAA.2视频流编号xxxx规格的pes包了,0表示流id为0,h264数据就在这个包里。

从Program Stream map里我们还能得知pes里的流是何种流(stream_type和elementary_stream_id表明),以及帧率()等

1110XXXX(0xex)表示视频数据,111XXXXX表示audio数据,其后的帧有关信息共5字节,2字节PES包长度是00 1A,表示此PES数据包的长度是0x001a 即26字节;2字节标准位信息是8C 80,5字节中的最后一字节表示附加数据长度是0A,跟在附加数据长度后的就是视频数据负载了。

pes包可以有多个,这里的i帧就把数据放到了多个pes包里,这里的非i帧就只有一个pes包

有了以上信息就已经可以从7816里剥离出h246数据了,更详细的说明请参考文档。

截取一段pes包头进行分析

00 00 01 E0 00 1A 8C 80 0A 21 1C C9 AE 0D FF FF FF FF FC  00 1A: 2字节表示长度,表示再这两个字节之后的数据长度(如果有附加数据包括了其后的附加数据,和负载数据,我们希望得到的是负载数据,因此要略过附加数据部分) 8C(10 00 1 1 00): 首先是固定值10,。 接下来的两位为(PES加扰控制字段)PES_scrambling_control,这里是00,表示没有加扰(加密)。剩下的01,10,11由用户自定义。 接下来第4位为PES优先级字段(PES_priority),当为1时为高优先级,0为低优先级。这里为1。 接下来第3位为(数据对齐指示符字段)PESdata_alignment_indicator, 接下来第2位为版权位, 接下来第1位为版权位, 80(10 000000): 首先是PTS,DTS标志字段,这里是10,表示有PTS,没有DTS。 接下来第6位是ESCR标志字段,这里为0,表示没有该段 接下来第5位是ES速率标志字段,,这里为0,表示没有该段 接下来第4位是DSM特技方式标志字段,,这里为0,表示没有该段 接下来第3位是附加版权信息标志字段,,这里为0,表示没有该段 接下来第2位是PES CRC标志字段,,这里为0,表示没有该段 接下来第1位是PES扩展标志字段,,这里为0,表示没有该段 0A(10):1个字节,指出包含在PES分组标题中的可选字段和任何填充字节所占用的总字节数(既是前面提到的附加数据)。该字段之前的字节指出了有无可选字段(这里只有PTS)。 因为这里PTS,DTS标志字段是10,那就有5个字节的PTS段,就是这里的21 1C C9 AE 0D 最后的五个字节的FF FF FF FF FC是海康自己的一个自减计数值

	#pragma pack(1)

	union littel_endian_size
	{
		unsigned short int	length;
		unsigned char		byte[2];
	};

	struct pack_start_code
	{
		unsigned char start_code[3];
		unsigned char stream_id[1];
	};

	struct program_stream_pack_header
	{
		pack_start_code PackStart;// 4
		unsigned char Buf[9];
		unsigned char stuffinglen;
	};

	struct program_stream_map
	{
		pack_start_code PackStart;
		littel_endian_size PackLength;//we mast do exchange
		//program_stream_info_length
		//info
		//elementary_stream_map_length
		//elem
	};

	struct program_stream_e
	{
		pack_start_code		PackStart;
		littel_endian_size	PackLength;//we mast do exchange
		char				PackInfo1[2];
		unsigned char		stuffing_length;
	};

	#pragma pack()

	int inline ProgramStreamPackHeader(char* Pack, int length, char **NextPack, int *leftlength)
	{
		//printf("[%s]%x %x %x %x\n", __FUNCTION__, Pack[0], Pack[1], Pack[2], Pack[3]);
		//通过 00 00 01 ba头的第14个字节的最后3位来确定头部填充了多少字节
		program_stream_pack_header *PsHead = (program_stream_pack_header *)Pack;
		unsigned char pack_stuffing_length = PsHead->stuffinglen & ‘\x07‘;

		*leftlength = length - sizeof(program_stream_pack_header) - pack_stuffing_length;//减去头和填充的字节
		*NextPack = Pack+sizeof(program_stream_pack_header) + pack_stuffing_length;

		if(*leftlength<4) return 0;

		//printf("[%s]2 %x %x %x %x\n", __FUNCTION__, (*NextPack)[0], (*NextPack)[1], (*NextPack)[2], (*NextPack)[3]);

		return *leftlength;
	}

	inline int ProgramStreamMap(char* Pack, int length, char **NextPack, int *leftlength, char **PayloadData, int *PayloadDataLen)
	{
		//printf("[%s]%x %x %x %x\n", __FUNCTION__, Pack[0], Pack[1], Pack[2], Pack[3]);

		program_stream_map* PSMPack = (program_stream_map*)Pack;

		//no payload
		*PayloadData = 0;
		*PayloadDataLen = 0;

		if(length < sizeof(program_stream_map)) return 0;

		littel_endian_size psm_length;
		psm_length.byte[0] = PSMPack->PackLength.byte[1];
		psm_length.byte[1] = PSMPack->PackLength.byte[0];

		*leftlength = length - psm_length.length - sizeof(program_stream_map);

		//printf("[%s]leftlength %d\n", __FUNCTION__, *leftlength);

		if(*leftlength<=0) return 0;

		*NextPack = Pack + psm_length.length + sizeof(program_stream_map);

		return *leftlength;
	}

	inline int Pes(char* Pack, int length, char **NextPack, int *leftlength, char **PayloadData, int *PayloadDataLen)
	{
		//printf("[%s]%x %x %x %x\n", __FUNCTION__, Pack[0], Pack[1], Pack[2], Pack[3]);
		program_stream_e* PSEPack = (program_stream_e*)Pack;

		*PayloadData = 0;
		*PayloadDataLen = 0;

		if(length < sizeof(program_stream_e)) return 0;

		littel_endian_size pse_length;
		pse_length.byte[0] = PSEPack->PackLength.byte[1];
		pse_length.byte[1] = PSEPack->PackLength.byte[0];

		*PayloadDataLen = pse_length.length - 2 - 1 - PSEPack->stuffing_length;
		if(*PayloadDataLen>0)
			*PayloadData = Pack + sizeof(program_stream_e) + PSEPack->stuffing_length;

		*leftlength = length - pse_length.length - sizeof(pack_start_code) - sizeof(littel_endian_size);

		//printf("[%s]leftlength %d\n", __FUNCTION__, *leftlength);

		if(*leftlength<=0) return 0;

		*NextPack = Pack + sizeof(pack_start_code) + sizeof(littel_endian_size) + pse_length.length;

		return *leftlength;
	}

	int inline GetH246FromPs(char* buffer,int length,CallbackHead& head, char **h264Buffer, int *h264length)
	{
		int leftlength = 0;
		char *NextPack = 0;

		*h264Buffer = buffer;
		*h264length = 0;

		if(ProgramStreamPackHeader(buffer, length, &NextPack, &leftlength)==0)
			return 0;

		char *PayloadData=NULL;
		int PayloadDataLen=0;

		while(leftlength >= sizeof(pack_start_code))
		{
			PayloadData=NULL;
			PayloadDataLen=0;

			if(NextPack
			&& NextPack[0]==‘\x00‘
			&& NextPack[1]==‘\x00‘
			&& NextPack[2]==‘\x01‘
			&& NextPack[3]==‘\xE0‘)
			{
				//接着就是流包,说明是非i帧
				if(Pes(NextPack, leftlength, &NextPack, &leftlength, &PayloadData, &PayloadDataLen))
				{
					if(PayloadDataLen)
					{
						memcpy(buffer, PayloadData, PayloadDataLen);
						buffer += PayloadDataLen;
						*h264length += PayloadDataLen;
					}
				}
				else
				{
					if(PayloadDataLen)
					{
						memcpy(buffer, PayloadData, PayloadDataLen);
						buffer += PayloadDataLen;
						*h264length += PayloadDataLen;
					}

					break;
				}
			}
			else if(NextPack
				&& NextPack[0]==‘\x00‘
				&& NextPack[1]==‘\x00‘
				&& NextPack[2]==‘\x01‘
				&& NextPack[3]==‘\xBC‘)
			{
				if(ProgramStreamMap(NextPack, leftlength, &NextPack, &leftlength, &PayloadData, &PayloadDataLen)==0)
					break;
			}
			else
			{
				//printf("[%s]no konw %x %x %x %x\n", __FUNCTION__, NextPack[0], NextPack[1], NextPack[2], NextPack[3]);
				break;
			}
		}

		return *h264length;
	}

ps:  这篇文章回复私信挺多的,有的同学读了成功的获取了原始的h.264数据,有的同学反映和他们遇到的情况不一样,比如subi2008同学说他读出的流有00 00 01 c0标识的pes数据,这个其实是音频数据,还有遇到00 00 01 bd的,这个是私有流的标识,总之,ps流就解析大家可以参看ps,ts流的文档,里面的内容都有,表2-18里说明了所有的流标识。

ps:

另外,有的hk摄像头回调然后解读出来的原始h.264码流,有的一包里只有分界符数据(nal_unit_type=9)或补充增强信息单元(nal_unit_type=6),如果直接送入解码器,有可能会出现问题,这里的处理方式要么丢弃这两个部分,要么和之后的数据合起来,再送入解码器里,如有遇到的朋友可以交流一下:)

时间: 2024-08-02 10:57:38

ps流来封装h.264数据的相关文章

FU-A分包方式,以及从RTP包里面得到H.264数据和AAC数据的方法

FU-A分包方式,以及从RTP包里面得到H.264数据和AAC数据的方法 RFC3984是H.264的baseline码流在RTP方式下传输的规范,这里只讨论FU-A分包方式,以及从RTP包里面得到H.264数据和AAC数据的方法. H.264的NAL层处理 H264以NALU(NALunit)为单位来支持编码数据在基于分组交换技术网络中传输. NALU定义了可用于基于分组和基于比特流系统的基本格式,同时给出头信息,从而提供了视频编码和外部事件的接口. H264编码过程中的三种不同的数据形式:S

H.264 数据示例

最近项目需要在研究视频实时监控功能. 第一个需要了解的就是 H.264 格式,先以 H.264 文件为例进行数据分析. 在网上下载了 foreman.264 文件,进行了帧类型的分析和帧数据的分析.然后对比实际项目视频的需要,大概分析了一下数据传输的可能性. 代码后续再上传吧,呵呵... // 分辨率为: 176 * 144 - foreman.264 FrameInfo // 实际多媒体录制为: 352 * 288,即关键帧数据约为此 H264 文件关键帧数据的 4 倍 // 关键帧数据约 2

(转)从海康7816的ps流里获取数据h264数据

海康7816使用ps流来封装h.264数据,这里使用的解码器无法识别ps流,因此需要将h264数据从ps流里提取出来 对于ps流的规定可以参考13818-1文档 这里从7816里获取到一些数据取样 00 00 01 BA 44 73 26 B8 34 01 00 00 03 FE FF FF 00 00 00 0100 00 01 BC00 5A E0 FF 00 24 40 0E 48 4B 00 01 0D AF C5 D3 E0 07 FF FF FF FF 41 12 48 4B 00

H.264码流与帧结构

参考连接:http://blog.csdn.net/dxpqxb/article/details/7631304 H264以NALU(NAL unit)为单位来支持编码数据在基于分组交换技术网络中传输. NALU定义了可用于基于分组和基于比特流系统的基本格式,同时给出头信息,从而提供了视频编码和外部世界的接口. H264编码过程中的三种不同的数据形式: SODB 数据比特串-->最原始的编码数据,即VCL数据: RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trai

H.264码流打包分析

H.264码流打包分析 SODB 数据比特串-->最原始的编码数据 RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit"1")若干比特"0",以便字节对齐. EBSP 扩展字节序列载荷-- >在RBSP基础上填加了仿校验字节(0X03)它的原因是: 在NALU加到Annexb上时,需要填加每组NALU之前的开始码 StartCodePrefix,如果该NALU对应的slice为一帧的开始

开放视频编码(H.264)编解码数据输入、输出接口

AnyChat是一套开放的音视频即时通信解决方案,早期的版本已经开放了原始数据的输入.输出接口:1.通过客户端回调函数可以输出用户原始的视频采样帧数据(YUV.RGB):视频数据回调函数2.通过外部数据输入接口可以支持将外部的视频帧传给AnyChat进行编码:如何使用外部音视频数据输入功能? 对于某些特定的场合,上层应用希望获取AnyChat内核原始的H.264编码数据,或是希望将H.264编码之后的数据传输给AnyChat,自AnyChat r4268版本开始提供了支持,该特性将给AnyCha

【转】实现RTP协议的H.264视频传输系统

1.  引言       随着信息产业的发展,人们对信息资源的要求已经逐渐由文字和图片过渡到音频和视频,并越来越强调获取资源的实时性和互动性.但人们又面临着另外一种不可避免的尴尬,就是在网络上看到生动清晰的媒体演示的同时,不得不为等待传输文件而花费大量时间.为了解决这个矛盾,一种新的媒体技术应运而生,这就是流媒体技术.流媒体由于具有启动时延小.节省客户端存储空间等优势,逐渐成为人们的首选,流媒体网络应用也在全球范围内得到不断的发展.其中实时流传输协议 RTP 详细说明了在互联网上传递音频和视频的

FFmpeg的H.264解码器源代码简单分析:熵解码(Entropy Decoding)部分

本文分析FFmpeg的H.264解码器的熵解码(Entropy Decoding)部分的源代码.FFmpeg的H.264解码器调用decode_slice()函数完成了解码工作.这些解码工作可以大体上分为3个步骤:熵解码,宏块解码以及环路滤波.本文分析这3个步骤中的第1个步骤. 函数调用关系图 熵解码(Entropy Decoding)部分的源代码在整个H.264解码器中的位置如下图所示. 单击查看更清晰的图片 熵解码(Entropy Decoding)部分的源代码的调用关系如下图所示. 单击查

FFmpeg的H.264解码器源代码简单分析:宏块解码(Decode)部分-帧内宏块(Intra)

本文分析FFmpeg的H.264解码器的宏块解码(Decode)部分的源代码.FFmpeg的H.264解码器调用decode_slice()函数完成了解码工作.这些解码工作可以大体上分为3个步骤:熵解码,宏块解码以及环路滤波.本文分析这3个步骤中的第2个步骤.由于宏块解码部分的内容比较多,因此将本部分内容拆分成两篇文章:一篇文章记录帧内预测宏块(Intra)的宏块解码,另一篇文章记录帧间预测宏块(Inter)的宏块解码. 函数调用关系图 宏块解码(Decode)部分的源代码在整个H.264解码器