在FPS游戏中，玩家对音画同步感知的量化与评估

前言

在游戏测试中，音画同步测试是个难点（所谓游戏音画同步：游戏中，音效与画面的同步程度），现在一般采用人工主观判断的方式测试，但这会带来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》