前言
在游戲測試中，音畫同步測試是個難點（所謂游戲音畫同步：游戲中，音效與畫面的同步程度），現在一般采用人工主觀判斷的方式測試，但這會帶來2個問題：
- 無法准確量化，針對同一場景的多次測試結果可能會相反；
- 人力投入與業務場景數成正比；
本文主要內容：
- 一、 音畫同步測試方案
- 二、 玩家對FPS游戲音畫不同步的感知
（注：上下文中，游戲默認為PC上的FPS游戲，音畫同步默認為PC上FPS游戲的音畫同步）
一、 音畫同步測試方案
如果我們采用 實時計算 的方案，這將導致該測試對計算機有很高的要求，因為我們需要對每秒60張1080P-JPEG圖片與44100Hz-wav音頻進行科學計算。
實際上，音畫同步測試對實時性並非硬核要求，而且無論計算是實時或者非實時，被測試的游戲場景音畫均需留檔，以備問題追查，所以，本方案使用 非實時計算。同時，引入 視頻錄制，把“游戲音畫同步”問題轉換為“視頻音畫同步”問題。
1. 視頻錄制
在PC上，錄制方案分2類：
(1). 硬件錄制
在游戲中，把游戲PC機音視頻流導出后，通過硬件采集卡+相關工具進行錄制，流程如下：
(2). 軟件錄制
PC上軟件錄制工具很多，本案使用：ffmpeg + “screen capture” directshow filter
-
安裝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
...
二、 玩家對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》