RTP负载类型及时间戳介绍

    在网络上看到一篇很好的文章,就转载过来了,以便自己以后能够用得上.

      在oRTP库中，提供了设置RTP负载类型的函数，请注意一定要记得根据实际的应用进行设置，我们先来看看RTP协议包头的格式:

前12个字节在每一个RTP packet中都存在，而一系列的CSRC标记只有存在Mixer时才有

   version (V): 2 bits
      标明RTP版本号。协议初始版本为0，RFC3550中规定的版本号为2。

   padding (P): 1 bit
      如果该位被设置，则在该packet末尾包含了额外的附加信息，附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因 为一些加密机制需要固定长度的数据块，或者为了在一个底层协议数据单元中传输多个RTP packets。

   extension (X): 1 bit
      如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。

   CSRC count (CC): 4 bits
      在固定头部后存在多少个CSRC标记。

   marker (M): 1 bit
      该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。

   payload type (PT): 7 bits
      标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。

   sequence number: 16 bits
      序列号，每个RTP packet发送后该序列号加1，接收方可以根据该序列号重新排列数据包顺序。

   timestamp: 32 bits
      时间戳。反映RTP packet所携带信息包中第一个字节的采样时间。

   SSRC: 32 bits
      标识数据源。在一个RTP Session其间每个数据流都应该有一个不同的SSRC。

   CSRC list: 0 to 15 items, 32 bits each

       标识贡献的数据源。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。

        10~16 Bit为PT域，指的就是负载类型（PayLoad），负载类型定义了RTP负载的格式，协议原文说该域由具体应用决定其解释。
        目前，负载类型主要用来告诉接收端（或者播放器）传输的是哪种类型的媒体（例如G.729，H.264，MPEG-4等），这样接收端（或者播放器）才知 道了数据流的格式，才会调用适当的编解码器去解码或者播放，这就是负载类型的主要作用。
        就oRTP库而言，负载类型定义如下：

每一种 负载类型都有着其独特的参数，这里基本上涵盖了当前主流的一些媒体类型，例如pcmu 、g.729、h.263（很奇怪，竟然没有定义h.264）、mpeg-4等等。Jrtplib库应该也有相类似的定义，你可以去找找源码，在此我就不 再赘述了。

    首先，了解几个基本概念：
    时间戳单位：时间戳计算的单位不是秒之类的单位，而是由采样频率所代替的单位，这样做的目的就是 为了是时间戳单位更为精准。比如说一个音频的采样频率为8000Hz，那么我们可以把时间戳单位设为1 / 8000。
    时间戳增量：相邻两个RTP包之间的时间差（以时间 戳单位为基准）。
    采样频率：  每秒钟抽取样本的次数，例如音频的采样率一般为8000Hz
    帧率：      每秒传输或者显示帧数，例如25f/s   

    再看看RTP时间戳课本中的定义：
    RTP包头的第2个32Bit即为RTP包的时间戳，Time Stamp ，占32位。
    时间戳反映了RTP分组中的数据的第一个字节的采样时刻。在一次会话开始时的时间戳初值也是随机选择的。即使是没有信号发送时，时间戳的数值也要随时间不 断的增加。接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块，从而消除传输中的抖动。时间戳还可用来使视频应用中声音和图像同步。
    在RTP协议中并没有规定时间戳的粒度，这取决于有效载荷的类型。因此RTP的时间戳又称为媒体时间戳，以强调这种时间戳的粒度取决于信号的类型。例如， 对于8kHz采样的话音信号，若每隔20ms构成一个数据块，则一个数据块中包含有160个样本（0.02×8000=160）。因此每发送一个RTP分 组，其时间戳的值就增加160。

    官方的解释看懂没？没看懂？没关系，我刚开始也没看懂，那就听我的解释吧。

    首先，时间戳就是一个值，用来反映某个数据块的产生（采集）时间点的， 后采集的数据块的时间戳肯定是大于先采集的数据块的。有了这样一个时间戳，就可以标记数据块的先后顺序。
    第二，在实时流传输中，数据采集后立刻传递到RTP 模块进行发送，那么，其实，数据块的采集时间戳就直接作为RTP包的时间戳。
    第三，如果用RTP来传输固定的文件，则这个时间戳 就是读文件的时间点，依次递增。这个不再我们当前的讨论范围内，暂时不考虑。
    第四，时间戳的单位采用的是采样频率的倒数，例如采 样频率为8000Hz时，时间戳的单位为1 / 8000 ，在Jrtplib库中，有设置时间戳单位的函数接口，而ORTP库中根据负载类型直接给定了时间戳的单位（音频负载1/8000，视频负载1 /90000）
    第五，时间戳增量是指两个RTP包之间的时间间隔， 详细点说，就是发送第二个RTP包相距发送第一个RTP包时的时间间隔（单位是时间戳单位）。
    如果采样频率为90000Hz，则由上面讨论可知，时间戳单位为1/90000，我们就假设1s钟被划分了90000个时间块，那么，如果每秒发送25 帧，那么，每一个帧的发送占多少个时间块呢？当然是 90000/25 = 3600。因此，我们根据定义“时间戳增量是发送第二个RTP包相距发送第一个RTP包时的时间间隔”，故时间戳增量应该为3600。
    在oRTP中每次数据的发送都需要自己传入时间戳的值，即自己需要每次发完一个RTP包后，累加时间戳增量，不是很方便，这就需要自己对RTP的时间戳有比较深刻地理解，我刚开始就是因为没搞清楚，随时设置时间戳增量导致传输一直有问题。

多媒体通信同步方法，主要有时间戳同步法、同步标记法、多路复用同步法三种。下面主要讨论时间戳同步法，特别是RTP时间戳同步。内容包括RTP媒 体间同步的实现，为什么需要RTCP的NTP时间来实现媒体间同步？没有RTCP，能实现RTP媒体间的同步吗？根据RTP规范，不同的RTP媒体流是分开传输的，且使用各自独立的时间戳进行同步。假设在一次视频点播中，传输两路RTP媒体流，一路视频，一 路音频。根据视频帧时间戳，可以实现视频流内同步，这很好理解，通过视频帧时间戳可以计算出相邻视频帧的时间间隔，也就是视频帧之间的相对时间关系很容易 通过时间戳来确定，按照这个间隔去呈现视频，就可以获得较好的效果。同理，音频流也可以实现自身的同步。