xSky 实验室关注高性能计算,分布式系统/存储,大数据/机器学习/WebRTC
目录
  • 首页
  • 技术相关
  • 原创作品
  • 人工智能/机器学习
  • 系统与架构
  • 数据库/数据分析
  • 分布式系统/存储
  • 服务端开发
  • WEBRTC研究
  • 开发调试
  • 网络与安全
  • 常用工具
  • 杂七杂八

关于RTP中的时间戳问题

2021-05-25 02:01:04
 
在使用JRTPLIB的发送数据的时候需要设置时间戳单位(timestamp)和时间戳增量(timestamp increment)。
看了网上一些文章,细细想来现在才想通这个问题。   


RFC3550对时间戳的描述是:

        时间戳(timestamp) 32比特 时间戳反映了RTP数据包中第一个字节的采样时间。(采样时钟必须来源于一个及时的单调、线性递增时钟,以便允许同步和去除网络引起的数据包抖动(见章节6.4.1)。该时钟的分辨率必须满足理想的同步精度和测量数据包到来时的抖动的需要(一种典型的时钟分辨率不满足情况是每个视频帧仅一个时钟周期)时钟频率依赖于负载数据的格式,并在描述文件(profile)中或者是在负载格式描述中(payload format speci_cation)进行静态描述。也可以通过非RTP方法(non-RTP means)对负载格式动态描述。

       如果RTP包是周期性产生的,那么将使用由采样时钟决定的名义上的采样时刻,而不是读取系统时间。例如,对一个固定速率的音频,采样时钟(时间戳时钟)将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块,那么对每个块,时间戳的值增加160,而不考虑该块是否用一个包传递或是被丢弃。

        时间戳的初始值应当是随机的,就像序号一样。几个连续的RTP包如果(逻辑上)是同时产生的,如:属于同一个视频帧的RTP包,将有相同的序列号。如果数据并不是以它采样的顺序进行传输,那么连续的RTP包可以包含不是单调递增(或递减)的时间戳(RTP包的序列号仍然是单调变化的)。

根据一些文章我自己推敲了一下几个概念如下:   
       时间戳单位:时间戳计算的单位不为秒之类的单位,而是由采样频率所代替的单位,这样做的目的就是为了是时间戳单位更为精准。比如说一个音频的采样频率为8000HZ,那么我们可以把时间戳单位设为1/8000。
       时间戳增量:相邻两个RTP包之间的时间差(以时间戳单位为基准)。
 
       如何设定时间戳之间的增量呢?
       按照刚才时间戳单位来看,1秒钟按照时间戳单位就是8000,那么一秒钟如果可以播放20帧,也就是发送30帧(帧率),那么可以求出相邻两帧之间的时间差,也就是时间戳增量,那么显而易见是用8000/20,那么这个时间戳增量就为400.
       网上大多数列举的一个例子是:   例如MPEG,每帧20ms,采样频率8000Hz,设定时间戳单位1/8000,而每个包之间就是160的增量
    这里又该如何理解呢?可以轻易地看出增量是直接8000与20ms相乘的结果,我们可以知道这里两帧之间的时间为20ms,也就是0.02s,这个单位是以秒来衡量的,那么我们要用时间戳单位来表示那么就是8000*0.02=160.所以时间戳增量为160.

        还有一点为什么一般都用90000作为视频采样频率呢?
        90k是用于视频同步的时间尺度(TimeScale),就是每秒90k个时钟tick。为什么采用90k呢?目前视频的帧速率主要有25fps、29.97fps、30fps等,而90k刚好是它们的倍数,所以就采用了90k。
 

时间戳与同步


      时间戳段是RTP报文头中说明数据包时间的同步信息,是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant),要求发送方时间戳的时钟是连续、单调增长的,即使在没有数据输入或发送数据时也是如此。在静默时,发送方不必发送数据,保持时间戳的增长,在接收端,由于接收到的数据分组的序号没有丢失,就知道没有发生数据丢失,而且只要比较前后分组的时间戳的差异,就可以确定输出的时间间隔。
        RTP规定一次会话的初始时间戳必须随机选择,但协议没有规定时间戳的单位,也没有规定该值的精确解释,而是由负载类型来确定时钟的颗粒,这样各种应用类型可以根据需要选择合适的输出计时精度。
        在RTP传输音频数据时,一般选定逻辑时间戳速率与采样速率相同,但是在传输视频数据时,必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的,协议标准还允许多个分组具有相同的时间戳值。
        RTCP的一个关键作用就是能让接收方同步多个RTP流,例如:当音频与视频一起传输的时候,由于编码的不同,RTP使用两个流分别进行传输,这样两个流的时间戳以不同的速率运行,接收方必须同步两个流,以保证声音与影像的一致。为能进行流同步,RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name),尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC),但具有相同的规范名,这样接收方就知道哪些流是有关联的。

1、SSRC的作用

        SSRC相当于一个RTP传输session的ID,就象每个人都有一个名字一样,每一个RTP传输也都有一个名字。这个数字是随机产生,并且要保证唯一。当RTP session改变(如IP等)时,这个ID也要改变。

2、序列号字段是否可以作为流内的同步标时

          我在上面已经说过,序列号只表示了包发出的先后顺序,它表示不了任何时间上的其它概念,所有严格的说,序列号并不能作为流内的同步标志。但是,由于一般来说,包的发送时间都会有严格限制,比如音频包是每秒种发送30个数据包,也就是说,每个包间隔1000/30MS,而这个时间就可以作为一个同步时间来播放。也就是说,按照序列号,每1000/30MS间隔播放一个数据包,这样也能保证同步,但是这时候请考虑丢包问题。

3、绝对时间戳和相对时间戳在进行同步处理时有什么不同

   当我们取得绝对时间后,我们就可以根据这个绝对时间来播放这些数据包。这个绝对时间,加上我们需要的延时(用于数据传输,解码等等的时间)就是我们的播放时间,这样我们可以保证时间的严格同步(相当于把对方的动作延时一段时间后原原本本的再现出来)。目前,在RTP中,能得到这个绝对时间的办法只有RTCP。
          对于相对时间戳,我们更关心的是两个时间戳之间的时间间隔,依靠这个时间间隔,来确定两个包的播放时间间隔。

4、单个媒体内的同步和不同媒体流之间的同步在处理方式上有什么不同
        应该说,不同媒体之间同步比单媒体同步要复杂得多,除了要保证本身的播放要和时间同步外,还要保证两个或多个媒体间同步(比如音视频的同步)。这种不同更关心的两个时间戳时间的换算统一,前面我已经说过,不同编码有不同的采样频率,那么时间戳的增长速度就不同。另外,两个时间戳也需要有一个标准时间来表示时间戳的同步。最简单的方法是两个媒体的第一个时间戳相同,表示两个流的采集开始时间统一。另外还可以通过RTCP来做不同流之间的同步,这在下个问题中会提到。

5、时间戳字段如何用于作为流间同步标识

          在RTP协议中,我们取得时间戳的方法有两个:一个是RTP包中的时间戳,另外一个是RTCP包中的绝对时间戳和相对时间戳。绝对时间戳的概念上面我已经说了,它可以表示系统的绝对时间。而RTCP包中的相对时间就是RTP包中的时间。根据这两个时间,不同流都可以纠正自己播放时间和真正时间的偏差以达到和绝对时间同步的目的。

举例说明一下:

G711编码,有两种G711A/G711U,主要在安防中应用,是一帧波形编码的音频数据,只是将PCM压缩一半数据量。一般G711,采样率8000,通道数1。所以G711中1B就是一个样本数据。G711打包RTP非常简单,只要在G711数据前加上RTP头即可。G711没有想AAC那样,按照帧一帧一帧发送,而是设定一个打包频率,打包频率有10ms,20ms,30ms,40ms 等。如40ms的打包频率,1S打包25帧,1S需要发送8000个样本,所以一帧需要8000/25=320个样本,RTP时间戳增量绝对值是320/8000S,协议要求以采样率作为时钟频率,所以RTP时间戳为 (320/8000)*8000。

 

By:xSky | WEBRTC研究 |

  • 分类目录

    • 技术相关 (35)
    • 原创作品 (13)
    • 人工智能/机器学习 (6)
    • 系统与架构 (9)
    • 数据库/数据分析 (11)
    • 分布式系统/存储 (4)
    • 服务端开发 (7)
    • WEBRTC研究 (7)
    • 开发调试 (7)
    • 网络与安全 (9)
    • 常用工具 (9)
    • 杂七杂八 (6)
  • 最新文章

    • 嵌入式分析型数据库(DuckDB)
    • WSL从C盘迁移到其他盘区
    • 赵何娟:中国AI追随之路的五大误区,我们至少落后十年
    • zap  发送日志到 websocket
    • QUIC(隐藏的)超能力
    • MYSQL 生成日期/时间序列总结
    • Linux bash终端设置代理(proxy)访问
    • centos 下 yum安装python3
    • 使用SQL查询Milvus 向量数据库
    • 浅谈 MySQL 新的身份验证插件 caching_sha2_password
    • Milvus v2.2.1 开源向量搜索引擎使用教程
    • 部署了一个SRS的demo
    • Dockerfile 详解
    • Docker常用命令
    • Tus文件上传协议
    • 编译运行Milvus
    • MinIO 快速入门
    • ESP32
    • Prometheus监控报警系统搭建
    • go语言JSON字典模拟
    • go语言的sql解析器
    • Grafana配置数据源,自定义查询语法
    • TDengine + Telegraf + Grafana
    • gRPC-Gateway 返回JSON数据int64类型被转为string类型问题
    • LLAMA模型试玩
    • 语音识别的一些开源项目整理
    • 使用MYSQL8进行统计分析
    • 记录FFmpeg抽帧、合流、转码、加水印等操作
    • 移动网络弱网处理研究
    • 翻译:使用 Semgrep 进行热点代码评审
  • 链接

    • xSky的Blog
    • 我的Github
    • 实时监控图表
    • 预印本
    • xRedis 在线文档
    • xSkyProxy
    • xChart 数据在线测试
    • 我的电子书
    • xChart 数据可视化系统
    • 树莓派技术圈
    • WebRTC开发者社区
  • 开源项目

    • xReis C++的redis客户端库
    • xBlog-C++ 博客程序
    • xSkyProxy-新型MySQL代理网关
    • 数据可视化平台- xChart
    • xhttpcache 高速数据缓存服务
    • xMonitor-图形监测工具
    • 网址收集

Powered By xBlog

Copyright 2010~2024 0xsky.com All Rights Reserved.