转自:http://www.360doc.com/content/11/1018/13/1016783_157133781.shtml

首 先,看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库应该也有相类似的定义,你可以去找找源码,在此我就不 再赘述了。

在ORTP库和JRTplib库中,都提供了设置RTP负载类型的函数,千万要记得根据实际的应用进行设置,我就是当时没有注意,使用ORTP默认的 pcmu音频的负载类型,传输H.264编码的视频数据,结果传输中一直有问题,困扰我好久好久。

好了,再说说RTP 的时间戳吧。

首先,了解几个基本概念:

时间戳单位:时间戳计算的单位不是秒之类的单位,而是由采样频率所代替的单位,这样做的目的就是 为了是时间戳单位更为精准。比如说一个音频的采样频率为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。
    在Jrtplib中好像不需要自己管理时间戳的递增,由库内部管理。但在ORTP中每次数据的发送都需要自己传入时间戳的值,即自己 需要每次发完一个RTP包后,累加时间戳增量,不是很方便,这就需要自己对RTP的时间戳有比较深刻地理解,我刚开始就是因为没搞清楚,随时设置时间戳增 量导致传输一直有问题,困扰我好久。

RTCP的bit图:(http://www.cnblogs.com/Jimmly/archive/2009/08/03/1537468.html)
 //        0                   1                   2                   3
 //        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //byte=0 |V=2|P|    RC   |   PT=SR=200   |             length            |
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //     4 |                         SSRC of sender                        |
 //       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 //     8 |              NTP timestamp, most significant word             |
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //    12 |             NTP timestamp, least significant word             |
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //    16 |                         RTP timestamp                         |
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //    20 |                     sender's packet count                     |
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //    24 |                      sender's octet count                     |
 //       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 //    28 |V=2|P|    SC   |  PT=SDES=202  |             length            |
 //       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 //    32 |                          SSRC/CSRC_1                          |
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //    36 |    CNAME=1    |     length    | user and domain name        ...
 //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

多媒体通信同步方法,主要有时间戳同步法、同步标记法、多路复用同步法三种。下面主要讨论时间戳同步法,特别是RTP时间戳同步。内容包括RTP媒 体间同步的实现,为什么需要RTCP的NTP时间来实现媒体间同步?没有RTCP,能实现RTP媒体间的同步吗?DirectShow时间戳和RTP时间 戳的区别,MPEG2-TS流的时间戳等。本文只简单讨论时间戳同步的原理,不涉及具体的实现方法,如音频帧和视频帧时间戳的计算方法,怎样根据时间戳去 做音视频的呈现等。

根据RTP规范,不同的RTP媒体流是分开传输的,且使用各自独立的时间戳进行同步。假设在一次视频点播中,传输两路RTP媒体流,一路视频,一 路音频。根据视频帧时间戳,可以实现视频流内同步,这很好理解,通过视频帧时间戳可以计算出相邻视频帧的时间间隔,也就是视频帧之间的相对时间关系很容易 通过时间戳来确定,按照这个间隔去呈现视频,就可以获得较好的效果。同理,音频流也可以实现自身的同步。

那么音频和视频这两路媒体间如何实现同步呢?我们只使用音视频的RTP时间戳,看能否实现媒体间的同步。音视频的RTP时间戳的增长速率一般是不同的,但没关系,知道了具体的单位后,两者是可以通过单位换算联系起来的。如下图:

现在来看,这种方法好像可以实现同步,因为音视频被映射到同一个时间轴上了,音频和视频帧间的相对关系很清楚。慢着,RTP规范要求时间戳的初 始值应该是一个随机值,那么假设音频帧时间戳的初始值是随机值1234,视频帧时间戳的初始值是随机值5678,看起来应该是下面这样:
这么做合适吗?我们把音频帧时间戳1234和视频帧时间戳5678对应到绝对时间轴的0上,我们这么做的理由是什么?你可能会说,因为那是第一 个音频帧和第一个视频帧,所以可以对应到同一个点上,在第一幅图中我们就是这么做的,把音频帧时间戳0和视频帧时间戳0对应到绝对时间轴的0上。但是 RTP规范并没有规定第一个视频帧的时间戳和第一个音频帧的时间戳必须或者应该对应到绝对时间轴的同一个点上,从整个RTP规范中不能直接得出这样的结 论,也推导不出这样的结论。 

我们上面两幅图所做的转换是不正确的,为什么呢?因为在做转换时,隐含了一个假设,我们想当然地认为这个假设是成立的,实际上它并不总是成立。这个假设就是第一个视频帧和第一个音频帧的时间戳应该对应到同一个点上,即无论它们时间戳是多少,都应该在同一时间播放。

仅仅使用RTP时间戳是无法实现媒体间同步的,根本的原因是音频时间轴和视频时间轴是完全独立的,通过音频帧和视频帧的时间戳,无法确定一个视频帧和一个音频帧的相对时间关系,也就是无法把它们都准确定位在绝对时间轴上,只能准确定位一个。

要实现RTP媒体间同步,需要借助于RTCP,在RTCP的SR包中,包含有<NTP时间,RTP时间戳>对,音频帧RTP时间戳和视 频帧RTP时间戳通过<NTP时间,RTP时间戳>对,都可以准确定位到绝对时间轴NTP上,音频帧和视频帧的相对时间关系就可以确定下来 了。

上面提到,我们的那个隐含的假设并不总是成立,那就是说它有成立的时候。那是不是说当它成立时,我们就可以不用RTCP来做媒体间同步了?答案是,基本上可以这么认为。

例如,对于RTP实时流,在发送端媒体间就同步的很好,在接收端只需做少许处理,不需要RTCP,就可以实现媒体间同步。当然,这只是少数例外。因为RTP规范并不包括这个假设,所以我们还是按照RTP规范来做吧。

下面说一下DirectShow和MPEG2-TS的时间戳。DirectShow中的时间戳和RTP中的时间戳,除了单位不一样,计算方法不一样 外,本质的区别就是DirectShow中的音频帧和视频帧时间戳使用的是同一个时间轴,所以不需要借助其他的东西,仅仅使用音频帧时间戳和视频帧时间戳 就可以实现媒体间同步。MPEG2-TS流中也有时间戳,它的时间戳和RTP及DirectShow的时间戳都不同,TS流中的音频帧和视频帧时间戳使用 的也是同一个时间轴,TS流中的音频和视频是复用的,这在一定程度上就起到了同步的作用,所以它并不是在每个帧上都打时间戳,比如它的PTS时间戳就是每 隔0.1秒一个,缺失的时间戳是通过其他时间戳插值计算出来的。

关于RTP负载类型及时间戳介绍的更多相关文章

  1. (转)谈谈RTP传输中的负载类型和时间戳

    原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://ticktick.blog.51cto.com/823160/350142 最近被 ...

  2. 【FFMPEG】谈谈RTP传输中的负载类型和时间戳

    谈谈RTP传输中的负载类型和时间戳 最近被RTP的负载类型和时间戳搞郁闷了,一个问题调试了近一周,终于圆满解决,回头看看,发现其实主要原因还是自己没有真正地搞清楚RTP协议中负载类型和时间戳的含义.虽 ...

  3. 多媒体开之之rtp 时间戳和负载类型介绍

    (1)时间戳 (2)负载类型 (3)rtp 包头 (1)时间戳 有三个 一个实时间单位 timestamp_increse=(unsigned int)(90000.0 / framerate); / ...

  4. H264的RTP负载打包的数据包格式,分组,分片

    H264的RTP负载打包的数据包格式,分组,分片 1.    RTP数据包格式 RTP报文头格式(见RFC3550 Page12): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ...

  5. H.264 RTPpayload 格式------ H.264 视频 RTP 负载格式

    H.264 RTPpayload 格式------ H.264 视频 RTP 负载格式 1. 网络抽象层单元类型 (NALU) NALU 头由一个字节组成, 它的语法如下: +------------ ...

  6. H.264 RTPpayload 格式------ H.264 视频 RTP 负载格式(包含AAC部分解析)

    H.264 RTPpayload 格式------ H.264 视频 RTP 负载格式 1. 网络抽象层单元类型 (NALU) NALU 头由一个字节组成, 它的语法如下: +------------ ...

  7. Oracle 日期类型timestamp(时间戳)和date类型使用

    body { font-family: "Microsoft YaHei UI","Microsoft YaHei",SimSun,"Segoe UI ...

  8. 【转】Java基础笔记 – 枚举类型的使用介绍和静态导入--不错

    原文网址:http://www.itzhai.com/java-based-notes-introduction-and-use-of-an-enumeration-type-static-impor ...

  9. Mysql中字段类型之时间戳大坑2

      本文的内容依旧是讨论mysql字段类型为时间戳timestamp的问题,在遇到了之前的那个问题之后,今天测试人员又给我提了一个bug,是在前端页面提交会议表单的时候,选择了一个会议时间(2059年 ...

随机推荐

  1. Git SourceTree 冲突解决方案

    Git现在越来越火,很多人都从Svn迁移到Git上面,Git让我们更加与世界接轨,不再是"局域网"的程序猿,特别是掌握了Git之后,会发现它真的很好用,本文对Git中比较烦人的冲突 ...

  2. java前后台之间传值的几种方式

    自己写的代码太少,有时候前后台传值还写的不是很熟练,现在总结一下,加深下印象. 1.jquery的Ajax传值 ---->前台到后台 期望功能:把前台用户输入的信息保存在数据库里. 前台jsp代 ...

  3. struts2 提供的校验器列表

  4. 【转载】通过JDBC对MySQL数据库的增删改查

    通过JDBC进行简单的增删改查(以MySQL为例) 目录 前言:什么是JDBC 一.准备工作(一):MySQL安装配置和基础学习 二.准备工作(二):下载数据库对应的jar包并导入 三.JDBC基本操 ...

  5. sql server 2008 不允许保存更改,您所做的更改要求删除并重新创建以下表 的解决办法

    启动SQL Server 2008 Management Studio 工具菜单----选项----Designers(设计器)----阻止保存要求重新创建表的更改  取消勾选即可.

  6. php curl get post

    post有3种. 1.post方式 privatefunction send_post($url,$post_data){ $ch = curl_init($url); curl_setopt($ch ...

  7. Redis事件管理(二)

    Redis的定时器是自己实现的,不是很复杂.说说具体的实现吧. 定时器的存储维护采用的是普通的单向链表结构,具体节点定义为: /*时间定时器结构体*/ typedef struct aeTimeEve ...

  8. stm32——NFC芯片--PN532的使用

    stm32——NFC芯片--PN532的使用 一.NFC简介 NFC(Near Field Communication)近场通信,是一种短距高频的无线电技术,在13.56MHz频率运行于20厘米距离内 ...

  9. 字符匹配算法之KMP

    KMP算法的精华在于从前往后,逐步循环地向前滑动搜索词,来最大限度地减少重复匹配次数,以达到提高效率的目的. 移动位数=已匹配字符数-最后一个匹配字符所对应搜索词的位置[从1开始]. 更加详细且具体的 ...

  10. Java使用JDBC连接MySQL数据库

    1.引用 JDBC(Java Data Base Connectivity,java数据库连接)是一种用于执行SQL语句的Java API,可以为多种关系数据库提供统一访问,它由一组用Java语言编写 ...