《直播疑難雜症排查》之三：首開慢

七牛直播雲在 2016 年 6 月發佈以後，幫助廣大客戶解決過形形色色的問題，如直播卡頓、馬賽克、花屏、黑屏、雜音、音畫不一樣步等等等等，這其中，有一些是網絡緣由，有一些是開發者的使用姿式問題，有一些是參數配置錯誤，固然，也有一些是 SDK 自己的問題。

總結下來，若是開發者可以對直播領域的一些基礎知識有更深刻的瞭解，掌握一些基本的排障手段，不少問題是可以很快自行解決的，甚至也可以更好地防患於未然。

所以，繼《直播技術詳解》系列文章以後，咱們推出了這個新的系列《直播疑難雜症排查》，咱們會把協助客戶解決直播問題的經驗逐步分享出來，同時也會穿插一些音視頻開發的基礎知識和優化經驗，但願可以幫助到直播領域的開發者們。

---

本系列會涵蓋的內容包括但不限於以下一些主題：

• 播放失敗

• 播放卡頓

• 首開慢

• 延時高

• 音畫不一樣步

• 馬賽克嚴重

• 播放黑屏、花屏、綠屏

• 播放雜音、噪音、回聲

• 點播拖動不許

• 直播發熱問題

• 其餘問題（待續）

本文是 《直播疑難雜症排查》系列的第三篇文章，咱們來看看直播過程當中，最重要的一個性能指標：首開。

---

首開慢的表現

點擊播放後，須要好幾秒才能顯示播放畫面。

常見首開慢問題排查

點擊播放後才從服務器取播放地址

播放視頻，第一件事就是要拿到播放地址，大多數直播 App，主播的播放地址是由 App 向服務端發 HTTP GET 請求才能拿到的，所以，何時去「拿」 這個播放地址，顯得相當重要，常見的作法有以下兩種：

App 拉取正在視頻列表的時候

用戶點擊某個視頻，跳轉到播放界面以後

顯然，後者的用戶體驗明顯會比前者差，由於經過 HTTP GET 請求播放地址的過程，無形增長了首開時間，特別是在弱網下，會更慢。

DNS 解析慢

不一樣的播放域名，DNS 解析有快有慢，再加上 DNS 解析服務的緩存策略，在本地沒有該域名緩存的狀況下，會逐級向更高級的域名服務器查詢域名，所以，播放域名解析的耗時，會對首開產生不小的影響。

爲了有效下降 DNS 解析對首開的影響，咱們能夠提早完成播放域名->IP 地址的解析，並緩存起來，播放的時候，直接傳入帶 IP 地址的播放地址，從而省去了 DNS 解析的耗時。

若是要支持用 IP 地址播放，是須要修改底層 ffmpeg 源碼的，目前咱們七牛的 PLDroidPlayer 就支持這樣的播放地址：
URL 格式「protocol://ip/path?domain=xxxx.com」

播放策略緣由

播放首開時間的定義，就是從點擊播放到第一幀畫面顯示出來的耗時，所以，咱們須要盡一切可能加快播放進度。

不少側重點播的播放器，爲了減小卡頓，會有一些緩衝策略，當緩衝足夠多的數據以後 ，再送入解碼播放。

而爲了加快首開效果，須要對播放的緩衝策略作一些調整，若是第一幀尚未渲染出來的狀況下，不要作任何緩衝，直接送入解碼器解碼播放，這樣就能夠保證沒有任何由於「主動」緩衝帶來的首開延時。

播放參數配置

全部基於 ffmpeg 的播放器，都會遇到 avformat_find_stream_info 這個函數耗時比較久，從而增大了首開時間，該函數主要做用是經過讀取必定字節的碼流數據，來分析碼流的基本信息，如編碼信息、時長、碼率、幀率等等，它由兩個參數來控制其讀取的數據量大小和時長，一個是 probesize，一個是 analyzeduration。

減小 probesize 和 analyzeduration 能夠有效地減小 avformat_find_stream_info 的函數耗時，從而加快首開，可是須要注意的是，設置地過小可能會致使讀取的數據量不足，從而沒法解析出碼流信息，致使播放失敗，或者出現只有音頻沒有視頻，只有視頻沒有音頻的問題。

服務端線路緣由

當播放端的優化作到極限後，剩下的首開快慢的決定性因素就是服務端的線路了，服務端的線路主要有哪些方面會影響首開呢？

• 冷熱流

當你去附近的邊緣服務器節點拉取某個流的時候，若是最近沒有任何人從該服務器拉過這個流，那麼這臺服務器就須要逐級向源頭拉流，並且該服務器也沒有任何 GOP 緩存，從而產生比較大的首開延時。

• 邊緣節點的 TTL

同等大小的數據，客戶端距離服務器越近，ttl 越小，那麼傳輸速度也就越快，首開也會越快。
服務器的響應速度

影響服務器響應速度的因素，一個是跟服務器的協議層優化有關，另外一個就是服務端的負載和性能了，服務器當前負載越大，響應天然越慢。

下面給出一張圖，來直觀的感覺一下服務端在加速首開這件事上的關鍵做用：

七牛的實時流網絡 (LiveNet)，咱們會根據網絡流量、各節點的鏈接、負載情況及到用戶網絡的響應時間等綜合信息，實時地將用戶的請求調度到最佳服務節點上，同時可計算出最佳服務節點與視頻源節點的最佳網絡路徑，使用戶能夠更快速的獲取到視頻內容，提升視頻服務的響應速度和用戶體驗。

小結

關於首開慢的排查大體就介紹到這裏了，下篇咱們將對延遲高這個話題進行探討。

---

本文做者：盧俊@七牛雲。若是有你感興趣的問題，可是不在上述列表中，也能夠來信 lujun.hust@gmail.com 交流，歡迎關注新浪微博 @盧_俊 或者 微信公衆號 @Jhuster 獲取最新的文章和資訊。