從四個(gè)方面分析云游戲自動(dòng)音視頻測試

在日益臨近的5G時(shí)代下，5G網(wǎng)絡(luò)和新的流視頻游戲服務(wù)將在未來幾年內(nèi)讓云游戲的增長一觸即發(fā)，云游戲已漸成行業(yè)熱點(diǎn)。英特爾基于OWT（Open WebRTC Toolkit）也對云游戲使用場景所需要的高分辨率，高比特率和高幀率的視頻超低延時(shí)的實(shí)時(shí)傳輸做了深入研究和廣泛優(yōu)化。云游戲中音視頻延時(shí)，音畫同步尤為重要。游戲中最為關(guān)注的音視頻檢測是怎么實(shí)現(xiàn)的？音視頻同步檢測是通過什么方式自動(dòng)化實(shí)現(xiàn)的呢？本次講座將圍繞上述幾個(gè)問題從痛點(diǎn)，難點(diǎn)和解決方案一一展開。

1. 項(xiàng)目背景介紹

大家看到這些圖會(huì)想到什么？會(huì)不會(huì)想到我們最近疫情在家工作的場景。隨著流量包的提升和帶寬計(jì)費(fèi)的下降，長短視頻最近非?；鸨?，疫情期間，在家上班、小朋友在家學(xué)習(xí)、在家會(huì)議已經(jīng)成為了一種生活的常態(tài)，它們從生活的可選項(xiàng)瞬間變成了生活的必需品。上圖左邊的云游戲作為一種新的游戲視頻服務(wù)方式，在未來幾年云游戲的增長一定會(huì)因?yàn)楦鞣N原因一觸即發(fā)。云游戲已然成為了業(yè)界追蹤的熱點(diǎn)，我們英特爾基于OWT對于云游戲使用場景所需要的高分辨率、高幀率的視頻，同時(shí)又需要滿足低延時(shí)的實(shí)時(shí)傳輸，在這方面我們做了深入的研究和廣泛的優(yōu)化。其實(shí)無論是音視頻會(huì)議系統(tǒng)還是云游戲場景中，音視頻的質(zhì)量，用戶的體驗(yàn)比如說音視頻的延時(shí)、音視頻的卡頓、音畫是否同步都極為重要。那么最為關(guān)注的音視頻的檢測是怎么實(shí)現(xiàn)的呢，比如說音畫同步怎么做？音視頻的檢測方法和算法有哪些呢？怎么融入到我們檢測體系中呢？這就是我將一一展開和大家講解的內(nèi)容。

2. 音視頻傳播流程分析 2.1 傳統(tǒng)音視頻傳輸流程和問題分析

傳輸流程

上圖是一個(gè)傳統(tǒng)的音視頻傳輸?shù)牧鞒蹋筮吺前l(fā)送方，我們可以想像成一個(gè)一對一的會(huì)議模式，右邊是接收方。發(fā)送方首先要進(jìn)行視頻的采集，不管是用什么設(shè)備，用瀏覽器、用中間設(shè)備、用虛擬攝像頭、用真正的文件傳輸或是用真正的Camera傳輸或者視頻，首先都得進(jìn)行采集。采集之后進(jìn)行前處理降噪，加水印或美顏的功能，再進(jìn)行編碼，通過網(wǎng)絡(luò)的傳輸，編碼后的視頻傳輸?shù)街虚g服務(wù)器，服務(wù)器會(huì)進(jìn)行視頻的中轉(zhuǎn)、處理，比如說會(huì)議模式會(huì)將多路收集到的視頻進(jìn)行合并、壓縮、轉(zhuǎn)碼等等。在服務(wù)器會(huì)進(jìn)行解碼壓縮再編碼，隨后視頻通過網(wǎng)絡(luò)傳輸送到接收方，接收方拿到這個(gè)視頻后會(huì)進(jìn)行后處理和渲染。

問題分析

在整個(gè)流程中哪些地方會(huì)對音視頻的質(zhì)量或者說發(fā)送給接收方的音視頻造成偏差呢？首先是發(fā)送方的采集，采集會(huì)有有損的損耗；其次是前處理；再然后是編碼，最后是發(fā)送方到接收方網(wǎng)絡(luò)因素的干擾，可能是網(wǎng)絡(luò)帶寬，網(wǎng)絡(luò)丟包等等影響。服務(wù)端這邊如果進(jìn)行一個(gè)轉(zhuǎn)碼，解碼，再編碼，或者進(jìn)行編碼的轉(zhuǎn)變，或者進(jìn)行一個(gè)壓縮都是有損的。接收方這邊處理渲染也會(huì)帶來一部分的損耗，可以看到視頻從發(fā)送方到接受方的過程會(huì)經(jīng)過各種各樣的曲折。 2.2 云游戲音視頻傳送流程分析

其實(shí)云游戲和上述傳統(tǒng)音視頻傳輸流程很類似，它們不同的點(diǎn)在于在云游戲的云端會(huì)有個(gè)終端游戲服務(wù)器，終端游戲服務(wù)器會(huì)進(jìn)行游戲音視頻的捕捉，在捕捉之后將游戲音視頻進(jìn)行一個(gè)編碼，編碼之后傳輸?shù)娇蛻舳?，客戶端可能是瀏覽器，也有可能是終端設(shè)備，再解碼、后處理、渲染播放。那么整個(gè)流程中哪些會(huì)對音視頻有影響呢？一是服務(wù)端音視頻的捕捉和編碼；二是網(wǎng)絡(luò)傳輸；三是終端的解碼，后處理，渲染播放等等。

3. 音視頻評估標(biāo)準(zhǔn)和方法

在了解到了傳統(tǒng)的音視頻傳輸流程中一些步驟會(huì)導(dǎo)致音視頻偏差，我們需要思考如何做音視頻的評估，評估時(shí)的方法和標(biāo)準(zhǔn)及其使用。我將音視頻評估標(biāo)準(zhǔn)和方法分為了以下幾個(gè)部分：視頻質(zhì)量評估、音頻質(zhì)量評估、音畫同步、音視頻延時(shí)。 3.1 視頻質(zhì)量評估 視頻的質(zhì)量評估分為兩種：主觀評估和客觀評估。

主觀評估顧名思義就是用人工評估，那么人工評估并不是我們聽一聽就好了這么簡單。人工評估目前來說在各種協(xié)會(huì)比如說IEC、EBU、ITU等等國際電信聯(lián)盟都有相應(yīng)的標(biāo)準(zhǔn)，以上的圖是我截取它們標(biāo)準(zhǔn)文檔的形式，首先是左上角的一個(gè)音頻設(shè)備，如果要搭建一個(gè)音視頻的實(shí)驗(yàn)室，需要注意廣播設(shè)備的設(shè)置位置、廣播設(shè)備的距離、分貝的大小。那我們對視頻評估要注意音視頻實(shí)驗(yàn)室觀看距離的設(shè)定、觀看視頻序列的設(shè)定、對觀測人員人數(shù)的限定（男女比例，老少比例，國籍比例等）。 由此可以看出搭建一個(gè)主觀評估的音視頻實(shí)驗(yàn)室所需要耗費(fèi)的時(shí)間、財(cái)力、人力成本是比較高的。評估之后會(huì)得出什么樣的結(jié)論呢？通常是一個(gè)1分到6分的結(jié)果：一分表示非常差、3分表示還可以接受，5分之后是非常好了。除了人力財(cái)力消耗比較高以外，主觀評估問題還有：我們要對非專業(yè)人員以專業(yè)標(biāo)準(zhǔn)進(jìn)行培訓(xùn)；隨機(jī)選取的人員也會(huì)導(dǎo)致主觀的差異、重復(fù)性低、數(shù)據(jù)無法量化，缺乏參考性、受到測試客觀環(huán)境的影響，比如如果視頻觀看遠(yuǎn)近的切換，順序的切換有可能會(huì)影響最終的結(jié)果。當(dāng)然它也有優(yōu)點(diǎn)，這樣的結(jié)果始終是人的感官，而評估的目標(biāo)就是為了知道這個(gè)音視頻給人感官的最后結(jié)果。

視頻客觀評估，通常稱為VQA（Video Quality Assessment），而Video通常是用一幀一幀的視頻幀數(shù)來組成的，每個(gè)視頻幀其實(shí)就是一張張圖片，我們會(huì)將VQA轉(zhuǎn)成IQA（Image Quality Assessment）。IQA的研究算法其實(shí)有很多，目前有很多學(xué)者會(huì)將IQA加入時(shí)域的特性，再轉(zhuǎn)成VQA的結(jié)果，進(jìn)行客觀評估。客觀評估分為兩類：有參考評估和無參考評估。

客觀評估-有參考評估

有參考評估是什么？從字面上非常好理解，就是將參考視頻和待評估視頻一一對標(biāo)之后輸入到評估算法和評估體系，最后得到分?jǐn)?shù)。

面對五花八門的各種算法，什么叫做好的算法呢？在業(yè)界上有很多開源的數(shù)據(jù)庫。各種學(xué)者和研究人員將他們的算法進(jìn)行研究。上圖左邊TID 2008是大家都知道的圖像的數(shù)據(jù)庫，其實(shí)更新的是TID 2013。根據(jù)TID 2008的文檔描述，它是由一些正常的圖片和一些扭曲之后的圖片組成的。比如說正常圖像占一部分，接下來會(huì)增加一些高斯噪聲的圖片，或者是一些有選編碼之后的圖片，這些都有詳細(xì)的描述。 右圖是我們從公開的算法數(shù)據(jù)庫中獲取的，判斷算法的好壞通常是選幾個(gè)database，在database上進(jìn)行評測，評測算法和數(shù)據(jù)庫中評估出來的評分，數(shù)據(jù)庫除了之前所說的圖像，還有一些扭曲視頻，另外一個(gè)很重要的因素是它會(huì)對提供的每張圖片做一個(gè)主觀打分的數(shù)值。算法和這個(gè)數(shù)值的相關(guān)性可以從PLCC、SROCC計(jì)算。相關(guān)關(guān)系函數(shù)的結(jié)果表示的是算法和真實(shí)的MSE值的偏差。通常絕對值越高，表示算法的性能越好。在拿到一些精簡的算法后會(huì)在各個(gè)數(shù)據(jù)庫中進(jìn)行對比，比如PSNR、SSIM、VMAF等等。在每一個(gè)database里，這些相關(guān)關(guān)系函數(shù)得出的結(jié)果都比已有的算法好，那么就是一個(gè)很好的新算法。

那么在我們的體系中，我選了三個(gè)比較經(jīng)典的算法PSNR、SSIM、VMAF作為有參考的評測標(biāo)準(zhǔn)。我們有了這些有參考的評算標(biāo)準(zhǔn)是否就足夠了呢？我們怎么將這些評估算法加入現(xiàn)有的體系中呢？

首先我們要解決的最核心的問題是測試結(jié)果和流程的可重復(fù)性，這是客觀評估和主觀評估非常大的差別。因?yàn)橛辛酥貜?fù)，所以可以重復(fù)地看問題出在哪兒，重現(xiàn)問題所在點(diǎn)。通常的做法是將隨機(jī)視頻輸入流，轉(zhuǎn)成固定視頻輸入流。光是轉(zhuǎn)成固定輸入流還不夠，將隨機(jī)視頻輸入流轉(zhuǎn)成固定視頻輸入流是恒定長度幀數(shù)的視頻流，比如說一千幀這樣一個(gè)視頻，那么我們在播放的時(shí)候就是一千幀重復(fù)播放，接收到的也是一千幀循環(huán)播放的視頻，我們需要知道我們接收到的視頻是對應(yīng)的發(fā)生到的哪一幀，就要幀與幀之間對標(biāo)之后才能算出有參考的算法，因?yàn)槟切┧惴ǘ际菐c幀之間對比出來的。 我們做了視頻幀的定位，在發(fā)送的時(shí)候就在視頻幀的左上角進(jìn)行一個(gè)視頻幀的標(biāo)記，標(biāo)記的是發(fā)送了多少幀，第幾幀。那么在接收的時(shí)候，這個(gè)幀就會(huì)原生地傳輸過來，然后我們在后臺進(jìn)行左上角幀字符的重識別。識別之后我們就知道是第幾幀，他在發(fā)送的時(shí)候我們進(jìn)行一個(gè)循環(huán)標(biāo)記符，通過循環(huán)標(biāo)記符和左上角視頻幀的定位到第幾輪的第幾幀；通過接收到的視頻幀序列，我們就可以反過來將發(fā)送的視頻序列進(jìn)行挑選。需要進(jìn)行挑選的原因是在接收到的視頻里面，通過網(wǎng)絡(luò)之后會(huì)有一些幀的流失，比如發(fā)送的是100幀收到的只有50幀，那么根據(jù)接收到的50幀我們就找到發(fā)送對應(yīng)的50幀進(jìn)行一一對標(biāo)的發(fā)送序列。發(fā)送序列和接收序列之間進(jìn)行對比，輸入到有參考的算法，最后就可以得到相應(yīng)的評估算法的結(jié)果。

客觀評估-無參考評估

在現(xiàn)實(shí)生活中，我們看到了有參考的評估，在評估一個(gè)編碼的算法時(shí)用得很多。但真實(shí)在直播環(huán)境下，有參考是非常難做的，因?yàn)樗枰獢[脫干擾。那么這就涉及到了另一種客觀評估方法無參考評估，無參考評估也很好理解，我只有待測視頻，直接將待測視頻輸入到評估算法模型中，我就可以得到這樣的一個(gè)結(jié)果。

無參考評估分為兩大類：打分類和全幀掃描。 打分類就是和有參考一樣，將待測視頻輸入到無參考的算法中就可以的得到一個(gè)分?jǐn)?shù)。 打分類通常有兩類。第一種是通過將VQA轉(zhuǎn)成IQA的無參考算法，這些算法都比較成熟了，我們可以看到有一些圖像熵評估算法（GRNN)，空域特性評估算法（BRISQUE)，除此之外很多學(xué)者都在研究DL算法，大家知道之前LiveVideoStackCon上有演講就是基于Camera的視頻的DL評估算法。整體來說，無參考的打分目前來看它的準(zhǔn)確度與數(shù)據(jù)庫中MSE的偏差還是比較大的，它是沒有辦法和有參考評估并列的，準(zhǔn)確度還是比較低的。

全幀掃描的意思是對收到的每一幀的數(shù)據(jù)都進(jìn)行掃描和判斷。 全幀掃描又可以分為兩大類。第一個(gè)是圖片像素檢測，把視頻幀作為一張圖片，通過圖片的像素層進(jìn)行模糊度檢測，來判斷這個(gè)視頻是不是帶有模糊，通過像素塊內(nèi)和像素塊外的相關(guān)項(xiàng)來檢測是否有馬賽克的塊效應(yīng)，同時(shí)也可以檢測是否有噪聲，快衰弱的評判算法，這些技術(shù)都已經(jīng)比較成熟了?？晌覀兒髞碛职l(fā)現(xiàn)我們雖然有很多算法，但是我們不能覆蓋現(xiàn)實(shí)中的馬賽克。以現(xiàn)實(shí)中的馬賽克檢測來說，很多馬賽克并沒有被檢測出來，它可能和我們期望的像素成塊的有差距，說明它的算法不夠通用。目前很多公司包括我們自己也還在研究DL這一塊，我們可以根據(jù)不同產(chǎn)品來定制，比如說我們就想檢測出來，正常視頻幀有多少，我的異常視頻幀有多少，可以做分類的算法，如果有足夠多的視頻，可以進(jìn)行標(biāo)注正常和非正常。還可以通過的DL聚類檢測，大部分時(shí)候，我們的標(biāo)注圖像信息不夠，我們可以通過一些聚類的檢測，做一些無參考的聚類、全幀掃描，所以可以根據(jù)自己的產(chǎn)品做一些相關(guān)的定制。

除了上文我們一直在講的視頻幀質(zhì)量，實(shí)際上大部分產(chǎn)品，比如說在打游戲時(shí)候，你的視頻畫面是清晰的，但視頻過于卡頓就會(huì)十分影響用戶體驗(yàn)。那么在有的情況下，比如說在開會(huì)的時(shí)候，并不要求視頻幀的質(zhì)量很清晰，可能更加關(guān)注流暢度；看電影的時(shí)候，每個(gè)人的感官是不一樣的，我可能會(huì)希望視頻更清晰，流暢度稍微差一點(diǎn)也沒有關(guān)系。那我們有沒有這樣一些相關(guān)的指標(biāo)可以體現(xiàn)出用戶的QoE體驗(yàn)?zāi)兀?

首先介紹一下我們的卡頓時(shí)長算法，將視頻按70000 fp值錄下來，每一幀通過濾波器，將每一幀分為8*8的像素塊，并為每一個(gè)像素塊的上一幀和下一幀計(jì)算絕對差值之和（SAD)，我們就可以定義一個(gè)準(zhǔn)則，設(shè)一個(gè)閾值，最高和最低差值，如果兩個(gè)視頻幀之間有足夠多的8*8之間的SAD大小都低于最低值，或者說我沒有一塊SAD大于最大值，在這種情況下就認(rèn)為這兩張圖片是一樣的，以此認(rèn)為它出現(xiàn)了卡頓，卡頓了多久就是卡頓的時(shí)長，卡頓了多少次就是卡頓的頻率，通常來說一秒左右的卡頓是人的肉眼可以感知的。但是我們又發(fā)現(xiàn)，如果卡頓頻率過快也會(huì)覺得畫面很卡。除了卡頓時(shí)長和卡頓頻率之外，還可以計(jì)算首幀時(shí)間，首幀時(shí)間就是當(dāng)畫面在特定的情況下首幀出現(xiàn)的時(shí)候，畫面從不變到畫面突變的情況，這種情況下我們可以按照上面的算法算出首幀出現(xiàn)的時(shí)間。 3.2 音頻質(zhì)量評估

客觀評估-有參考評估

從客觀評估來講，它的方法主要分兩種，有參考評估和無參考評估。有參考評估就是參考視頻和待測音頻，將兩個(gè)音頻進(jìn)行對標(biāo)，傳輸?shù)皆u估算法模型里，得到相應(yīng)的分?jǐn)?shù)。打分的結(jié)果也和視頻一樣，上圖的分?jǐn)?shù)是舉出例子可以看出哪些是滿意的哪些是不滿意的。

在這主要介紹客觀評估的算法PESQ，這是大家經(jīng)常通用的算法。我們來看一下這套算法的主要流程。第一步是信號處理，我們將發(fā)送的音頻和待測的音頻進(jìn)行信號處理，將兩個(gè)音頻進(jìn)行一一對標(biāo)，將時(shí)間對齊等等。第二步是建模，第一個(gè)模型是感知模型，這步中還包括頻率的映射以及帶寬信號的過密；第二個(gè)模型是認(rèn)知建模，包括一些叫聲相關(guān)的信息組合進(jìn)來，最后將它組合到MSE計(jì)算值的統(tǒng)計(jì)中，計(jì)算參考信號和失幀待評估信號之間的差，正值代表有噪聲，負(fù)值代表無噪聲或有較小的噪聲。這個(gè)模型的優(yōu)點(diǎn)是它允許發(fā)現(xiàn)發(fā)送信號和接收信號有延時(shí)導(dǎo)致的偏差，它會(huì)將這些延時(shí)干擾去除，真正的評價(jià)參考信號和失幀待評估信號之間的偏差。但也有專家認(rèn)為這樣是不合理的，因?yàn)橹虚g有延時(shí)也會(huì)影響音頻感官的結(jié)果。

上圖是從polqa網(wǎng)頁上獲取的幾大有參考音頻評估算法的對比，圖下有網(wǎng)頁地址，它認(rèn)為寬帶的算法可以作為PESQA后一代的音頻算法，目前更為大眾所用，但是這個(gè)算法需要購買LICENSE，所以大家用PESQ也是可以的。

客觀評估 無參考評估

無參考評估分為兩大類：專項(xiàng)檢測和通用檢測。有些時(shí)候我們想進(jìn)行特征音的查找，比如說人聲、噪音、歌聲的檢測。我們通過聲音指紋，相關(guān)度來進(jìn)行特征音的檢測。除了這些專項(xiàng)檢測之外，也有些通用的檢測。我們可以將音頻型號輸入到DL序列號的模型進(jìn)行打分評估，去年LiveVideoStackCon上也有介紹這樣的通用檢測方法，目前來說這種無參考檢測，它的準(zhǔn)確度與有參考檢測的準(zhǔn)確度對比還是相差很多。 3.3 音畫同步

單獨(dú)講音畫同步的原因是音畫同步是視頻和音頻評估的另外一部分。是不是音頻和視頻發(fā)送和接收做到分秒不差才能叫做音畫同步呢？那么多差才叫差也是有一定標(biāo)準(zhǔn)的。上圖所列的幾個(gè)組織，比如說國際電信聯(lián)盟、美國數(shù)字電視國家標(biāo)準(zhǔn)ATSC、歐洲廣播聯(lián)盟標(biāo)準(zhǔn)EBU等等都有相應(yīng)標(biāo)準(zhǔn)。目前還是以ITU的標(biāo)準(zhǔn)作為主導(dǎo)方向。

主觀評估

上圖是ITU標(biāo)準(zhǔn)的定義。這是一個(gè)場景定義，現(xiàn)在是棒球的直播現(xiàn)場，棒球運(yùn)動(dòng)員正在打球，下面有一個(gè)實(shí)時(shí)的播音員，通過兩個(gè)采集設(shè)備進(jìn)行采集之后，經(jīng)過中間中轉(zhuǎn)，包括信息塔的傳輸或網(wǎng)絡(luò)的傳輸?shù)鹊龋ㄋx的比較早，所以是電視信號），最后終端用戶接收。 那音畫之間的差別多少是差呢？多少差別是可以接受的程度呢？最后他們總結(jié)了一個(gè)標(biāo)準(zhǔn)，負(fù)表示畫前音后，正表示音前畫后。他們認(rèn)為畫前音后100ms到音前畫后25ms是無法感知的，所以認(rèn)為這個(gè)時(shí)候視頻是音畫同步的。畫前音后125ms到音前畫后45ms是可以感知的，<-185ms到>90ms是不可以接受的。這是他們定義出來的標(biāo)準(zhǔn)。對于這個(gè)標(biāo)準(zhǔn)，我們有什么辦法對他做自動(dòng)化的評估呢？

客觀評估

上圖就是我們經(jīng)常做的工作。大概說一下整個(gè)流程供大家參考。我們在音頻和視頻中分別插入一系列的特征音和特征視頻幀，在插入的同時(shí)，我們在發(fā)送時(shí)對每個(gè)特征音和特征視頻幀記了時(shí)間錯(cuò)信息，比如它標(biāo)記成第一個(gè)特征視頻幀和第一個(gè)特征音頻幀的時(shí)間偏差，把它記錄下來。那么在接收方這邊，我們同樣的將音頻和視頻每一個(gè)都做后處理，先錄制存儲下來，然后在視頻中查找第一個(gè)特征視頻幀，計(jì)算它的時(shí)間偏差，同時(shí)查找第一個(gè)它對應(yīng)的特征音頻幀，記錄它的時(shí)間信息，兩個(gè)相減，接收到的偏差和發(fā)送的偏差進(jìn)行對標(biāo)就可以算出音畫同步的偏差數(shù)值。 3.4 音視頻延遲

音視頻延時(shí)測試

在前文也有介紹過怎么處理音視頻的延時(shí)，在做白盒干擾的時(shí)候，我們在每一個(gè)視頻幀的左上角進(jìn)行視頻幀的標(biāo)注信息，可以知道這是第幾幀，在發(fā)送的同時(shí)會(huì)記一個(gè)時(shí)間戳給這一幀，接收到這樣的視頻序列之后，我們對接收到的每一個(gè)視頻幀標(biāo)記時(shí)間信息，通過視頻幀的數(shù)據(jù)可以反推這是第幾幀。如果找到對標(biāo)的兩個(gè)幀的時(shí)間信息，直接相減就可以得到端對端的延時(shí)，這里我還加一個(gè)bias是因?yàn)槲覀儼l(fā)送和接收要做到時(shí)間同步，發(fā)送和接收時(shí)間是兩臺不同的機(jī)器，有時(shí)間的偏差，只有考慮到這一點(diǎn)才能算出真正的端對端的延時(shí)。 音頻延時(shí)我們借助于音畫同步的偏差來計(jì)算，在接收到的序列中，通過特征音的查找找到對應(yīng)視頻的時(shí)間戳，他們的偏差就是音畫同步的偏差，音畫同步的偏差結(jié)合視頻的偏差就能算出音頻的偏差。

鼠標(biāo)點(diǎn)擊延時(shí)測試

除了端對端的延時(shí)，在游戲中就是鼠標(biāo)響應(yīng)的時(shí)長。特別是在云游戲中，在客戶端開一槍，這一槍傳到服務(wù)器端最終相應(yīng)到客戶端的時(shí)間長度就是鼠標(biāo)的相應(yīng)時(shí)長。通常我們會(huì)在點(diǎn)擊鼠標(biāo)時(shí)刻記一個(gè)時(shí)間，然后將事件網(wǎng)絡(luò)傳輸?shù)椒?wù)端，服務(wù)端在進(jìn)行回傳的時(shí)候，真正相應(yīng)到客戶端中計(jì)算記錄時(shí)間（time2），time2減去之前鼠標(biāo)點(diǎn)擊的時(shí)間（time1）就是鼠標(biāo)來回的時(shí)間。在后續(xù)，要根據(jù)不同的終端來做不同的處理，比如說瀏覽器可以借助Video Tag的event來做，其他終端可能要借助于視頻幀的檢測。

4. 系統(tǒng)性能評估輔助方法

在音視頻評估體系中，考慮到音視頻的質(zhì)量、音視頻的延時(shí)、音畫同步參數(shù)之外，我們還會(huì)對系統(tǒng)的性能進(jìn)行評估。我們整個(gè)通用中用了WebRTC，WebRTC stats其實(shí)提供了很多indicator，比如說fps、Bandwidth、幀率、幀大小、Nack cout、PacketLost等等因素。它其實(shí)也可以反饋給用戶系統(tǒng)的實(shí)時(shí)性能評估，我們?yōu)榱诵拚@些信號利用OpenCensus，它提供了不管是服務(wù)端C++還是用客戶端js來做，用Node js的后端，最后將所有的數(shù)據(jù)不管是WebRTC stats的或是音畫同步的信息還是音視頻質(zhì)量的時(shí)間信息統(tǒng)一傳輸?shù)胶蠖?，通過Prometheus終端顯示，這樣很多數(shù)據(jù)就可以做實(shí)時(shí)監(jiān)測的終端顯示,優(yōu)點(diǎn)就是不管你在哪里，通過一臺瀏覽器就可以監(jiān)控到目前的狀態(tài)。