1、*性能測試*

（1）結(jié)論：

　　關(guān)于推流丟包率，我們上次就發(fā)現(xiàn)了這個問題，幾乎沒有丟包，也就意味著每次傳輸都保證了傳輸數(shù)據(jù)到達(dá)率，但是這個在弱網(wǎng)下就是一個好的表現(xiàn)嗎？沒有主動丟包的策略每幀數(shù)據(jù)都傳輸是否加劇了網(wǎng)了擁堵程度？所以這部分是否我們可以主動控制鍵丟包.這點不知道我理解得對不對（參考聲網(wǎng)丟包xx %突然能夠聽清楚對方的話）或者（低端設(shè)備播放高清視頻時有跳幀的說法）所以我們可以定制下自己的丟包策略 2.極限測試，主要是比較的舍我們sdk和行業(yè)水準(zhǔn)。所以我們對sdk的測試過程提出了高的要求 連麥數(shù)（友商基本上號稱十多路）分辨率，尤其在教育領(lǐng)域 共享屏幕的分辨率幾乎遠(yuǎn)超360*640，其他幀率，碼率也是同理。

（2）解釋：

　　上行無丟包，說明推流到服務(wù)端是沒問題的，只有一路上行，所以上行數(shù)據(jù)會好一些。下行有丟包，是因為下行拉4路流，平均碼率600k，4路就是2.4M，加上重傳等其他冗余包等，應(yīng)該會比這個2.4M更大，下行拉流越多，帶寬不夠的情況下，丟包可能會更嚴(yán)重。這個的確也會是以后一個長期優(yōu)化的方向點。
　　9連麥拉9路流，分辨率是144x192，大部分碼率只有50K，9路加起來才450K，有一部分9連麥?zhǔn)?50k碼率，9路流加起來也才2.25M。所以今天的這個測試數(shù)據(jù)量應(yīng)該是已經(jīng)超過了APP 9連麥的場景。SDK會陸續(xù)支持大小流模式或者SVC去支持更多的并發(fā)拉流，能一定程度上更好地支持教育模式或者會議模式。

2、內(nèi)存、cpu獲取工具
https://github.com/didi/DoraemonKit

3、多家RTC服務(wù)的MOS評測方法
（1）科普：影響音視頻質(zhì)量和穩(wěn)定性的因素

網(wǎng)絡(luò)

　　音視頻對網(wǎng)絡(luò)傳輸?shù)囊蕾囆栽絹碓斤@而易見。網(wǎng)絡(luò)狀況對于音視頻質(zhì)量的影響是很直觀的，如果音視頻包在網(wǎng)絡(luò)傳輸?shù)倪^程中丟失，晚到，或者不均勻的到，就會造成我們常說的丟包，延時和抖動。隨著網(wǎng)絡(luò)上主機數(shù)量的不斷增加，網(wǎng)絡(luò)服務(wù)的需求將超過網(wǎng)絡(luò)提供的能力，從而造成傳輸時延變化(抖動)、傳輸時延過大甚至引起分組丟失，也就是說出現(xiàn)了大塞車(網(wǎng)絡(luò)擁塞)，這將對傳輸時延要求比較苛刻的實時音視頻傳輸造成很大影響，從主觀聽感或視覺感受上造成聲音或視頻畫面的卡頓和滯后，嚴(yán)重影響通話的質(zhì)量和可懂度。在公共互聯(lián)網(wǎng)上，特別是在遠(yuǎn)距離通信的情況下，如果缺乏足夠的網(wǎng)絡(luò)部署和丟包對抗技術(shù)，這種情況就會變得尤為明顯。

　　此外，除了在傳輸層引起的丟包抖動，路由器，移動數(shù)據(jù)網(wǎng)絡(luò)等問題也會引起丟包抖動。網(wǎng)絡(luò)中存在很多的節(jié)點，如路由器、網(wǎng)關(guān)等。這些節(jié)點采用排隊機制決定數(shù)據(jù)發(fā)放的順序。如果在瞬間某節(jié)點數(shù)據(jù)排隊較長，該節(jié)點就會采取丟棄數(shù)據(jù)包的方式保證節(jié)點的正常工作。即使沒有被丟棄，經(jīng)過較長的排隊之后，這些數(shù)據(jù)包往往要花很長的時間才能到達(dá)目的地，由此就產(chǎn)生了網(wǎng)絡(luò)的時延以及時延抖動。

設(shè)備

設(shè)備對于音視頻質(zhì)量的影響是相對隱性的，但是往往會起著決定性的作用。相較于蘋果機，安卓機的問題就非常碎片化了。由于安卓機型太多，適配對和安卓機打交道的開發(fā)者來說往往司空見慣，比如受一些中低端機型性能影響，音視頻在蘋果機上測試覺得不錯，但是到一些中低端的安卓機器上就問題百出。這類問題無論網(wǎng)絡(luò)好壞都會產(chǎn)生，這時候就必須有音視頻引擎的算法模塊來做對應(yīng)的算法適應(yīng)和適配了，解決這類問題的技術(shù)門檻一般都是很高的。

物理環(huán)境

物理環(huán)境對音視頻通話的影響不易察覺，但又不可忽視。例如，近場時候的尖銳雜音（嘯叫）就是由于設(shè)備A的麥克風(fēng)會直接收錄到設(shè)備B的揚聲器播放的聲音，然后又會傳回設(shè)備B播放出來，形成了一個正反饋回環(huán)導(dǎo)致的。只要分開一定距離通話或者靜音掉其中一方就會消失。而本地身處嘈雜的環(huán)境下的聽對方會更困難，對方聽自己也會有受到噪聲的干擾。

一、設(shè)置參數(shù)
在測試以前，要設(shè)置音視頻參數(shù):分辨率、碼率、和幀率。設(shè)置好音視頻參數(shù)以后，在測試過程中，參數(shù)要保持不變。
推薦使用下面兩組參數(shù)分別進行測試：

參數(shù)設(shè)置	分辨率	幀率(fps)	碼率(kbps)
Profile1	640*360	15	800
Profile2	540*960	20	1200
Profile3	1280*720	25	2000
Profile4（PC）	1920*1080	25	4000

二、測試報告的設(shè)置條件如下:

測試對象	XXX- SDK
參數(shù)設(shè)置	Profile1
測試設(shè)備	iPhone6

三、評估指標(biāo)
我們使用音視頻技術(shù)方案的三個關(guān)鍵指標(biāo)來評估其表現(xiàn)：延遲時間、流暢度、和清晰度。

延遲時間	采用客觀的評估方法。以毫秒為單位，測量單向通訊的延遲時間。
流暢度	采用主觀的評估方法，MOS 評分法，分?jǐn)?shù)范圍為 1 分至 5 分。
清晰度	采用主觀的評估方法，MOS 評分法，分?jǐn)?shù)范圍為 1 分至 5 分。

　　延遲時間比較適合采用客觀的評估方法，單位為毫秒，只需要測量單向音視頻數(shù)據(jù)流從推流 端到拉流端所耗費的時間即可。這個方法十分直觀，也廣為接受。

　　流暢度和清晰度完全是用戶體驗的主觀反饋，而且不流暢或者不清晰的技術(shù)原因有多源性的 特點，無法簡單地通過技術(shù)指標(biāo)來衡量。因此流暢度和清晰度比較適合采用主觀的評估方法， 這里推薦用 MOS 評分法來評估。

　　MOS (Mean Opinion Score)是一種在通訊工程中用來評估 QoE(Quality of Experience)的 方法。它是一個有統(tǒng)計意義的數(shù)量樣本空間的算術(shù)平均值。需要組建一個人數(shù)有統(tǒng)計意義的 測試團隊，對測試對象的質(zhì)量根據(jù)主觀體驗進行打分，分?jǐn)?shù)范圍為 1 分至 5 分，1 分最差， 5 分最好。建立打分結(jié)果的數(shù)量樣本空間以后，計算其算數(shù)平均值，就可以得到 MOS 值。

　　MOS 作為一種主觀的質(zhì)量評估方法，被廣泛的應(yīng)用于音頻、視頻、和音視頻的質(zhì)量評估中。 對于 MOS 的評分梯度和標(biāo)準(zhǔn)，ITU-T 在 P.800.1 中有詳細(xì)的方法建議。

　　MOS分采用人工評分的評估方法。主觀MOS分采用ITU-T P.800和P.830建議書，由不同的人分別對原始語料和經(jīng)過系統(tǒng)處理后有衰退的語料進行主觀感覺對比，得出MOS分，最后求平均值。
MOS值=測試視頻值+(5-視頻源值)
(例如：評分人A給測試視頻序號為1的視頻評分為3分，同時給視頻源的評分為4.5分，那么A實際最終給1號測試視頻的分值應(yīng)該是3.5分 。)
進行人工評分時打分可以打到小數(shù)點1位（例如4.6分）

為了簡單和可操作期間，下面采用 ACR(Absolute Category Rating)來為 MOS 定義評分梯度:

MOS 評分	描述
5	Excellent，十分流暢，或者十分清晰
4	Good，十分偶然有卡頓或者花屏，但不影響整體體驗。
3	Fair，偶有卡頓，或者偶有花屏/馬賽克，但是還能接受
2	Poor，卡頓，或者花屏/馬賽克出現(xiàn)的頻率較多，但是還算可用。
1	Bad，完全卡住，或者畫面不可辨，完全不可用。

　　在測試某個指標(biāo)表現(xiàn)的時候，請保持其它方面的條件不變。

四、現(xiàn)網(wǎng)測試

為純粹測試技術(shù)方案的真實表現(xiàn)，而不受其他因素干擾測試效果，因而沒有使用專線， 不加任何外部輔助，在公共互聯(lián)網(wǎng)上進行真實的測試。
建議測試區(qū)分開互聯(lián)網(wǎng)使用的低高峰時段，有些測試時段和高峰時段分別測試。
流暢度和清晰度的評估采用主觀的評估方法：MOS 評分法，最低 1 分，最高 5 分。

1. 跨運營商網(wǎng)絡(luò)測試(中國國內(nèi))
不同的運營商網(wǎng)絡(luò)之間是存在帶寬瓶頸的。本測試的目的是評估RTC服務(wù)商在跨運營商網(wǎng)絡(luò)情況下的表現(xiàn)。

跨網(wǎng)組合	延遲時間(ms)	流暢度(MOS)	清晰度(MOS)
電信-聯(lián)通
電信-移動
移動-聯(lián)通

2. 跨國網(wǎng)絡(luò)測試(全球)
在不同的國家之間的進出口光纖是存在帶寬瓶頸的。本測試的目的是評估RTC服務(wù)商在跨國跨洋網(wǎng)絡(luò)情況下的表現(xiàn)。(下圖內(nèi)容為示意數(shù)據(jù))

用戶A	用 戶 B( 國 外	國外省市	網(wǎng)絡(luò)類型	分辨率/碼 率/機型	流暢度 (MOS	延遲 (ms)
中國北京	美國	紐約
中國北京	加拿大	蒙特利爾
中國北京	阿聯(lián)酋	迪拜
中國北京	日本	東京

五、模擬測試
根據(jù)現(xiàn)網(wǎng)測試的結(jié)果和客戶運營的反饋，添加了模擬測試的設(shè)計。模擬測試是通過網(wǎng)損設(shè)備模擬各種網(wǎng)絡(luò)損傷的情形，在公司8點之前和23點之后進行測試。
1. 上行網(wǎng)絡(luò)丟包測試

上行丟包率	延遲時間(ms)	流暢度(MOS)	清晰度(MOS)
5%
10%
20%
30%
50%

2. 下行網(wǎng)絡(luò)丟包測試

下行丟包率	延遲時間(ms)	流暢度(MOS)	清晰度(MOS)
5%
10%
20%
30%
50%

3. 網(wǎng)絡(luò)抖動測試

網(wǎng)絡(luò)抖動	延遲時間(ms)	流暢度(MOS)	清晰度(MOS)
50 毫秒
100 毫秒
200 毫秒

4. 帶寬限制測試
假設(shè)當(dāng)前推流的碼率是 800k bps，對上行帶寬進行限制到 500k bps，期望的結(jié)果是RTC服務(wù)商SDK 會自動調(diào)節(jié)碼率來適應(yīng)網(wǎng)絡(luò)情況，碼率會被調(diào)整到 500kbps 或以下。

限制帶寬	碼率	延遲時間(ms)	流暢度(MOS)	清晰度(MOS)
不限制帶寬	800 kbps -2000 kbps
限制帶寬到 500k bps

5. 如何觀察延遲時間
1)登錄https://miaobiao.51240.com，即可看到以毫秒為單位計時的時鐘。這是為了 方便客戶測試，注意:時鐘頁面經(jīng)過調(diào)整，和下文截圖不完全一致。
2)具體方案舉例：準(zhǔn)備兩個 iPhone6 手機，在每個手機上都安裝demo app。然后讓兩個個手機處于 連麥狀態(tài)。在每個手機的 APP 界面上都可以看到當(dāng)前的時間。 3)使用第三個手機拍攝這兩個手機上的即構(gòu) demo app 的界面,捕捉連麥狀態(tài)下的瞬間鏡 頭，即可看到音視頻連麥雙方的 demo app 界面上的時間差距。這個時間差距就是延遲時間。

總結(jié)

以上是生活随笔為你收集整理的【音视频】专项培养-MOS评测的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。