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

七牛直播雲在 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 獲取最新的文章和資訊。