WebRTC 之音视频同步

在网络视频会议中, 我们常会遇到音视频不同步的问题, 我们有一个专有名词 lip-sync 唇同步来描述这类问题,当我们看到人的嘴唇动作与听到的声音对不上的时候,不同步的问题就出现了

而在线会议中, 听见清晰的声音是优先级最高的, 人耳对于声音的延迟是很敏感的

根据 T-REC-G.114-200305 中的描述

  • 大于~280ms 有些用户就会不满意
  • 大于~380ms 多数用户就会不满意
  • 大于~500ms 几乎所有用户就会不满意

我们就尽量使得声音的延迟在 280 ms 之内,这是解决 lip-sync 问题的前提, 声音不好的严重程序超过音视频不同步。

我们可以定义一个 sync_diff 值 来表示音频帧和视频帧之间的时间差

  • 正值表示音频领先于视频
  • 负值表示音频落后于视频

ITU 对此给出以下的阈值:

  • 不可感知 Undetectability (-100ms, +25ms)
  • 可感知 Detectability: (-125ms, +45ms)
  • 可接受 Acceptability: (–185ms, +90 ms)
  • 影响用户 Impact user experience (-∞, -185ms) ∪ (+90ms,∞)

(ITU-R BT.1359-1, Relative Timing of Sound and Vision for Broadcasting" 1998. Retrieved 30 May 2015)

当我们在播放一个视频帧及对应的音频帧的时候,要计算一下这个 sync_diff

sync_diff = audio_frame_time - video_frame_time

如果这个 sync_diff 大于 90ms, 也就是音频包到得过早,就会有音视频不同步的问题 - 声音听到了,嘴巴没跟上.

如果这个 sync_diff 小于 -185ms, 也就是视频包到得过早,就会有音视频不同步的问题 - 嘴巴在动,声音没跟上.

不同步的原因

lip sync 1

这个问题的原因主要在于音频的采集, 编码,传输, 解码, 播放与视频的采集,编码,传输,解码以及渲染一般是分开进行的,因为音频和视频采集自不同的设备,即它们的来源不同,在网络上传输也会有延迟,也由不同的设备进行播放,这样如果在接收方不采取措施进行时间同步,就会极有可能看到口型和听到的声音对不上的情况。

由此派生出 3 个小问题:

  1. 如何将来自同一个人或设备的多路 audio 及 video stream关联起来?
  2. 如何将 RTP 中的时间戳 timestamp 映射到发送方的音视频采集时间
  3. 如何调整音频或者视频帧的播放时间,让它们怎么之间相对同步?

解决方案

1. 如何将来自同一个人或设备的音视频流关联起来?

对于多媒体会话,每种类型的媒体(例如音频或视频)一般会在单独的 RTP 会话中发送,发送方会在 RTCP SDES 消息中指明
接收方通过 CNAME 项关联要同步的RTP流, 而这个 CNAME 包含在发送方所发送的 RTCP SDES 中

SDES 数据包包含常规包头,有效负载类型为 202,项目计数等于数据包中 SSRC/CSRC 块的数量,后跟零个或多个 SSRC/CSRC 块,其中包含有关特定 SSRC 或 CSRC,每个都与 32 位边界对齐。

0               1               2               30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|    SC   |  PT=SDES=202  |            length L           |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+|                          SSRC/CSRC_1                          |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                           SDES items                          ||                              ...                              |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+|                          SSRC/CSRC_2                          |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                           SDES items                          ||                              ...                              |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

CNAME 项在每个 SDES 数据包中都是必需的,而 SDES 数据包又是每个复合 RTCP 数据包中的必需部分。

与 SSRC 标识符一样,CNAME 必须与其他会话参与者的 CNAME 不同。 但 CNAME 不应随机选择 CNAME 标识符,而应允许个人或程序通过 CNAME 内容来定位其来源。

0               1               2               30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|    CNAME=1    |     length    | user and domain name         ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

例如 Alice 向外发送一路音频流,一路视频流, 这两路流会使用不同的 SSRC, 但是在其所发送的 RTCP SDES 消息会使用相同的 CNAME.

  • RTP SSRC 1 ~ CNAME 1
  • RTP SSRC 2 ~ CNAME 1

2. 同步的时间如何计算

来自同一个终端用户的音频和视频, 在编码发送的 RTP 包中有一个 timestamp, 这个时间戳表示媒体流的捕捉时间。
同时, 作为发送者也会发送 RTCP Sender Report, 其中包含发送的 RTP timestamp 和 NTP timestamp 的映射关系,这样我们在接收方就可以把 RTP 包里的

lip sync flow

对于每个 RTP 流,发送方定期发出 RTCP SR, 其中包含一对时间戳:

NTP 时间戳以及与该 RTP 流关联的相应 RTP 时间戳。

这对时间戳传达每个媒体流的 NTP 时间和 RTP 时间之间的关系。

先回顾一下 RTP packet 和 RTCP sender report

  • RTP 包结构
0                   1                   2                   30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X|  CC   |M|     PT      |       sequence number         |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                           timestamp                           |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|           synchronization source (SSRC) identifier            |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+|            contributing source (CSRC) identifiers             ||                             ....                              |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • RTCP Sender Report 结构
0                   1                   2                   30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P|    RC   |   PT=SR=200   |             length            |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                         SSRC of sender                        |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+sender |              NTP timestamp, most significant word             |info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|             NTP timestamp, least significant word             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                         RTP timestamp                         |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                     sender's packet count                     |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                      sender's octet count                     |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report |                 SSRC_1 (SSRC of first source)                 |block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1    | fraction lost |       cumulative number of packets lost       |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|           extended highest sequence number received           |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                      interarrival jitter                      |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                         last SR (LSR)                         |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                   delay since last SR (DLSR)                  |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report |                 SSRC_2 (SSRC of second source)                |block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2    :                               ...                             :+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+|                  profile-specific extensions                  |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

通过 NTP timestamp 和 RTP timestamp 之间的映射, 我们可以知道 audio 包的时间和 video 包的时间。

具体的计算可以参见 WebRTC 的 RtpToNtpEstimator 类, 它将收到的若干 SR 中的 NTP time 和 RTP timestamp 保存下来,然后 应用最小二乘法来估算后续 RTP timestamp 所对应的 NTP timestamp, 大致为用最近 N=20 个 RTCP SR 包的 ntp timestamp 和 rtp timestamp 的构造出线性关系 y = ax + b, 通过最小二乘法来计算收到的 RTP 包对应的 ntp timestamp.

// Converts an RTP timestamp to the NTP domain.
// The class needs to be trained with (at least 2) RTP/NTP timestamp pairs from
// RTCP sender reports before the convertion can be done.
class RtpToNtpEstimator {public://...enum UpdateResult { kInvalidMeasurement, kSameMeasurement, kNewMeasurement };// Updates measurements with RTP/NTP timestamp pair from a RTCP sender report.UpdateResult UpdateMeasurements(NtpTime ntp, uint32_t rtp_timestamp);// Converts an RTP timestamp to the NTP domain.// Returns invalid NtpTime (i.e. NtpTime(0)) on failure.NtpTime Estimate(uint32_t rtp_timestamp) const;// Returns estimated rtp_timestamp frequency, or 0 on failure.double EstimatedFrequencyKhz() const;private:// Estimated parameters from RTP and NTP timestamp pairs in `measurements_`.// Defines linear estimation: NtpTime (in units of 1s/2^32) =//   `Parameters::slope` * rtp_timestamp + `Parameters::offset`.struct Parameters {double slope;double offset;};// RTP and NTP timestamp pair from a RTCP SR report.struct RtcpMeasurement {NtpTime ntp_time;int64_t unwrapped_rtp_timestamp;};void UpdateParameters();int consecutive_invalid_samples_ = 0;std::list<RtcpMeasurement> measurements_;absl::optional<Parameters> params_;mutable RtpTimestampUnwrapper unwrapper_;
};

3. 调整播放和渲染时间

一般我们会以 audio 为主, video 向 audio 靠拢, 两者时间一致也就会达到 lip sync 音视频同步

  1. audio 包先来, video 包后来: audio 包放在 jitter buffer 时等一会儿, 但是这个时间是有限的, 音频的流畅是首先要保证的, 视频跟不上可以降低视频的码率
  2. video 包先来, audio 包后来: video 包要等 audio 包来, 这是为了让音视频同步要付出的代价

一般以音频为主流 master stream,视频为从流 slave stream。 一般方法是接收方维护音频流的缓冲区的管理,并通过将视频 RTP 时间戳转换为正确从属于音频流的时间戳来调整视频流的播放。

当带有RTP时间戳 RTPv的视频帧到达接收器时,接收器通过四个步骤将RTP时间戳 RTPv 映射到视频设备时间戳VTB( Video Time Base),如图所示。

  1. 使用 Video RTCP SR 中的 RTP/NTP 时间戳对建立的映射,将视频 RTP 时间戳 RTPv 映射到发送方 NTP 时间。

  2. 根据该 NTP 时间戳,使用 Audio RTCP SR 中的 RTP/NTP 时间戳对建立的映射,计算来自发送方的相应音频 RTPa 时间戳。
    此时,视频RTP时间戳被映射到音频RTP 包的相同时间基准。

  3. 根据该音频 RTP 时间戳,使用卡尔曼滤波的方法计算音频设备时间基准中的相应时间戳。 结果是音频设备时间基准 ATB(Audio Time Base) 中的时间戳。

  4. 根据 ATB,使用偏移量 AtoV 计算视频设备时基 VTB 中的相应时间戳。

接收方需要确保带有 RTP 时间戳 RTPv 的视频帧使用所计算出的发送方视频设备时间基准 VTB 播放。

AtoV = V_time - A_Time/(audio sample rate)

注:

  • AtoV: 音频相较视频的偏移量
  • ATB: Audio device Time Base 音频设备的时间基准
  • VTB: Video device Time Base 视频设备的时间基准

具体方法可以参见 https://www.ccexpert.us/video-conferencing/using-rtcp-for-media-synchronization.html)

WebRTC 的做法原理上差不多,实现略有不同,可以参见 WebRTC 的源代码 StreamSynchronization 类和 RtpStreamsSynchronizer 类

大致上它会计算出 video 的延迟

current_delay_ms = max(min_playout_delay_ms, jitter_delay_ms + decode_time _ms + render_delay_ms)

然后再计算视频相对于音频的延迟 relative_delay_ms,

  • 如果它大于0, 视频比音频慢,减小视频延迟(主要是调整 jitter buffer delay),或者是增大音频延迟, 取决于阈值 base_target_delay_ms
  • 如果它小于0, 音频比视频慢,减小音频延迟,或者是增大视频延迟, 取决于阈值base_target_delay_ms

base_target_delay_ms 的比较逻辑参见StreamSynchronization::ComputeDelays,

if (diff_ms > 0) {// The minimum video delay is longer than the current audio delay.// We need to decrease extra video delay, or add extra audio delay.if (video_delay_.extra_ms > base_target_delay_ms_) {// We have extra delay added to ViE. Reduce this delay before adding// extra delay to VoE.video_delay_.extra_ms -= diff_ms;audio_delay_.extra_ms = base_target_delay_ms_;} else {  // video_delay_.extra_ms > 0// We have no extra video delay to remove, increase the audio delay.audio_delay_.extra_ms += diff_ms;video_delay_.extra_ms = base_target_delay_ms_;}} else {  // if (diff_ms > 0)// The video delay is lower than the current audio delay.// We need to decrease extra audio delay, or add extra video delay.if (audio_delay_.extra_ms > base_target_delay_ms_) {// We have extra delay in VoiceEngine.// Start with decreasing the voice delay.// Note: diff_ms is negative; add the negative difference.audio_delay_.extra_ms += diff_ms;video_delay_.extra_ms = base_target_delay_ms_;} else {  // audio_delay_.extra_ms > base_target_delay_ms_// We have no extra delay in VoiceEngine, increase the video delay.// Note: diff_ms is negative; subtract the negative difference.video_delay_.extra_ms -= diff_ms;  // X - (-Y) = X + Y.audio_delay_.extra_ms = base_target_delay_ms_;}
}

更多细节在 WebRTC 的代码中

  • class StreamSynchronization
  • class RtpStreamsSynchronizer

通过StreamSynchronization::ComputeDelays计算出音频和视频的相对延迟,如果相对延迟很小( < 30ms), 则无需调整音视频的播放时间,如果相对延迟很大, 则以 80ms 的幅度进行逐步调整。 与传统的只调视频延迟,不调音频延迟, WebRTC 会两边都调点,使得音视频的时间彼此靠近,前提是音频的延迟是在上面提到的可接受范围之内。

参考资料

  • https://www.ciscopress.com/articles/article.asp?p=705533&seqNum=6
  • https://www.ccexpert.us/video-conferencing/using-rtcp-for-media-synchronization.html
  • https://testrtc.com/docs/how-do-you-find-lip-sync-issues-in-webrtc/
  • https://en.wikipedia.org/wiki/Audio-to-video_synchronization
  • https://www.simplehelp.net/2018/05/29/how-to-fix-out-of-sync-audio-video-in-an-mkv-mp4-or-avi/
    *RFC6051: Rapid Synchronisation of RTP Flows

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/53948.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

EditPlus连接Linux系统远程操作文件

EditPlus是一套功能强大的文本编辑器&#xff01; 1.File ->FTP->FTP Settings&#xff1b; 2.Add->Description->FTP server->Username->Password->Subdirectory->Advanced Options 注意&#xff1a;这里的Subdirectory设置的是以后上传文件的默认…

使用uni-app的uniCloud 云数据库入门:实现一个简单的增删改查

官方云数据库文档 前置步骤使用uni-app新建一个uniCloud项目 [外链图片转存失败,源站可能有防盗官方云数据库文档]!链机制,建议将()https://uniapp.dcloud.net.cn/uniCloud/hellodb.html)] 新建表 这里我加了几个测试字段 createTime、remark、money // 文档教程: https://un…

Qt 6. 其他类调用Ui中的控件

1. 把主类指针this传给其他类&#xff0c;tcpClientSocket new TcpClient(this); //ex2.cpp #include "ex2.h" #include "ui_ex2.h"Ex2::Ex2(QWidget *parent): QDialog(parent), ui(new Ui::Ex2) {ui->setupUi(this);tcpClientSocket new TcpClient…

Docker 容器化学习

文章目录 前言Docker架构 1、 docker安装2、启动docker服务3、设置docker随机器一起启动4、docker体验5、docker常规命令5.1、容器操作docker [run|start|stop|restart|kill|rm|pause|unpause]docker [ps|inspect|exec|logs|export|import] 5.2、镜像操作docker images|rmi|tag…

zookeeper --- 高级篇

一、zookeeper 事件监听机制 1.1、watcher概念 zookeeper提供了数据的发布/订阅功能&#xff0c;多个订阅者可同时监听某一特定主题对象&#xff0c;当该主题对象的自身状态发生变化时(例如节点内容改变、节点下的子节点列表改变等)&#xff0c;会实时、主动通知所有订阅者 …

matlab智能算法程序包89套最新高清录制!matlab专题系列!

关于我为什么要做代码分享这件事&#xff1f; 助力科研旅程&#xff01; 面对茫茫多的文献&#xff0c;想复现却不知从何做起&#xff0c;我们通过打包成品代码&#xff0c;将过程完善&#xff0c;让您可以拿到一手的复现过程以及资料&#xff0c;从而在此基础上&#xff0c;照…

QT属性系统

1 介绍 Qt中的属性系统是用于为对象添加自定义属性并管理这些属性的一种机制。它允许开发者在不修改类定义的情况下&#xff0c;动态地为Qt对象添加新的属性&#xff0c;并且能够对这些属性进行读取、设置和监听。 属性系统在Qt中是通过Q_PROPERTY宏和QObject的元对象系统来实现…

【Linux】【docker】安装sonarQube免费社区版9.9

文章目录 ⛺sonarQube 镜像容器⛺Linux 安装镜像&#x1f341;出现 Permission denied的异常&#x1f341;安装sonarQube 中文包&#x1f341;重启服务 ⛺代码上传到sonarQube扫描&#x1f341;java语言配置&#x1f341;配置 JS TS Php Go Python⛏️出现异常sonar-scanner.ba…

基于 yolov8 的人体姿态评估

写在前面 工作中遇到&#xff0c;简单整理博文内容为使用预训练模型的一个预测 Demo测试图片来源与网络,如有侵权请告知理解不足小伙伴帮忙指正 对每个人而言&#xff0c;真正的职责只有一个&#xff1a;找到自我。然后在心中坚守其一生&#xff0c;全心全意&#xff0c;永不停…

WIN大恒工业相机SDK开发

大恒工业相机SDK开发概览 一、开发环境搭建1、C# 环境配置&#xff08;VS2019&#xff09;2、C 环境配置&#xff08;VS2019&#xff09;3、python 环境配置&#xff08;Pycharm&#xff09; 二、相机二次开发流程三、相机相机属性参数配置四、图像采集单帧采集回调采集 注意事…

❤ npm不是内部或外部命令,也不是可运行的程序 或批处理文件

❤ npm不是内部或外部命令,也不是可运行的程序 或批处理文件 cmd或者终端用nvm 安装提示&#xff1a; npm不是内部或外部命令,也不是可运行的程序或批处理文件 原因&#xff08;一&#xff09; 提示这个问题&#xff0c;有可能是Node没有安装&#xff0c;也有可能是没有配置…

掌握Memory Profiler技巧:识别内存问题

关于作者&#xff1a;CSDN内容合伙人、技术专家&#xff0c; 从零开始做日活千万级APP。 专注于分享各领域原创系列文章 &#xff0c;擅长java后端、移动开发、人工智能等&#xff0c;希望大家多多支持。 目录 一、导读二、概览三、如何使用四、页面说明4.1 Java 和 Kotlin 分配…