本文內容由「微信多媒體團隊」整理髮布。php
廣州TIT創意園,這裏是騰訊在廣州的研發團隊所在地,LiveVideoStack採訪了微信多媒體內核中心音視頻算法高級工程師梁俊斌(Denny)。從華爲2012實驗室到騰訊,過去十餘年梁俊斌一直專一在音頻技術。他告訴LiveVideoStack:音頻技術還有許多難點須要解決,而做爲技術人也延展到應用場景,關注用戶需求。本文整理了本次訪談的主要內容,僅供參閱。html
學習交流:程序員
- 即時通信開發交流3羣:185926912[推薦]算法
- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM》數據庫
(本文同步發佈於:http://www.52im.net/thread-1828-1-1.html)小程序
《微信團隊分享:視頻圖像的超分辨率技術原理和應用場景》微信小程序
《微信團隊分享:微信每日億次實時音視頻聊天背後的技術解密》緩存
《微信團隊分享:微信Android版小視頻編碼填過的那些坑》 安全
《微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等》服務器
梁俊斌:如今是2018年,二十年前(1998年)我考進華南理工大學,直到2007年這9年都在華南理工大學完成個人本科、碩士、博士的學業,期間跨越了好幾個不一樣的學科和技術領域,包括機械、電子、自動化、人工智能,這些不一樣的學科跨度仍是蠻大的,和其餘的音頻同行有不一樣,他們一開始在學校就專攻音視頻多媒體、編解碼算法。我在大學期間,在音視頻領域是沒有較多的積累,只是基本瞭解一點,實際接觸很少。
2007年,從華南理工大學畢業以後加入了華爲公司,進入了「2012實驗室」多媒體工程能力中心,在這裏我開始踏入語音頻領域,並今後鎖定了本身的職業道路方向,到如今我還在持續作語音相關的技術。期間有過一些其餘部門的同事邀請我轉行,但我拒絕了,我堅信要作本身認爲正確的事情,就必須破釜沉舟把它作深作透。音頻這個行業還有不少很不成熟的東西,可能從外界普通用戶的角度來講,咱們這塊已經很成熟了,沒什麼可作的,但實際上(語音)還有不少還沒有解決的難題,須要有人來作。
後來我進入了騰訊公司,加入了微信團隊。微信給我最大的觸動就是全部人都在用,這種空前的成就感是不言而喻的,全部的親戚朋友都在用,要是本身作很差的話,尤爲是語音通話、語音消息天天都在用,哪天不當心出點Bug,就會影響到不少不少身邊的人,因此在享受微信工做帶來的知足感的同時作技術每一個環節都要求很是嚴謹。
華爲最爲神祕的「2012實驗室」(聽說研究的都是各類黑科技):
華爲的「2012實驗室」是華爲的總研究組織,據稱,該實驗室的名字來自於任正非在觀看《2012》電影后的暢想,他認爲將來信息爆炸會像數字洪水同樣,華爲要想在將來生存發展就得構造本身的「諾亞方舟」。
華爲2012實驗室的主要研究的方向有新一代通訊、雲計算、音頻視頻分析、數據挖掘、機器學習等。主要面向的是將來5-10年的發展方向。華爲官方數據顯示,2015年,華爲研發投入爲596億元人民幣,佔2015年銷售收入的15.1%,近十年來,華爲已經在研發方面投入了超過2400億元人民幣。
2012實驗室的二級部門包括:中央硬件工程學院、海思、研發能力中心、中央軟件院。今天着重講述華爲不多對外公開,但在2012實驗室裏有着極高戰略地位的研究部門。
梁俊斌:語音通話是兩個或多我的在不一樣的地點經過手機或者說其餘終端完成對話的過程,這裏涉及到通話的外界聲學環境因素,包括噪聲、回聲,混響,全部這些環境因素都會影響對方的收聽效果,而不一樣場景環境下問題現象差別較大,如何有效解決這是一個方面。
第二方面,微信是一個超十億級用戶的APP,其中的音視頻通話功能是最基礎的,咱們天天都有幾億人在使用這個功能,這裏涉及成千上萬款不一樣廠家不一樣型號的手機(固然還有PC、Mac等設備),其不一樣硬件有不一樣的聲學特性,例如頻響、不一樣設備的內置硬件處理後的噪聲、雜音等,也有操做系統非實時性的問題,還有各類APP的音頻資源衝突等各類情況,咱們都須要作相應的適配和有針對性的優化。
另外,網絡傳輸可靠性是很是關鍵的部分,網絡傳輸存在丟包、抖動、時延等問題,網絡越複雜問題更多。語音包到達對方終端後解碼、播放。聲音傳入耳朵的過程是心理聲學感知的過程,你能不能感知的到對方傳遞的聲音信息,信息是否乾淨且易懂。聲音傳遞到大腦,其中的關鍵信息是否讓你有深入印象仍是聽了就忘沒有痕跡,這些都是很值得研究的課題。而咱們微信技術架構部多媒體內核中心自主研發的WAVE(微信音視頻引擎)組件正是圍繞上述問題不斷迭代、持續改進優化,構建高可用性的互聯網音視頻通話技術基石。
行外人不瞭解這些細節問題,因此才以爲沒什麼可作的,然而這個細節問題是必須有人作的,並且須要長期的一絲不苟的投入。作一個能通話的APP不難,但作一個超十億級用戶都承認的通話功能是不簡單的。
梁俊斌:是的,這是一個系統工程,而不只是一個安裝在手機上的應用軟件,須要涉及通話雙方端到端一環扣一環的質量監控和故障應對體系。咱們天天都會積極蒐集用戶的反饋信息,深刻具體case去分析通話問題的緣由,盡咱們所能幫助用戶解決問題。
此外咱們擁有功能強大的後臺運維繫統,該系統能實時對大盤通話質量作端到端的分析,對異常狀況會及時報警,保障通話功能的正常使用。雖然微信通話是免費的,但咱們身上的責任是巨大的,咱們微信技術架構部多媒體內核中心每一個同事天天都在爲提高改進用戶音視頻通話體驗而不斷努力。
梁俊斌:是的,互聯網是相對不可靠的,在WAVE引擎裏面提供了適配不一樣網絡傳輸特性的抗丟包、抗抖動算法和機制,讓通話過程語音更順暢。
心理聲學是研究物理聲學與人類聽覺感知之間關係的一門邊緣學科,心理聲學其中一個基本特性就是掩蔽特性,其又分爲時域效應和頻域效應,這裏咱們側重在頻域上的掩蔽效應,常規狀況下相鄰頻帶能量強的會屏蔽掉能量弱的頻帶,在通話應用中,例如降噪算法,咱們會經過下降噪聲頻點能量至掩蔽值如下來下降噪聲對人耳感知的干擾,同時減小對正常語音的損傷。
除此之外,心理聲學還應用到不少技術點上,這裏就不一一細說了。
梁俊斌:部分手機在耳機模式下因爲聲屏蔽設計因此基本沒有回聲,但也有些手機在耳機模式下仍是有可能產生回聲的,多是電耦合的電學回聲,由於這裏耳機產生的回聲的線性度比較高,相對聲學回聲的非線性度高而言是比較容易經過AEC抵消抑制的,因此常規狀況下你經過耳機接聽基本沒有回聲問題。
什麼是AEC?
AEC是回聲消除器(Acoustic Echo Canceller)技術的簡稱, AEC是對揚聲器信號與由它產生的多路徑回聲的相關性爲基礎,創建遠端信號的語音模型,利用它對回聲進行估計,並不斷地修改濾波器的係數,使得估計值更加逼近真實的回聲。而後,將回聲估計值從話筒的輸入信號中減去,從而達到消除回聲的目的,AEC還將話筒的輸入與揚聲器過去的值相比較,從而消除延長延遲的屢次反射的聲學回聲。根椐存儲器存放的過去的揚聲器的輸出值的多少,AEC能夠消除各類延遲的回聲。
梁俊斌:從5G的設計目標是高帶寬低時延,但目前還沒真正商用,對此我仍是有點保留的,由於頻率越高傳輸的距離越有限,網絡覆蓋應該更小,最終的網絡質量還要跟基站建設密度相關,要是作得很差的話,對咱們音視頻通話是一個挑戰。因爲純語音通話自己所佔帶寬有限,5G的影響相對來講還不是很大,對於視頻通話體驗應該是有提高的,固然帶寬越大、時延越低,咱們能夠作得技術能夠更多。
另外通話雙方使用的若是是不一樣網絡或者不一樣運營商網絡,如何適配和確保數據的鏈接的可靠性,正確性、低時延,這些是比較重要的。
關於移動弱網的文章,能夠讀一讀如下幾篇:
《現代移動端網絡短鏈接的優化手段總結:請求速度、弱網適應、安全保障》
梁俊斌:剛纔提到「孤獨」這個詞很準確,爲何呢?搞技術的人就必須習慣孤獨,享受埋頭鑽研的「孤獨」帶來的愉悅,技術人常常面對挫折而無助的局面,每一次失敗的嘗試讓咱們感覺到了冰冷的絕望,但心裏的光明指引着咱們砥礪前行。
爲何選擇音頻?剛開始接觸音頻的時候,我以爲音頻技術可操做性很強。相對於之前在學校裏面作的不少底層芯片相關的項目,DSP、ARM、MCU、FPGA等,須要藉助別人的專用平臺,在別人提供的最小系統板上或本身設計的PCB上開發,硬件制(電路)板週期長。若是工廠制板工藝環節出現什麼問題,例如PCB層間有金屬絲殘留致使短路或不穩定情況,返工還要考慮外面制板工廠的工期以及芯片供貨週期,有時候芯片要從國外申購就要等好幾周的時間。
而作音頻則方便多了,很簡單,只要你有一臺PC或者手機,你就能錄音,你就能作處理,你就能立刻聽到本身作的東西的效果,整個過程徹底能夠本身掌控。並且在華爲、騰訊公司可以提供至關不錯的大平臺和優越環境,讓我能夠沉下心來搞音頻,因此我就一直堅持下來了。
梁俊斌:(搞多媒體開發)就是要不斷的積累,積澱越深厚才能看得更高更遠。
那時候我在華爲作了幾年的管理以後反思,由於在大公司裏面作管理,大部分時間都是被支配的,沒有太多的時間能夠專心作本身想作的事情。後來本身就作了決定,仍是全身心投入到技術研發,作本身想作的事情,這個是最理想的狀態。
梁俊斌:我在學校的時候就開始接觸AI的理論和算法,例如神經網絡、無監督學習和有監督學習等,那時候的機器比如今差太遠了,更沒有適合並行運算的GPU,跑不了很複雜的東西,耗時很長,並且沒有如今那麼開放的數據庫可供訓練,因此當時的AI理論技術沒能獲得長足發展,也沒有成功的實際應用。回到如今,過了那麼多年後,之前冷門的技術如今變成熱門了。如今AI和語音結合得比較緊密,語音識別、聲紋識別、語音合成、AI降噪等等,但處理及存儲的開銷、時延問題,以及AI算法在實際運行中如何作到可觀可控等問題還有待進一步解決。
你提到音頻這一塊是否是愈來愈小衆了?當下看到的感受是愈來愈小,但咱們要看將來(的應用)。
目前咱們只是作了單聲道、雙聲道的通話應用,將來必然是沉浸式的虛擬現實音視頻體驗,隨着傳感器工藝升級,設備體積進一步微型化,網絡管道的海量帶寬支持,將來咱們將能夠很是自由的體驗與現實世界無異的虛擬現實世界,這裏運用到的3D立體音頻動態建模,實際環境聲場與虛擬聲場的融合交互技術。
另外,隨着便攜傳感器的普及,AI對我的和羣體的數據分析,AI會比咱們本身更瞭解本身,例如AI根據外界環境情況、我的喜愛、當前身體的各項檢測指標判別你當下的情緒和心理情況,能夠爲你提供更適合當前我的心情、場景環境的音樂,讓你身心更愉悅或者讓你的情緒獲得更有效的宣泄。如今也有一些主動降噪的音效設備,放在牀邊,可以主動抑制你的打鼾的聲音,讓你和家人可以睡得更好,這些都是音頻技術能夠看到的將來。
不要侷限在本身所作的事情,技術能夠在不一樣的應用場景上得以延展,不一樣應用場景反過來決定了須要什麼樣的技術,什麼樣的算法。因此我並不以爲咱們沒什麼事情可作了,只有咱們沒有把場景和用戶需求理解到位,這反而是咱們擔憂的。假若咱們對用戶需求都不理解,對使用場景不理解,那咱們確實沒什麼可作的。若是咱們搞清楚了用戶的應用場景,咱們才能開發出相應的技術,並告知用戶這個技術特性是你所須要的。因此要吃透分析用戶場景和需求,確定會有不少事情須要咱們作的。
梁俊斌:通常人只有兩個耳朵,若是播放單聲道音源的時候,你能夠理解人只用了一個耳朵,由於他兩個耳朵聽到的東西是徹底同樣的。
人在聽單聲道的信號的時候,單個耳朵就能抽取出本身感興趣的內容,而忽略干擾信號的部分,這就是雞尾酒會效應,即在一個很繁雜的環境里人都能快速捕獲本身想聽的內容。
相比之下,咱們目前還須要藉助多個麥克風組成陣列,經過陣列算法來加強某個方向的信號衰弱其它方向的信號,若是須要角度分辨度更高,或者立體空間某個角落的聲音信號則須要更加多的麥克風和更復雜的陣列布局。
因此這個領域的研究就頗有趣了,單我的耳完勝咱們目前商用的麥克風陣列。不少大牛都在研究這個,尚未徹底攻克,若是這個問題解決了,那普通手機只須要一個麥克風就能夠實現人耳相近的效果了。
什麼是麥克風陣列?
麥克風陣列(Microphone Array),從字面上,指的是麥克風的排列。也就是說由必定數目的聲學傳感器(通常是麥克風)組成,用來對聲場的空間特性進行採樣並處理的系統。採用該技術,能利用兩個麥克風接收到聲波的相位之間的差別對聲波進行過濾,能最大限度將環境背景聲音清除掉,只剩下須要的聲波。對於在嘈雜的環境下采用這種配置的設備,能使聽者聽起來很清晰,無雜音。
[1] 開源實時音視頻技術WebRTC的文章:
《訪談WebRTC標準之父:WebRTC的過去、如今和將來》
《良心分享:WebRTC 零基礎開發者教程(中文)[附件下載]》
《新手入門:到底什麼是WebRTC服務器,以及它是如何聯接通話的?》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基於開源WebRTC開發實時音視頻靠譜嗎?第3方SDK有哪些?》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC:看起來很美,但離生產應用還有多少坑要填?》
《了不得的WebRTC:生態日趨完善,或將實時音視頻技術白菜化》
>> 更多同類文章 ……
[2] 實時音視頻開發的其它精華資料:
《即時通信音視頻開發(五):認識主流視頻編碼技術H.264》
《即時通信音視頻開發(九):實時語音通信的迴音及迴音消除概述》
《即時通信音視頻開發(十):實時語音通信的迴音消除技術詳解》
《即時通信音視頻開發(十一):實時語音通信丟包補償技術詳解》
《即時通信音視頻開發(十三):實時視頻編碼H.264的特色與優點》
《即時通信音視頻開發(十五):聊聊P2P與實時音視頻的應用狀況》
《即時通信音視頻開發(十六):移動端實時音視頻開發的幾個建議》
《即時通信音視頻開發(十七):視頻編碼H.26四、VP8的前世此生》
《學習RFC3550:RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究(論文全文)》
《還在靠「喂喂喂」測試實時語音通話質量?本文教你科學的評測方法!》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《技術揭祕:支持百萬級粉絲互動的Facebook實時視頻直播》
《理論聯繫實際:實現一個簡單地基於HTML5的實時視頻直播》
《首次披露:快手是如何作到百萬觀衆同場看直播仍能秒開且不卡頓的?》
《騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天》
《七牛雲技術分享:使用QUIC協議實現實時視頻直播0卡頓!》
《實時視頻直播客戶端技術盤點:Native、HTML五、WebRTC、微信小程序》
《微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等》
>> 更多同類文章 ……
《騰訊技術分享:騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享:Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享:iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享:iOS版微信是如何防止特殊字符致使的炸羣、APP崩潰的?》
《騰訊技術分享:Android手Q的線程死鎖監控系統技術實踐》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)》
《騰訊團隊分享 :一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享:微信Android版小視頻編碼填過的那些坑》
《微信團隊披露:微信界面卡死超級bug「15。。。。」的前因後果》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《微信客戶端團隊負責人技術訪談:如何着手客戶端性能監控和優化》
《微信團隊原創分享:Android版微信的臃腫之困與模塊化實踐之路》
《微信團隊原創分享:微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一):如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)》
《騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(上篇)》
《如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫:單機千萬鏈接、支撐微信8億用戶的後臺框架基石 [源碼下載]》
《微信新一代通訊安全解決方案:基於TLS1.3的MMTLS詳解》
《微信團隊原創分享:Android版微信後臺保活實戰分享(進程保活篇)》
《微信團隊原創分享:Android版微信後臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享:Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構:微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量用戶背後的後臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐:8億月活、單機千萬鏈接背後的後臺解決方案》
《架構之道:3個程序員成就微信朋友圈日均10億發佈量[有視頻]》
《微信團隊原創分享:Android內存泄漏監控和優化技巧總結》
《微信團隊原創Android資源混淆工具:AndResGuard [有源碼]》
《移動端IM實踐:Android版微信如何大幅提高交互性能(一)》
《移動端IM實踐:Android版微信如何大幅提高交互性能(二)》
《移動端IM實踐:WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)》
《信鴿團隊原創:一塊兒走過 iOS10 上消息推送(APNS)的坑》
《騰訊TEG團隊原創:基於MySQL的分佈式數據庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等》
《瞭解iOS消息推送一文就夠:史上最全iOS Push技術詳解》
《騰訊資深架構師乾貨總結:一文讀懂大型分佈式系統設計的方方面面》
>> 更多同類文章 ……
(本文同步發佈於:http://www.52im.net/thread-1828-1-1.html)