本文由網易云信資深音視頻客戶端工程師張根寧在LiveVideoStackCon 2019上海音視頻技術大會的演講整理而成，張根寧分享了團隊在線視頻播放器優化的主要方向，即緩沖和卡頓問題。對于卡頓，可以優化CDN轉發過程來解決緩存不足的問題，通過無縫切換保證流暢度。針對首屏秒開，可以通過合適的切流措施和多CDN的災備策略來保證拉流成功率，而優化的根本在于首屏流程中移除耗時操作。
文 / 張根寧整理 / LiveVideoStack
我是來自網易云信的張根寧，今天我將會站在用戶的角度來跟大家探討播放器的相關優化，也會詳細闡述網易云信團隊在播放器方面都做了哪些努力。

1.?移動端播放器優化實踐

?我本人也是一個短視頻的愛好者，在看頭條抖音的時候根本停不下來，一刷就是幾個小時就過去了。我時常就在想什么原因能把我粘在這里，后來我想明白了，除內容因素之外有兩點是最吸引我的：第一所見即所得。點擊的同時可以把我想要的內容呈現。第二，在播放過程當中不會給我有任何停頓感。

1.1 播放器

從這個反向推，我覺得在播放器的播放過程當中給用戶最不好的體驗就是這兩點，一個是開始的頻繁緩沖，第二個是在播放的過程當中的卡頓。這兩點在播放器里會涉及到兩個關鍵的指標：卡頓率和秒開率。今天的內容主要是將如何針對這兩點來進行優化。??我們的播放器底層基于ijkplayer，跟大部分的播放器的底層架構一樣，有三個外部視頻輸入，（像網絡視頻）經過輸入之后會經過解協議，到下面解封裝，音視頻流分離進行解碼、同步、最后呈現。?關鍵點在兩塊緩存，第一個緩存是原始數據緩存，第二個解碼出來的數據緩存。今天的所有的優化會針對這兩個緩存進行。?把播放器從拿到流到播放流理解成一個工廠，有三種原因會導致流播不出來：?1.根本沒拿到，所謂的緩存不足，存貨不足。2.拿到了，但是性能有限處理不過來，只能頻繁丟幀。給用戶的感覺要么就是慢速播放，要么頻繁跳幀。3.時間戳是亂的。這種是比較極端的情況，可能是上行的推流端在錯誤的情況下或者在CDN轉發的時候出現了錯誤，這種卡頓只能及時檢測。?

1.2 為什么緩存里沒有數據了？

??其實從整個鏈路來看，無論是點播還是直播都是大概經過這三個方向：比如直播。上行會推個流到CDN。點播采用CDN回源去點播原站去拿視頻流，最終終端會從CDN的一個節點上拉取視頻流。?但在這三個節點上面每一個都有可能會發生卡頓：?第一，在推流端發出來的時候視頻流丟了。（針對于這種情況我們推流端做了很多工作，像QS實時偵測網絡帶寬、根據網絡帶寬調整分辨率以及碼率進行頻繁發送）?第二，在CDN轉發過程丟幀或者不及時。這種是主要優化對象。因為播放質量跟CDN是息息相關的，如果CDN不及時本地再怎么優化也于事無補。第三，本地帶寬不夠。當用戶在本地網絡不好的時候這是最常見的一種卡頓。從節點上看，在回來的時候（當前的解包能力和解析流的能力是不會占用太多的CPU和內存的）主要的性能瓶頸就是在解碼。與渲染相比，一些低端的IOS（像4，4S解一個1080P視頻）解碼器的性能不夠，它在30毫秒之內吐不出來一幀，所以在用戶看到的時候已經變成慢速播放。而有些幀可能在送到解碼器之前就已經丟掉了。或者渲染能力不行，解碼能力雖然跟上了，但無法在指定的時間內渲染出來圖像給用戶。?

1.3?卡頓優化-CDN質量

我們服務端有調度服務器來控制CDN的選擇。?

服務端選擇CDN的流程。播放器發起調度請求的時候，調度服務器會對所有的CDN進行一個可用NGB調度：把所有的CDN節點都返回進行簡單測速，以及根據統一上報的信息來進行權重，把這些信息返回再做相應處理。?而在客戶端會進行二次測速。因為服務端是基于大數據來篩選出來CDN質量評優，而在本地還要參照當地網絡帶寬情況再根據服務端給的推薦權重比例，會有下面的公式：Pn是服務端給的權重，成正比。在拿到每個CDN結點的時候跟每條CDN依次建連，時間消耗是Tn。Tn越小這條流的質量越高。?如果經過一系列的處理，發現在CDN質量還是不高，此時應該分兩步來走。
第一步，感知卡頓。依賴一套完備的卡頓處理監控體系。在典型模型里面這三塊對應三塊緩沖區，會有數據流入和數據流出量，以及當前數據平緩度的統計。渲染會有丟幀率的統計，根據統計上報信息在服務端計算當前的網絡狀態以及數據情況，給出最優的當前卡頓率結果。就可以判斷當前的卡頓率范圍屬于正常還是異常。?

具體的指標有網絡、ISP、位置作為維度參與運算。卡頓統計精確到秒級。示范卡頓上報數據，以每秒打一個點來標記當前正在處于卡頓，以一分鐘一個周期進行上報。在服務端拿到數據的時候就可以看到第五秒到第十秒已經發生了卡頓，其他屬于正常情況。卡頓時長、卡頓頻率都可以通過數據解析出來，比較精細化。?第二步，感知卡頓統計，快速恢復播放分為兩方面：??1. 服務端CDN不行了。通過兩輪校驗，沒有辦法提供正常的流，服務端經過統計服務器報警之后會自動將CDN下發權重降低，而當前CDN會列為CDN的黑名單節點,這樣后上來的用戶就不會再拉到這個CDN給他的節點去拉流。?2.客戶端會進行災備地址的切換。切換的維度有三個：第一個要保證當前Ping公網對本地網絡進行有效的評估，利用Ping公網包的方式來判斷當前帶寬是否處于正常的狀態。第二個看緩沖池，手機緩沖數據流入量的平穩度。第三，計算當前卡頓總時長。當數據流入很平穩并且本地帶寬很充裕的情況下，單位時間內卡頓時長上來了，就認為是CDN沒有及時給到東西，會根據當前的綜合歷史記錄進行切流。?

1.4?本地性能優化

?首先應該要去除網絡的因素。要保證Buffer的數據流入量是正常的。保證本地流入量（本地的帶寬）正常把網絡因素去除。第二，看渲染丟幀率。當渲染沒辦法以正常比例幀率渲染，會在緩存Buffer里面均勻丟幀來保證渲染流暢度。統計的丟幀率越大渲染性能越差，這表示當前渲染的性能出了問題。?去掉最左邊和最右邊的因素之后再去評價解碼器的流入跟流出數據的平緩度，就能確定當前是解碼還是渲染引出的問題。??這個問題可以分兩個方面。?渲染性能問題。第一，IOS9以后會引入一些高效渲染方式（如Metal），這種渲染方式天生就比OpenGL要高效。第二，有畸形的黑白名單，根據畸形來判斷渲染的最佳比例（Max渲染的Size），根據渲染圖像等比例裁減后保證當前的渲染圖像流暢播放。第三，引入丟幀機制。在性能極差，損失畫面彌補不了的情況下會現均勻丟幀。犧牲用戶產生跳幀，來保證流暢播放。?解碼性能不足怎么辦？解碼性分為軟解碼和硬解碼。1.因為軟解碼依賴FFmpeg解碼，軟解碼引入多線程解碼2.優先推薦硬解碼來代替解碼（比如低端的機型在解H265的時候CPU會飆到一百到一百五左右，推薦使用使用硬解碼代替軟解碼）。3.采取隔幀參考的方式，根據推流端協商，在某一幀進行跳幀的參考。在這種編碼方式下播放器可以在解碼前把一些不必要的非參考幀丟棄，還原出原來的圖像。?

1.5?點播卡頓

?關于點播。點播會采用無縫切換用犧牲畫質來獲取流暢度：兩條視頻流在切換的過程當中時間上保持連續性，用戶不知不覺降低了畫質而且畫面不間斷。?大概的實現流程：視頻流A在HD的T1點卡頓會開啟T2點B低分辨率的碼流。當T1點播放完成（T1點紅色部分就是T1當前所緩存的所有數據）第一批數據播放完成之前如果T2已經完成了加載，直接切到T2。沒有完成加載也切到T2，因為可以判定當前的低分辨率網絡也不行，會按照這個順序繼續降級。（當然這種降級可以供用戶在選擇是自動還是手動）。?這種無縫切換有種問題：當切換點剛好處于兩個I、一個GoP中間，而這個GoP是比較大，可能會產生畫面回跳。?因為播放器是生產者消費者的模式，消費掉的數據會丟棄。解碼解到這里前面的幀已經不可見了，Seek到這一點服務端強制從第一個I幀開始解，用戶的直觀體驗就是畫面回跳。針對這種的優化是把當前的一整個GoP全部都保存下來，只針對前面這一部分進行解碼，不輸出，就不會渲染在畫面上，解到這一點再繼續輸出。這樣做在用戶體驗上可以達到畫面連續的效果。?經過一系列從推流端到服務端到終端的優化，之前的用戶負荷（百萬級日活量）在接入之后整體卡頓率平均能下降30+%?

?

1.6?秒開

其實要先看一下，播放器在秒開之前都做了什么。?正常的流程播放器流程大概是這樣。因為有CDN節點，第一個步驟是跟調度服務器進行HTTP交互。第二步在拿到節點之后Socket建連的過程。第三步從流解析到解碼最后渲染。在優化之前做了測試，網絡極佳性能沒有問題的情況下，調度服務器在200到500毫秒之間，Socket也是在200+，后續也都是在100到200毫秒，總體加起來再打開會在一千毫秒以上，達不到秒開的效果。?

1.7 GSLB調度優化-預調度

?針對以上問題對每個節點進行了優化 以第一個節點為例，GSLB調度必須在播放的時候同步等HTTP返回，拿到最優節點才能進行播放。引入方案：把結果提前存起來，用的時候從緩存里拿。
引入模型：有一個隊列，用戶可以提前加入一批他拿到的URL地址，交給調度分為兩塊緩存來存，一塊是4G，一塊是WiFi。播放的時候會判斷緩存里有沒有。沒有，開始調度。有的話，直接緩存命中去播。這樣可以節省首屏的HTTP請求的時間。?在這個方向還會有兩個問題。第一，調度速度。第二，基于調度優先級。?因此在考慮并發性的情況下，允許最大的并發數量為4 - 6個。為了保證優先級遵循先進先出，先進先調的順序。而有即時的調度任務會優先調度，并且在避免帶寬搶占的情況下會把預調度里面的所有隊列里面的任務暫停，優先調度。?另外CDN調度，本身即時有效，比如說用戶在某一時間、某一網絡狀態、在某一地點，此時服務端返回的大數據就是這一時刻最有效、質量最高的節點。有預調度了，用戶如果發生位置或者網絡的切換，就不再是最佳節點。?有哪些維度能保證有效性？?第一個，有效性。強制設置有效期，在有效期過了以后會強制重新調度一下隊列里面的一些結果。?第二個，網絡切換。因為分了兩塊緩存，一塊是WiFi的結果，一塊是4G的結果， 基于流量考慮（像4G，通常流量是比較敏感的。）如果網絡切換看到4G里面有結果了，把失去有效期結果的重新刷新一遍，有效期的繼續保留。（因為認為切回到4G的時候，它的運營商不變。） 切換到WiFi。安卓上面做了熱點的對比，切回到同一個熱點，邏輯跟4G一樣，但是IOS上面拿到這個熱點會有些障礙，我們無腦把它全部更新。因為WiFi下用戶對流量也不敏感。?

1.8 建連優化

?服務端建連有三個方面。第一個方面，跟服務器交互的時候首先要跟服務器請求流地址。跟服務器建連的流程為了保證跟建連服務器時間最短，引入了測速機制。（就是剛才說的這個） 回來的時候進行權重排序把服務端建連時間長的節點篩選，不會參與到后續建連。測速機制第二個作用就是篩選節點服務器。第二個方面，建連成功了，但是服務端回包特別慢，會啟動災備邏輯。經過幾重維度判斷之后會啟動切換流程達到災備的效果。第三個方面，回來的結點還會把原始DNS URL進行最后災備：所有流都拉不到的時候會啟用DNS拉流。這時提前把DNS做預熱（因為DNS本身尋址的過程很耗時。而這個時機，因為DNS本身它是阻塞式、不可取消的過程），在整個首屏流程里會有兩次更新網絡請求。第一次跟調度服務器進行HTTP請求。調度服務器的域名是固定的，可以在APP起來的時候并行開啟一個線程去把調度服務器域名進行DNS解析。第二個，域名拿到，在進行NGP調度的時候同步開線程，把當前拉流域名進行DNS解析。這樣在同一時間內做了兩件事情，走到這個分支就可以直接從DNS緩存里拿IP地址進行建連。

2. 流解析優化首屏空間，解碼優化，渲染。

?解碼的時候FFmpeg里面有幾個比較重要的優化參數。?第一個，FFmpeg在拉到流首先會對視頻的首包進行解包操作。解包的過程當中會進行流的探測，比如解析到SPS或者PPS，拿到所有的meta信息，再分析每一線長度，這個本身很耗時。針對這種情況優化是直接指定視頻格式（一般客戶知道自己的視頻格式。如果接入自己的轉碼服務器，通常支持的格式也是主流的FLV或者MP4）這樣只要把格式植入進去就完全可以省略FFMpeg解析的時間。?第二個， 探測長度和探測時長（probesize/analyeduration）。這個探測主要的作用是解析當前視頻流音軌和視頻軌道的信息。采用動態下發機制來設置。理論上來說這兩個參數設置越小，首屏時間會越短。但是這也會帶來一些其它問題問題，有些異常的流，比如互動直播在一個連上上下麥的過程當中，混流的時候會出現前半段是音頻的連麥（音頻軌道流）， 此時用戶以視頻形式上麥，混流的時候會同時混音頻流和視頻流。對于播放器這邊來說，播著音頻流突然來了個視頻流，探測時間如果太短就感知不到這種格式的流，會導致最后解碼器開不了。

后來針對這種流解析進行了改進。就是在FFmpeg解析出來有流的Index變化的時候再去開相應的Codeck。?

2.1?點播業務級別秒開優化-預加載

??在點播有業務級的秒開，類似于劃屏滾動，抖音這種滾到什么地方就播放什么地方。這里提供了兩種方式，第一種采用多實例，第二種就是采用DataSource。?多實例就是播放器性能。（自測之后發現，播放器性能以iPhone7為例來測，最多可能會同時開十個播放器，完全可以滿足這種場景）維護播放器的緩沖池。當用戶播放到當前預加載上下的幾個，這樣用戶在不停的滾動當中（數據因為已經加載好了，只需要調用一個播放渲染就可以了）也可以達到秒開的即時感。但是這種情況有一個問題，在低端機型上緩沖池的大小會受限制，因為同時它會開N個實例，這N個實例里面的解碼線程，渲染線程也會有N個，在低端機上吃不消。第二，帶寬搶占的問題。他們幾個同時去加載，上下幾個在正在占著帶寬，中間這個加載很慢。這種實現方式不是很靈活最根本在播放器。??Data source就是播放器提供了一組接口，第一種要給當前的Content Size。第二就是Play、Stop和Seek這種常規的操作接口。而應用層需要有完善的拉流機制和緩存機制，把所有拉回來的流作為Source data存在隊列里面，也可以根據自己的需求去拉某個優先級高的流，進行優先級排序，或者進行其他維度權重的排序。這樣整個秒開邏輯只需要用一個播放器就可以了。比如想用Data ?source 1 只需要按照播放器邏輯塞給播放器，播放器就會進行同步渲染。而如果播放到2（因為數據已經有了）渲染的性能正常的情況下打開是會在秒以內的。而且對低端機的性能要求不嚴格。?這樣做的缺點是大部分邏輯都需要應用層來維護，而應用層拉流機制和緩存機制可能會比較麻煩，但靈活度是最高的。做點播業務級優化的另外一個問題與秒開也是有關的。?

2.2 無限循環

?無限循環在播放器內部就是播放到最后再Seek到開始。而在Seek過程當中每次都是請求重新建連Socket，發起HTTP請求建連。這種短視頻每次發起Socket都會有網絡請求、執行加載，用戶的體驗很不好。?針對這個進行優化，引入了本地緩存，邊下邊播功能：有兩份文件，原始數據文件，對應Map文件。Map文件對應的數據就是原始數據的時間段，因為有可能點播播放到某一個點，Seek到另外一個點，在文件寫入的時候中間會有個空洞，用Map就是來記錄到這個點跟點之間以及已經記錄的視頻段。用戶播的時候優先從原始的本地的文件里面進行Seek，就可以達到無限循環秒開的優化。?邊下邊播另外一種優勢是真的可以做到用戶即播即看，類似于引入了內部管理和外部管理的快播效果。比如說用戶想要優化本地緩存。就引入內部管理，視頻在播放器完成的時候把緩存消除，整個流程對用戶是不可見的。外部管理就是把內部緩存文件的路徑以及管理全部都委托給外部，用戶在播完的時候會拿到一個原始文件，這種文件根據它設置好的格式重新進行封裝后再發給它。??經過優化，去年負荷在經過引入調度之后，秒開率小于五百毫秒大概占43%，大于五百毫秒到一千毫秒有36.72%。整體秒開率能達到75%以上。?2.3 災備策略
?
播放器優化過程當中遇到很多坑。比如網絡路由變換，在播放器從CDN某一個節點進行拉流的時候路由從4G變到WiFi。經過測試，如果從原節點拉流，可能有三種情況。第一種可以正常拉到流，第二種情況，沒有流，CDN直接就把流停了，第三種情況，會發出時間戳異常的流。這三種情況全是CDN的行為沒法預期。因此對于網絡變更，會引入自動重聯的機制。無論當前流是不是可靠，都會自動強制重連一次來保證流的魯棒性。?CDN服務停止，統計平臺會發生報警，通過兩種方式：一種服務端調整下發權重，讓用戶重新拉流；第二種是客戶端內部有重聯機制。如果重連會依次按照當前CDN節點順序，依次向下重連。第二個，遇到邊緣節點分配錯誤。這種是比較普遍的，（因為比如說有些之前遇到了一些個小的運營商，他介紹的運營商，在的CDN廠商的一個列表里面并沒有備份，比如說它是一個教育網，但是在CDN那邊，它可能誤認為電信網，這樣有可能發生最極端的情況，以前在新疆、西藏那邊的一個用戶，節點直接給調到了山東，這樣用戶可能根本拉不到流）在災備要及時發現并且反饋給CDN，讓CDN及時調整節點。第三種，CDN返回視頻流有格式錯誤。因為在推流端有QS機制不停刷新SPS跟PPS信息，而CDN在早期有可能會因為頻繁變更而導致它的數據錯誤，這樣就導致播放器無法做到兼容。還有一種情況，在做SEI透穿的時候，有一些CDN會把的SEI信息強制關掉，這樣也達不到所要的效果。??服務端災備核心策略就是盡可能多下發CDN，而CDN里面最可靠的是自己的CDN和原站，通常作為最保險的CDN下發。內部會專門監測CDN的平臺質量，它監測平臺質量分為兩個方面，第一個方面就是會有心跳上報機制定時探測每個CDN，以及CDN下面可能分配結點的活躍度。第二個方面根據播放器上報的卡頓率來評判，實時向調度服務器匯報CDN情況，根據匯報結果綜合計算來評判當前CDN到底是不是可靠。?客戶端的災備。在合適的時機進行切流，因為不管怎么樣不能讓用戶產生拉不到流的這種情況。最開始會逐條拉送，CDN下發回來之后會拉第一個地址，第一個地址異常會拉第二個地址，當所有地址都拉不到會從原始地址進行拉流，經過這一系列的災備再拉不到流，還會依賴于外部設置的重新調度，以及重新重試的機制進行第二次災備。而在播放過程當中會完全依賴重置機制，這個重置機制對外的接口里面給用戶開放了足夠的靈活度，比如重試幾次或間隔，或者在他需要的時候進行重試。這樣做既可以保證拉流成功率，也可以省去應用層開發工作量。?3. 總結??卡頓不是播放器端的問題，播放器能夠體現出用戶感知卡頓的結果，最終體現的應該是整個視頻鏈路的質量問題，發生卡頓肯定是鏈路上某個節點有問題。?秒開優化的根本是需要在首屏流程中把耗時的操作移除，這樣只要拿到了第一個數據包就馬上進行解碼渲染，最快給用戶呈現畫面。?鏈路質量需要有完整的質量監控體系。第一是監測鏈路質量。第二,幫助選擇最優的鏈路質量，持續優化過程，以備后面拉流的用戶來每次都可以拿到最高質量的流。?在拉流過程當中通過合適的切流措施和多CDN的災備邏輯來保證拉流成功率。

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。同時，也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

LiveVideoStackCon 2019北京 音視頻技術大會 初版日程現已上線，掃描圖中二維碼或點擊【閱讀原文】了解大會最新日程。

總結

以上是生活随笔為你收集整理的移动端视频缓存保障与CDN调度优化的全部內容，希望文章能夠幫你解決所遇到的問題。

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