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

时间 2019-11-06

标签 fps 游戏玩家同步感知量化评估栏目游戏繁體版

原文原文链接

前言

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

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

本文主要内容：ide

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

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

1、音画同步测试方案

若是咱们采用 实时计算 的方案，这将致使该测试对计算机有很高的要求，由于咱们须要对每秒60张1080P-JPEG图片与44100Hz-wav音频进行科学计算。工具

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

1. 视频录制

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

(1). 硬件录制

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

(2). 软件录制

PC上软件录制工具不少，本案使用：ffmpeg + “screen capture” directshow filtercode

安装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游戏

(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

    ...

2、玩家对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). 评测流程

步骤一、二、3
- 评测视频的录制流程；
步骤1中，游戏音画同步差：△t1；
步骤三、4(采集、编解码)
- 因为这2步基于timestamp进行处理，尽管编解码会致使delay，但这是总体delay（音画同时delay），让咱们暂且相信基于timestamp对齐，编解码不会致使相对差吧；
步骤二、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游戏场景有关。

3、参考文档

《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》