本文首发于个人博客：https://www.cnblogs.com/hyddd/p/11175919.html

前言

在游戏测试中，音画同步测试是个难点（所谓游戏音画同步：游戏中，音效与画面的同步程度），现在一般采用人工主观判断的方式测试，但这会带来 2 个问题：

• 无法准确量化，针对同一场景的多次测试结果可能会相反；
• 人力投入与业务场景数成正比；

本文主要内容：

• 一、 音画同步测试方案
• 二、 玩家对 FPS 游戏音画不同步的感知

（注：上下文中，游戏默认为PC 上的 FPS 游戏，音画同步默认为PC 上 FPS 游戏的音画同步）

一、 音画同步测试方案

如果我们采用 实时计算 的方案，这将导致该测试对计算机有很高的要求，因为我们需要对每秒 60 张 1080P-JPEG 图片与 44100Hz-wav 音频进行科学计算。

实际上，音画同步测试对实时性并非硬核要求，而且无论计算是实时或者非实时，被测试的游戏场景音画均需留档，以备问题追查，所以，本方案使用 非实时计算。同时，引入 视频录制，把 “游戏音画同步” 问题转换为 “视频音画同步” 问题。

1. 视频录制

在 PC 上，录制方案分 2 类：

(1). 硬件录制

在游戏中，把游戏 PC 机音视频流导出后，通过硬件采集卡 + 相关工具进行录制，流程如下：

(2). 软件录制

PC 上软件录制工具很多，本案使用：ffmpeg + “screen capture” directshow filter

1. 安装 dshow filter: Screen Capturer Recorder

2. 录制：ffmpeg -f dshow -framerate 30 -i video="screen-capture-recorder" -c:v h264 -r 30 -f dshow -i audio="virtual-audio-capturer" -b:a 192k -ar 44100 -ac 2 -t 5 out.mp4

(3). 对比 2 类录制方式

• 硬件录制
  • 优点：画质无损，不丢帧
  • 缺点：不利于自动化
• 软件录制
  • 优点：利于自动化
  • 缺点：画质损失，丢帧/不能满帧录制

在音画同步测试中，画质损失对于帧特征识别影响不大，但丢帧/不能满帧录制则会引入误差，比如：

上图中，音频起始时间：time1，特征首帧时间：frame2(time1)，不能满帧录制导致 frame2 丢帧，特征首帧时间变为：frame3(time2)，引入误差：∆t' = time2 - time1，60fps 游戏使用 30fps 录制，则可能引入误差 ∆t' = 0.016s。

（注：上文中，特征含义：当音频出现时，在画面中应该出现的图像特征，比如：射击时，画面出现的枪体震动...）

误差对测试的影响，将在下文讨论。

2. 计算音画同步差

流程核心步骤：帧特征识别 与 音频特征识别。

(1). 帧特征识别

这里，我们把 “帧特征识别” 问题转化为：在图像中寻找子图像（特征）。

问题转换后，解决方案就很明确了，可以使用 opencv 提供模板匹配处理，部分源码如下：

...

feature = cv2.imread(feature_path, 0)

for frame_path in frame_paths:      
    frame_rgb = cv2.imread(frame_path)
    frame_gray = cv2.cvtColor(frame_rgb, cv2.COLOR_BGR2GRAY)

    res = cv2.matchTemplate(frame_gray, feature, cv2.TM_CCOEFF_NORMED)
    loc = numpy.where(res >= threshold)

    if len(list(zip(*loc[::-1]))) > 0:
        index = get_frame_index(frame_path)
        T1 = index / framerate
        break

...

(2). 音频特征识别

这里，我们把 “帧特征识别” 问题转化为：在长音频（视频音频）中寻找子音频（特征音频），这里使用 “互相关” 函数处理。

需要注意的“坑”：

• 互相关函数对有背噪的音频处理效果不理想，如果长音频（视频音频）存在背噪，要先进行降噪处理；
• 基于测试目的是:识别音画同步差，故测试场景选取时，要避免出现特征音频叠加情况；
• 多声道音轨，在测试时以第一个声道为准，所以构造测试场景时需要注意；

...

src_data, s_framerate = read_wav(feature_path)
deg_data, d_framerate = read_wav(audio_path)

if s_framerate ！= d_framerate:
    return

n = max(len(src_data), len(deg_data))

result = numpy.correlate(src_data, deg_data, mode='full')
m = result.max().item()
m_indexs, = numpy.where(result == m)
m_index = m_indexs[0]

offset = m_index - n + 1
if offset < 0:
    offset = -offset

T2 = offset / s_framerate

...

二、 玩家对 FPS 游戏音画不同步的感知

在这部分，我们要讨论一个问题：玩家对 FPS 游戏音画不同步的感知力到底如何？探讨这个问题，可以让我们订立一个针对 FPS 游戏的音画同步标准。

1. 现有业界标准

关于音画同步，业界有 3 个标准：

• ITU-R BT.1359（1998）：国际电信联盟标准
• ATSC IS/191（2003）：美国的数字电视国家标准
• EBU R37（2007）：欧洲广播联盟标准

其中，影响力最大的是 ITU-R BT.1359，下面将重点对 ITU-R BT.1359 进行分析。

《ITU-R BT.1359-1》是国际电信联盟于 1998 年修订，针对电视广播的音画同步标准，该标准至今仍被使用，同时应用范围也扩展到互联网直播领域。

(1). 标准值

• 无法感知：-100ms ~ 25ms
• 能识别： –125ms & 45ms
• 不可接受：小于-185ms & 大于 90ms

其中，负值表示：画前音后；正值表示：画后音前；

(2). 评测方案

上图是电视广播简化版处理链路，每个节点均可能引入同步差。其中：

• 1’ 到 6’ 的音画差应满足：-185ms ~ 90ms
• 6’：评测者这类型包括：专家与一般人
• 6： 22 寸 CRT，SDTV（即：576x720）
• 评测者使用 ITU-R 的 5 级评分（5 分最高，1 分最低），无法感知阈值：4.5，能识别阈值：3.5

分值	含义
5	完全不可察觉
4	可察觉，但不讨厌
3	稍微讨厌
2	讨厌
1	完全无法接受

2. FPS 游戏音画不同步的感知力

(1). 场景

FPS 游戏音画场景很多，如：脚步声，敌方开枪，玩家开枪......

但玩家对不同场景的感知力并不相同，因为玩家关注点可能并不在上面：

• 脚步声：因为玩家视觉范围一般只有 130°左右，脚步声更多是触发玩家进行视觉转移，未必需要体现音画同步性；
• 敌方开枪：理由同上。另外，敌方开枪一般会距玩家一定距离，由于敌方图像较小，音画同步性不易观察；
• 玩家开枪：该场景是最常见、且玩家对音画同步最敏感的场景；

所以，以下评测 FPS 游戏音画同步性采用：“玩家开枪” 场景；

(2). 评测流程

• 步骤 1、2、3
  • 评测视频的录制流程；
• 步骤 1 中，游戏音画同步差：△t1；
• 步骤 3、4(采集、编解码)
  • 由于这 2 步基于 timestamp 进行处理，尽管编解码会导致 delay，但这是整体 delay（音画同时 delay），让我们暂且相信基于 timestamp 对齐，编解码不会导致相对差吧；
• 步骤 2、5(渲染处理)：
  • 画面处理：去除垂直同步、计算性能不足导致的丢帧，画面渲染 delay 可看作 0ms；
  • 音频处理：现在 windows 音频处理基于 WASAPI，而 WASAPI 会引入 delay 为 0~10ms（取△ta2=-5ms）
• 步骤 6
  • 液晶显示在输出时，液晶份子变换颜色会导致一定 delay，TN 面板 1ms，而 IPS 和 VA 面板一般是 4~5ms(△tv6=5ms)
  • 耳机
    • 有线：一般有 7ms 的 delay(△ta6=-7ms)
    • 蓝牙：蓝牙耳机会引入更严重音频的延迟，但本次测试不涉及该操作。
  • 即：步骤 6 引入误差-2ms(△t6=-2ms)
• 评测者观察到的音画差：△t = △t1 + 2*△ta2 + △t6，并且当测试视频不使用 60fps 而使用 x 帧录制时，会引入±(1/x-1/60) 的误差，即： △t = △t1 + 2*△ta2 + △t6 ± (1/x-1/60)

(3). 真实玩家交互流程

与评测流程相比，真实交互流程是少了 1 次△ta2 的延迟。

(4). 主观评测方案

• 场景
  • 玩家开枪 (单发) * top10 枪械
• 评测音画同步差范围
  • 通过 (一) 中方案识别同步差后，再进行音频偏移，范围：-450ms ~ 500ms
• 评测者
  • FPS 游戏资深玩家
• 评分方式
  • 二元选择，评测者针对视频给出结论：同步、不同步
• 样本数
  • 约 10000
• 其他
  • 测试过程中，随机加入校验案例，测试评测者结果可信度

与 ITU 评测方案差异分析：

• 评测者
  • ITU 包括：一般人与专家，而我们只包含资深玩家，因为我们相信不玩 FPS 游戏的人对评测 FPS 音画体验意义不大，而资深玩家对枪械表现敏感，所以从这角度看，我们认为资深玩家等价于 ITU 中的专家
• 评测地点
  • ITU 在实验室中进行评测，而我们使用众包方式进行，评测地点在评测者家里
• 硬件设备
  • 由于 ITU 是 98 年标准，所以对于今天来说，ITU 当年使用的都是古董......
  • ITU 使用 SDTV，分辨率为 576P，我们使用液晶显示器，分辨率为 1080P 或以上。在分辨率、观看距离上的差异，会导致评测者敏感度不同
  • 由于评测地点在各自家里，导致评测设备不同，参差的设备质量将加大误差，但这并不是坏事，因为实际玩家环境就是如此，对此，我们采用加大采样量方式解决。
• 评分方式
  • ITU 使用 5 分制，我们使用二元选择。使用二元选择，不可否认会降低结果精度。而使用二元选择原因：以往经验，虽然明确描述了 5 分标准，但评测者对此各有理解，评测时由于无法亲身指导 (评测者在家里进行评测)，导致评分出现各种问题。为了简化流程，我们使用了二元选择，并同时加大采样量。

(5). 主观评测结果

音画同步差△t 的范围 (ms)	认为 “同步” 的占比
-400 ~ -450	23%
-300 ~ -350	48%
-200 ~ -250	80%
-100 ~ -150	90%
-30 ~ 30	95%
100 ~ 150	75%
200 ~ 250	47%
300 ~ 350	19%
400 ~ 450	7%
500 ~ 550	2%

（注：音画同步差△t 的范围* 表示 步骤 1~7 音画差总和的范围）*

(6). 结论

• 从上表中可以看出，当游戏音画同步差在 [-150ms, 30ms] 时，用户难以察觉。但本次评测使用了 30fps 视频，且需减去一个△ta2，所以修正后，用户难以察觉的游戏音画同步差区间为： [-160ms, 50ms]，与 ITU 的阈值区间相似。
• 在 FPS 游戏中，画后音前(即：Sound advanced，数值>0) 比 画前音后(即：Sound delay，数值<0) 更容易让人察觉，且让人感觉卡顿与不适。相同区间下，画后音前 与 画前音后 的效果并不等价。
• 评测者普遍对 画前音后 有较好的容忍度，这可能与 FPS 游戏场景有关。

三、 参考文档

• 《ITU-R BT.1359：Relative Timing of Sound and Vision for Broadcasting》
• 《ITU-R BT.500-13：Methodology for the subjective assessment of the quality of television pictures》