本文首发于个人博客：https://www.cnblogs.com/hyddd/p/11175919.html
在游戏测试中，音画同步测试是个难点（所谓游戏音画同步：游戏中，音效与画面的同步程度），现在一般采用人工主观判断的方式测试，但这会带来 2 个问题：
本文主要内容：
（注：上下文中，游戏默认为PC 上的 FPS 游戏，音画同步默认为PC 上 FPS 游戏的音画同步）
如果我们采用 实时计算 的方案，这将导致该测试对计算机有很高的要求，因为我们需要对每秒 60 张 1080P-JPEG 图片与 44100Hz-wav 音频进行科学计算。
实际上，音画同步测试对实时性并非硬核要求，而且无论计算是实时或者非实时，被测试的游戏场景音画均需留档，以备问题追查，所以，本方案使用 非实时计算。同时，引入 视频录制，把 “游戏音画同步” 问题转换为 “视频音画同步” 问题。
在 PC 上，录制方案分 2 类：
在游戏中，把游戏 PC 机音视频流导出后，通过硬件采集卡 + 相关工具进行录制，流程如下：
PC 上软件录制工具很多，本案使用：ffmpeg + “screen capture” directshow filter
安装 dshow filter: Screen Capturer Recorder
录制：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
在音画同步测试中，画质损失对于帧特征识别影响不大，但丢帧/不能满帧录制则会引入误差，比如：
上图中，音频起始时间：time1，特征首帧时间：frame2(time1)，不能满帧录制导致 frame2 丢帧，特征首帧时间变为：frame3(time2)，引入误差：∆t' = time2 - time1，60fps 游戏使用 30fps 录制，则可能引入误差 ∆t' = 0.016s。
（注：上文中，特征含义：当音频出现时，在画面中应该出现的图像特征，比如：射击时，画面出现的枪体震动...）
误差对测试的影响，将在下文讨论。
流程核心步骤：帧特征识别 与 音频特征识别。
这里，我们把 “帧特征识别” 问题转化为：在图像中寻找子图像（特征）。
问题转换后，解决方案就很明确了，可以使用 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
...
这里，我们把 “帧特征识别” 问题转化为：在长音频（视频音频）中寻找子音频（特征音频），这里使用 “互相关” 函数处理。
需要注意的“坑”：
...
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 游戏的音画同步标准。
关于音画同步，业界有 3 个标准：
其中，影响力最大的是 ITU-R BT.1359，下面将重点对 ITU-R BT.1359 进行分析。
《ITU-R BT.1359-1》是国际电信联盟于 1998 年修订，针对电视广播的音画同步标准，该标准至今仍被使用，同时应用范围也扩展到互联网直播领域。
其中，负值表示：画前音后；正值表示：画后音前；
上图是电视广播简化版处理链路，每个节点均可能引入同步差。其中：
| 分值 | 含义 |
|---|---|
| 5 | 完全不可察觉 |
| 4 | 可察觉，但不讨厌 |
| 3 | 稍微讨厌 |
| 2 | 讨厌 |
| 1 | 完全无法接受 |
FPS 游戏音画场景很多，如：脚步声，敌方开枪，玩家开枪......
但玩家对不同场景的感知力并不相同，因为玩家关注点可能并不在上面：
所以，以下评测 FPS 游戏音画同步性采用：“玩家开枪” 场景；
与评测流程相比，真实交互流程是少了 1 次△ta2 的延迟。
与 ITU 评测方案差异分析：
| 音画同步差△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 音画差总和的范围）*
