1秒钟延时程序（延时探究---IP制作系统中视音频相对延时和绝对延时）

前言：延时话题属于信号质量优化的重点和难点，前人有很多探索和解决方法，可以说这棵树上结出了很多果实，促进了技术的进展，IP化新雨过后高处又冒出了嫩枝，笔者不自量力踩着前人搭好的梯子试图尝一尝鲜。本文的内容对于经验丰富的工程师而言，可能存在颇多老调重弹之处，但复习理论、温故知新似乎也没什么坏处。本篇将分上下两期，为大家详细介绍IP系统视音频相对延时和绝对延时的一些心得。

无论在制作域还是传输域，计划外的过大延时常是令工程师们头疼的问题。伴随着近几年IP设备普及，系统链路设计多样化，远程制作、云制作、虚拟制作等新兴技术迅猛发展，老生常谈的延时话题又有了新篇，延时大小也成为设备选型和系统设计时需要衡量的核心指标之一。

在实际测量过程中，我们发现有时某一节点或某一段链路的延时很难直接量化，因此清晰的测量思路以及合理利用测试仪器至关重要。为了系统性进行阐述，下面将常见的延时问题按笔者个人理解进行简单分类。

图1：延时问题分类

延时(Delay)与延迟(Latency)有何不同

阅读国外资料时，经常会看到 “Delay”和“Latency”这两个单词，多数情况两者进行互换混用不会造成理解障碍，部分外国工程师也不会刻意去区分它们。但二者并不总是相同的，严格来讲Delay是数据从一个端点传输到另一个端点所花费的时间。而Latency有双重含义，有时被认为是数据包从一个端点传输到另一个端点所用的时间，这与单向Delay是一样的，但更多的情况，Latency表示的是往返时间，包括发送数据包所需的时间加上它返回所需的时间。本文中阐述的多为单向延时，因此也不做过多区分。

一、相对延时

1.什么是相对延时？标准值从何而来？

音视频相对延时是系统工程师们非常熟悉的一个概念，指的是由于系统内音频信号和视频信号途经不同路由，各设备信号处理时长有快有慢，导致音视频信号再度汇聚时，存在相对定时误差，也被称做AV Delay。音视频加嵌后的末级信号相对延时过大，将出现“口型对不上”的声画不同步现象，最终影响系统指标和素材收录。此外，如果监看与监听信号间有过大的相对延时，超出可察觉门限甚至可接受门限，还会干扰到导播正常工作。

图2：相对延时产生示意

那么专业制作系统相对延时的容限是多少？一些标准化组织对此给出了要求或建议，比如在EBU R37-2007中建议范围是-60ms~ 40ms（即音频滞后60ms~音频超前40ms），ATSC IS/191中是-45ms~ 15ms。目前国内更多采用的是由ITU-R BT.1359-1 (1998) 和GB/T 22150-2008 《电视广播声音和图像的相对定时》中规定的-30ms~ 22.5ms，那么这个范围从何而来，背后有哪些深层的考虑？

图3：BT.1359-1电视广播声音和图像相对定时可察觉和可接受门限

经过评估测试，在BT.1359中定义了以下概念：

平均可接受门限范围：-185ms~ 90ms（图3中A-A’）

平均可察觉门限范围：-125ms~ 45ms（图3中B-B’）

根据ITU制定的主观评价等级，一个位于不可察觉平稳段（图3中C-C’）的信号，叠加上系统可能引入的误差（B-C，-30ms；B’-C’， 22.5ms），依然能够使系统输出端音视频相对延时保持在可察觉门限（B-B’）之上。因此，广电总局测试以及索尼系统检测服务都是以-30ms~ 22.5ms作为系统内音视频相对延时的评判指标。

2.相对延时与系统架构有关吗？有没有参考经验值？

不管采用基带架构、IP架构或是混合架构，以及系统链路如何设计，只要视音频信号路由不同，都会存在相对延时。根据以往项目经验，IP系统末级链路的相对延时平均典型值为 30ms左右，基带系统普遍在 100ms上下，混合架构需视混合程度具体分析。（数值仅供参考，系统设计或不同品牌设备可能有一定浮动）

图4：索尼系统检测服务对某IP系统音视频相对延时检测结果

图5：总局对某IP/SDI混合系统音视频相对延时检测结果

3.相对延时超出标准范围怎么办？

音视频相对延时问题的解决方法十分成熟，可以概括为先测量再校正。测量时首先打开同步信号发生器的LipSync (Leader)或AV Timing(Telestream）功能，将测试信号由外来通道输入，解嵌后分别经过待测系统的音、视频链路，末级加嵌后由示波器AV phase (Leader)或 AV Delay (Telestream)功能测得音视频相对延时量。需要注意的是，同步信号发生器和示波器需要具备相应选件，且应保持品牌一致，混用可能无法测量出结果。

图6：利用同步信号发生器 示波器测量音视频相对延时

除了用LipSync测试信号进行测试外，还可以将声画同步校准装置LSC-1（图7）摆放于镜头前，用摄像机拍摄这一圈LED，同时用话筒拾取其发出的蜂鸣，将经过待测链路后的信号录制下来，检查回放内容。当LSC-1最上方黄色LED亮起时，会同步发出一个蜂鸣，如在回放中听到蜂鸣时对应亮起的LED是左半圈红色，则表示系统为音频超前；如亮起的是右侧绿色，则表示系统为音频滞后。相邻两个LED时间间隔为一帧，并且帧率50/60可选。类似设备在国外也有应用，比如2022年欧歌赛，NEP用类似功能的Sync-it装置进行音视频同步校准。由于这种测试方法可以将现场→摄像机→系统完整链路全部囊括在测试范围内，所以是更偏重于实战应用层面的测试及校准。

图7：利用声画同步校准装置测量音视频相对延时

如果不具备以上测试条件，也可通过在摄像机前朗读爆破音、打板、扎气球等动作，用慢动作服务器逐帧回放主观判断，进行低精度替代。

图8：冬奥会日本出镜记者进行声画同步测试——ばべびぶべぼばぼ（日语中浊音）

4. IP系统中相对延时问题有高效的解决办法吗？

首先，IP系统与基带系统没有区别，也存在相对延时问题，其产生原因同样是音视频信号路由不同。对IP系统音视频相对延时进行测量时，既可以用IP示波器在IP域完成，也可以经网关设备转换为SDI信号后，再用传统示波器测量。

图9：Timestamp生成过程

IP系统中设备采用PTP协议同步，IP流利用RTP协议进行分发，且在RTP Header中有Timestamp字段记录时间戳。根据ST2059标准，各类信号虽采用不同频率的采样时钟（视频90kHz，音频48kHz，辅助数据90kHz），但是仍旧可以根据PTP计算出RTP时钟，再生成各个流的时间戳，在接收端也可以根据时间戳还原信号相位，最终保持信号同步。这是否意味着理论上可以通过Timestamp自动对齐视音频流，以实现LipSync？

可惜的是，目前在系统层面暂时无法做到。其最核心问题是：数据包每到达下一个设备并发出新流的同时，Timestamp字段会被重写。换而言之，当前最多可实现由A到B两设备间音视频流自动对齐。如果是更复杂但却很现实的情况——音视频流分别经不同链路、多台设备处理并路由，以目前的机制无法在系统层面实现全局自动Lipsync。

未来IP系统中是否可能产生自动Lipsync解决方案呢？业内已经有专业人士提出建议：带内携带原始时间戳——将音频辅助数据也作为Payload有效载荷的一部分，或采用RTP头部扩展机制，或在带外辅助数据中携带原始时间戳（这将需要通过新的标准或协议去定义，比如AES X242, ST2110-41/-42, 或者NMOS），利用原始时间戳将视音频流对齐。另一种思路是：链路中所有信号处理设备将信息给到Broadcast Controller，并且能够接受Broadcast Controller下发的指令，通过控制系统辅助实现时间对齐。

图10：Broadcast Controller接收并发送时间对齐信息

不过笔者认为想要实现全流程音视频自动对齐还是存在一定技术难点，简单列举以下：

· 当多路IP音频流混音时，具备多个不同时间戳该以哪个为准作为原始时间戳？

· IP音视频自动对齐时，如果希望对IP音频流施加的延时量超出设备buffer容量时怎么处理？

· 在相对延时不稳定的情况下，自动对齐会不停改变音频延时量，是否会带来打火声？（或许可以通过算法进一步消耗算力来解决，以实现变速不变调）

· 如果两个音频系统采用基带信号互联互通(比如二级调音或级联)，直到音频网关类设备才转换为IP流打上时间戳，这时视频全流程都在IP域，音频全流程则由基带加IP两部分组成，最终若在IP域实现音视频流自动对齐，将会有误差，这样做的意义和必要性看似不大。想要消除误差，需要基带音频信号带外传输时间信息，但如何将其转换作为原始时间戳或许是需要突破的技术难点。目前看来，自动对齐最为适用的场景还是图10中列举的IP摄像机视频信号和机头Mic音频信号之间的对齐。

以上问题为笔者个人疑问，欢迎各位读者沟通交流。

相对延时总结：

· 基带系统、IP系统、混合系统都存在相对延时问题。

· 测试系统相对延时用同步信号发生器 示波器组合更准确，但也有其他替代手段。节目制作前的准备阶段可以用声画同步校准装置进行辅助确认。

· 转播车、演播室系统中大多数情况都是音频信号超前，通过在加嵌板卡（Sony IPG板卡AM50许可最大能够延时250ms）或是调音台主输出母线相应调整音频延时量，即可消除末级信号中声音和图像的定时误差。

· 如果监听信号与监看信号间存在不同步，可以通过监听延时器或调音台监听母线调整延时，结合主观判断，控制监听声音滞后一定量，达到与监看图像匹配的目的。

下期我们将为大家分享绝对延时内容。

,