RTP之H264封包和解包

1. RTP数据包格式

RTP报文头格式(见RFC3550 Page12):

图片

1) V:RTP协议的版本号,占2位,当前协议版本号为2

2) P:填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。

3) X:扩展标志,占1位,如果X=1,则在RTP报头后跟有一个扩展报头

4) CC:CSRC计数器,占4位,指示CSRC 标识符的个数

5) M: 标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。

6) PT: 有效荷载类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的,这样便于客户端进行解析。

7) 序列号:占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序,序列号的初始值是随机的,同时音频包和视频包的sequence是分别记数的。

8) 时戳(Timestamp):占32位,必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。

9) 同步信源(SSRC)标识符:占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。

10) 特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

从 RTP 数据包的格式不难看出,它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息。这些都为实时的流媒体传输提供了相应的基础。而传输控制协议RTCP为 RTP传输提供了拥塞控制和流控制,它的具体包结构和各字段的含义可参考RFC3550,此处不再赘述。

注:基本的RTP说明并不定义任何头扩展本身,如果遇到X=1,需要特殊处理。

#define RTP_VERSION 2 // RTP version field must equal 2 (p66)
#define N_FU_HEADER  2
#define FU_START    0x80
#define FU_END      0x40
#define nbo_w32 rtp_write_uint32
typedef struct _rtp_header_t
{
  uint32_t v:2;    /* protocol version */
  uint32_t p:1;    /* padding flag */
  uint32_t x:1;    /* header extension flag */
  uint32_t cc:4;    /* CSRC count */
  uint32_t m:1;    /* marker bit */
  uint32_t pt:7;    /* payload type */
  uint32_t seq:16;  /* sequence number */
  uint32_t timestamp; /* timestamp */
  uint32_t ssrc;    /* synchronization source */
} rtp_header_t;

#define RTP_V(v)  ((v >> 30) & 0x03) /* protocol version */
#define RTP_P(v)  ((v >> 29) & 0x01) /* padding flag */
#define RTP_X(v)  ((v >> 28) & 0x01) /* header extension flag */
#define RTP_CC(v)  ((v >> 24) & 0x0F) /* CSRC count */
#define RTP_M(v)  ((v >> 23) & 0x01) /* marker bit */
#define RTP_PT(v)  ((v >> 16) & 0x7F) /* payload type */
#define RTP_SEQ(v)  ((v >> 00) & 0xFFFF) /* sequence number */

#define RTP_FIXED_HEADER 12

struct rtp_packet_t
{
  rtp_header_t rtp;
  uint32_t csrc[16];
  const void* extension; // extension(valid only if rtp.x = 1)
  uint16_t extlen; // extension length in bytes
  uint16_t reserved; // extension reserved
  const void* payload; // payload
  int payloadlen; // payload length in bytes
};

H264demo:
  rtp_packet_t packer;
  packer->pkt.rtp.v = RTP_VERSION;
  packer->pkt.rtp.pt = pt;//102 (h264) RTP报文中有效载荷的类型
  packer->pkt.rtp.seq = seq; //sequence number
  packer->pkt.rtp.ssrc = ssrc;//随机数
  
   if (bytes + RTP_FIXED_HEADER <= packer->size)
  {
    // single NAl unit packet 
    return rtp_h264_pack_nalu(packer, nalu, bytes, last ? 1 : 0);
  }
  else //这里就要分成多个RTP包发送了。
  {
    return rtp_h264_pack_fu_a(packer, nalu, bytes, last ? 1 : 0);
  } 
  ///@param[in] h264 H.264 byte stream format data(A set of NAL units)
int rtp_h264_annexb_nalu(const void* h264, int bytes, int (*handler)(void* param, const uint8_t* nalu, int bytes, int last), void* param)
{
int r;
  ptrdiff_t n;
  const uint8_t* p, * next, * end;
  end = (const uint8_t*)h264 + bytes;
  p = h264_startcode((const uint8_t*)h264, bytes);

  r = 0;
  while (p && 0 == r)
  {
    next = h264_startcode(p, (int)(end - p));
    if (next)
    {
      n = next - p - 3;
    }
    else
    {
      n = end - p;
    }

    while (n > 0 && 0 == p[n - 1]) n--; // filter tailing zero

    assert(n > 0);
    if (n > 0)
    {
     // r = handler(param, p, (int)n, next ? 0 : 1);
     r = rtp_h264_pack_nalu(param, p, (int)n, next ? 0 : 1);
    }

    p = next;
}
static int rtp_h264_pack_fu_a(struct rtp_encode_h264_t *packer, const uint8_t* nalu, int bytes, int mark)
{
  int r, n;
  unsigned char *rtp;

  // RFC6184 5.3. NAL Unit Header Usage: Table 2 (p15)
  // RFC6184 5.8. Fragmentation Units (FUs) (p29)
  uint8_t fu_indicator = (*nalu & 0xE0) | 28; // FU-A
  uint8_t fu_header = *nalu & 0x1F;

  r = 0;
  nalu += 1; // skip NAL Unit Type byte
  bytes -= 1;
  assert(bytes > 0);

  // FU-A start
  for (fu_header |= FU_START; 0 == r && bytes > 0; ++packer->pkt.rtp.seq)
  {
    if (bytes + RTP_FIXED_HEADER <= packer->size - N_FU_HEADER)
    {
      assert(0 == (fu_header & FU_START));
      fu_header = FU_END | (fu_header & 0x1F); // FU-A end
      packer->pkt.payloadlen = bytes;
    }
    else
    {
      packer->pkt.payloadlen = packer->size - RTP_FIXED_HEADER - N_FU_HEADER;
    }

    packer->pkt.payload = nalu;
    n = RTP_FIXED_HEADER + N_FU_HEADER + packer->pkt.payloadlen;
    rtp = (uint8_t*)packer->handler.alloc(packer->cbparam, n);
    if (!rtp) return -ENOMEM;

    packer->pkt.rtp.m = (FU_END & fu_header) ? mark : 0; // set marker flag
    n = rtp_packet_serialize_header(&packer->pkt, rtp, n);
    if (n != RTP_FIXED_HEADER)
    {
      assert(0);
      return -1;
    }

    /*fu_indicator + fu_header*/
    rtp[n + 0] = fu_indicator;
    rtp[n + 1] = fu_header;
    memcpy(rtp + n + N_FU_HEADER, packer->pkt.payload, packer->pkt.payloadlen);

    r = packer->handler.packet(packer->cbparam, rtp, n + N_FU_HEADER + packer->pkt.payloadlen, packer->pkt.rtp.timestamp, 0);
    packer->handler.free(packer->cbparam, rtp);

    bytes -= packer->pkt.payloadlen;
    nalu += packer->pkt.payloadlen;
    fu_header &= 0x1F; // clear flags
  }

  return r;
}

  static int rtp_h264_pack_nalu(struct rtp_encode_h264_t *packer, const uint8_t* nalu, int bytes, int mark)
{
  int r, n;
  uint8_t *rtp;

  packer->pkt.payload = nalu;
  packer->pkt.payloadlen = bytes;
  n = RTP_FIXED_HEADER + packer->pkt.payloadlen;
  rtp = (uint8_t*)packer->handler.alloc(packer->cbparam, n);
  if (!rtp) return ENOMEM;

  //packer->pkt.rtp.m = 1; // set marker flag
  packer->pkt.rtp.m = (*nalu & 0x1f) <= 5 ? mark : 0; // VCL only
  n = rtp_packet_serialize(&packer->pkt, rtp, n);
  if (n != RTP_FIXED_HEADER + packer->pkt.payloadlen)
  {
    assert(0);
    return -1;
  }

  ++packer->pkt.rtp.seq;
  //cb rtp数据
  r = packer->handler.packet(packer->cbparam, rtp, n, packer->pkt.rtp.timestamp, 0);
  packer->handler.free(packer->cbparam, rtp);
  return r;
}
static inline void nbo_write_rtp_header(uint8_t *ptr, const rtp_header_t *header)
{
  ptr[0] = (uint8_t)((header->v << 6) | (header->p << 5) | (header->x << 4) | header->cc);
  ptr[1] = (uint8_t)((header->m << 7) | header->pt);
  ptr[2] = (uint8_t)(header->seq >> 8);
  ptr[3] = (uint8_t)(header->seq & 0xFF);

  nbo_w32(ptr+4, header->timestamp);
  nbo_w32(ptr+8, header->ssrc);
}
static inline void rtp_write_uint32(uint8_t* ptr, uint32_t val)
{
  ptr[0] = (uint8_t)(val >> 24);
  ptr[1] = (uint8_t)(val >> 16);
  ptr[2] = (uint8_t)(val >> 8);
  ptr[3] = (uint8_t)val;
}
int rtp_packet_serialize_header(const struct rtp_packet_t *pkt, void* data, int bytes)
{
  int hdrlen;
  uint32_t i;
  uint8_t* ptr;

  if (RTP_VERSION != pkt->rtp.v || 0 != (pkt->extlen % 4))
  {
    assert(0); // RTP version field must equal 2 (p66)
    return -1;
  }

  // RFC3550 5.1 RTP Fixed Header Fields(p12)
  hdrlen = RTP_FIXED_HEADER + pkt->rtp.cc * 4 + (pkt->rtp.x ? 4 : 0);
  if (bytes < hdrlen + pkt->extlen)
    return -1;

  ptr = (uint8_t *)data;
  nbo_write_rtp_header(ptr, &pkt->rtp);
  ptr += RTP_FIXED_HEADER;

  // pkt contributing source
  for (i = 0; i < pkt->rtp.cc; i++, ptr += 4)
  {
    nbo_w32(ptr, pkt->csrc[i]);
  }

  // pkt header extension
  //注:基本的RTP说明并不定义任何头扩展本身,如果遇到X=1,需要特殊处理
  if (1 == pkt->rtp.x)
  {
    // 5.3.1 RTP Header Extension
    assert(0 == (pkt->extlen % 4));
    nbo_w16(ptr, pkt->reserved);
    nbo_w16(ptr + 2, pkt->extlen / 4);
    memcpy(ptr + 4, pkt->extension, pkt->extlen);
    ptr += pkt->extlen + 4;
  }

  return hdrlen + pkt->extlen;
}
int rtp_packet_serialize(const struct rtp_packet_t *pkt, void* data, int bytes)
{
  int hdrlen;

  hdrlen = rtp_packet_serialize_header(pkt, data, bytes);
  if (hdrlen < RTP_FIXED_HEADER || hdrlen + pkt->payloadlen > bytes)
    return -1;

  memcpy(((uint8_t*)data) + hdrlen, pkt->payload, pkt->payloadlen);
  return hdrlen + pkt->payloadlen;
}

2、RTP荷载H264码流

NALU打包成RTP的方式有三种:

1). 单一 NAL 单元模式

即一个RTP 包仅由一个完整的 NALU 组成,这种情况下 RTP NAL 头类型字段和原始的 H.264的。

NALU 头类型字段是一样的,对于 NALU 的长度小于 MTU 大小的包,一般采用单一 NAL 单元模式。

对于一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成,其中 Start Code 用于标示这是一个。

NALU 单元的开始, 必须是 “00 00 00 01” 或 “00 00 01”, NALU 头仅一个字节, 其后都是 NALU 单元内容。

打包时去除 “00 00 01” 或 “00 00 00 01” 的开始码, 把其他数据封包的 RTP 包即可。

封装成 RTP 包将如下:

[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F]

即只要去掉 4 个字节的开始码就可以了

2). 组合封包模式

 即可能是由多个NAL 单元组成一个 RTP 包. 分别有4种组合方式: STAP-A, STAP-B, MTAP16, MTAP24。

那么这里的类型值分别是 24, 25, 26 以及 27.当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中。

例:
如有一个 H.264 的 NALU 是这种:

[00 00 00 01 67 42 A0 1E 23 56 0E 2F … ]
[00 00 00 01 68 42 B0 12 58 6A D4 FF … ]

封装成 RTP 包将例如以下:

[ RTP Header ] [78 (STAP-A头,占用1个字节)] [第一个NALU长度 (占用两个字节)] [ 67 42 A0 1E 23 56 0E 2F ] 

[第二个NALU长度 (占用两个字节)] [68 42 B0 12 58 6A D4 FF … ]

3). 分片封包模式

    用于把一个NALU 单元封装成多个 RTP 包. 存在两种类型 FU-A 和 FU-B. 类型值分别是 28 和 29。

图片

当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包. 也称为 Fragmentation Units (FUs)。

FU-A的分片格式

数据比较大的H264视频包,被RTP分片发送,12字节的RTP头后面跟随的就是FU-A分片。

FU indicator有以下格式:

      +—————+

      |0|1|2|3|4|5|6|7|

      +-+-+-+-+-+-+-+-+

      |F|NRI|  Type   |

      +—————+

 FU指示字节的类型域 Type=28表示FU-A。。NRI域的值必须根据分片NAL单元的NRI域的值设置。

 uint8_t fu_indicator = (*nalu & 0xE0) | 28; // FU-A

   FU header的格式如下:

      +—————+

      |0|1|2|3|4|5|6|7|

      +-+-+-+-+-+-+-+-+

      |S|E|R|  Type   |

      +—————+

   S: 1 bit

 当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始,开始位设为0。

   E: 1 bit

  当设置成1, 结束位指示分片NAL单元的结束,即, 荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的FU荷载不是分片NAL单元的最后分片,结束位设置为0。

   R: 1 bit

   保留位必须设置为0,接收者必须忽略该位。

   Type: 5 bits

   NAL单元荷载类型定义见下表

表1.  单元类型以及荷载结构总结

      Type  Packet      Typename                      

     ———————————————————

      0     undefined                                   –

      1-23   NALunit    Single NAL unit packet per H.264  

      24    STAP-A     Single-time aggregation packet   单一时间的组合包

      25    STAP-B     Single-time aggregation packet    单一时间的组合包

      26    MTAP16    Multi-time aggregation packet   多个时间的组合包  

      27    MTAP24    Multi-time aggregation packet  多个时间的组合包   

      28     FU-A     Fragmentation unit           分片的单元    

      29    FU-B      Fragmentationunit        分片的单元        

      30-31 undefined        没有定义

图片

3.拆包和解包

拆包:当编码器在编码时需要将原有一个NAL按照FU-A进行分片,原有的NAL的单元头与分片后的FU-A的单元头有如下关系:

原始的NAL头的前三位为FU indicator的前三位,原始的NAL头的后五位为FU header的后五位,FU indicator与FU header的剩余位数根据实际情况决定。

解包:当接收端收到FU-A的分片数据,需要将所有的分片包组合还原成原始的NAl包时,FU-A的单元头与还原后的NAL的关系如下:

还原后的NAL头的八位是由FU indicator的前三位加FU header的后五位组成,即:

nal_unit_type = (fu_indicator & 0xe0) | (fu_header & 0x1f)


int rtp_packet_deserialize(struct rtp_packet_t *pkt, const void* data, int bytes)
{
  uint32_t i, v;
  int hdrlen;
  const uint8_t *ptr;

  if (bytes < RTP_FIXED_HEADER) // RFC3550 5.1 RTP Fixed Header Fields(p12)
    return -1;
  ptr = (const unsigned char *)data;
  memset(pkt, 0, sizeof(struct rtp_packet_t));

  // pkt header
  v = nbo_r32(ptr);
  pkt->rtp.v = RTP_V(v);
  pkt->rtp.p = RTP_P(v);
  pkt->rtp.x = RTP_X(v);
  pkt->rtp.cc = RTP_CC(v);
  pkt->rtp.m = RTP_M(v);
  pkt->rtp.pt = RTP_PT(v);
  pkt->rtp.seq = RTP_SEQ(v);
  pkt->rtp.timestamp = nbo_r32(ptr + 4);
  pkt->rtp.ssrc = nbo_r32(ptr + 8);
  assert(RTP_VERSION == pkt->rtp.v);

  hdrlen = RTP_FIXED_HEADER + pkt->rtp.cc * 4;
  if (RTP_VERSION != pkt->rtp.v || bytes < hdrlen + (pkt->rtp.x ? 4 : 0) + (pkt->rtp.p ? 1 : 0))
    return -1;

  // pkt contributing source
  for (i = 0; i < pkt->rtp.cc; i++)
  {
    pkt->csrc[i] = nbo_r32(ptr + 12 + i * 4);
  }

  assert(bytes >= hdrlen);
  pkt->payload = (uint8_t*)ptr + hdrlen;
  pkt->payloadlen = bytes - hdrlen;

  // pkt header extension
  if (1 == pkt->rtp.x)
  {
    const uint8_t *rtpext = ptr + hdrlen;
    assert(pkt->payloadlen >= 4);
    pkt->extension = rtpext + 4;
    pkt->reserved = nbo_r16(rtpext);
    pkt->extlen = nbo_r16(rtpext + 2) * 4;
    if (pkt->extlen + 4 > pkt->payloadlen)
    {
      assert(0);
      return -1;
    }
    else
    {
      pkt->payload = rtpext + pkt->extlen + 4;
      pkt->payloadlen -= pkt->extlen + 4;
    }
  }

  // padding
  if (1 == pkt->rtp.p)
  {
    uint8_t padding = ptr[bytes - 1];
    if (pkt->payloadlen < padding)
    {
      assert(0);
      return -1;
    }
    else
    {
      pkt->payloadlen -= padding;
    }
  }

  return 0;
}

static int rtp_h264_unpack_input(void* p, const void* packet, int bytes)
{
  int r;
  uint8_t nalt;
  struct rtp_packet_t pkt;
  struct rtp_decode_h264_t *unpacker;

  unpacker = (struct rtp_decode_h264_t *)p;
  if(!unpacker || 0 != rtp_packet_deserialize(&pkt, packet, bytes) || pkt.payloadlen < 1)
    return -EINVAL;
  
  if (-1 == unpacker->flags)
  {
    unpacker->flags = 0;
    unpacker->seq = (uint16_t)(pkt.rtp.seq - 1); // disable packet lost
  }

  if ((uint16_t)pkt.rtp.seq != (uint16_t)(unpacker->seq + 1))
  {
    unpacker->flags = RTP_PAYLOAD_FLAG_PACKET_LOST;
    unpacker->size = 0; // discard previous packets
  }
  unpacker->seq = (uint16_t)pkt.rtp.seq;

  nalt = ((unsigned char *)pkt.payload)[0];
  switch(nalt & 0x1F)
  {
  case 0: // reserved
  case 31: // reserved
    assert(0);
    return 0; // packet discard

  case 24: // STAP-A
    return rtp_h264_unpack_stap(unpacker, (const uint8_t*)pkt.payload, pkt.payloadlen, pkt.rtp.timestamp, 0);
  case 25: // STAP-B
    return rtp_h264_unpack_stap(unpacker, (const uint8_t*)pkt.payload, pkt.payloadlen, pkt.rtp.timestamp, 1);
  case 26: // MTAP16
    return rtp_h264_unpack_mtap(unpacker, (const uint8_t*)pkt.payload, pkt.payloadlen, pkt.rtp.timestamp, 2);
  case 27: // MTAP24
    return rtp_h264_unpack_mtap(unpacker, (const uint8_t*)pkt.payload, pkt.payloadlen, pkt.rtp.timestamp, 3);
  case 28: // FU-A (编码 uint8_t fu_indicator = (pkt.payload & 0xE0) | 28; // FU-A)
    return rtp_h264_unpack_fu(unpacker, (const uint8_t*)pkt.payload, pkt.payloadlen, pkt.rtp.timestamp, 0);
  case 29: // FU-B
    return rtp_h264_unpack_fu(unpacker, (const uint8_t*)pkt.payload, pkt.payloadlen, pkt.rtp.timestamp, 1);

  default: // 1-23 NAL unit
    r = unpacker->handler.packet(unpacker->cbparam, (const uint8_t*)pkt.payload, pkt.payloadlen, pkt.rtp.timestamp, unpacker->flags);
    unpacker->flags = 0;
    unpacker->size = 0;
    return 0 == r ? 1 : r; // packet handled
  }
}

后续分享RTP的排序与AV1的编码。

作者:aliveyun

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

  • RTP技术概念中的转换器和混音器

    RTP处理的中间节点,除了普通的终端系统外,RTP还支持可以在会话中对媒体流进行操作的中间设备。RTP定义了两类中间设备:转换器和混音器。 转换器是一种中间设备系统,它在操作RTP…

    2024年4月5日
  • 音视频问答–RTP时间戳的作用

    背景介绍 在知乎上收到这样一个问题邀请: RTP传输中时间戳字段在任何情况下都是必要的吗? 刚开始学习RTP协议,以传输视频为例,播放端可以根据时间戳,将每一帧在适当的时间点播放出…

    2023年12月3日
  • 实现一个h264编码器前期准备

    前言: H264是新一代的编码标准,以高压缩高质量和支持多种网络的流媒体传输著称,在编码方面,我理解的他的理论依据是:参照一段时间内图像的统计结果表明,在相邻几幅图像画面中,一般有…

    2023年10月22日
  • 音视频编解码–H264 帧内预测

    帧内预测 最近看书学习过程中做了一些笔记,分别和大家一起分享一下,今天首先分享的是H264的帧内预测。 H.264/AVC 标准中规定的 4×4 亮度块的帧内预测样本预测…

    2023年10月11日
  • x264 如何提升 1‰ 的转码性能

    在8K视频编解码特别是解码部分,我做了一些优化工作,转码速度提升了50%以上。专家们评价曰:“主要围绕算法并行度的优化,属于算法性能优化的常规手段,在创新性和技术难度方面的体现较为…

    2024年3月22日
  • H264视频解码算法概述

    为什么要有视频编码 视频其实是连续的图片,一般30帧每秒,以1分钟的1080p视频举例。 每个像素点的大小比如说是1.5字节(YUV420格式),一张图片的大小是: 1080*72…

    2024年3月15日

发表回复

登录后才能评论