體驗共享含義及其與RTC技術(shù)的關(guān)系

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

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

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

Part 01

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

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

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

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

Part 02

RTC服務的體驗優(yōu)化思路

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

2.1 RTC體驗刻畫

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

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

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

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

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

2.2 RTC系統(tǒng)特征

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

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

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

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

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

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

2.3.1 全鏈路跟蹤

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

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

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

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

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

2.3.2 主動探測

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

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

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

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

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

接入探測

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

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

全球IDC探測

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

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

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

Part 03

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

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

3.1 線上教育

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

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

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

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

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

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

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

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

3.2 一起KTV

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

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

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

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

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

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

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

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

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

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

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

Part 04

總結(jié)和展望

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

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

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

責任編輯：haq