B站Up主上传质量调优实践
Up主上傳的大量?jī)?yōu)質(zhì)視頻內(nèi)容使得bilibili(B站)深受年輕用戶(hù)的喜愛(ài)。bilibili視頻云高級(jí)研發(fā)經(jīng)理 唐君行在LiveVideoStack線(xiàn)上交流分享中詳細(xì)介紹了B站為提供更流暢、穩(wěn)定用戶(hù)體驗(yàn),努力優(yōu)化上傳系統(tǒng)架構(gòu),建立質(zhì)量體系以及質(zhì)量調(diào)優(yōu)中的實(shí)踐經(jīng)驗(yàn)。
文 / Json(唐君行)
整理 / LiveVideoStack
直播回放:
https://www.baijiayun.com/web/playback/index?classid=19012252228433&token=oxx9-k_ZrxvhKKZLIMQ5hscti3kMCPTn5jjVy0_0ZBG_6qrsbCBq-khAVqheOz1TCqdH1zJ1Si0
大家好,我是來(lái)自bilibili(B站)的Json,目前主要負(fù)責(zé)bilibili的視頻上傳、存儲(chǔ)、點(diǎn)播CDN建設(shè)與架構(gòu)演進(jìn)。在進(jìn)入B站之前我主要負(fù)責(zé)系統(tǒng)架構(gòu)設(shè)計(jì)與數(shù)據(jù)驅(qū)動(dòng)研發(fā),同樣這也是我非常擅長(zhǎng)的領(lǐng)域。
我將從以上幾個(gè)方面為大家分享B站上傳調(diào)優(yōu)實(shí)踐的具體內(nèi)容:兩三年前,B站服務(wù)器有限的承載能力使得用戶(hù)上傳視頻失敗的狀況時(shí)有發(fā)生,這也是我剛加入B站時(shí)希望通過(guò)調(diào)整系統(tǒng)架構(gòu)努力優(yōu)化的方面;同時(shí)這樣一個(gè)基于數(shù)據(jù)優(yōu)化的項(xiàng)目,需要建立正確的優(yōu)化指標(biāo)與質(zhì)量?jī)?yōu)化方案,借助數(shù)據(jù)的力量驅(qū)動(dòng)整個(gè)平臺(tái)的開(kāi)發(fā),使得用戶(hù)能夠在B站收獲流暢穩(wěn)定的使用體驗(yàn)。
?
1.?系統(tǒng)架構(gòu)
?
上圖展示的是B站的用戶(hù)創(chuàng)作中心,用戶(hù)上傳到B站的視頻文件體積較大,質(zhì)量較高。初期我們僅開(kāi)發(fā)了通過(guò)PC(網(wǎng)頁(yè)端)上傳文件的功能。視頻體積較大是我們的優(yōu)化工作帶中的主要挑戰(zhàn),因?yàn)橹挥兴蟹制忌蟼鞒晒?#xff0c;一個(gè)視頻文件才算被上傳成功。
B站為了確保內(nèi)容的高質(zhì)量,僅有答對(duì)一定數(shù)量題目的Up主才能獲取上傳視頻的資格,這就使得上傳至B站的視頻內(nèi)容多為平均體積在400MB左右的優(yōu)質(zhì)長(zhǎng)視頻;雖然采取了這種設(shè)置一定門(mén)檻的上傳機(jī)制,但我們的日上傳量依舊保持在15萬(wàn)左右并且維持著年100%的增長(zhǎng),這也就是為什么在未來(lái)我們希望在鞏固現(xiàn)有網(wǎng)頁(yè)版上傳服務(wù)的同時(shí)繼續(xù)開(kāi)發(fā)Android、iOS、PC客戶(hù)端的上傳功能,方便用戶(hù)隨時(shí)隨地上傳高質(zhì)量視頻內(nèi)容。
作為上傳系統(tǒng)的關(guān)鍵組件,存儲(chǔ)部分的架構(gòu)并不復(fù)雜。我們使用一臺(tái)節(jié)點(diǎn)服務(wù)器處理數(shù)據(jù)提供服務(wù),當(dāng)用戶(hù)將視頻文件成功上傳至此服務(wù)器時(shí),視頻文件在服務(wù)器后端會(huì)經(jīng)過(guò)一系列系統(tǒng)處理,并在主機(jī)之間多次交換數(shù)據(jù),其傳輸協(xié)議與溝通方式更像一個(gè)運(yùn)維系統(tǒng),比較原始,我們將其重構(gòu)為一個(gè)帶有網(wǎng)關(guān)的系統(tǒng),改進(jìn)原先每開(kāi)始一種新業(yè)務(wù)就需新分配一批服務(wù)器的機(jī)制,使用網(wǎng)關(guān)的匯集功能可大大降低在配置域名與接入新業(yè)務(wù)等運(yùn)維工作的壓力與成本,并將節(jié)省下來(lái)的時(shí)間資源運(yùn)用于優(yōu)化工作。
除此之外,我們將統(tǒng)一存儲(chǔ)升級(jí)為可以分Bucket配置不同參數(shù)且與業(yè)務(wù)無(wú)關(guān)的通用對(duì)象存儲(chǔ),其承接了B站的UGC、PGC、音頻、短視頻的上傳、處理與回源等工作;同時(shí),使用此上傳、存儲(chǔ)體系統(tǒng)一的方案可有效減少文件在系統(tǒng)間轉(zhuǎn)移產(chǎn)生的IO。
隨著B(niǎo)站的不斷發(fā)展,從一開(kāi)始投入大量資源至業(yè)務(wù)發(fā)展到現(xiàn)在逐漸專(zhuān)注于內(nèi)容與資源的分享與呈現(xiàn),B站不斷嘗試將主要精力從與業(yè)務(wù)相關(guān)的內(nèi)容剝離出并投入優(yōu)化工作,基于此網(wǎng)關(guān)統(tǒng)一所有業(yè)務(wù)的通訊協(xié)議從而進(jìn)一步簡(jiǎn)化存儲(chǔ)架構(gòu)。
?
我們基于OpenResty搭建了B站的上傳系統(tǒng)。初期B站的上傳系統(tǒng)基于PHP搭建,雖然PHP并沒(méi)有明顯缺陷,但由于其還需搭建Nginx才能正常工作,因此相對(duì)于OpenResty這樣可直接在Nginx中讀取與合并上傳文件分片的架構(gòu),PHP并不是我們的首選項(xiàng)。使用OpenResty的同時(shí),對(duì)外發(fā)起Gap請(qǐng)求的次數(shù)也更多,同樣也支持用戶(hù)從網(wǎng)站獲取視頻數(shù)據(jù)的高性能模式。純粹從編程語(yǔ)言層面來(lái)講 ,以上是OpenResty在網(wǎng)關(guān)層面的作用之一。就我目前的體驗(yàn)來(lái)看,OpenResty并不輸給其他語(yǔ)言:我們的視頻云中包括大量基于OpenResty架構(gòu)的技術(shù)棧,而CDN、存儲(chǔ)系統(tǒng)與直播系統(tǒng)也基于OpenResty實(shí)現(xiàn),推薦大家使用OpenResty。
?
一般大公司會(huì)使用OpenResty重寫(xiě)相應(yīng)模塊以應(yīng)對(duì)高并發(fā)場(chǎng)景,實(shí)際來(lái)說(shuō)我們可在一些高I/O場(chǎng)景中使用OpenResty。雖然Node.js與Go也可實(shí)現(xiàn)異步I/O但其需要開(kāi)發(fā)者編寫(xiě)大量的回調(diào),而OpenResty能夠借助同步代碼實(shí)現(xiàn)異步I/O;相對(duì)于需要大量時(shí)間精力應(yīng)對(duì)高并發(fā)場(chǎng)景的Python與PHP,OpenResty可極大提高開(kāi)發(fā)效率。除此之外,Nginx本身也扮演著網(wǎng)關(guān)與業(yè)務(wù)服務(wù)的角色,可明顯簡(jiǎn)化架構(gòu);OpenResty也可直接訪(fǎng)問(wèn)Nginx的ClientBody且不存在語(yǔ)言框架的損耗,如果是其他語(yǔ)言則需在CGI層通過(guò)上行Buffer將ClientBody傳至所用語(yǔ)言中,并且需要一定轉(zhuǎn)化如Python需要WSGI轉(zhuǎn)化;最后,Lua較高的開(kāi)發(fā)效率也能幫助開(kāi)發(fā)者盡可能實(shí)現(xiàn)最佳開(kāi)發(fā)效果。
?
上圖展示了存儲(chǔ)系統(tǒng)的整體架構(gòu),其主要分為以下三個(gè)模塊:網(wǎng)關(guān)、Meta數(shù)據(jù)庫(kù)與存儲(chǔ)。用戶(hù)的訪(fǎng)問(wèn)請(qǐng)求首先經(jīng)由網(wǎng)關(guān)處理,網(wǎng)關(guān)繼而讀取Meta數(shù)據(jù)庫(kù)中一部分符合請(qǐng)求存儲(chǔ)位置的數(shù)據(jù),隨后存儲(chǔ)會(huì)將網(wǎng)絡(luò)流依次通過(guò)圖中的路徑5與路徑6傳輸至客戶(hù)端。這樣一個(gè)簡(jiǎn)單的存儲(chǔ)架構(gòu)自然而然會(huì)受到許多需要重構(gòu)小部分存儲(chǔ)減小內(nèi)容存儲(chǔ)風(fēng)險(xiǎn)的公司的青睞。
?
我們選擇S3作為上傳協(xié)議。在早期上傳協(xié)議的選型過(guò)程中我們研究了國(guó)內(nèi)許多互聯(lián)網(wǎng)公司的選型策略,其實(shí)國(guó)內(nèi)的大部分互聯(lián)網(wǎng)公司所采取的上傳協(xié)議都類(lèi)似于亞馬遜的S3協(xié)議,因此我們?cè)跇?gòu)建B站的上傳存儲(chǔ)系統(tǒng)時(shí)直接使用了亞馬遜的這一協(xié)議,其優(yōu)勢(shì)不僅在于亞馬遜的上傳協(xié)議本身就很完善,更在于我們可直接復(fù)用亞馬遜S3生態(tài)中的大量組件。無(wú)論是在分片上傳、分片大小、并行數(shù)量還是在其他我們能想到的可用于關(guān)鍵技術(shù)上的優(yōu)化,通過(guò)長(zhǎng)期的實(shí)踐與探索亞馬遜已將其一一實(shí)現(xiàn),不得不說(shuō)這明顯降低了我們的開(kāi)發(fā)難度與工作壓力。
S3上傳協(xié)議的整體流程如上圖展示:首先,初始化過(guò)程會(huì)在服務(wù)端為用戶(hù)分配一定空間,隨后來(lái)自客戶(hù)端的數(shù)據(jù)會(huì)通過(guò)并行上傳發(fā)送至服務(wù)端;在這里我們考慮優(yōu)化整個(gè)上傳過(guò)程,為提升上傳速度與上傳體驗(yàn)我們使用并行上傳的方式分片傳輸數(shù)據(jù);在這些數(shù)據(jù)被存儲(chǔ)于服務(wù)端時(shí),客戶(hù)端會(huì)生成與并行傳輸相關(guān)的會(huì)話(huà),此會(huì)話(huà)會(huì)被服務(wù)端讀取從而將所有分片正確合并。
?
S3上傳協(xié)議共需三個(gè)請(qǐng)求:用于分配上傳空間的Uploads、用于并行上傳的Put與用于合并完整文件的Post-complete。其中Put用于并行上傳,并行上傳時(shí)分片大小可自己定義,分片的順序則通過(guò)PartNumber標(biāo)示;在合并文件時(shí)服務(wù)端根據(jù)PartNumber所標(biāo)示的不同順序正確組合所有分片合并生成完整文件并在最后進(jìn)行校驗(yàn)從而確保合并完整文件的正確無(wú)誤。
?
上圖展示的便是整個(gè)上傳系統(tǒng)與后續(xù)工作的簡(jiǎn)化架構(gòu)。首先,客戶(hù)端會(huì)請(qǐng)求上傳調(diào)度,其實(shí)如果按照中心存儲(chǔ)架構(gòu)重構(gòu)來(lái)說(shuō)上傳調(diào)度并非必要流程,這里設(shè)計(jì)上傳調(diào)度的目的是便于后續(xù)優(yōu)化工作的進(jìn)行:上傳調(diào)度可為客戶(hù)端分配用于將數(shù)據(jù)上傳至CDN的不同地址與不同上傳模式。緊接著在客戶(hù)端請(qǐng)求完成調(diào)度并將數(shù)據(jù)上傳至存儲(chǔ)之后,存儲(chǔ)會(huì)產(chǎn)生一條可驅(qū)動(dòng)視頻處理流程的消息,從而啟動(dòng)轉(zhuǎn)碼、截圖、審核、分發(fā)等一系列圍繞存儲(chǔ)進(jìn)行的流程。與此同時(shí),存儲(chǔ)會(huì)接受所有上傳分片并產(chǎn)生相應(yīng)日志,這些日志會(huì)被傳輸至日志中心并呈現(xiàn)給負(fù)責(zé)分析的運(yùn)維人員或作為可優(yōu)化上傳調(diào)度過(guò)程提升用戶(hù)體驗(yàn)的信息使用。
2.??建立指標(biāo)
?
擁有上傳架構(gòu)之后,我們需要建立完善的指標(biāo)體系。音視頻行業(yè)有與播放相關(guān)的首幀、卡頓率等用于表征用戶(hù)播放體驗(yàn)的指標(biāo)參數(shù)。我們可憑借這些指標(biāo)反映出的動(dòng)態(tài)變化規(guī)律對(duì)用戶(hù)的多方面體驗(yàn)做出優(yōu)化。對(duì)于上傳過(guò)程而言,大家比較容易想到的與用戶(hù)上傳體驗(yàn)相關(guān)的指標(biāo),首先就是分片上傳的瞬時(shí)速度——瞬時(shí)速度決定數(shù)據(jù)上傳的耗時(shí),耗時(shí)越短用戶(hù)體驗(yàn)越優(yōu)秀;但瞬時(shí)速度的計(jì)算非常復(fù)雜,且無(wú)法明確幫助我們實(shí)現(xiàn)期待的優(yōu)化目標(biāo)。慢速比也是十分關(guān)鍵的指標(biāo)之一,但慢速比不但不滿(mǎn)足線(xiàn)性相關(guān)關(guān)系,同樣難以幫助我們實(shí)現(xiàn)優(yōu)化目標(biāo)。瞬時(shí)速度與慢速比并不能很好體現(xiàn)用戶(hù)上傳體驗(yàn)的優(yōu)劣,我們希望建立一些能夠幫助我們實(shí)現(xiàn)優(yōu)化目標(biāo)的指標(biāo),且計(jì)算過(guò)程相對(duì)簡(jiǎn)單,允許我們通過(guò)數(shù)據(jù)盡可能詳細(xì)量化優(yōu)化所帶來(lái)的用戶(hù)體驗(yàn)的變動(dòng)。經(jīng)過(guò)不斷探索我們將全局均速與成功率作為評(píng)價(jià)用戶(hù)上傳體驗(yàn)的兩項(xiàng)關(guān)鍵指標(biāo)——全局均速的定義是使用一個(gè)用戶(hù)所上傳文件的體積除以上傳時(shí)間得到的一個(gè)以兆每秒為單位的物理量,成功率則是用戶(hù)完成上傳的次數(shù)除以用戶(hù)發(fā)起上傳的次數(shù),而后將結(jié)果乘以100%。通過(guò)長(zhǎng)時(shí)間的實(shí)踐,我們可以說(shuō)此兩項(xiàng)指標(biāo)能夠客觀準(zhǔn)確地反映出用戶(hù)上傳體驗(yàn)的優(yōu)劣程度。
?
數(shù)據(jù)閉環(huán)值得我們?cè)趦?yōu)化過(guò)程中重點(diǎn)關(guān)注。將用戶(hù)反饋與上述指標(biāo)體系中的關(guān)鍵數(shù)據(jù)相結(jié)合,我們便能得到有助于優(yōu)化整個(gè)上傳系統(tǒng)的關(guān)鍵參考信息,從而得到調(diào)試所需的最佳技巧方案。比如我們需要從多家CDN中選出合適的作為接入服務(wù)商,那么就可根據(jù)比較各家方案的全局均速與成功率判斷第三方CDN的上傳質(zhì)量。這里需要強(qiáng)調(diào)的是,有些可以明顯提升傳輸速度的優(yōu)化方案會(huì)降低傳輸成功率,這就使得我們?cè)趯?duì)比時(shí)一定要綜合考慮這兩項(xiàng)指標(biāo);而像分片體積、并發(fā)數(shù)、重試次數(shù)等對(duì)上傳成功率造成影響的參數(shù),就需要我們通過(guò)建立abtest數(shù)據(jù)閉環(huán)納入考量。
除了上述內(nèi)容,比較不同平臺(tái)的上傳質(zhì)量同樣至關(guān)重要。初期B站僅有Web端上傳,使用手機(jī)與PC訪(fǎng)問(wèn)Web端上傳同樣的文件,PC端的成功率明顯高于移動(dòng)端。我們需要在比較不同平臺(tái)上傳質(zhì)量時(shí)盡可能規(guī)避由平臺(tái)限制造成的影響因素,從而得到傳輸鏈路本身對(duì)用戶(hù)上傳體驗(yàn)的影響。
3.?質(zhì)量?jī)?yōu)化
3.1 鏈路層面優(yōu)化
?
鏈路層面的優(yōu)化至關(guān)重要,其中不可或缺的條件便是CDN。初期我們的方案是接入多家上傳CDN,但多家CDN良莠不齊,對(duì)用戶(hù)體驗(yàn)的影響也存在差異;隨后我們通過(guò)調(diào)研發(fā)現(xiàn)許多大公司會(huì)選擇通過(guò)建立BGP直連或CDN節(jié)點(diǎn)加速的方式傳輸數(shù)據(jù),而這兩種方案對(duì)邊遠(yuǎn)地區(qū)或小規(guī)模運(yùn)營(yíng)商的支持并不完善;ab對(duì)比上傳指標(biāo)同樣是鏈路層面優(yōu)化的一項(xiàng)重要參考,但最后我們明確了將選用節(jié)點(diǎn)數(shù)較多的CDN運(yùn)營(yíng)商作為數(shù)據(jù)上傳技術(shù)支持的思路,CDN公司所提供的節(jié)點(diǎn)數(shù)量直接決定了數(shù)據(jù)上傳的質(zhì)量。
3.2 客戶(hù)端選線(xiàn)VS服務(wù)端選線(xiàn)
?
身處不同地區(qū)的用戶(hù)如何選擇最佳傳輸路線(xiàn)?客戶(hù)端選線(xiàn)與服務(wù)端選線(xiàn)哪一個(gè)是最佳方案?這些都是值得我們研究探索的命題。服務(wù)端優(yōu)化的思路之一是我們可通過(guò)在服務(wù)端建立數(shù)據(jù)庫(kù)并記錄某一地區(qū)用戶(hù)的上傳質(zhì)量為這一地區(qū)分配優(yōu)選CDN,但在實(shí)際應(yīng)用中,相對(duì)于隨機(jī)分配路線(xiàn)的策略,此方案并未收獲令人滿(mǎn)意的性能與質(zhì)量提升;通過(guò)進(jìn)一步探索我們發(fā)現(xiàn),客戶(hù)端在上傳前對(duì)線(xiàn)路進(jìn)行探測(cè)能夠有助于實(shí)現(xiàn)較高傳輸質(zhì)量。具體思路是在數(shù)據(jù)上傳前先借助小范圍客戶(hù)端進(jìn)行一次簡(jiǎn)單的包探測(cè)并與預(yù)設(shè)方案進(jìn)行比較從而得到最佳優(yōu)化方案。
?
使用電信網(wǎng)絡(luò)的用戶(hù)易被上下行寬帶不對(duì)等的問(wèn)題所困擾,鑒于此我們與電信運(yùn)營(yíng)商進(jìn)行交涉,通過(guò)IP庫(kù)檢測(cè)電信用戶(hù)并為其打開(kāi)電信上傳限制,通過(guò)上述優(yōu)化可使電信用戶(hù)的上傳速率提升10倍左右。
3.3 JSSDK優(yōu)化
?
對(duì)于JSSDK的優(yōu)化主要是通過(guò)將多文件并發(fā)的策略改為文件內(nèi)分片并發(fā)實(shí)現(xiàn),前者相當(dāng)于多個(gè)文件同時(shí)占用一個(gè)上行總帶寬,造成的結(jié)果是三個(gè)文件的上傳均十分緩慢;而后者則可明顯提升文件傳輸效率。
?
支持將數(shù)據(jù)上傳到第三方存儲(chǔ)可以說(shuō)是我們?yōu)橛脩?hù)充分考慮而設(shè)計(jì)的一項(xiàng)優(yōu)化,來(lái)源于客戶(hù)端的數(shù)據(jù)會(huì)先被上傳至第三方存儲(chǔ)并通知原站將其從第三方存儲(chǔ)拉取回原站存儲(chǔ),這樣的好處在于可以讓一些身處距離較遠(yuǎn)如海外等不方便直連原站存儲(chǔ)的用戶(hù)享受到近距離節(jié)點(diǎn)用戶(hù)的上傳體驗(yàn),例如將原先海外客戶(hù)端與國(guó)內(nèi)直連改成國(guó)外客戶(hù)端將視頻先上傳至如亞馬遜等第三方海外節(jié)點(diǎn),而后國(guó)內(nèi)原站存儲(chǔ)再?gòu)牡谌胶M夤?jié)點(diǎn)拉取視頻數(shù)據(jù),用較低成本實(shí)現(xiàn)良好傳輸效果。
3.4 跨會(huì)話(huà)上傳控制
?
通過(guò)大數(shù)據(jù)我們發(fā)現(xiàn)周末上傳成功率下降明顯,從用戶(hù)行為的角度分析其原因在于周末Up主人均上傳稿件數(shù)量增多,很多用戶(hù)會(huì)選擇打開(kāi)兩個(gè)甚至多個(gè)播放器進(jìn)行并發(fā)上傳,這對(duì)帶寬資源的占據(jù)是顯而易見(jiàn)的。為應(yīng)對(duì)此情況我們使用js的LocalStorage實(shí)現(xiàn)鎖,實(shí)現(xiàn)了將周末視頻文件的上傳成功率相較于工作日時(shí)期提升1%左右的優(yōu)化。
?
2018年我們上線(xiàn)了移動(dòng)端上傳服務(wù),其中的一項(xiàng)關(guān)鍵優(yōu)化在于服務(wù)端下發(fā)參數(shù)以便于數(shù)據(jù)驅(qū)動(dòng)優(yōu)化。移動(dòng)端與Web端最大的區(qū)別在于移動(dòng)端的發(fā)版代價(jià)更大,通過(guò)上報(bào)網(wǎng)絡(luò)環(huán)境與主機(jī)型號(hào)等得到服務(wù)端的下發(fā)參數(shù),利用數(shù)據(jù)驅(qū)動(dòng)優(yōu)化,從而將發(fā)版代價(jià)巨大的移動(dòng)端場(chǎng)景轉(zhuǎn)換為與Web瀏覽器類(lèi)似的一種易于服務(wù)端與數(shù)據(jù)驅(qū)動(dòng)優(yōu)化的場(chǎng)景,從而通過(guò)調(diào)整不同參數(shù)實(shí)現(xiàn)移動(dòng)端的最佳上傳服務(wù)。相對(duì)于基于無(wú)線(xiàn)網(wǎng)或?qū)拵ЬW(wǎng)絡(luò)等環(huán)境與質(zhì)量較高的Web瀏覽器端,基于移動(dòng)網(wǎng)絡(luò)的手機(jī)移動(dòng)端可能無(wú)法提供傳輸所需的高質(zhì)量網(wǎng)絡(luò)環(huán)境,面對(duì)這種情況我們會(huì)根據(jù)網(wǎng)絡(luò)環(huán)境的不同為移動(dòng)端匹配最合適的節(jié)點(diǎn),優(yōu)選并發(fā)數(shù)、分片體積、重試次數(shù)與間隔等,確保移動(dòng)端用戶(hù)上傳體驗(yàn)的一致性。
4.?總結(jié)與成果
?
通過(guò)重構(gòu)系統(tǒng)、建立指標(biāo)體系、優(yōu)化指標(biāo)與明確達(dá)成目標(biāo)等一系列舉措,我們得以將上傳成功率從最初的的85%提升至94%,同時(shí)實(shí)現(xiàn)平均速度提升4倍,實(shí)現(xiàn)用戶(hù)相關(guān)投訴0記錄的優(yōu)化成果,與此同時(shí)我們是業(yè)界少有的能夠較好支持網(wǎng)頁(yè)端并行上傳的視頻平臺(tái)。
?
關(guān)于未來(lái)我們探索的方向,我們希望借助QUIC上傳優(yōu)化移動(dòng)端的上傳體驗(yàn),并為實(shí)現(xiàn)動(dòng)態(tài)切換上傳線(xiàn)路而不斷努力以達(dá)成高可用與更佳的體驗(yàn)優(yōu)化。
點(diǎn)擊【閱讀原文】或掃描圖中二維碼了解更多LiveVideoStackCon 2019 上海 音視頻技術(shù)大會(huì) 講師信息。
超強(qiáng)干貨來(lái)襲 云風(fēng)專(zhuān)訪(fǎng):近40年碼齡,通宵達(dá)旦的技術(shù)人生總結(jié)
以上是生活随笔為你收集整理的B站Up主上传质量调优实践的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 2019年低延迟直播技术展望
- 下一篇: QUIC DataChannels的第一