• RTP 时间戳的处理


    原文:http://general.blog.51cto.com/927298/328220

    RTP 时间戳的处理
      时间戳字段是RTP首部中说明数据包时间的同步信息,是数据能以正 确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling  Instant),要求发送方时间戳的时钟是连续、单调增长的,即使在没有数据输入或发送数据时也 是如此。在静默时,发送方不必发送数据,保持时间戳的增长,在接收端,由于接收到的数据分组的序号没有丢失,就知道没有发生数 据丢失,而且只要比较前后分组的时间戳的差异,就可以确定输出的时间间隔。
      RTP规定一次会话的初始时间戳必须随机选择,但协议没有规定时 间戳的单位,也没有规定该值的精确解释,而是由负载类型来确定时钟的颗粒,这样各种应用类型可以根据需要选择合适的输出计时精度。
      在RTP传输音频数据时,一般选定逻辑时间戳速率与采样速率相同, 但是在传输视频数据时,必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的,协议标准还允许多个分组具有相同的时 间戳值。
      RTP协议没有规定RTP分组的长度和发送数据的速度,因而需要根据具体情况调整服务器端发送 媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区,在有新数据输入时发送数据的方式,时间戳的设置相对 容易。对已经录制好的本地硬盘上的媒体文件,以H.263格式的文件为例,由于文件本身不包含帧率信息,所以需要知道录制时的帧率或者设置一个初始值,在 发送数据的时候找出发送数据中的帧数目,根据帧率和预置值来计算时延,以适当的速度发送数据并设置时间戳信息。
      RTCP的一个关键作用就是能让接收方同步多个RTP流,例如:当音频与视频一起传输的时候, 由于编码的不同,RTP使用两个流分别进行传输,这样两个流的时间戳以不同的速率运行,接收方必须同步两个流,以保证声音与影 像的一致。为能进行流同步,RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical  Name),尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC),但具有相同的规范 名,这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含 有一个以网络时间协议NTP(Network  Time  Protocol)格式表示的绝对时间值,接着RTCP报告中给出一个RTP时间戳值,产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟,接收方就可以比较来自同一数据 源的两个流的绝对时间,从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。
    主要是:
    1)根据负载类型,如何确定时间 戳的颗粒?
    1、epoch -时间戳开始计时的起点
    2、diff -时间差,指的是相邻这个包和上个包的负载的第一个采样
    3、timestamp  freqrency: audio=8000, video=90000

    diff=cur time-epoch
    timestamp=diff*frequency
    例如MPEG,每帧20ms,采样频率8000Hz,设定时间戳单位1/8000,而每个包之间就是160的增量。
    2)绝对时间NTP
    两个包的NTP的时间差和RTP时间差的比较来推算jitter(抖动),计时单位要统一
  • 相关阅读:
    【译】用 Chart.js 做漂亮的响应式表单
    【译】快速高效学习Java编程在线资源Top 20
    【译】理解Spring MVC Model Attribute 和 Session Attribute
    Github 恶搞教程(一起『玩坏』自己的 Github 吧)
    Effective Java 读书笔记(一):使用静态工厂方法代替构造器
    JavaScript 中 onload 事件绑定多个方法的优化建议
    【译】常见 Java 异常解释(恶搞版)
    Java 重写 equals 与 hashCode 的注意事项
    【译】Java语言速览:StackOverflow
    【译】StackOverflow——Java 中的 finally 代码块是否总会被执行?
  • 原文地址:https://www.cnblogs.com/whisht/p/3085090.html
Copyright © 2020-2023  润新知