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