代码改变世界

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

2019-07-12 15:19 by hyddd, ... 阅读, ... 评论, 收藏, 编辑

前言

在游戏测试中,音画同步测试是个难点(所谓游戏音画同步:游戏中,音效与画面的同步程度),现在一般采用人工主观判断的方式测试,但这会带来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). 标准值

ITU-R BT.1359-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》