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

匿名 · 2019年07月12日 · 最后由 linzhi 回复于 2019年09月11日 · 125 次阅读

本文首发于个人博客:https://www.cnblogs.com/hyddd/p/11175919.html

前言

在游戏测试中,音画同步测试是个难点(所谓游戏音画同步:游戏中,音效与画面的同步程度),现在一般采用人工主观判断的方式测试,但这会带来 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》
共收到 1 条回复 时间 点赞

楼主用的是什么采集卡啊 然后是用脚本直接读采集卡输出的视频流么

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册