您的位置:首页 > 其它

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

2019-07-12 15:19 561 查看

前言

在游戏测试中,音画同步测试是个难点(所谓游戏音画同步:游戏中,音效与画面的同步程度),现在一般采用人工主观判断的方式测试,但这会带来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》
  • 内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
    标签: 
    相关文章推荐