本文主要是介绍RTP 资料汇总收集，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
RTP协议分析 -- //
RTCP资料详解
视音频数据处理入门：UDP-RTP协议解析
H264 RTP 封包原理
实现RTP协议的H.264视频传输系统 ： （包含NALU 的类型 0~31）
RTP协议全解析（H264码流和PS流）
RTP打包发送H.264 //
这个好，有源码
RTP格式打包发送H.264数据 //备选
RTP打包发送H.264 //备选
rfc3550的定义，在5.1节(http://tools.ietf.org/html/rfc3550#section-5.1)。
RTP timestamp与帧率及时钟频率的关系
RTP packet：
RTP是基于UDP协议的，RTP服务器会通过UDP协议，通常每次会发送一个RTP packet。客户端通过解析RTP packet，读取其中的数据然后进行播放了。
RTP packet的结构如下：
1. RTP Header：RTP 包的头部
2. contributing sources：个数为0-n个，所以可以为空。具体定义参考rfc3550
3. RTP payload：即RTP要传输的数据
网友:
1、裸的H264码流可以直接通过RTP进行发送，但是发送的方式可以不同，这要看对面对RTP包中的数据做怎样的处理，有的可以直接将裸的H264码流在不进行严格NALU分片的情况下直接对H264数据进行平分，接收端只是简单地对RTP进行拼包，这样可以，同样，严格的对RTP的分包必须对H264码流进行分析，向接海康的平台时，RTP发送H264裸码流必须将H264进行NALU的分包，每个分片再通过RTP发送。接收端通过对RTP中的NALU拼包才还原裸的H264码流。
2、裸的H264码流也可以通过RTP+PS流的方式进行打包发送，但是要对H264（ES）进行分包处理，不然高清的视频帧在 PS封装时会出现无法解码的情况，具体的解决方式：对长度过长的H264数据帧（ES）进行PES分包处理，在打成PS通过RTP发送
NALU分割： 00 00 00 01; 00 00 01; 两种
网友;
字节序需要变一下。高地位互换就行了。这个长度也可以用wireshark中的信息算出来。其实只需要发送RR包就行了，RR包32字节。另外28字节是SDES包。我试过，只发送RR包的32字节也行.
RTP中使用时间戳排序还是序号排序？
以前看RTP文档的时候一直搞不清楚，在接收音视频数据的时候，是用序号排序还是用时间戳排序呢？由于搞不清楚，一直都是随便用哪个的。
今天搞清楚了，如果你想你的程序在程序退出以后再接入还能正确接收音视频，那就用时间戳排序，如果你觉得程序退出了再起一个实例是不能发送或者接收原来的数据的，那么就用序号进行排序。
前几天程序里面用序号排序的，结果发现程序退出之后再启动，接收程序就不播放音视频了，想了我半天，最后才追踪到序号的问题，如果用时间戳排序，是不会有这种问题的。
紧跟着Session值， 你可以看到一个值： “timeout= xxxx”。. 这是服务器需要得到回应或者ACK回应（为了保持连接）的时间。客户端必须在这个时段内发送一个ACK ，要不然连接就要被强制中断。一个ACK就是发送一条GET_PARAMETER命令到服务器。
、、、、、、、、、、、、、、、、、、、、、、、、、、
收到一个RTP包之后,通常的处理逻辑是:
1. 如果rtp包的ssrc与这个流的SSRC不一致, 丢弃
2. 判断序号是否连续,是否存在丢包或乱序
3. 组包,提取整帧编码图像解码
、、、、、、、、、、、、、、、、、、、、、、、、、、
这篇关于RTP 资料汇总收集的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
