RTP协议详解

最新推荐文章于 2024-04-22 07:00:00 发布

dusk0825

最新推荐文章于 2024-04-22 07:00:00 发布

阅读量6.5k

点赞数 2

分类专栏：流媒体

本文链接：https://blog.csdn.net/dusk0825/article/details/108240156

版权

流媒体专栏收录该内容

2 篇文章 1 订阅

订阅专栏

RTP协议负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

一、RTP数据包格式

RTP码流由多个RTP包组成，每个RTP包，由RTP头标准字段（固定12字节）、RTP头扩展字段、RTP负载、填充字段组成，私有数据存放在私有扩展字段，包括各种描述及各种私有类型数据，RTP保存成文件是不能直接播放的，抓包下来的RTP码流中往往含有协议交互数据和冗余数据。

(1) V：RTP协议的版本号，占2位，当前协议版本号为2；
(2) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。如果P=1,需要查看这一个RTP包文最后一个字节(该字节的值只可能为1，2，3)，如果字节值是0x01，说明只有一个字节填充；如果是0x02, 说明有两个字节填充；如果字节值是0x03，说明有三个字节填充；
(3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。一般只有hik私有帧(90 F0开头)才会有扩展数据。如果X=1，在RTP头的12个字节之后，会带有以下内容：两个字节的扩展内容说明extenProfile；两个字节的扩展数据长度extenLength；扩展数据4*extenLength字节；
(4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数（作用信源CSRC计数器，字节数为4n个）。比如一个rtp头中，cc的值为2，则在RTP的12个字节后会带上4*2=8个字节的数据，表示CSRC；
(5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始；
(6) PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，H264:96; G711u:0; g711a:8; aac:104; hik私有数据:112，其他荷载类型，参考官网https://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml
(7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的；
(8) 时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制；
(9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。可以简单理解为一路媒体信息的标记，比如码流中所有H264视频的RTP头中这个标记为0x12345678；所有G711音频的RTP头中这个标记为0x11111111；对于hik私有帧，这个标记很多时候都是0x55667788；
(10) 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。具体数量由前面的CC决定。

二、RTP数据格式解析

我们经常会看到“RTP中视频帧第1个字节是0x80或0xA0，第2个字节是0x60或0xE0”这句话。它具体是怎么来的呢？首先，将0x80 0x60拆成二进制：1000 0000 0110 0000，第一个字节前两位是10，也就是版本号是2，这个是当前标准规定的；其余位都是0。然而平时填充位是有可能存在的，所以第一个字节为1010 0000，也就是A0；
第二个字节第一位是mark位，如果这位是0，那个第二个字节就是pt值，平时264，265的pt值都是0x60。但是如果是视频帧的首帧，那么mark位就是1，也就是E0。

详细介绍：
(1) 其中1000 0000 0110 0000前面2位(二进制10转成十进制就是2)就是RTP版本号，当前标准规定这个版本号固定为2；
(2) 其中1000 0000 0110 0000第三个比特位0是填充位(pad)。这个就是用来对齐字节用的，在平时码流传输中，这个比特位有可能会被置1 ；
(3) 其中1000 0000 0110 0000第四个比特位0是扩展位(extend)。这个基本都是设置为0的，可以忽略，只有在hik私有帧的时候会被置1 ；
(4) 其中1000 0000 0110 0000 四个比特位是CC，这个基本也都是设置为0的，可以忽略；
(5) 其中1000 0000 0110 0000 这个比特位是mark标志；
(6) 其中1000 0000 0110 0000 这七个比特位是PT值，用来说明码流类型，这里110 0000转成10进制是96，说明当前RTP封装的数据是H264。如果是G711U数据，那么这七位应该是000 0000；如果是G711A数据，那这七位就是000 1000，这些也是标准规定的。

接着是两个字节的序列号，也就是0x8D 0xA9。从上图中可以看到，第二个RTP头中序号为0x8D 0xAA，也标明序号会依次增加1，RTP也就是根据这个来判断是否丢帧和乱序的。最后是四个字节的时间戳和四个字节的SSRC号。

一般找H264的RTP头的方法可以先在文件中搜索0x80 0x60,然后假设这个是RTP头，找到SSRC号；第二步是在文件中搜索SSRC号，看能否找到，如果找不到，说明这个不是RTP头。如果找到了，看下是否也是80 60开头(或者是80 E0,A0 E0, A0 60.因为有可能有pad位，那第一个字节就是A0，如果mark位是1，第二个字节就是E0)，并且序号和上一个假设的RTP头相近(因为可能会丢序号，所以不一定刚好相差1)，以此来确定是否是真实RTP头。

三、RTP组包

1、基于TCP传输，包格式为： RTP标志+RTP头+RTP负载数据（RTP Over TCP、RTP Over RTSP）

其中：RTP标志位（4个字节）：$+channel id(1 byte)+长度（2字节），此长度不包含本身这4个字节。

//以$字符开头，见标准文档rfc2326 10.12 Embedded (Interleaved) Binary Data
struct INTERLEAVED_HEAD {
   UINT8 nMagic;
   UINT8 nChan;
   UINT16 nDataLen;

   INTERLEAVED_HEAD()  {
       nMagic = '$';
       nChan = 0;
       nDataLen = 0;
   }
};

INTERLEAVED_HEAD* stInterleavedHead = (INTERLEAVED_HEAD*)((char*)data - 4);
stInterleavedHead->nMagic = '$';

stInterleavedHead->nChan = iInterLeaved; //Setup信令交互，Transport参数传入的

stInterleavedHead->nDataLen = Htons(len);
2、基于UDP传输中，无RTP标志；

3、时间戳

时间戳单位：时间戳计算的单位不是秒之类的单位，而是由采样频率所代替的单位。时间戳增量：相邻两个RTP包之间的时间差（以时间戳单位为基准）。采样频率：每秒钟抽取样本的次数，例如音频的采样率一般为8000Hz。

UINT32 GetRTPTimeStamp(BOOL bMark)
{
   //上面个判断，处理初始值
   bool bFirstFrame = false;
   if ((UINT32)(-1) == m_beginRtpCalcTime) { //first packet
       m_beginRtpCalcTime = GetTimeTick();//返回值为微妙
   }
   if ((UINT32)(-1) == m_lastRtpStampTime) { //first packet
       bFirstFrame = true;
       m_lastRtpStampTime = 0;
   }
   //下面逻辑判断，计算时间戳
   HPR_UINT32 tmpRtpStampTime = m_lastRtpStampTime;
   if (bMark) {
//视频的采样频率是90khz，相当于1秒内采样90000次，则1毫秒采样90次
       m_lastRtpStampTime = HPR_UINT32((GetTimeTick()-m_beginRtpCalcTime)*90);   //溢出后,自动取低bit,理论上pts不会溢出
       if (tmpRtpStampTime >= m_lastRtpStampTime && !bFirstFrame)
       {//如果网络发生拥塞，两帧时间戳一样，在前一帧基础上加上
           m_lastRtpStampTime = tmpRtpStampTime + 90;
       }
   }
   return tmpRtpStampTime;
}
4、RTP分包发送、流控、mark位

RTP数据包有大小限制，完整的一帧数据，可能需要多个RTP包传输，如果是视频帧，最后一包的Mark位需要设置为1，同一帧数据内的多个包，时间戳是相同的。

int g_iUdpMaxOnePackLen = 1276;
#define TCP_MAX_ONE_FRAME_DATA_LEN 8192

struct PACKET_T {
   char* pszDataBuf;
   INT32 iDataLen;
   INT32 iPayload;
   BOOL bMark;
   UINT32 nTimestamp;
};

BOOL g_isUdpSpeedControl = HPR_FALSE; //udp码流发送，是否进行控制
INT32 g_iUdpIntervalNum = 3; //udp码流发送，每间隔几个包sleep一次
INT32 g_iUdpSleepTimeMs = 1; //udp码流发送，每次sleep多少毫秒
void SendData(PACKET_T stPack)
{
int iSendTimes = 1;
int iMaxOneFrameLen = eRtpTransMethod == RTP_OVER_UDP ? g_iUdpMaxOnePackLen : TCP_MAX_ONE_FRAME_DATA_LEN;
int iDataTotalLen = stPack.iDataLen;
if (bSubPackageByUdp)//配置UDP分包
{
iSendTimes = (iDataTotalLen % iMaxOneFrameLen) == 0 ? iDataTotalLen / iMaxOneFrameLen : iDataTotalLen / iMaxOneFrameLen + 1;
}

if (iSendTimes > 1) {//分包处理
char* pSrcData = stPack.pszDataBuf;
bool bSrcMark = stPack.bMark;
int iDataOffset = 0;
for (int i = 0; i < iSendTimes; ++i)
{
if (meRtpTransMethod == RTP_OVER_UDP && g_isUdpSpeedControl && g_iUdpIntervalNum > 0)//udp发送数据流控
{
if ((++m_iSendFrameNum) % (UINT32)(g_iUdpIntervalNum * 1) == 0)
{
Sleep(g_iUdpSleepTimeMs);
}
}
int iSendLen = (i ==iSendTimes-1) ? (iDataTotalLen - i*iMaxOneFrameLen) : iMaxOneFrameLen;
stPack.bMark = (i ==iSendTimes-1) ? bSrcMark : FALSE; //最后一包时，使用原mark标识
stPack.iDataLen = iSendLen;
stPack.pszDataBuf = pSrcData + iDataOffset;
int iTmpRet = pRtpTransSession->SendData(&stPack, m_bSendRtpPacket);
if (iTmpRet != 0)
{
//容错的重发处理
}
iDataOffset+= iSendLen;
}
}else {
//直接发送
}
}

四、RTP解析

1、RTP解包

struct RTP_HEAD {
unsigned char count : 4;
unsigned char extension : 1;
unsigned char padding : 1;
unsigned char version : 2;
unsigned char payload : 7;
unsigned char marker : 1;
unsigned short sequence;
UINT32 timestamp;
UINT32 ssrc;
};
const HPR_INT32 RTP_HEAD_LEN = sizeof(RTP_HEAD);

struct RTP_HEAD_EXT {
unsigned short id;
unsigned short len;
};

void UnpackRtpPacket(PACKET_T* pstData, UINT32& ssrc)
{
if (pstData->iDataLen > RTP_HEAD_LEN) {
RTP_HEAD* pRtpHead = (RTP_HEAD*)pstData->pszDataBuf;
INT32 iPaddingBytes = 0;
if (pRtpHead->padding == 1)//填充位
{
UINT8* pPadingNum = (UINT8*)pstData->pszDataBuf + pstData->iDataLen - 1;
iPaddingBytes = *pPadingNum;
}
pstData->bMark = pRtpHead->marker;
pstData->iPayload = pRtpHead->payload;
pstData->nTimestamp = Ntohl(pRtpHead->timestamp);
ssrc = pRtpHead->ssrc;
INT32 iCSRCLen = pRtpHead->count*sizeof(UINT32);//CSRC
INT32 iExtenHeadLen = 0;
if (pRtpHead->extension == 1)//扩展头
{
RTP_HEAD_EXT* pRtpExtHead = (RTP_HEAD_EXT*)((char*)pstData->pszDataBuf + RTP_HEAD_LEN + iCSRCLen);
iExtenHeadLen = HPR_Ntohs(pRtpExtHead->len)*sizeof(UINT32) + sizeof(RTP_HEAD_EXT);
}
INT32 iDataLen = pstData->iDataLen - RTP_HEAD_LEN - iCSRCLen - iExtenHeadLen - iPaddingBytes;
if (iDataLen > 0)
{
pstData->pszDataBuf = pstData->pszDataBuf + RTP_HEAD_LEN + iCSRCLen + iExtenHeadLen;
pstData->iDataLen = iDataLen;
}
}
}

2、RTP排序

可以根据序号，也可以根据时间戳排序；

五、RTP开源库

Jrtplib、ORTP

JRTPLIB 是一个高度封装后的RTP库，在使用它时很多时候并不用关心RTCP数据报是如何被发送和接收的，因为这些都可以由 JRTPLIB自己来完成。只要PollData()或者SendPacket()方法被成功调用，JRTPLIB就能够自动对到达的RTCP数据报进行处理，并且还会在需要的时候发送RTCP数据报，从而能够确保整个RTP会话过程的正确性。

dusk0825

关注

2
点赞
踩
23

收藏

觉得还不错? 一键收藏
0
评论
RTP协议详解

RTP协议负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。一、RTP数据包格式 RTP码流由多个RTP包组成，每个RTP包，由RTP头标准字段（固定12字节）、RTP头扩展字段、RTP负载、填充字段组成，私有数据存放在私有扩展字段，包括各种描述及各种私有类型数据，RTP保存成文件是...
复制链接

扫一扫