關於音視頻測試的一點建議

做者：羅必達，騰訊音視頻實驗室質量平臺組組長，高級工程師。早年在微軟從事移動測試開發，前後參與了 Windows Live Messenger 和 Bing Mobile 兩個項目的測試工做。2011 年加入騰訊，轉型音視頻技術研究，從事創建音視頻技術測試體系的工做，並負責 QQ 音視頻通話以及騰訊雲互動直播 SDK 的底層音視頻引擎的測試，在工做和研究中對音視頻質量評估積累了豐富的經驗。喜歡音樂和玩樂器，喜歡攝影，喜歡繪畫，是個徹徹底底的「文藝青年」。

從事音視頻相關的測試工做也有將近5年的時間了，一路看着QQ音視頻的發展，從當時只有幾我的的小團隊，到如今連續兩年公司技術突破獎金獎，回想起來確實挺激動。好吧，自戀的東西少提爲妙，進入正題。

爲何要寫這篇文章

幾年前我就想寫這麼一篇文章了，可是當時音視頻在SNG乃至公司都是一塊比較小衆、相對獨立的一個業務分支。隨着SNG對音視頻愈來愈重視，最近也有愈來愈多的團隊線下找我諮詢關於音視頻測試的一些方法，我忽然以爲，是時候把本身這幾年對音視頻測試相關的思考分享給你們了。固然也有自私的一面，由於音視頻只是一種技術，應用很是普遍，而咱們多年投身在實時音視頻通訊這其中一塊分支上，不免會對整個音視頻行業產生片面的認識，因此也想借此跟你們交流，讓咱們團隊自身能夠拓展一下知識面。

音視頻測試測的到底是什麼

我以爲這個問題很重要。不少向我諮詢音視頻測試方法的同窗，也許連這個問題都尚未想清楚（說得太直接，抱歉）。其實這不奇怪，說實話我也是最近纔開始思考這個問題。音視頻測試測的到底是什麼？

我思考這個問題的緣由是，不少同窗向我諮詢音視頻測試方法，但我卻沒辦法給出一個明確的答案。腦海裏把這5年的經驗都翻了一遍，發現都沒法找到能夠知足他們的答案。最後終於茅塞頓開，緣由是咱們都沒想清楚要測的是什麼。

上文已經提到，音視頻只是一種技術，應用面太廣，並不是但凡跟「音視頻」這幾個字眼沾上邊的均可以用一套方法去解決，也就是說，沒有「銀彈」。

首先咱們要問本身，我所負責的音視頻業務究竟要測的是什麼。是「音視頻自己」的質量，仍是「音視頻周邊」相關的東西。

這麼說有點抽象，我仍是舉些例子吧。

例如咱們這5年來一直負責的QQ音視頻通話，學術一點來講就是實時音視頻通話，由於音視頻的內容是咱們實時生成的，在傳輸過程當中，爲了保證通話的實時性，咱們還須要對音視頻的一些參數進行實時調控（例如分辨率、碼率和幀率等等），以適應複雜的網絡情況（注意網絡情況是不斷在實時變化的，以前看了不少公司內部關於網絡相關的分享，大多數創建在靜態分析上，這實際上是不正確的，固然業務不一樣，關注點不同）。因此咱們要測試的就是「音視頻的質量」。

好了，你們可能要問，還有不是測「音視頻質量」的音視頻測試嗎？有的，我再舉個例子。例如QQ空間裏可能要播一個騰訊視頻，這個視頻已經在後臺存好了，你沒辦法控制它的生成，也沒法動態對它進行調控（即便能夠調控，也是非實時調控）。在這種狀況下，你測試的並非「音視頻質量」，而是「播放質量」，也就是我剛剛所說的「音視頻周邊」相關的東西。這類測試，跟你們平時測的其餘非音視頻需求沒有太大的不一樣，惟一區別就是，可能對音視頻相關知識的一些瞭解會對你設計測試用例帶來一些幫助。

分析所測的音視頻需求

剛剛說了一大堆，無非是想告訴你們，在接到音視頻測試需求的時候，須要對其進行業務分析。我再重申一下剛剛的論點：

首先問本身，我所測試的是否是音視頻質量

在解答了這個問題後，你能夠進行業務分析了。

不一樣的業務，對音視頻的要求是不同的，相應的測試方法也不同。我這裏簡單作一些歸類：

• 實時通話類業務

例如咱們所負責的QQ音視頻，就是這類業務。這類業務對實時性的要求很高。想象一下，你在跟家人聊天，在講完一句話後，要在幾秒後才能聽到對方的反應，這是不可接受的。這就要求咱們實時地根據網絡狀況，提供不一樣質量的音視頻。例如，在鏈路帶寬突降的時候，咱們須要馬上感知到，而且儘快下降碼率，以使得通話可以順利進行（可參考網絡帶寬的水池效應，這時候若是咱們還追求所謂的清晰度、流暢度，那實際上是本末倒置的）；當帶寬恢復後，咱們還要儘快地把碼率提上來，以便用戶獲得清晰流暢的畫面和聲音。這些調整一樣須要在其餘網絡損傷中進行，例如丟包（還分隨機丟包和連續丟包）、抖動等等。

因此實時通話類業務的測試，咱們更多地把關注點放在」流控策略「上面。

• 異步通話類業務

異步通話類業務典型的表明是PTT。因爲不須要根據網絡進行實時調控（有點相似於傳文件），因此這類音視頻業務的音視頻測試相對簡單，只須要關注生成的語音音質和大小的權衡關係就好了（注意我只是說音視頻測試，其餘例如到達率等等的測試，那已經不是音視頻測試的範疇了，下面幾個分類也如此）。也就是由於這樣，這種業務的音視頻開發工做更多地是在選擇合適的CODEC以及選擇哪一個碼率（非實時選擇）更優上。這種狀況下，對用戶在音質和流量的接受程度就相當重要了，固然，這種事情我我的認爲應該產品經理來把握比較好（別跟我扯產品經理不須要技術知識）。

• 一對多的秀場類業務

這類業務最近很火，最典型的就是全民直播（例如映客、花椒等等，一抓一大把）。這類業務的特色是對延時要求不高，但對清晰度和流暢度要求很高。也正是由於延時要求不高的特色，才能夠把碼率維持在高段，來作到高分辨率和高幀率（這是實時類沒法作到的）。通常來說，技術上都以RTMP來實現。

基於以上特色，這類音視頻業務，重點就不是放在」音視頻自己」的質量上了，而是其餘體驗了，好比說美顏、美白等等跟趣味相關的前處理上，還有頻道進入的速度、切換速度等用戶體驗上。

另外必需要提一下，這類業務並不是徹底對實時性沒有要求。例如教育，在通常場景下，確實是這種一對多的業務形態，可是，一旦有老師跟學生之間的交互，那麼，保證必定的實時性也是必須的。因此，仍是得看具體的業務形態具體分析。

• 流媒體類業務

流媒體類業務是音視頻技術的一個很重要的分支。做爲常年從事通話類業務的我，或許沒有太多資格來對這一塊提建議。但由於這個部分是介紹不一樣業務的音視頻測試特色，我仍是有必要來說一下流媒體這一個分類。

流媒體類業務相對通話類業務，有一個很大的不一樣，那就是用戶之間基本上沒有音視頻層面的互動。廣義上來說秀場類業務也能夠歸爲這一類。

一樣，這類業務對實時性沒有要求，音視頻也是存儲在後臺的數據。音視頻測試在這類業務上更可能是關注編碼或者轉碼的質量。這類測試因爲可使用不少全參考的工具（如PEAQ、PEVQ等），相對來說會比較簡單，甚至開發人員本身就能夠對這一塊進行測試了。

在傳輸層面，我不太清楚如今的流媒體業務會不會根據網絡狀況來動態轉碼（好比動態轉分辨率和碼率）。若是有，那這一塊文章就大了。若是沒有，只是靜態地切換幾個已生成的分辨率，那基本上也跟音視頻測試沒太大的關係了。

這類業務離不開下面要講的另外一類業務。

• 播放類業務

我把QQ音樂和騰訊視頻這種業務的客戶端歸類到播放類上（也就是說，不考慮服務器的內容生成或轉碼部分）。這類業務剛剛提過，測試的其實不是「音視頻自己」的質量，而是播放器的質量。這類業務在傳輸方面，更多的是考慮緩存大小與實際體驗（例如流暢性）的關係。

可是這裏有一點要注意的，這類業務也並非徹底和音視頻測試毫無關係，例如QQ音樂客戶端有個音效相關的功能，這是後處理技術，也是須要必定的音視頻測試。

。。。。。。

還有不少業務類型，就不在這裏一一列舉了。

也許上面的分類不必定準確，但這不重要，重要的是想但願你們在面對音視頻相關的測試需求時，認真分析一下其特色，而後有所針對地進行測試。

須要什麼知識

不管你是否是「真的在測音視頻」，跟音視頻沾點邊的需求，都須要你具有必定的音視頻基礎知識。

固然這些知識沒有辦法在一篇文章裏面講清楚，因此僅在這裏列舉一下，你們能夠根據本身的需求去學習。

音頻知識

（基礎篇）

瞭解術語：採樣率、聲道、碼率、噪聲抑制（NS）、回聲抵消（EC）、增益控制（GC）、信噪比

瞭解CODEC：語音類CODEC、音樂類CODEC，以及他們之間的應用範圍及區別

（進階篇）

瞭解採樣定理、心理聲學模型、傅里葉變換、頻譜

視頻知識

（基礎篇）

瞭解術語：分辨率、顏色空間（RGB、YUV等）、幀率、碼率

（進階篇）

瞭解人眼視覺系統特性，瞭解視頻編碼原理，瞭解幀類型（I幀、P幀、B幀）及參考關係

網絡知識

（基礎篇）

瞭解損傷類型：丟包（連續丟包、隨機丟包；固有丟包、擁塞丟包）、延時、抖動

（進階篇）

瞭解丟包恢復策略（FEC、重傳）及其優缺點，瞭解Jitter Buffer及其影響，瞭解實時帶寬預測算法

評測知識

無參考評估、全參考評估（PESQ、POLQA、PEAQ、PSNR、SSIM、PEVQ等）、MOS

其餘

瞭解一些攝影相關的知識（例如快門、光圈、感光度），瞭解一些平臺音視頻相關的API（採集和渲染）

Q&A

這裏把一些你們之前問到，或者可能問題的一些典型問題，拋出來給你們分享一下。

Q：清晰度高指的是分辨率高嗎？

A：這個估計是不少非音視頻專業的同窗經常會搞混的兩個概念。我這裏先給出答案：分辨率確實會影響清晰度，可是二者沒有絕對的關係。爲何這麼說呢？拋開採集因素（例如攝像頭沒對焦）以外，這裏還涉及一個因素：碼率。我先假設這裏你們講的不是無損視頻，那麼必然涉及到編碼。若是編碼碼率低，就算分辨率再高，單幀質量也會因爲各類塊效應顯得很「髒」，就更不用提清晰度了。

Q：採樣率對音質有什麼影響？

A：首先要了解採樣定理，即採樣率必須高於輸入信號最高頻率的2倍，這樣才能無失真地恢復原始信號或完整地保留信息。也就是說，8kHz的採樣率只能表示0~4kHz頻率的聲音信號，而48kHz可以表示0~24kHz頻率的聲音信號。因此，若是要表示全部人耳能聽到的全部聲音（頻率範圍20~20kHz），就必須使用40kHz以上的採樣率（常見的是44.1kHz和48kHz）。固然，採樣率高了，意味着數據量就大了，編碼後的碼率也就高了。因此選擇什麼採樣率，跟你的應用對高頻的需求有多大。例如電話這種應用，目的是用於人與人的溝通，而人類的發聲範圍是100~3400Hz，因此8kHz基本上就能知足。QQ音視頻用的是16kHz採樣率，由於用戶在知足溝通之餘，還須要必定的所謂的真實感。

這個採樣定理也能夠用在視頻上，好比上面所說的分辨率，實際上就是空間採樣率，分辨率越高，可以表示的空間頻率越大，也就是說能夠表示更加複雜的紋理，因此通常狀況下清晰度也就上去了。

Q：碼率能再低些嗎？

A：這是我最常常被問到的問題，特別是以前在跟手Q基礎側PK音視頻流量的時候。這個問題其實很差回答，由於這裏涉及到質量與碼率的權衡關係。在相同的CODEC狀況下，碼率對質量的影響最大，下降碼率，意味着就損失質量，而音視頻質量卻又是一個很是主觀的東西。你很難證實目前的質量是否能夠再降。所以QQ音視頻只能在移動網絡這種流量敏感的網絡類型中，提供比wifi及有線網絡質量稍差的體驗，以減小流量的消耗。可是依然會被問，還能再低些嗎？這個問題沒有答案。

Q：我看大家的文檔裏常常有提到主觀測試，有更高效的方法嗎？

A：首先，我要強調一點，若是你是作音視頻測試，必定不能排斥主觀測試，哪怕效率低下。這是由於音視頻質量原本就是一個很主觀的東西。我舉個例子，在可用帶寬極低的狀況下，QQ音視頻能用的碼率有限，在視頻中，必然涉及清晰度和流暢度的權衡。若是這時你問不一樣的人，是但願保證清晰度仍是流暢度，你確定會獲得不一樣的答案。ITU對主觀測試有一些規範，也就是咱們常常聽到的MOS評分，這是最準確的測試方法。

可是主觀測試確實很影響效率，這個毋庸置疑，因此業內也有不少人在研究客觀評測的方法，例如PESQ等等，目的是使得這些工具評測的結果更加符合主觀。

再來舉個咱們常常提到的一個悖論的例子。咱們來講一下回聲抵消的測試。目前咱們回聲抵消只有主觀測試的方法，爲何呢？回聲抵消算法的關鍵是區分一段語音近端信號和遠端回聲，而後進行消除。咱們要測試回聲抵消的效果，那麼就須要一個判斷回聲是否被消除乾淨的算法或工具，咦，這不就是在作回聲抵消嗎？若是個人算法沒有開發的算法好，那我確定檢查不出來是否有回聲，若是算法比開發的好，那爲啥開發不直接把個人算法用在回聲抵消中呢？

Q：可否告訴我你的測試結果到底是pass仍是fail？

A：能，也不能。音視頻質量的測試歷來就不僅有0和1的結果。音視頻質量每每是在給定資源狀況下的一種權衡結果（參考上面講到的清晰度與流暢度）。因此這裏要明確你的目標是什麼，但這個目標不必定是「正確」的。若是拿捏不許本身的產品音視頻質量是否已經達到最優，經過競品對比分析也是一種頗有效的解決方法，這也是不少產品在作性能優化時採用的手段

結語

好了，先寫到這了。歡迎你們找我交流，也但願經過這篇文章，可讓你們瞭解到咱們這個組平時都在作些什麼東西

歡迎各位打擾。