2. 程式人生 > >在FPS遊戲中，玩家對音畫同步感知的量化與評估

在FPS遊戲中，玩家對音畫同步感知的量化與評估

阿新 • • 發佈：2019-07-12

前言

在遊戲測試中，音畫同步測試是個難點（所謂遊戲音畫同步：遊戲中，音效與畫面的同步程度），現在一般採用人工主觀判斷的方式測試，但這會帶來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遊戲場景有關。

三、 參考文件