雖然音視頻技術(shù)日趨成熟，但是不同場(chǎng)景對(duì)音視頻的需求有不同側(cè)重。為了將體驗(yàn)做到極致，音視頻技術(shù)平臺(tái)也面臨著很大的挑戰(zhàn)。今天我們邀請(qǐng)到了即構(gòu)科技邱國(guó)欽老師，為大家介紹多媒體場(chǎng)景中新的體驗(yàn)場(chǎng)景面臨的挑戰(zhàn)，以及該如何應(yīng)對(duì)這些挑戰(zhàn)。

大家好，我是邱國(guó)欽，本次與大家分享的是“體驗(yàn)共享”。首先做一下個(gè)人介紹，我大學(xué)畢業(yè)于通信專業(yè)，而后進(jìn)入騰訊從事互聯(lián)網(wǎng)軟件、QQ相關(guān)的工作，2015年進(jìn)入即構(gòu)科技負(fù)責(zé)SDK研發(fā)，目前專注于整體解決方案，包括理解平臺(tái)細(xì)節(jié)、客戶需求，并從商業(yè)角度根據(jù)需求驅(qū)動(dòng)研發(fā)。這是一項(xiàng)極具挑戰(zhàn)的工作，應(yīng)綜合考慮到需要滿足的點(diǎn)，包括基本功能需求、穩(wěn)定性需求、性能需求、成本需求等。有關(guān)需求的落地，具體做法就是使客戶能夠獲得收益。

本次分享包括四個(gè)方面。第一，體驗(yàn)共享的含義及其與RTC技術(shù)的關(guān)系；第二，RTC服務(wù)的優(yōu)化思路（優(yōu)化到適配訴求及滿足各場(chǎng)景各種需求）；第三，RTC業(yè)務(wù)的體驗(yàn)優(yōu)化經(jīng)驗(yàn)；第四，總結(jié)與展望。

Part 01

體驗(yàn)共享與RTC技術(shù)

首先介紹體驗(yàn)共享的含義。

體驗(yàn)共享在線下是一個(gè)自然而然的概念，舉幾個(gè)體驗(yàn)共享的例子：大家在看電影時(shí)，喜劇片會(huì)一起笑，恐怖片會(huì)一起尖叫。共享體驗(yàn)需要立即看到對(duì)方的反饋，感受到對(duì)方，得到精神的放松并有所收獲。第二個(gè)例子是線上教育，其實(shí)大多數(shù)人偏向線下教育，因?yàn)榭梢愿玫鼗?dòng)，老師可以從學(xué)生的反應(yīng)中得到信息并指導(dǎo)學(xué)生成長(zhǎng)，學(xué)生之間也可以通過(guò)互動(dòng)促進(jìn)學(xué)習(xí)。以上例子的特征是都具有很強(qiáng)的互動(dòng)性，大家可以看到對(duì)方的行為反應(yīng)，獲得某種感受、認(rèn)知，并從中得到快樂(lè)、成長(zhǎng)和學(xué)習(xí)。

RTC技術(shù)（Real-time ）就是實(shí)時(shí)互動(dòng)，是這類應(yīng)用的基礎(chǔ)，所以RTC良好的體驗(yàn)可以很大程度上影響整個(gè)APP體驗(yàn)。今天介紹的是基礎(chǔ)RTC體驗(yàn)的優(yōu)化，以及如何做好線上共享體驗(yàn)的APP。

Part 02

RTC服務(wù)的體驗(yàn)優(yōu)化思路

正式進(jìn)入今天的主題。首先介紹基礎(chǔ)的技術(shù)——RTC服務(wù)本身的優(yōu)化。

2.1 RTC體驗(yàn)刻畫

我們會(huì)從哪些方面評(píng)價(jià)RTC的體驗(yàn)（王老師講了第一個(gè)方面——畫質(zhì)、視頻的質(zhì)量）。從觀眾的角度來(lái)看，畫質(zhì)和音質(zhì)非常直觀，但RTC還有另外兩個(gè)維度，也是直觀的體驗(yàn)：

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

第二個(gè)是卡頓，如果卡頓較多，即便是很高的畫質(zhì)，體驗(yàn)感也會(huì)較差。這些所謂直觀的評(píng)價(jià)越好，付出的成本越高，基于成本之上，這三者需要做權(quán)衡?？赡軙r(shí)延更低，但流暢性有所欠缺；或是高畫質(zhì)，然而時(shí)延較高，這些都是權(quán)衡利弊的結(jié)果，要根據(jù)場(chǎng)景而定。

以上指標(biāo)雖然直觀但很有效。比如作為一家RTC服務(wù)的供應(yīng)商，客戶可以使用這些直觀的指標(biāo)對(duì)供應(yīng)商進(jìn)行考核。如客戶可以看某個(gè)區(qū)域、某個(gè)時(shí)間段整體的時(shí)延分布、卡頓占比，而且時(shí)延、卡頓都有指標(biāo)來(lái)考核服務(wù)質(zhì)量。

從服務(wù)本身出發(fā)，如果要做更好的RTC服務(wù)，只考核這些指標(biāo)還不夠，還要繼續(xù)探索提升整體三個(gè)維度質(zhì)量的問(wèn)題點(diǎn)，所以要看需要用哪些更細(xì)的數(shù)據(jù)提升RTC服務(wù)的水平。

2.2 RTC系統(tǒng)特征

實(shí)際上RTC系統(tǒng)還是分布式的網(wǎng)絡(luò)系統(tǒng)。比如做一個(gè)大并發(fā)，要做高可用的設(shè)計(jì)，這些都很關(guān)鍵，如果成不了并發(fā)，或是系統(tǒng)不可靠，服務(wù)可能無(wú)人使用。即構(gòu)之前也做過(guò)高可用架構(gòu)設(shè)計(jì)主題的分享。本次重點(diǎn)是從RTC體驗(yàn)本身出發(fā)，探討哪些因素會(huì)影響到過(guò)程，以及在系統(tǒng)可用的情況下如何提升體驗(yàn)。

首先，從數(shù)據(jù)流動(dòng)的角度看。其實(shí)這個(gè)過(guò)程是采集、編碼的前處理、編碼、通過(guò)網(wǎng)絡(luò)發(fā)送到對(duì)端、對(duì)端收到并解碼、后處理、渲染，最終使別人聽到、看到。這是一個(gè)串聯(lián)的過(guò)程，也意味著其中某一步出現(xiàn)問(wèn)題時(shí)，整體質(zhì)量就會(huì)受到影響。

第二個(gè)是從信息生產(chǎn)消費(fèi)的角度看。RTC是信息實(shí)時(shí)生產(chǎn)、實(shí)時(shí)消費(fèi)的過(guò)程。它包括兩點(diǎn)，首先是生產(chǎn)消費(fèi)模型，這個(gè)模型很常用，中間的一個(gè)環(huán)節(jié)總是作為上一個(gè)環(huán)節(jié)的消費(fèi)者、下個(gè)環(huán)節(jié)的生產(chǎn)者，再將它們串起來(lái)。其次，它是實(shí)時(shí)的系統(tǒng)，生產(chǎn)的數(shù)據(jù)到對(duì)端有時(shí)效要求，過(guò)期會(huì)失效。這里會(huì)相互矛盾。剛剛提到的各個(gè)環(huán)節(jié)之間可能出現(xiàn)不穩(wěn)定的因素，解決這個(gè)問(wèn)題的手段通常是加緩沖，比如網(wǎng)絡(luò)傳輸容易出現(xiàn)不穩(wěn)定，接收環(huán)節(jié)加一個(gè)Delay Jitter Buffer來(lái)對(duì)抗上游（網(wǎng)絡(luò)傳輸）的不穩(wěn)定。緩沖就意味著引入延遲。剛才提到的時(shí)效性的要求，本質(zhì)上就是和緩沖矛盾的，我們需要針對(duì)不同的系統(tǒng)目標(biāo)來(lái)做這兩者的權(quán)衡。

另一個(gè)是不同環(huán)節(jié)可能出現(xiàn)生產(chǎn)速率的不匹配，可能有一端生產(chǎn)非?？欤热缥覀兛梢宰鋈咔宀杉?、編碼，但網(wǎng)絡(luò)無(wú)法及時(shí)傳輸這么大的碼流，這里存在生產(chǎn)和消費(fèi)的速率不匹配。通常做法是做流控，讓消費(fèi)者速率指導(dǎo)生產(chǎn)者，另一個(gè)是做分層編碼，或加入轉(zhuǎn)碼環(huán)節(jié)，輸出不同大小的碼流，讓消費(fèi)者根據(jù)自身情況選擇消費(fèi)。

剛剛描述的是RTC業(yè)務(wù)生產(chǎn)消費(fèi)串行過(guò)程，結(jié)合實(shí)時(shí)性要求，這些特征可以指導(dǎo)我們?nèi)プ鱿到y(tǒng)觀測(cè)。我們需要觀測(cè)這個(gè)系統(tǒng)的運(yùn)行情況，才能識(shí)別出它的問(wèn)題把系統(tǒng)做好。這需要各種數(shù)據(jù)去支撐，觀測(cè)各個(gè)生產(chǎn)消費(fèi)環(huán)節(jié)，刻畫整個(gè)過(guò)程。

2.3 RTC系統(tǒng)質(zhì)量問(wèn)題分析思路

2.3.1 全鏈路跟蹤

基于上文提出的基礎(chǔ)想法，剛剛是一個(gè)比較High Level的講法，我們是從生產(chǎn)和消費(fèi)的角度去看。那么在做質(zhì)量問(wèn)題分析時(shí)，需要做哪些事情呢？

從即構(gòu)的一些實(shí)踐出發(fā)，我在這里提出兩個(gè)點(diǎn)。

第一是做全鏈路的跟蹤，出發(fā)點(diǎn)很直接，要知道系統(tǒng)處于什么狀態(tài)，大部分問(wèn)題可以通過(guò)分析每個(gè)環(huán)節(jié)究竟是如何運(yùn)作的來(lái)得到初步想法，再基于此作推測(cè)攻關(guān)。得到數(shù)據(jù)的基本機(jī)制是事件跟蹤，這個(gè)大部分人都知道，也有許多優(yōu)秀實(shí)踐。比如Linux的Ftrace就是做好事件打點(diǎn)、Google的Perfetto、Apple的Signpost、Windows的ETW，這一系列就是提供了工具去打點(diǎn)數(shù)據(jù)和后面的事件展示。當(dāng)然這只是思路，即構(gòu)內(nèi)部有類似工具的實(shí)現(xiàn)。這里的基本概念是需要記錄兩類東西，第一類是所謂跨度事件——Span（開始時(shí)間、結(jié)束時(shí)間）、第二類是獨(dú)立事件（發(fā)生時(shí)間）。然后基于這一系列事件構(gòu)造出從一端到另一端發(fā)生的事情，做起來(lái)很復(fù)雜，因?yàn)橛泻芗?xì)的數(shù)據(jù)，量也很大，關(guān)聯(lián)性很難做好，因?yàn)橐到y(tǒng)。這些核心工作量在于整個(gè)監(jiān)測(cè)點(diǎn)的梳理，這就深究到業(yè)務(wù)了。因?yàn)閿?shù)據(jù)量大，我們需要做上報(bào)機(jī)制，要分級(jí)別，分目標(biāo)做好控制。

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

接著是做業(yè)務(wù)分析，這是運(yùn)營(yíng)系統(tǒng)所需要的，因?yàn)槲覀兛倳?huì)遇到些問(wèn)題，那么怎么做運(yùn)營(yíng)系統(tǒng)分析，打點(diǎn)數(shù)據(jù)從一端到另一端，這整個(gè)過(guò)程應(yīng)該有個(gè)展示的東西，圖中是我們運(yùn)營(yíng)系統(tǒng)的一部分，告訴用戶從推流端到拉流端的各種數(shù)據(jù)情況。打點(diǎn)信息需要足夠豐富，包括設(shè)備異常、操作行為等信息，這很關(guān)鍵。

2.3.2 主動(dòng)探測(cè)

接下來(lái)介紹主動(dòng)探測(cè)，這是一個(gè)基本的想法。對(duì)RTC系統(tǒng)來(lái)說(shuō)，很重要的一部分是網(wǎng)絡(luò)，而我們認(rèn)為網(wǎng)絡(luò)實(shí)際上非常復(fù)雜，復(fù)雜到無(wú)法控制，只能適應(yīng)，這里的適應(yīng)分兩塊：第一塊是客戶端到接入的服務(wù)器這一層如何適應(yīng)；第二塊是服務(wù)節(jié)點(diǎn)之間如何適應(yīng)。

所以我們的基本思路是既然不能掌控那就探測(cè)，改變調(diào)度策略和接入措施。這里的探測(cè)就要提到主動(dòng)探測(cè)。我們收集的數(shù)據(jù)是很基本的，包括RTT、丟包率、抖動(dòng)（Delay Jitter）。另一塊重要的數(shù)據(jù)是實(shí)際業(yè)務(wù)傳輸數(shù)據(jù)，這里就造成很大的困難，因?yàn)榱亢艽?，需要做一套很?qiáng)的系統(tǒng)消費(fèi)它、計(jì)算出來(lái)。而且不能讓它有很高的時(shí)延，要做到實(shí)時(shí)計(jì)算。

基于此，要做一些分析，包括Bad case的分析，這是很正常的，因?yàn)檎麄€(gè)做法上線之后總會(huì)遇到很多問(wèn)題，特別是在國(guó)外，也會(huì)進(jìn)行一些按區(qū)域、時(shí)間、力度劃分的各種數(shù)據(jù)分析對(duì)比。通過(guò)這些分析得到一些想法，繼而去指導(dǎo)系統(tǒng)設(shè)計(jì)的策略，當(dāng)然這些東西都很細(xì)節(jié)，有時(shí)候沒(méi)有很契合的理論支撐。這都是在運(yùn)營(yíng)系統(tǒng)時(shí)必須要做的事情。

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

主動(dòng)探測(cè)方面有些細(xì)節(jié)想和大家分享，比如客戶端探測(cè)服務(wù)器，探測(cè)的行為包括客戶端探測(cè)接入點(diǎn)和服務(wù)節(jié)點(diǎn)間的相互探測(cè)。服務(wù)節(jié)點(diǎn)間的探測(cè)比較好做，客戶端發(fā)起的探測(cè)比較復(fù)雜，什么時(shí)機(jī)探測(cè)？是業(yè)務(wù)開始前探測(cè)，還是業(yè)務(wù)過(guò)程中持續(xù)探測(cè)、采樣探測(cè)，還是業(yè)務(wù)遇到問(wèn)題了才探測(cè)？要用多大流量探測(cè)？如果流量大了，會(huì)不會(huì)影響主業(yè)務(wù)？流量小了，會(huì)不會(huì)不準(zhǔn)確？?jī)?nèi)部的做法通常是做A/BTest，做一些選擇，得到概率性數(shù)據(jù)。

接入探測(cè)

接入探測(cè)就是客戶端到服務(wù)器探測(cè)的應(yīng)用經(jīng)驗(yàn)。黑色的圖顯示的是我們?cè)谀硞€(gè)區(qū)域監(jiān)測(cè)網(wǎng)絡(luò)質(zhì)量的情況，以丟包率來(lái)看。最上面的線表示零丟包的情況，可以看到15：05時(shí)，零丟包率下降，掉到了接近60%，很難解釋下降的原因，所以只能適應(yīng)，那么如何適應(yīng)呢，我們?cè)赟DK做了探測(cè)，如果發(fā)現(xiàn)這時(shí)的接入出現(xiàn)異常，那么考慮有無(wú)更好的連接點(diǎn)選擇，SDK可以自主地找到更好的路。第二，SDK探測(cè)得到的信息還會(huì)用來(lái)指導(dǎo)服務(wù)調(diào)度策略調(diào)整，讓后續(xù)其他用戶不用重蹈覆轍。主要是兩個(gè)策略，第一個(gè)是服務(wù)器下發(fā)的指導(dǎo)調(diào)度，反映綜合最優(yōu)，第二個(gè)是當(dāng)遇到問(wèn)題，調(diào)度服務(wù)吸收實(shí)時(shí)接入質(zhì)量反饋，可以自動(dòng)更新策略，恢復(fù)到正常水平。

圖中點(diǎn)雖然看起來(lái)下降很大，實(shí)際上是算法同時(shí)在補(bǔ)救，對(duì)業(yè)務(wù)來(lái)說(shuō)、對(duì)整體上層體驗(yàn)來(lái)說(shuō)影響不大。做探測(cè)的目的是不能讓算法解決整件事情，算法只是應(yīng)急使用，網(wǎng)絡(luò)才是基礎(chǔ)。雖然我們的傳輸控制算法能夠在70% 丟包下工作，但我們不希望我們服務(wù)一直處于極限情況運(yùn)作。這也是一個(gè)很基礎(chǔ)的想法。

全球IDC探測(cè)

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

這兩張圖展示了SDN的效果。左邊的圖表達(dá)的是從深圳到香港兩個(gè)節(jié)點(diǎn)間直連的效果，丟包明顯，RTT很大，在170ms左右。右邊是經(jīng)過(guò)了SDN后的效果，只有偶發(fā)少量丟包，并且RTT下降明顯，基本在20ms左右。

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

Part 03

RTC業(yè)務(wù)的體驗(yàn)優(yōu)化經(jīng)驗(yàn)

系統(tǒng)的穩(wěn)定性和性能很大程度上基于以上兩個(gè)思路進(jìn)行優(yōu)化。下面介紹RTC業(yè)務(wù)的體驗(yàn)優(yōu)化經(jīng)驗(yàn)。

3.1 線上教育

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

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

另一個(gè)是網(wǎng)絡(luò)，網(wǎng)絡(luò)通過(guò)剛剛提到的主動(dòng)探測(cè)已經(jīng)解決了很大的問(wèn)題，傳輸調(diào)優(yōu)指的是針對(duì)教育場(chǎng)景的特點(diǎn)做好參數(shù)調(diào)節(jié)。教育場(chǎng)景對(duì)穩(wěn)定性要求高，但是對(duì)時(shí)延沒(méi)有太特殊的要求，通常300ms是能夠滿足需求的。因此可以利用好這樣的資源減少卡頓。設(shè)置一個(gè)最低下限的Jitter Buffer的Level；另一個(gè)，通常教育可以提一個(gè)更高成本的方式，SDN可以有更大范圍的尋路，每多轉(zhuǎn)發(fā)一層就會(huì)多一份出口的流量。更大范圍的話，比如再多一跳，增加成本是否有用，用處有多大？這都是需要權(quán)衡的，如果要求系統(tǒng)穩(wěn)定，那么多轉(zhuǎn)發(fā)一層是沒(méi)有必要的。

還有一個(gè)點(diǎn)是音質(zhì)，音質(zhì)有各種理解，包括保真、音量、底噪、回聲，這些都是特定場(chǎng)景下的需求。對(duì)教育場(chǎng)景來(lái)說(shuō)音量夠大是基本需求，所以3A策略需要更激進(jìn)。

這里我想強(qiáng)調(diào)的一點(diǎn)是，教育場(chǎng)景最核心的訴求是穩(wěn)定，而穩(wěn)定需要很多細(xì)節(jié)積累。

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

另一個(gè)需求是小班課，特別是低齡的學(xué)生，很活躍，老師們?yōu)榱斯膭?lì)學(xué)生開口說(shuō)話，通常會(huì)有齊聲朗讀的場(chǎng)景。如果二三十個(gè)人一起說(shuō)話，現(xiàn)場(chǎng)會(huì)十分混亂，基本沒(méi)有辦法聽清楚。即構(gòu)去年前往開設(shè)小班課的公司體驗(yàn)，發(fā)現(xiàn)學(xué)生們很喜歡說(shuō)話，老師們雖然鼓勵(lì)孩子們說(shuō)話，但并不希望他們吵鬧，所以我們做了焦點(diǎn)語(yǔ)音功能，可以凸顯老師的聲音，同時(shí)自適應(yīng)協(xié)調(diào)學(xué)生的聲音，既保證了氛圍，又不至于太吵鬧。這個(gè)功能需要一些門檻和細(xì)節(jié)，比如某些學(xué)生的聲音是否應(yīng)該被放出來(lái)或被抑制。功能上線后，得到了老師們的良好反饋，提升了小班課體驗(yàn)。

同時(shí)教育場(chǎng)景的穩(wěn)定需要運(yùn)營(yíng)工具支持，比如如何識(shí)別問(wèn)題，做好一系列配套的事情。即構(gòu)棱鏡就是這樣的一個(gè)平臺(tái)，用于做問(wèn)題分析和數(shù)據(jù)運(yùn)營(yíng)，可以發(fā)現(xiàn)端到端中各種情況和統(tǒng)計(jì)類數(shù)據(jù)。

3.2 一起KTV

接著是即構(gòu)一直在努力改進(jìn)的場(chǎng)景——一起KTV。這個(gè)場(chǎng)景提出已經(jīng)很多年了，每次提出都有新東西出現(xiàn)。2019年，提出了串行的方案：首先一個(gè)人演唱，將聲音傳給另一人，第二個(gè)人再將自己的聲音混進(jìn)整合后傳給聽眾，這個(gè)方案比較簡(jiǎn)單而且對(duì)網(wǎng)絡(luò)要求不高，市面上很多音樂(lè)平臺(tái)的落地應(yīng)用已經(jīng)真正在線上使用了，但即構(gòu)想做的是真正的合唱，就是實(shí)現(xiàn)KTV中的多人合唱，這是一個(gè)很具吸引力的場(chǎng)景。我們?cè)趯?shí)時(shí)合唱方案上打磨已久，在近期行業(yè)內(nèi)首發(fā)了多人實(shí)時(shí)在線合唱的解決方案。

下面介紹一下優(yōu)化，最終效果是合唱者體驗(yàn)優(yōu)良，端到端感官極致低延遲，結(jié)構(gòu)更適合多人合唱，對(duì)觀眾端無(wú)特殊要求。這里的主體結(jié)構(gòu)分為幾個(gè)部分，下面這部分是RTC網(wǎng)絡(luò)，RTC網(wǎng)絡(luò)就是提出極致低延遲，我們做到IOS 76ms，Android 因?yàn)椴杉秩镜脑蜃龅窖舆t111ms，Windows 92ms。這個(gè)時(shí)延是比較低的，這里指的是從采集到真正從喇叭播放出的時(shí)間，包括端到端真正的時(shí)間，不只是網(wǎng)絡(luò)。

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

首先要做端到端時(shí)延的壓榨，第一是分析鏈路情況，要做好事件的打點(diǎn)，從整個(gè)鏈路來(lái)說(shuō)，包括采集、前處理、編碼、傳輸、對(duì)端解碼、后處理、渲染，這里的耳返時(shí)延是一個(gè)硬的約束，如果約束突破不了，時(shí)延有100ms或200ms，那么網(wǎng)絡(luò)就不可用了，因?yàn)檫€要疊加下面一部分編解碼和傳輸?shù)臅r(shí)延。

為了應(yīng)對(duì)每個(gè)環(huán)節(jié)處理的不穩(wěn)定，我們會(huì)加緩存，大家傾向于多加緩存來(lái)追求穩(wěn)定。如果開發(fā)者是分人開發(fā)的話，他會(huì)希望自己的模塊穩(wěn)定，但這就會(huì)給整個(gè)系統(tǒng)引入很多時(shí)延，我們需要判斷緩存是否必須。

另一個(gè)是整個(gè)算法的時(shí)延，就是系統(tǒng)設(shè)計(jì)出來(lái)本身需要的時(shí)延，比如右圖是Codec引入的時(shí)延，縱軸表示時(shí)延，橫軸表示碼率。對(duì)于Opus，它的時(shí)延可以做得很低，Opus有兩類編碼方案，分別是基于時(shí)域和基于頻域的。如果是基于時(shí)域的SILK，可以將時(shí)延做到極低——5ms左右，但因?yàn)闀r(shí)域的基于語(yǔ)音模型，效果不太好，無(wú)法達(dá)到高質(zhì)量。另一個(gè)基于頻域的方案，默認(rèn)幀長(zhǎng)情況下時(shí)延極限可以做到20ms左右（默認(rèn)一幀20ms，Lookahead 2.5ms）。當(dāng)然可以減幀長(zhǎng)。

總結(jié)一下，首先我們要看算法時(shí)延，音頻系統(tǒng)一定會(huì)有算法時(shí)延，要選擇更好的算法，更好的Codec。我們還要Review整個(gè)Pipeline緩存的水平是否必要或者權(quán)衡用什么東西去降緩存。

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

除了演唱者，還要從觀眾的角度來(lái)看。對(duì)觀眾的網(wǎng)絡(luò)要求不能過(guò)高，因?yàn)榇蟛糠秩司W(wǎng)絡(luò)都沒(méi)有較好的保障，那如何做好觀眾效果？觀眾效果會(huì)遇到什么問(wèn)題？比如演唱者的演唱已經(jīng)非常同步，但是觀眾聽到的不同步，原因包括觀眾與兩個(gè)主播的距離不同，或是某人的網(wǎng)絡(luò)突然抖動(dòng)，總會(huì)存在一些不穩(wěn)定的情況。我們的想法是在服務(wù)端將云端回流對(duì)齊，想法很基礎(chǔ)，通過(guò)加緩沖，用延遲換對(duì)齊，另外還要加播放的伸縮讓整個(gè)過(guò)程更平滑。

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

即構(gòu)主要希望不同端、不同地域的人在一起唱歌時(shí)都像是在KTV唱歌，內(nèi)部測(cè)試在普通要求下已經(jīng)可以達(dá)到KTV效果了。同時(shí)提供Demo在展臺(tái)體驗(yàn)。（Demo下載地址：https://doc-zh.zego.im/scene-plan/26）

Part 04

總結(jié)和展望

以上都是基于基礎(chǔ)設(shè)施做的，優(yōu)化方面除了功能優(yōu)化，還要有基礎(chǔ)設(shè)施的優(yōu)化包括更好的Codec、更強(qiáng)大的終端、VR、AR幫助方案落地。LVS也搞過(guò)線上的大會(huì)，現(xiàn)在疫情緩和了，大家也來(lái)參加線下的大會(huì)了。當(dāng)然一方面國(guó)內(nèi)對(duì)疫情的控制做得很好，另一方面還是因?yàn)榫€下體驗(yàn)確實(shí)比線上更有吸引力，在線下能夠更自由地交流。這其實(shí)也說(shuō)明了線上體驗(yàn)確實(shí)還有很多值得改進(jìn)的地方。如果有選擇，大家會(huì)傾向于線上參加LVS大會(huì)嗎？我相信隨著基礎(chǔ)設(shè)施的演進(jìn)，我們?cè)趯?shí)際場(chǎng)景中歷練方案，不但可以將線下個(gè)各種體驗(yàn)場(chǎng)景復(fù)刻到線上，還將演進(jìn)出更多線上獨(dú)有的體驗(yàn)，給大家更多的選擇，做到真正的體驗(yàn)共享。希望整個(gè)行業(yè)一起努力，讓音視頻技術(shù)、RTC技術(shù)融入于生活無(wú)形。

原文標(biāo)題：體驗(yàn)共享——技術(shù)實(shí)現(xiàn)瓶頸與突破

文章出處：【微信公眾號(hào)：LiveVideoStack】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯：haq