雖然音視頻技術日趨成熟，但是不同場景對音視頻的需求有不同側重。為了將體驗做到極致，音視頻技術平臺也面臨著很大的挑戰。今天我們邀請到了即構科技邱國欽老師，為大家介紹多媒體場景中新的體驗場景面臨的挑戰，以及該如何應對這些挑戰。

文 / 邱國欽

整理 / LiveVideoStack

大家好，我是邱國欽，本次與大家分享的是“體驗共享”。首先做一下個人介紹，我大學畢業于通信專業，而后進入騰訊從事互聯網軟件、QQ相關的工作，2015年進入即構科技負責SDK研發，目前專注于整體解決方案，包括理解平臺細節、客戶需求，并從商業角度根據需求驅動研發。這是一項極具挑戰的工作，應綜合考慮到需要滿足的點，包括基本功能需求、穩定性需求、性能需求、成本需求等。有關需求的落地，具體做法就是使客戶能夠獲得收益。

本次分享包括四個方面。第一，體驗共享的含義及其與RTC技術的關系；第二，RTC服務的優化思路（優化到適配訴求及滿足各場景各種需求）；第三，RTC業務的體驗優化經驗；第四，總結與展望。

Part 01

體驗共享與RTC技術

首先介紹體驗共享的含義。

體驗共享在線下是一個自然而然的概念，舉幾個體驗共享的例子：大家在看電影時，喜劇片會一起笑，恐怖片會一起尖叫。共享體驗需要立即看到對方的反饋，感受到對方，得到精神的放松并有所收獲。第二個例子是線上教育，其實大多數人偏向線下教育，因為可以更好地互動，老師可以從學生的反應中得到信息并指導學生成長，學生之間也可以通過互動促進學習。以上例子的特征是都具有很強的互動性，大家可以看到對方的行為反應，獲得某種感受、認知，并從中得到快樂、成長和學習。

RTC技術（Real-time ）就是實時互動，是這類應用的基礎，所以RTC良好的體驗可以很大程度上影響整個APP體驗。今天介紹的是基礎RTC體驗的優化，以及如何做好線上共享體驗的APP。

Part 02

RTC服務的體驗優化思路

正式進入今天的主題。首先介紹基礎的技術——RTC服務本身的優化。

2.1 RTC體驗刻畫

我們會從哪些方面評價RTC的體驗（王老師講了第一個方面——畫質、視頻的質量）。從觀眾的角度來看，畫質和音質非常直觀，但RTC還有另外兩個維度，也是直觀的體驗：

第一個是延遲的高低，如果延遲很高就不是Real Time；

第二個是卡頓，如果卡頓較多，即便是很高的畫質，體驗感也會較差。這些所謂直觀的評價越好，付出的成本越高，基于成本之上，這三者需要做權衡。可能時延更低，但流暢性有所欠缺；或是高畫質，然而時延較高，這些都是權衡利弊的結果，要根據場景而定。

以上指標雖然直觀但很有效。比如作為一家RTC服務的供應商，客戶可以使用這些直觀的指標對供應商進行考核。如客戶可以看某個區域、某個時間段整體的時延分布、卡頓占比，而且時延、卡頓都有指標來考核服務質量。

從服務本身出發，如果要做更好的RTC服務，只考核這些指標還不夠，還要繼續探索提升整體三個維度質量的問題點，所以要看需要用哪些更細的數據提升RTC服務的水平。

2.2 RTC系統特征

實際上RTC系統還是分布式的網絡系統。比如做一個大并發，要做高可用的設計，這些都很關鍵，如果成不了并發，或是系統不可靠，服務可能無人使用。即構之前也做過高可用架構設計主題的分享。本次重點是從RTC體驗本身出發，探討哪些因素會影響到過程，以及在系統可用的情況下如何提升體驗。

首先，從數據流動的角度看。其實這個過程是采集、編碼的前處理、編碼、通過網絡發送到對端、對端收到并解碼、后處理、渲染，最終使別人聽到、看到。這是一個串聯的過程，也意味著其中某一步出現問題時，整體質量就會受到影響。

第二個是從信息生產消費的角度看。RTC是信息實時生產、實時消費的過程。它包括兩點，首先是生產消費模型，這個模型很常用，中間的一個環節總是作為上一個環節的消費者、下個環節的生產者，再將它們串起來。其次，它是實時的系統，生產的數據到對端有時效要求，過期會失效。這里會相互矛盾。剛剛提到的各個環節之間可能出現不穩定的因素，解決這個問題的手段通常是加緩沖，比如網絡傳輸容易出現不穩定，接收環節加一個Delay Jitter Buffer來對抗上游（網絡傳輸）的不穩定。緩沖就意味著引入延遲。剛才提到的時效性的要求，本質上就是和緩沖矛盾的，我們需要針對不同的系統目標來做這兩者的權衡。

另一個是不同環節可能出現生產速率的不匹配，可能有一端生產非?？?#xff0c;比如我們可以做全高清采集、編碼，但網絡無法及時傳輸這么大的碼流，這里存在生產和消費的速率不匹配。通常做法是做流控，讓消費者速率指導生產者，另一個是做分層編碼，或加入轉碼環節，輸出不同大小的碼流，讓消費者根據自身情況選擇消費。

剛剛描述的是RTC業務生產消費串行過程，結合實時性要求，這些特征可以指導我們去做系統觀測。我們需要觀測這個系統的運行情況，才能識別出它的問題把系統做好。這需要各種數據去支撐，觀測各個生產消費環節，刻畫整個過程。

2.3 RTC系統質量問題分析思路

2.3.1 全鏈路跟蹤

基于上文提出的基礎想法，剛剛是一個比較High Level的講法，我們是從生產和消費的角度去看。那么在做質量問題分析時，需要做哪些事情呢？

從即構的一些實踐出發，我在這里提出兩個點。

第一是做全鏈路的跟蹤，出發點很直接，要知道系統處于什么狀態，大部分問題可以通過分析每個環節究竟是如何運作的來得到初步想法，再基于此作推測攻關。得到數據的基本機制是事件跟蹤，這個大部分人都知道，也有許多優秀實踐。比如Linux的Ftrace就是做好事件打點、Google的Perfetto、Apple的Signpost、Windows的ETW，這一系列就是提供了工具去打點數據和后面的事件展示。當然這只是思路，即構內部有類似工具的實現。這里的基本概念是需要記錄兩類東西，第一類是所謂跨度事件——Span（開始時間、結束時間）、第二類是獨立事件（發生時間）。然后基于這一系列事件構造出從一端到另一端發生的事情，做起來很復雜，因為有很細的數據，量也很大，關聯性很難做好，因為要串系統。這些核心工作量在于整個監測點的梳理，這就深究到業務了。因為數據量大，我們需要做上報機制，要分級別，分目標做好控制。

應用上分為兩類。第一類是做性能分析的時候，我們要知道它發生了什么事情，在開發過程中需要判斷各個過程的速率是否穩定，或者是否出現設計的方案導致一端消費的不及時或者其它問題。有些情況中，問題可能沒那么明顯，比如1秒少了一幀或是10秒少了一幀，單單靠感官很難發現；第二類是耗時分析，特別是啟動耗時，一幀進去之后什么時候出來，如果是一個百毫秒級別的，串著看很難發現，還是要進行數據分析，而啟動耗時可能大家都會遇到一個問題，第一幀什么時候能夠出來是非常關鍵的。

接著是做業務分析，這是運營系統所需要的，因為我們總會遇到些問題，那么怎么做運營系統分析，打點數據從一端到另一端，這整個過程應該有個展示的東西，圖中是我們運營系統的一部分，告訴用戶從推流端到拉流端的各種數據情況。打點信息需要足夠豐富，包括設備異常、操作行為等信息，這很關鍵。

2.3.2 主動探測

接下來介紹主動探測，這是一個基本的想法。對RTC系統來說，很重要的一部分是網絡，而我們認為網絡實際上非常復雜，復雜到無法控制，只能適應，這里的適應分兩塊：第一塊是客戶端到接入的服務器這一層如何適應；第二塊是服務節點之間如何適應。

所以我們的基本思路是既然不能掌控那就探測，改變調度策略和接入措施。這里的探測就要提到主動探測。我們收集的數據是很基本的，包括RTT、丟包率、抖動（Delay Jitter）。另一塊重要的數據是實際業務傳輸數據，這里就造成很大的困難，因為量很大，需要做一套很強的系統消費它、計算出來。而且不能讓它有很高的時延，要做到實時計算。

基于此，要做一些分析，包括Bad case的分析，這是很正常的，因為整個做法上線之后總會遇到很多問題，特別是在國外，也會進行一些按區域、時間、力度劃分的各種數據分析對比。通過這些分析得到一些想法，繼而去指導系統設計的策略，當然這些東西都很細節，有時候沒有很契合的理論支撐。這都是在運營系統時必須要做的事情。

此外還會做一些大數據分析的情況，讓機器幫我們找到特征，但在探索之中，這都要和人工結合在一起，無法完全依賴機器。

主動探測方面有些細節想和大家分享，比如客戶端探測服務器，探測的行為包括客戶端探測接入點和服務節點間的相互探測。服務節點間的探測比較好做，客戶端發起的探測比較復雜，什么時機探測？是業務開始前探測，還是業務過程中持續探測、采樣探測，還是業務遇到問題了才探測？要用多大流量探測？如果流量大了，會不會影響主業務？流量小了，會不會不準確？內部的做法通常是做A/BTest，做一些選擇，得到概率性數據。

• 接入探測

接入探測就是客戶端到服務器探測的應用經驗。黑色的圖顯示的是我們在某個區域監測網絡質量的情況，以丟包率來看。最上面的線表示零丟包的情況，可以看到15：05時，零丟包率下降，掉到了接近60%，很難解釋下降的原因，所以只能適應，那么如何適應呢，我們在SDK做了探測，如果發現這時的接入出現異常，那么考慮有無更好的連接點選擇，SDK可以自主地找到更好的路。第二，SDK探測得到的信息還會用來指導服務調度策略調整，讓后續其他用戶不用重蹈覆轍。主要是兩個策略，第一個是服務器下發的指導調度，反映綜合最優，第二個是當遇到問題，調度服務吸收實時接入質量反饋，可以自動更新策略，恢復到正常水平。

圖中點雖然看起來下降很大，實際上是算法同時在補救，對業務來說、對整體上層體驗來說影響不大。做探測的目的是不能讓算法解決整件事情，算法只是應急使用，網絡才是基礎。雖然我們的傳輸控制算法能夠在70% 丟包下工作，但我們不希望我們服務一直處于極限情況運作。這也是一個很基礎的想法。

• 全球IDC探測

另外一個應用是SDN。SDN在即構RTC服務網絡中的作用非常大。首先我們的架構是混合云，圖中是我們的部分部分供應商的節點情況，包括騰訊云、阿里云、亞馬遜、微軟等，這些點是我們可以用的，那么如何管理這些點、找到足夠好的鏈路也是需要思考的，比如從一端到另一端有足夠好的RTT、足夠少的丟包、足夠穩的抖動等。

這兩張圖展示了SDN的效果。左邊的圖表達的是從深圳到香港兩個節點間直連的效果，丟包明顯，RTT很大，在170ms左右。右邊是經過了SDN后的效果，只有偶發少量丟包，并且RTT下降明顯，基本在20ms左右。

為什么深圳到香港會有這樣的問題，這其實是跨域的情況，如果不做優化，跨域調度的網絡流量會隨著運營商對成本的考慮而變化，比如到香港之前可能會先繞去日本，如何發現問題？就是要主動探測，根據實時探測的結果，找到一條綜合最優的鏈路，把數據轉發到這條路上去。這就引發一個實際問題——怎么轉發。需要在網絡層轉發？還是理解業務在應用層轉發？這兩個方法我們都試驗過，第一個在網絡層，我們認為是合適信令業務的。這種包的時效性和要求不高，所以可以在三層做轉發，攔截系統的IP包，在IP包一層的指定點做轉發。在流媒體層，三層轉發是不足夠的，流媒體層更注重時延，如果中間跨了很多層，發現丟包會經過很多層，會變慢。所以我們傾向于信令直接在網絡做，流媒體單獨在應用層部署專用應用做轉發。

Part 03

RTC業務的體驗優化經驗

系統的穩定性和性能很大程度上基于以上兩個思路進行優化。下面介紹RTC業務的體驗優化經驗。

3.1 線上教育

首先是教育場景，看起來非常普通的場景，沒有特殊的玩法，最基本的要求是保持穩定的通話。這個場景大多是付費場景，用戶付了錢，并且目的很明確，需要學到東西。任何一點阻礙他們溝通的問題都很煩人。有哪些東西比較容易出問題呢？分為兩大類：第一是設備問題，教育場景有各種各樣的設備；第二是網絡兼容問題，怎樣減少網絡抖動和音視頻卡頓。這里的設備主要是指采集設備和播放設備。如果采集失敗了，那之后的環節都沒有意義了，同樣，如果渲染失敗了，那前面的努力就白費了。

因此，需要做好廣泛的設備兼容。首先要有多套采集渲染方案，然后針對不同的設備選定合適的方案。其次，需要做好設備故障實時監控，針對異常需要能夠自動恢復。比如當前正在使用的設備被其他應用打斷了，需要有個時機恢復異常：打斷、后臺等。最終，設備兼容通常是case by case，我們會不斷兼容新的case，到這時，加上一些有云控，需要策略隨著新設備出現及時演化，比如去年出臺的SDK要兼容今年的新設備，比如iPad，它的變化比較大，那如何設置它的3A參數，就是通過這種策略來設置的。

另一個是網絡，網絡通過剛剛提到的主動探測已經解決了很大的問題，傳輸調優指的是針對教育場景的特點做好參數調節。教育場景對穩定性要求高，但是對時延沒有太特殊的要求，通常300ms是能夠滿足需求的。因此可以利用好這樣的資源減少卡頓。設置一個最低下限的Jitter Buffer的Level；另一個，通常教育可以提一個更高成本的方式，SDN可以有更大范圍的尋路，每多轉發一層就會多一份出口的流量。更大范圍的話，比如再多一跳，增加成本是否有用，用處有多大？這都是需要權衡的，如果要求系統穩定，那么多轉發一層是沒有必要的。

還有一個點是音質，音質有各種理解，包括保真、音量、底噪、回聲，這些都是特定場景下的需求。對教育場景來說音量夠大是基本需求，所以3A策略需要更激進。

這里我想強調的一點是，教育場景最核心的訴求是穩定，而穩定需要很多細節積累。

教育場景里，教具比較豐富，也有些特殊的需求，比如白板和音視頻通常不走同一個通道，并且數據行為模式也不一致，如果不特殊處理，可能出現音視頻和白板動作對不齊的情況，這個問題可以通過將時間戳埋到流中做同步來解決。錄制也需要結合教具，即構提供了一套關于錄制的方案，有各種選擇。同時，教育場景有挺多屏幕共享的操作，有不少是文字的場景，我們針對性地做了編碼優化，讓文字更銳利。

另一個需求是小班課，特別是低齡的學生，很活躍，老師們為了鼓勵學生開口說話，通常會有齊聲朗讀的場景。如果二三十個人一起說話，現場會十分混亂，基本沒有辦法聽清楚。即構去年前往開設小班課的公司體驗，發現學生們很喜歡說話，老師們雖然鼓勵孩子們說話，但并不希望他們吵鬧，所以我們做了焦點語音功能，可以凸顯老師的聲音，同時自適應協調學生的聲音，既保證了氛圍，又不至于太吵鬧。這個功能需要一些門檻和細節，比如某些學生的聲音是否應該被放出來或被抑制。功能上線后，得到了老師們的良好反饋，提升了小班課體驗。

同時教育場景的穩定需要運營工具支持，比如如何識別問題，做好一系列配套的事情。即構棱鏡就是這樣的一個平臺，用于做問題分析和數據運營，可以發現端到端中各種情況和統計類數據。

3.2 一起KTV

接著是即構一直在努力改進的場景——一起KTV。這個場景提出已經很多年了，每次提出都有新東西出現。2019年，提出了串行的方案：首先一個人演唱，將聲音傳給另一人，第二個人再將自己的聲音混進整合后傳給聽眾，這個方案比較簡單而且對網絡要求不高，市面上很多音樂平臺的落地應用已經真正在線上使用了，但即構想做的是真正的合唱，就是實現KTV中的多人合唱，這是一個很具吸引力的場景。我們在實時合唱方案上打磨已久，在近期行業內首發了多人實時在線合唱的解決方案。

下面介紹一下優化，最終效果是合唱者體驗優良，端到端感官極致低延遲，結構更適合多人合唱，對觀眾端無特殊要求。這里的主體結構分為幾個部分，下面這部分是RTC網絡，RTC網絡就是提出極致低延遲，我們做到IOS 76ms，Android 因為采集渲染的原因做到延遲111ms，Windows 92ms。這個時延是比較低的，這里指的是從采集到真正從喇叭播放出的時間，包括端到端真正的時間，不只是網絡。

基于上述兩個部分，分別介紹一下具體的操作流程。

首先要做端到端時延的壓榨，第一是分析鏈路情況，要做好事件的打點，從整個鏈路來說，包括采集、前處理、編碼、傳輸、對端解碼、后處理、渲染，這里的耳返時延是一個硬的約束，如果約束突破不了，時延有100ms或200ms，那么網絡就不可用了，因為還要疊加下面一部分編解碼和傳輸的時延。

為了應對每個環節處理的不穩定，我們會加緩存，大家傾向于多加緩存來追求穩定。如果開發者是分人開發的話，他會希望自己的模塊穩定，但這就會給整個系統引入很多時延，我們需要判斷緩存是否必須。

另一個是整個算法的時延，就是系統設計出來本身需要的時延，比如右圖是Codec引入的時延，縱軸表示時延，橫軸表示碼率。對于Opus，它的時延可以做得很低，Opus有兩類編碼方案，分別是基于時域和基于頻域的。如果是基于時域的SILK，可以將時延做到極低——5ms左右，但因為時域的基于語音模型，效果不太好，無法達到高質量。另一個基于頻域的方案，默認幀長情況下時延極限可以做到20ms左右（默認一幀20ms，Lookahead 2.5ms）。當然可以減幀長。

總結一下，首先我們要看算法時延，音頻系統一定會有算法時延，要選擇更好的算法，更好的Codec。我們還要Review整個Pipeline緩存的水平是否必要或者權衡用什么東西去降緩存。

第二個方案是基于一個前提，我們希望每個人都可以自己唱，這樣的話沒有因果關系，不需要等前一個人唱完，這里引入一段時延。那么如何做好這件事情？方案是做時鐘同步，這是很老的概念。首先要有可靠的時鐘源，一般是原子鐘、GPS，這個成本很高，但有公用服務可用；其次是同步總會存在誤差，怎么過濾壞的點、找到好的點，包括多個服務器探測，多次探測選擇好的點，同時需要注重細節，包括一些系統本身的API始終分辨率不高，本身誤差就達到十幾毫秒。

除了演唱者，還要從觀眾的角度來看。對觀眾的網絡要求不能過高，因為大部分人網絡都沒有較好的保障，那如何做好觀眾效果？觀眾效果會遇到什么問題？比如演唱者的演唱已經非常同步，但是觀眾聽到的不同步，原因包括觀眾與兩個主播的距離不同，或是某人的網絡突然抖動，總會存在一些不穩定的情況。我們的想法是在服務端將云端回流對齊，想法很基礎，通過加緩沖，用延遲換對齊，另外還要加播放的伸縮讓整個過程更平滑。

這是一個Demo，展示視頻的第一部分是19年方案的效果，主唱無法實時聽到副唱，興致減半；第二部分是我們做到的效果，猶如線下KTV的體驗共享。

即構主要希望不同端、不同地域的人在一起唱歌時都像是在KTV唱歌，內部測試在普通要求下已經可以達到KTV效果了。同時提供Demo在展臺體驗。（Demo下載地址：https://doc-zh.zego.im/scene-plan/26）

Part 04

總結和展望

以上都是基于基礎設施做的，優化方面除了功能優化，還要有基礎設施的優化包括更好的Codec、更強大的終端、VR、AR幫助方案落地。LVS也搞過線上的大會，現在疫情緩和了，大家也來參加線下的大會了。當然一方面國內對疫情的控制做得很好，另一方面還是因為線下體驗確實比線上更有吸引力，在線下能夠更自由地交流。這其實也說明了線上體驗確實還有很多值得改進的地方。如果有選擇，大家會傾向于線上參加LVS大會嗎？我相信隨著基礎設施的演進，我們在實際場景中歷練方案，不但可以將線下個各種體驗場景復刻到線上，還將演進出更多線上獨有的體驗，給大家更多的選擇，做到真正的體驗共享。希望整個行業一起努力，讓音視頻技術、RTC技術融入于生活無形。

謝謝！

The cover is from Pexels.com

總結

以上是生活随笔為你收集整理的体验共享——技术实现瓶颈与突破的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。