h264 RTP头解析流程 结合NALDecoder.c分析
协议分析 :每一个RTP数据报都由头部(Header)和负载(Payload)两个部分组成,其中头部前 12 个字节的含义是固定的,而负载则可以是音频或者视频数据。
一个活动顺序参数集在一个编码视频序列中保持不变,一个活动图像参数集在一个编码图像里保持不变。
H.264编码器必须根据H.264规范设置NRI值(subclause 7.4.1)当nal_unit_type 范围的是1到12. 特别是,H.264规范, 要求对于nal_unit_type为6,9,10,11,12的NAL单元的NRI的值应该为0。
对于nal_unit_type等于7,8 (指示顺序参数集或图像参数集)的NAL单元,H.264编码器应该设置NRI为11 (二进制格式)
对于nal_unit_type等于5的主编码图像的编码片NAL单元(指示编码片属于一个IDR图像), H.264编码器应设置NRI为11。
打开H264文件,读取流
找到 NALU 标致startcode,即00 00 01 或 00 00 00 01 串
判断UALU单元数据段大小,(UDP一次能发送最大数据为64K字节)
使用何种发送方式(单一发送、聚合发送、分片发送)
如果UALU数据<1500(自己设定),使用单一包发送:
填充RTP头(12 BYTE),payload(7 bit):96 marker(1 bit):0 seq_no(16 bit):随机取 timestamp(32 bit):
第13字节填充NALU头(startcode 的下一个字节),
如果NALU数据>1500,使用分片发送:(分三种情况设备:第一次RTP,中间的RTP,最后一次RTP)
填充RTP头,类似单一包发送,发送整个NALU,timestamp只曾加一次。
不同的是,第13字节填FU INDICATOR,它的type要成28;第14字节才填FU HEADER,
- 第一次RTP:第13 BYTE 是FU INDICATOR ,其中它的TYPE设置成 28 ;第14 BYTE 是 FU HEADER ,S:E:R = 1:0:0,之后才是视频数据。
- 中间的RTP:第13 BYTE 是FU INDICATOR,其中它的TYPE设置成 28 ;第14 BYTE 是 FU HEADER ,S:E:R = 0:0:0,之后才是视频数据。
- 最后一次RTP:第13 BYTE 是FU INDICATOR,其中它的TYPE设置成 28 ;第14 BYTE 是 FU HEADER ,S:E:R = 0:1:0,之后才是视频数据。
NALU数据很小时,用组合封装:
组合封装:NALU payload = NALU payload size + NALU payload header + NALU payload data
如有一个 H.264 的 NALU 是这样的:
[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ] [00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]
这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.
封装成 RTP 包可能如下:
[ RTP Header ] [78, STAP-A NAL HDR, 一个字节 ] [长度, 两个字节] [ 67 42 A0 1E 23 56 0E 2F ...] [长度, 两个字节] [ 67 42 A0 1E 23 56 0E 2F... ]
读rfc 3984搞混了的几个TYPE:
- RTP 中的PT 负载类型 Payload type (PT) : 7 bits --发送H264视频,此值固定设成 96
- NALU 中的TYPE 描述了NALU的属性,如:7指示顺序参数集,8指示图像参数集
- RTP之后的TYPE,即13 BYTE开始,单一打包的TYPE,与NALU中的TYPE一样;FU 分片打包方式,TYPE设成28;
参考:
http://bbs.chinavideo.org/viewthread.php?tid=2451&highlight=rtp%2Bh264
http://www.cppblog.com/czanyou/archive/2010/02/09/67940.html#107573
h264 RTP头解析流程 结合NALDecoder.c分析
协议分析 :每一个RTP数据报都由头部(Header)和负载(Payload)两个部分组成,其中头部前 12 个字节的含义是固定的,而负载则可以是音频或者视频数据。
一个活动顺序参数集在一个编码视频序列中保持不变,一个活动图像参数集在一个编码图像里保持不变。
H.264编码器必须根据H.264规范设置NRI值(subclause 7.4.1)当nal_unit_type 范围的是1到12. 特别是,H.264规范, 要求对于nal_unit_type为6,9,10,11,12的NAL单元的NRI的值应该为0。
对于nal_unit_type等于7,8 (指示顺序参数集或图像参数集)的NAL单元,H.264编码器应该设置NRI为11 (二进制格式)
对于nal_unit_type等于5的主编码图像的编码片NAL单元(指示编码片属于一个IDR图像), H.264编码器应设置NRI为11。
打开H264文件,读取流
找到 NALU 标致startcode,即00 00 01 或 00 00 00 01 串
判断UALU单元数据段大小,(UDP一次能发送最大数据为64K字节)
使用何种发送方式(单一发送、聚合发送、分片发送)
如果UALU数据<1500(自己设定),使用单一包发送:
填充RTP头(12 BYTE),payload(7 bit):96 marker(1 bit):0 seq_no(16 bit):随机取 timestamp(32 bit):
第13字节填充NALU头(startcode 的下一个字节),
如果NALU数据>1500,使用分片发送:(分三种情况设备:第一次RTP,中间的RTP,最后一次RTP)
填充RTP头,类似单一包发送,发送整个NALU,timestamp只曾加一次。
不同的是,第13字节填FU INDICATOR,它的type要成28;第14字节才填FU HEADER,
- 第一次RTP:第13 BYTE 是FU INDICATOR ,其中它的TYPE设置成 28 ;第14 BYTE 是 FU HEADER ,S:E:R = 1:0:0,之后才是视频数据。
- 中间的RTP:第13 BYTE 是FU INDICATOR,其中它的TYPE设置成 28 ;第14 BYTE 是 FU HEADER ,S:E:R = 0:0:0,之后才是视频数据。
- 最后一次RTP:第13 BYTE 是FU INDICATOR,其中它的TYPE设置成 28 ;第14 BYTE 是 FU HEADER ,S:E:R = 0:1:0,之后才是视频数据。
NALU数据很小时,用组合封装:
组合封装:NALU payload = NALU payload size + NALU payload header + NALU payload data
如有一个 H.264 的 NALU 是这样的:
[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ] [00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]
这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.
封装成 RTP 包可能如下:
[ RTP Header ] [78, STAP-A NAL HDR, 一个字节 ] [长度, 两个字节] [ 67 42 A0 1E 23 56 0E 2F ...] [长度, 两个字节] [ 67 42 A0 1E 23 56 0E 2F... ]
读rfc 3984搞混了的几个TYPE:
- RTP 中的PT 负载类型 Payload type (PT) : 7 bits --发送H264视频,此值固定设成 96
- NALU 中的TYPE 描述了NALU的属性,如:7指示顺序参数集,8指示图像参数集
- RTP之后的TYPE,即13 BYTE开始,单一打包的TYPE,与NALU中的TYPE一样;FU 分片打包方式,TYPE设成28;
参考:
http://bbs.chinavideo.org/viewthread.php?tid=2451&highlight=rtp%2Bh264
http://www.cppblog.com/czanyou/archive/2010/02/09/67940.html#107573
分享到:
相关推荐
h264RTP实例分析带数据和程序,有h264原始数据,和经RTP打包后的数据,带有打包程序
h264协议分析资料 实现rtp打包发送 用vlc可以观看
超级完整的live555代码分析学习文档以及基于live555的H.264 RTP发送程序
通过tcpdump或者wireshark抓到的包通常是rtp流,保存为.pcap格式文件后中,可通过wireshark进行解析,得出h264裸流,并保存为文件。 我这里有一段rtp流文件,作为演示使用(这个文件有点不标准,一般一个nal打一个...
本文从视频传输系统模型入手,分析了最新视频编码标准H.264在算法上的层次结构特点以及音、视频实时传送协议RTP的高效性。并且随着适合H.264流的RTP栽荷格式的提出,基于RTP的H.264流媒体无线传输渐渐地得到应用...
1、解析rtpdump文件获取rtp包。 2、将rtp包解为hevc/h265裸流并存为265文件。 资源是一个完整的vs2012工程。 对应的CSDN博文http://blog.csdn.net/andyshengjl/article/details/79330610
基于RTP的H_264视频传输技术,详细分析基于RTP的h264传输技术
rtp_over_rtsp精简分析.pdf ,Mpeg4 h264 RTP打包格式。
https://blog.csdn.net/engineer_james/article/details/81743571 配合分析 用来学习,rtsp rtp的dump文件,已经在wireshark 中分类,用wireshark打开
1. 需要将aac的前7个(或9个)字节的ADTS去掉,即是跳过adts header 5. 从第17字节开始就是payload(去掉ADTS的aac数据)数据
EasyICE_2.7.0.2 Elecard HEVC Analyzer Elecard StreamEye Tool flvAnalyser v0.0.3.003 H264BSAnalyzer.exe H264Visa h265_export.lua ...rtp_h264_extractor.lua SpecialVH264_1.1.exe VideoEye_0.2
摘要:本文介绍了使用Wireshark从H.264编码的RTP流中分析出视频的质量和分辨率的方法。 关键词:Wireshark; 分辨率; RTP; H.264; 1080P;
--- -----RTP协议分析中文---------h很详细的中文,全部翻译过来的。
接着对网络传输协议进行分析比较,选用RTP协议作为本系统的传输层协议,并深入分析了RTP/RTCP的特点及数据包格式。最后给出了本系统的总体结构和系统各个模块的实现方法,包括TCP/IP通信模块,RTP通信模块、视频...
H.265裸流,可用VLC播放,用于编码分析,使用海康威视IPC相机获取的RTP流解析为H.265并保存的文件
网络摄像机一般使用的是rtsp协议,rtsp协议使用的是rtp协议打包h.264格式的视频数据,rtp协议和rtp打包h.264视频数据的协议见链接:https
该文档从实际工程范例的角度,详尽地描述了RTP,RTCP, SIP协议的结合使用,包括MPEG4和H.264 封装RTP包,以及UDP,TCP封装发送等,是一篇非常好的学习资料.....
海康大华码流分析和标准化,海康大华的视频解码文件格式解析, 1. 文件头、帧头解析 ...3. 格式包括标准流文件, 海康大华私有文件, 包括海康PS封装、TS封装、RTP封装,格式支持H264、MPEG-4、AVC264
工具包括FFMPEG原生万能视频解码器、音视频分离器、YUV视频解码器、PCAP数据包音视频码流播放器、RTP码流推流器、PCM音频文件播放器、PCM转AAC转换器、主机端口检测器、FTP快登、IP主机网络转换、264视频分析、UDP/...
比如APK多渠道打包就要我们了解zip格式中字节数据的意义,这还只是字节,一个字节8位,去分析H.264要更细致到二进制位的数据,信息量就更大了。 3、然后我们就可以学习音视频的基础知识了:RGB、YUV像素数据处理、...