對全球不可靠的互聯(lián)網(wǎng)絡(luò)和大容量分布式系統(tǒng)的挑戰(zhàn)，如何以用戶為中心，從可用變得更好用，追求更流暢、更清晰、更快、更省的極致用戶音視頻體驗(yàn)？2021LiveVideoStacCon北京站邀請到華為云媒體服務(wù)資深研發(fā)專家—康永紅，為大家分享華為云

對全球不可靠的互聯(lián)網(wǎng)絡(luò)和大容量分布式系統(tǒng)的挑戰(zhàn)，如何以用戶為中心，從可用變得更好用，追求更流暢、更清晰、更快、更省的極致用戶音視頻體驗(yàn)？2021LiveVideoStacCon北京站邀請到華為云媒體服務(wù)資深研發(fā)專家—康永紅，為大家分享華為云媒體服務(wù)在追求極致用戶體驗(yàn)質(zhì)量道路上的沉淀成果——“視鏡”。

文/康永紅

整理/Live Video Stack

今天分享的主題是華為云媒體質(zhì)量管理最新實(shí)踐成果，“視鏡”是華為云研發(fā)的與媒體服務(wù)相關(guān)的質(zhì)量管理平臺(tái)。

分享的內(nèi)容主要包括三部分：

• 首先從新需求和新挑戰(zhàn)二方面分享下我們對音視頻媒體業(yè)務(wù)質(zhì)量的發(fā)展理解；
• 第二部分針對媒體質(zhì)量的新需求與挑戰(zhàn)，華為云的解決之道；
• 第三部分華為云針對媒體質(zhì)量做了哪些實(shí)踐。

媒體質(zhì)量新需求與新挑戰(zhàn)

隨著用戶對音視頻業(yè)務(wù)的體驗(yàn)要求越來越高，音視頻體驗(yàn)整體表現(xiàn)特點(diǎn)是“二高二低”，超高質(zhì)量、超高流暢、極低時(shí)延、低成本。

超高質(zhì)量：用戶對于沉浸式的觀感要求越來越高，視頻碼率也從4K、8K發(fā)展到更高；同時(shí)幀率也在向120fps發(fā)展。超高流暢：要求低于0.3%的丟包率；極低時(shí)延：用戶“天涯若比鄰”的實(shí)時(shí)交互感要求低于50ms的極低時(shí)延；

低成本：當(dāng)前互聯(lián)網(wǎng)流量中，音視頻流量占比約80%，算力消耗占比約40%，60%的儲(chǔ)存占比60%。不同運(yùn)營商的帶寬成本不同，不同區(qū)域的計(jì)算算力價(jià)格也不同，要綜合考慮成本最優(yōu)。

另外，要支撐極致體驗(yàn)，還需要一張具備帶寬、時(shí)延和可靠性三個(gè)核心特征的媒體網(wǎng)絡(luò)，具備感知QoS質(zhì)量的Fullmesh化實(shí)時(shí)音視頻網(wǎng)絡(luò)。

這里提到三個(gè)關(guān)鍵詞：無所不在的音視頻聯(lián)接、“資源共享”、“云原生”。

網(wǎng)絡(luò)時(shí)代，人們白天使用云桌面辦公，進(jìn)行視頻會(huì)議，晚上看直播或和朋友視頻聊天等，用戶隨時(shí)隨地在消費(fèi)音視頻業(yè)務(wù)，音視頻聯(lián)接無處不在，多種業(yè)務(wù)跑在音視頻媒體網(wǎng)絡(luò)上，從成本和質(zhì)量上要求資源共享復(fù)用，資源復(fù)用模式也在不斷演進(jìn)，從CDN共棧模式，向共網(wǎng)絡(luò)、共算力、共實(shí)例的OneMedia的趨勢發(fā)展。而且未來隨著高清晰度、高流暢度、強(qiáng)交互感的元宇宙在驅(qū)動(dòng)算力重構(gòu)，向邊緣計(jì)算快速演進(jìn)，高計(jì)算處理能力放置在更靠近用戶和設(shè)備的位置，內(nèi)容就近計(jì)算儲(chǔ)存，邊緣計(jì)算可節(jié)省高達(dá)35%的資源。

以上是新需求，再來看一下音視頻媒體業(yè)務(wù)面臨的質(zhì)量挑戰(zhàn)。眾所周知，體驗(yàn)質(zhì)量對業(yè)務(wù)至關(guān)重要：體驗(yàn)質(zhì)量每提升1個(gè)點(diǎn)，收益預(yù)估可以增加20%，而且成本會(huì)下降30%。從直播來看嗎，如果我們能將直播卡頓率降低20%，整個(gè)直播播放時(shí)長，能增加30%以上。但體驗(yàn)質(zhì)量優(yōu)化提升面臨的挑戰(zhàn)也非常大，以直播業(yè)務(wù)媒體網(wǎng)絡(luò)結(jié)構(gòu)為例，從推流、拉流、傳輸、到分發(fā)，任何一個(gè)環(huán)節(jié)出現(xiàn)不穩(wěn)定的情況，都會(huì)導(dǎo)致終端播放體驗(yàn)變差。

總體而言，目前音視頻業(yè)務(wù)普遍面臨著以下四大挑戰(zhàn)：

1. 用戶體驗(yàn)優(yōu)化手段少，目前主要是局部調(diào)優(yōu)或人工調(diào)優(yōu)，效率較低，效果較差；
2. 終端硬件種類多，有低端、中端、高端、操作系統(tǒng)也分為Android、Windows等。不同終端、不同操作系統(tǒng)上跑的業(yè)務(wù)也不同，比如直播、實(shí)時(shí)音視頻互動(dòng)、視頻會(huì)議，每個(gè)場景對體驗(yàn)的要求各不相同，比如直播更關(guān)注清晰度，會(huì)議通話更關(guān)注流暢度。如何適應(yīng)不同終端的不同業(yè)務(wù)場景，也是一個(gè)挑戰(zhàn)；
3. 成本優(yōu)化難：多樣性體驗(yàn)成本訴求以及資源建設(shè)周期成本都需要優(yōu)化；
4. 查問題定位難，運(yùn)維效率低。

以上四個(gè)挑戰(zhàn)可以綜合為一個(gè)問題：如何實(shí)現(xiàn)多業(yè)務(wù)多客戶多目標(biāo)質(zhì)量最優(yōu)？

如何做到多業(yè)務(wù)多客戶多目標(biāo)的綜合質(zhì)量最優(yōu)，接來下從體系和能力建設(shè)視角分享下我們的優(yōu)化之道。去年也做了關(guān)于體驗(yàn)優(yōu)化這個(gè)問題的分享，但當(dāng)時(shí)只分享了兩部分，體驗(yàn)診斷及體驗(yàn)提升。但在實(shí)際業(yè)務(wù)中，這兩點(diǎn)根本無法達(dá)到預(yù)期。

經(jīng)過摸索總結(jié)，我們認(rèn)為局部優(yōu)化在業(yè)務(wù)量比較小的階段作用很明顯，但進(jìn)入到幾百T的大業(yè)務(wù)量階段時(shí)其作用就不明顯。體驗(yàn)質(zhì)量貫穿媒體業(yè)務(wù)的設(shè)計(jì)-研發(fā)-運(yùn)維全生命周期，就要求建立端到端的質(zhì)量管理過程，音視頻媒體網(wǎng)絡(luò)是基于不可靠組件和不可靠互聯(lián)網(wǎng)絡(luò)，在全球范圍構(gòu)建大容量分布式系統(tǒng)，在設(shè)計(jì)階段，考慮跨國跨區(qū)域跨運(yùn)營商的網(wǎng)絡(luò)的不可靠性，要具備面向不同業(yè)務(wù)場景定義體驗(yàn)質(zhì)量體系標(biāo)準(zhǔn)和網(wǎng)絡(luò)設(shè)計(jì)能力，來保障用戶確定的實(shí)時(shí)音視頻互動(dòng)體驗(yàn)需求。在研發(fā)環(huán)節(jié)要具備音視頻體驗(yàn)質(zhì)量的測試服務(wù)能力，在運(yùn)維階段，整個(gè)閉環(huán)中的每一環(huán)節(jié)都需要進(jìn)行從監(jiān)控到診斷智能的體驗(yàn)提升。最后是專業(yè)的運(yùn)維保障能力，對重大的運(yùn)維事件及場景進(jìn)行保障。

接來下分別針對各個(gè)環(huán)節(jié)分享華為云的實(shí)踐。

華為云音視頻媒體體驗(yàn)質(zhì)量體系

首先分享下華為云音視頻媒體體驗(yàn)質(zhì)量體系，華為云以用戶為中心，從用戶使用不同音視頻業(yè)務(wù)的生命周期體驗(yàn)歷程去看體驗(yàn)質(zhì)量。入房請求階段，用戶關(guān)注的是快速看到內(nèi)容，這一階段的核心關(guān)注項(xiàng)是拉流成功率、首幀時(shí)長、時(shí)延等指標(biāo)。播放環(huán)節(jié)用戶關(guān)注的是播放是否清晰流暢以及端到端到時(shí)延。

音視頻媒體網(wǎng)絡(luò)是基于不可靠組件和不可靠互聯(lián)網(wǎng)絡(luò)，在全球范圍構(gòu)建大容量分布式系統(tǒng)，來保障用戶確定的實(shí)時(shí)音視頻互動(dòng)體驗(yàn)需求。為解決音視頻體驗(yàn)質(zhì)量無章可循、不可衡量、無保障的痛點(diǎn)，基于用戶體驗(yàn)歷程，從保障的維度范圍我們綜合端、網(wǎng)絡(luò)，從傳輸層、媒體層、信令層定義了一套華為云音視頻全網(wǎng)絡(luò)體驗(yàn)規(guī)范框架ELA，各個(gè)音視頻業(yè)務(wù)都可以參照這個(gè)框架來定義體驗(yàn)質(zhì)量。

我們認(rèn)為“質(zhì)量”的邊界絕不會(huì)僅止于此，一切皆為“序章”。

區(qū)別于直播體系只關(guān)注QoS或QoE環(huán)節(jié)，我們基于體驗(yàn)框架ELA以用戶體驗(yàn)為中心的宗旨設(shè)計(jì)了一套4層SLA-QoS-QoE-ELA的音視頻體驗(yàn)指標(biāo)金字塔體系，每層都包含對應(yīng)體驗(yàn)框架定義的傳輸、媒體、信令三種類型，從低向上逐層支撐用戶體驗(yàn)。

每個(gè)音視頻業(yè)務(wù)都可以參照這個(gè)金字塔體系定義業(yè)務(wù)指標(biāo)。 SLA層定義系統(tǒng)的高可用性（節(jié)點(diǎn)可用度、實(shí)例可用度、API可用度），將“可用”轉(zhuǎn)為“好用”的過程需要QoS層和QoE層來保障，ELA層是我們向客戶提供音視頻服務(wù)的體驗(yàn)承諾，是非常嚴(yán)謹(jǐn)?shù)闹笜?biāo)，只有達(dá)到這個(gè)指標(biāo)，服務(wù)才是好用的。從網(wǎng)絡(luò)端環(huán)節(jié)和終端環(huán)節(jié)的每一層打開都包含網(wǎng)絡(luò)層、媒體層和管理層，對每一層進(jìn)行相應(yīng)的質(zhì)量評估。以終端媒體層為例，在QoS層，會(huì)監(jiān)控媒體的卡頓率、幀率、碼率，在QoE層，會(huì)監(jiān)控流暢度、清晰度。在ELA層，會(huì)監(jiān)控卡頓達(dá)標(biāo)情況等業(yè)務(wù)綜合性指標(biāo)。

以SparkRTC業(yè)務(wù)為例，基于ELA體系，SparkRTC發(fā)布了視鏡服務(wù)，可以通過9個(gè)維度方面的指標(biāo)實(shí)時(shí)監(jiān)控和洞察分析業(yè)務(wù)質(zhì)量情況和發(fā)展情況，例如通話監(jiān)控觀測實(shí)時(shí)通信指標(biāo)、體驗(yàn)監(jiān)控分析體驗(yàn)質(zhì)量、規(guī)模監(jiān)控觀測用量規(guī)模、網(wǎng)絡(luò)監(jiān)控實(shí)時(shí)情況、設(shè)備監(jiān)控判斷內(nèi)存、CPU情況、異常診斷（基于ELA體系及時(shí)發(fā)現(xiàn)問題在終端或是網(wǎng)絡(luò)）、質(zhì)量評測。

視鏡服務(wù)依賴于網(wǎng)絡(luò)和端的監(jiān)控?cái)?shù)據(jù)，由用戶行為數(shù)據(jù)、網(wǎng)絡(luò)傳輸面及媒體面數(shù)據(jù)等綜合分析計(jì)算而成。

有了體驗(yàn)質(zhì)量框架和指標(biāo)體系，還需要質(zhì)量管理過程和技術(shù)平臺(tái)保障，從技術(shù)架構(gòu)上，支持媒體體驗(yàn)質(zhì)量工作涉及音視頻測試技術(shù)、云網(wǎng)絡(luò)設(shè)計(jì)、全鏈路監(jiān)控與分析、智能決策和調(diào)度、智能A/B實(shí)驗(yàn)平臺(tái)、音視頻專業(yè)的運(yùn)維能力等6方面的核心技術(shù)。

下面針對這6個(gè)核心能力展開介紹我們做的一些實(shí)踐。

華為云媒體質(zhì)量優(yōu)化實(shí)踐

之前在研發(fā)環(huán)節(jié)沒有對音視頻體驗(yàn)質(zhì)量進(jìn)行充分測試，導(dǎo)致版本上線后出現(xiàn)了體驗(yàn)質(zhì)量問題，有用戶反映出現(xiàn)黑屏、卡頓，經(jīng)過復(fù)盤及思考整個(gè)研發(fā)環(huán)節(jié)的短板后，我們構(gòu)建了專業(yè)的音視頻測試服務(wù)，具體包括：

• 現(xiàn)網(wǎng)環(huán)境的無參考自動(dòng)對比測試，替換傳統(tǒng)的手工撥測方式，提高撥測效率；
• 實(shí)驗(yàn)室環(huán)境的體驗(yàn)全參考評測，基于網(wǎng)絡(luò)模型+全參考，全覆蓋測試現(xiàn)網(wǎng)真實(shí)場景的體驗(yàn)質(zhì)量，解決路測的短板，因?yàn)槁窚y無法覆蓋測試現(xiàn)網(wǎng)所有的網(wǎng)絡(luò)弱網(wǎng)場景，而有了全參考的環(huán)境評測機(jī)制，基本能夠模擬現(xiàn)網(wǎng)90%的場景，而且全參考測試出的質(zhì)量更接近用戶主觀感受。

在測試流程中，我們針對兩個(gè)短板設(shè)計(jì)了解決方案。

• 自動(dòng)化持續(xù)檢測視頻畫面質(zhì)量測試：解決了以往在會(huì)議場景下只能抽取某一時(shí)間點(diǎn)觀察畫質(zhì)情況的問題，彌補(bǔ)單點(diǎn)抽測質(zhì)量覆蓋不完整的短板。
• 音視頻質(zhì)量測試集成研發(fā)流水線：音視頻質(zhì)量測試集成研發(fā)流水線---增加了體驗(yàn)質(zhì)量的流水線門禁，通過和上個(gè)版本測試結(jié)果對比自動(dòng)驗(yàn)證體驗(yàn)質(zhì)量通過。

產(chǎn)品上線，進(jìn)入運(yùn)維周期，首先要具備全鏈路質(zhì)量監(jiān)控與分析，對于了解網(wǎng)絡(luò)狀況、體驗(yàn)優(yōu)化、容量規(guī)劃、故障排除等十分重要。全鏈路檢測和分析面臨著四方面挑戰(zhàn)：準(zhǔn)確性（監(jiān)控指標(biāo)是否完整，定義指標(biāo)是否合理）、可擴(kuò)展性（對于監(jiān)控上千個(gè)節(jié)點(diǎn)的大容量網(wǎng)絡(luò)時(shí)，需要具備實(shí)時(shí)伸縮性）、速度（達(dá)到實(shí)時(shí)監(jiān)控）、完備性（監(jiān)控需要覆蓋端到端，從推流到拉流）。

我們設(shè)計(jì)了三條優(yōu)化實(shí)踐之路：

1. 基于云原生大數(shù)據(jù)湖構(gòu)建了億級規(guī)模音視頻質(zhì)量監(jiān)控?cái)?shù)據(jù)服務(wù)價(jià)值鏈體系，支撐幾十T業(yè)務(wù)監(jiān)控。另外數(shù)據(jù)湖基于流式計(jì)算，能做到毫秒級、秒級、分鐘級的實(shí)時(shí)監(jiān)控，解決了可擴(kuò)展性及速度問題；
2. 基于“人、站、流”三維度空間實(shí)時(shí)監(jiān)控百萬級對象各項(xiàng)指標(biāo)，將系統(tǒng)分為人、站、流后基本能夠詳細(xì)定義指標(biāo)；
3. 基于端（一方端+三方端）和網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行全鏈路的網(wǎng)絡(luò)實(shí)時(shí)監(jiān)控與分析，解決完備性問題。下面2個(gè)案例分別是直播業(yè)務(wù)和SparkRTC二個(gè)業(yè)務(wù)的全鏈路監(jiān)控和分析，直播全鏈路分析場景下，端的數(shù)據(jù)是結(jié)合客戶的三方端數(shù)據(jù)和我們的一方端網(wǎng)絡(luò)數(shù)據(jù)構(gòu)建而來，可以監(jiān)控從主播到觀眾到網(wǎng)絡(luò)的整個(gè)鏈路。

右側(cè)的SparkRTC是基于一方端的數(shù)據(jù)和一方網(wǎng)絡(luò)數(shù)據(jù)做的全鏈路網(wǎng)絡(luò)質(zhì)量監(jiān)控，每個(gè)節(jié)點(diǎn)的QoE、QoS指標(biāo)都可以進(jìn)行對比，還可以分析用戶操作，監(jiān)控網(wǎng)絡(luò)的質(zhì)量。

下面我們從監(jiān)控的三個(gè)維度，用戶、站、流分析打開看一些具體實(shí)踐。

首先是用戶體驗(yàn)監(jiān)控和分析。

在通話過程中，由于用戶、網(wǎng)絡(luò)、設(shè)備等限制，用戶可能會(huì)遇到卡頓、延時(shí)、黑屏等問題，此類問題統(tǒng)稱為體驗(yàn)異常，解決體驗(yàn)異常之前先要定義體驗(yàn)指標(biāo)，不同業(yè)務(wù)的體驗(yàn)指標(biāo)不同，以SparkRTC為例，對進(jìn)房慢的用戶（5s內(nèi)入房失敗）、音頻卡頓用戶（音頻卡頓率≥3%）、視頻卡頓用戶（視頻卡頓率≥5%），進(jìn)行實(shí)時(shí)指標(biāo)監(jiān)控，檢測到指標(biāo)異常會(huì)觸發(fā)告警、同時(shí)實(shí)時(shí)自動(dòng)診斷技術(shù)能夠檢測卡頓原因在于主播端網(wǎng)絡(luò)、傳輸網(wǎng)絡(luò)還是接收端網(wǎng)絡(luò)，如果原因在于端網(wǎng)絡(luò)，后續(xù)還要對其進(jìn)行網(wǎng)絡(luò)調(diào)度及解決。

其次從網(wǎng)絡(luò)質(zhì)量監(jiān)控分享一些實(shí)踐。

音視頻媒體網(wǎng)絡(luò)是基于不可靠互聯(lián)網(wǎng)絡(luò)，在網(wǎng)絡(luò)優(yōu)化實(shí)踐中，我們遇到了三個(gè)困境：

1. 研發(fā)測試基本是路測，帶著手機(jī)去地鐵站、機(jī)場等場所，無法覆蓋真實(shí)、全量的網(wǎng)絡(luò)場景；
2. 現(xiàn)網(wǎng)監(jiān)控缺少基于網(wǎng)絡(luò)QoS對卡頓等用戶體驗(yàn)質(zhì)量的預(yù)測；
3. 現(xiàn)網(wǎng)會(huì)針對弱網(wǎng)、編解碼做優(yōu)化算法，但目前優(yōu)化算法較單一，缺少對真實(shí)網(wǎng)絡(luò)各種場景的針對性優(yōu)化。

基于這些困境，我們思考構(gòu)建網(wǎng)絡(luò)模型學(xué)習(xí)系統(tǒng)，學(xué)習(xí)現(xiàn)網(wǎng)所有發(fā)送端及接收端的QoS數(shù)據(jù)，之后用于研發(fā)的音視頻測試服務(wù)、在線體驗(yàn)自動(dòng)診斷和在線體驗(yàn)調(diào)控優(yōu)化。在線體驗(yàn)自動(dòng)診斷是在測試某個(gè)網(wǎng)絡(luò)模型時(shí)，這個(gè)網(wǎng)絡(luò)模型會(huì)告知此模型中機(jī)場或辦公室場景的大致卡頓率或其它質(zhì)量指標(biāo)，此時(shí)如果現(xiàn)網(wǎng)來了一段類似的網(wǎng)絡(luò)QoS時(shí)序，那么就會(huì)匹配到此網(wǎng)絡(luò)模型上，我們就可以大概知道可能會(huì)出現(xiàn)何種體驗(yàn)問題。在線體驗(yàn)調(diào)控優(yōu)化是在發(fā)現(xiàn)某位用戶端的網(wǎng)絡(luò)特別差時(shí)，我們會(huì)為他選擇弱網(wǎng)場景的優(yōu)化參數(shù)（流控參數(shù)或降碼參數(shù)）進(jìn)行適配。

技術(shù)上采用基于網(wǎng)絡(luò)QoS時(shí)序聚類智能學(xué)習(xí)業(yè)務(wù)場景網(wǎng)絡(luò)模型，先時(shí)序特征聚類，后形狀聚類。這里面臨的兩個(gè)挑戰(zhàn)，1、每天需要學(xué)習(xí)現(xiàn)網(wǎng)幾十甚至上百T的QoS數(shù)據(jù)，通過結(jié)合特征聚類和形狀聚類的方式能夠解決此問題。2、每天要學(xué)習(xí)現(xiàn)網(wǎng)前一天的全量模型，這里有一個(gè)增量策略。

從實(shí)際使用情況來看，有以下兩個(gè)觀點(diǎn)適用于所有業(yè)務(wù)：

1. 聚類模型數(shù)量呈現(xiàn)顯著長尾效應(yīng)，針對少量場景模型優(yōu)化可覆蓋大部分場景（前100個(gè)模型能覆蓋95%+場景）；
2. QoS模型數(shù)量呈現(xiàn)亞線性增長，不會(huì)新增過多模型，針對已有場景模型優(yōu)化可覆蓋后續(xù)大部分場景。

最后是媒體流內(nèi)容質(zhì)量評估的實(shí)踐。

媒體流在現(xiàn)網(wǎng)傳輸、分發(fā)過程中可能出現(xiàn)損傷，引起畫質(zhì)變差。一般幀率、碼率能側(cè)面反映視頻質(zhì)量，但不等同于用戶的主觀質(zhì)量評價(jià)。目前如PSNR、SSIM以及比較火的VMF視頻質(zhì)量評估主要是有參考的，我們需要有效的、實(shí)時(shí)的、無參考的客觀視頻質(zhì)量評估模型以解決四個(gè)方面的問題：

• 質(zhì)量評估，對視頻質(zhì)量做出客觀評估，保證最終用戶的視覺體驗(yàn)；
• 編碼優(yōu)化，評估、優(yōu)化編碼器質(zhì)量；
• 質(zhì)量提升，前處理、后處理、畫質(zhì)增強(qiáng)對清晰度的影響；
• 成本優(yōu)化，調(diào)節(jié)最優(yōu)的清晰度、節(jié)省碼率以及帶寬成本。

構(gòu)建自動(dòng)化極致體驗(yàn)優(yōu)化系統(tǒng)，提升終端用戶體驗(yàn)。

為此，華為自研構(gòu)建視頻在線媒體質(zhì)量評估能力HVQA。HVQA是基于深度網(wǎng)絡(luò)學(xué)習(xí)模型的無參考視頻質(zhì)量評估，主要解決兩個(gè)問題：1、能夠檢測異常內(nèi)容，比如黑屏、花屏，目前能滿足1080p，30幀的檢測能力。2、能對畫質(zhì)進(jìn)行評估，比如清晰度等客觀指標(biāo)。HVQA已應(yīng)用在兩個(gè)場景中：1、端側(cè)視頻質(zhì)量評估。2、服務(wù)側(cè)視頻質(zhì)量評估：在服務(wù)端對轉(zhuǎn)碼視頻流進(jìn)行視頻內(nèi)容質(zhì)量評估。

實(shí)際測試效果顯示，異常內(nèi)容檢測方面，在實(shí)際業(yè)務(wù)測試集上對黑屏、花屏的檢測準(zhǔn)確率達(dá)100%，召回率達(dá)60%，對視頻畫質(zhì)，如清晰度的測試情況為SROCC=0.8283，PLCC=0.7886，CPU占用增加1.9%，內(nèi)存占用增加1%。

目前華為云的會(huì)議系統(tǒng)已在逐步應(yīng)用HVQA。

大家平時(shí)在體檢時(shí)會(huì)按照體檢的大致框架一步步進(jìn)行，框架中包括體檢的指標(biāo)，也就是系統(tǒng)的組成。我們將體檢思路運(yùn)用到媒體質(zhì)量診斷，在診斷網(wǎng)絡(luò)之前要先理解網(wǎng)絡(luò)，主要做法是基于時(shí)空理解網(wǎng)絡(luò)，包括理解系統(tǒng)、理解用戶、理解內(nèi)容，從影響音視頻卡頓的因素看，包括系統(tǒng)（站點(diǎn)之間的網(wǎng)絡(luò)時(shí)好時(shí)壞，邊緣站點(diǎn)有水位，資源有瓶頸）、用戶（接入網(wǎng)絡(luò)wifi/4G、本區(qū)域和跨區(qū)域接入影響）和內(nèi)容（冷熱流影響，主播端產(chǎn)生內(nèi)容質(zhì)量差）等各方面。

基于時(shí)空體驗(yàn)診斷能力，我們構(gòu)建了一個(gè)整個(gè)網(wǎng)絡(luò)時(shí)空孿生世界。主要解決了運(yùn)維面臨的問題如查找難、定位難、優(yōu)化難，解決之道是基于數(shù)據(jù)和算法重新定義媒體網(wǎng)絡(luò)運(yùn)維，首先要感知網(wǎng)絡(luò)中的業(yè)務(wù)類型，業(yè)務(wù)內(nèi)容，用戶內(nèi)容，感知之后基于“人、站、流”構(gòu)建數(shù)字世界。系統(tǒng)站方面主要感知時(shí)延、帶寬、丟包、抖動(dòng)、負(fù)荷等參數(shù)；視頻流內(nèi)容方面主要感知質(zhì)量；用戶人方面主要感知行為、QoE。

數(shù)字世界中已有百萬級對象、千萬級關(guān)系、億級時(shí)序線。

診斷模型的構(gòu)建策略是分三層來構(gòu)建整體的能力，最基礎(chǔ)的能力就是構(gòu)建L0全鏈路網(wǎng)絡(luò)拓?fù)浠A(chǔ)能力，其次是基于L0能力構(gòu)建基于時(shí)空質(zhì)量因素自動(dòng)診斷全網(wǎng)體驗(yàn)問題，最上層是業(yè)務(wù)分析能力層，支撐體驗(yàn)指標(biāo)與業(yè)務(wù)規(guī)模的多維分析，如果上層業(yè)務(wù)體驗(yàn)指標(biāo)發(fā)生了變化，通過業(yè)務(wù)模型、診斷能力，全鏈路能夠快速找到影響因素并進(jìn)行優(yōu)化。

接下來介紹在體驗(yàn)提升方面的一些實(shí)踐，實(shí)踐包括業(yè)務(wù)層的全域調(diào)度及傳輸層的全鏈路加速?，F(xiàn)網(wǎng)存在的很多問題是無法使用單一方法解決，這里有四個(gè)問題：多SLA保障問題，成本高昂問題、資源訴求劇增、業(yè)務(wù)場景融合，這些問題往往都是多業(yè)務(wù)，多目標(biāo)的綜合性問題，需要一個(gè)數(shù)據(jù)驅(qū)動(dòng)的云原生媒體網(wǎng)絡(luò)決策系統(tǒng)來解決，決策系統(tǒng)需要具備的核心能力是智能畫像（能夠進(jìn)行QoS預(yù)測、帶寬預(yù)測、用戶數(shù)預(yù)測、算力消耗預(yù)測），流量調(diào)度、算力調(diào)度、商業(yè)助手（因?yàn)樗袠I(yè)務(wù)都跑在一張網(wǎng)絡(luò)上，涉及到資源復(fù)用，需要知道下一位用戶第二天的復(fù)用情況。需要從回源率、成本、復(fù)用比三個(gè)維度進(jìn)行預(yù)測）。

解密多業(yè)務(wù)多目標(biāo)全域決策的實(shí)施流程，首先從四個(gè)維度感知各個(gè)音視頻業(yè)務(wù)，包括健康特征、容量特征、成本特征，質(zhì)量特征。接著建立特征畫像庫，包括用戶畫像庫、站點(diǎn)畫像庫、網(wǎng)絡(luò)畫像庫。綜合以上畫像結(jié)合調(diào)度算法（接入調(diào)度算法、回源調(diào)度算法、Full Mesh調(diào)度算法、轉(zhuǎn)碼算力調(diào)度算法）支撐用戶體驗(yàn)的提升及降成本。

通過多目標(biāo)、多業(yè)務(wù)的調(diào)度技術(shù)實(shí)踐，在回源率降低20%的情況下，首幀時(shí)延還能優(yōu)化8%，轉(zhuǎn)碼算力成本降低50%。

下面分享傳輸層全鏈路加速服務(wù)。

傳統(tǒng)Internet通過OSPF、BGP等標(biāo)準(zhǔn)路由協(xié)議Underlay傳輸，它不感知時(shí)延、丟包等QoS故障，導(dǎo)致無法滿足上層業(yè)務(wù)應(yīng)用QoS質(zhì)量訴求。Internet長距離傳輸無法滿足普通TCP類業(yè)務(wù)QoS要求，因?yàn)榭鐕说臅r(shí)延基本大于300ms，丟包率超過20%。

我們針對以上問題自研了全鏈路網(wǎng)絡(luò)加速服務(wù)，在Internet Underlay網(wǎng)絡(luò)上疊加Overlay網(wǎng)絡(luò)，實(shí)時(shí)感知每條鏈路的QoS（時(shí)延、丟包率），選擇最佳Overlay路徑流量轉(zhuǎn)發(fā)，從而提供相應(yīng)的QoS承諾。

基于全鏈路傳輸加速服務(wù)，應(yīng)用于國內(nèi)RTC加速場景，從測量數(shù)據(jù)上看，ADN選擇的路徑時(shí)延要小于級聯(lián)架構(gòu)組網(wǎng)下RTC的時(shí)延，在極端情況下對比更明顯。部分路徑優(yōu)勢非常明顯，如鄭州到濟(jì)南，從50ms提升至10ms以內(nèi)。應(yīng)用于海外加速效果，時(shí)延加速在Internet傳輸?shù)膸装俸撩氲幕A(chǔ)上平均提升20%，全球時(shí)延在200ms以內(nèi)，消除了90%的丟包場景。

最后分享我們在重大事件運(yùn)維保障的一些實(shí)踐，如保障國家級重大會(huì)議或直播賽事，保障挑戰(zhàn)很大，包括時(shí)間緊，任務(wù)重，保障方案復(fù)雜，保障壓力大，還要做到零事故、零中斷、零卡頓，零花屏。通過上百個(gè)項(xiàng)目的沉淀，我們將保障實(shí)踐總結(jié)為一個(gè)高可用平臺(tái)加6個(gè)保障DNA，高可用平臺(tái)是基于云原生基礎(chǔ)設(shè)施提出一個(gè)高可用架構(gòu)，同時(shí)建造穩(wěn)定的音視頻網(wǎng)絡(luò)系統(tǒng)及豐富的故障管理能力。DNA主要覆蓋需求交付、整體協(xié)調(diào)、全球覆蓋、系統(tǒng)高可靠、立體演練。系統(tǒng)高可靠包括雙平面保底方案，確保極限場景下可用；媒體資源VIP保障，資源隔離，專屬使用；關(guān)鍵風(fēng)險(xiǎn)識(shí)別、應(yīng)急預(yù)案制定并演練。立體演練包括全流程演練，問題日清日結(jié)；同聲傳譯、主會(huì)場屏幕顯示、掌聲等關(guān)鍵場景多場次演練并優(yōu)化方案；數(shù)字化遠(yuǎn)程運(yùn)維平臺(tái)，演練及時(shí)監(jiān)控，效果和問題分析。

總結(jié)與展望

最后，總結(jié)下今天分享的內(nèi)容：

1、音視頻發(fā)展的兩個(gè)需求（網(wǎng)絡(luò)感知，F(xiàn)ullMesh化；算力重構(gòu)、多業(yè)務(wù)融合、資源復(fù)用）和四大挑戰(zhàn)（用戶體驗(yàn)優(yōu)化手段少、多場景客戶端QoS保障難、降資源成本難、查問題定位難）；

2、音視頻體驗(yàn)質(zhì)量解決之道：

• 業(yè)務(wù)策略，建立面向不同媒體業(yè)務(wù)場景的體驗(yàn)質(zhì)量體系；
• 端到端的質(zhì)量管理過程，體驗(yàn)質(zhì)量貫穿媒體業(yè)務(wù)的設(shè)計(jì)、研發(fā)、運(yùn)維全生命周期；
• 核心技術(shù)實(shí)踐，音視頻質(zhì)量測試服務(wù)、全鏈路質(zhì)量監(jiān)控分析、智能決策與全域調(diào)度、全鏈路智能加速等。

展望未來，當(dāng)元宇宙時(shí)代出現(xiàn)時(shí)，怎么定義音視頻體驗(yàn)質(zhì)量規(guī)范?；诙恕⑦?、云時(shí)空數(shù)據(jù)協(xié)同，如何做到多業(yè)務(wù)、多目標(biāo)、多客戶的綜合決策和千人千面的用戶體驗(yàn)。這兩點(diǎn)都以上是本次的分享，謝謝！

關(guān)注@華為云，了解更多資訊