搞音視頻開發(fā)好些年，分享過許多博客文章，比如：前幾年發(fā)布的《FFmpeg Tips》系列，《Android 音頻開發(fā)》系列，《直播疑難雜癥排查》系列等等。最近想把多年來開發(fā)和優(yōu)化播放器的經(jīng)驗也分享出來，希望能幫助到音視頻領(lǐng)域的初學(xué)者。第一期文章要推出的內(nèi)容主要涉及到播放器比較核心的幾個技術(shù)點，大概的目錄如下：

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：空間域名、網(wǎng)站空間、營銷軟件、網(wǎng)站建設(shè)、科爾沁右翼前網(wǎng)站維護(hù)、網(wǎng)站推廣。

1.  播放器技術(shù)分享（1）：架構(gòu)設(shè)計

2. 播放器技術(shù)分享（2）：緩沖區(qū)管理

3. 播放器技術(shù)分享（3）：音畫同步

4. 播放器技術(shù)分享（4）：首開時間

5. 播放器技術(shù)分享（5）：延時優(yōu)化

本篇是系列文章的第四篇，主要聊一聊如何優(yōu)化播放器的首開時間。

1 首開時間的定義

首開時間：從點擊播放到第一幀畫面顯示出來的耗時。通常大家說的 “首屏秒開” 指的就是播放器的“首開時間”在 1s 以內(nèi)。

首開速度是用戶最簡單、最直接的體驗，所以通常是播放器開發(fā)中優(yōu)化的重點。

下面是一個典型的首開速度和用戶感受的關(guān)系表：

2 首開時間的影響因子

要優(yōu)化播放器的首開時間，我們得先了解一下影響播放器首開時間的因素有哪些，下圖簡單展示了播放器向服務(wù)器申請播放一個視頻流的全過程。

想優(yōu)化播放器的首開時間，首先關(guān)注一下播放流程中的每個環(huán)節(jié)，如圖所示，可能的優(yōu)化點列表如下：

1. 申請資源的播放 URL 地址的時機(jī)優(yōu)化 -> 爭取在用戶點擊播放之前拿到 URL

2. DNS 解析優(yōu)化 -> 提前完成 DNS 解析，并緩存結(jié)果

3. 服務(wù)器的連接和數(shù)據(jù)傳輸速度優(yōu)化 -> 主要是服務(wù)器節(jié)點與播放器之間的網(wǎng)絡(luò)傳輸優(yōu)化

4. 視頻流的媒體信息解析優(yōu)化 -> 主要是解析提取算法的優(yōu)化

5. 解碼和渲染策略優(yōu)化 -> GOP 緩存，確保首幀為關(guān)鍵幀解碼渲染

6. 其他優(yōu)化手段 -> 測速選線、解碼算法性能等

在這個過程中，每一個環(huán)節(jié)都有一些影響因子會決定播放器的首開時間，我們下面詳細(xì)展開優(yōu)化思路。

3 首開優(yōu)化方法

3.1 優(yōu)化 URL 的獲取時機(jī)

如圖是一個播放列表，每個視頻都會對應(yīng)一個資源的 URL 播放地址，如果在用戶點擊視頻后，APP 再去后臺業(yè)務(wù)服務(wù)器去申請這個 URL 播放地址，無疑增加了一次 HTTP 請求和應(yīng)答的耗時，特別是網(wǎng)絡(luò)不穩(wěn)定的時候，耗時更加明顯。

因此，這是一個可以在 APP 層進(jìn)行的優(yōu)化點：在拉取視頻播放列表的時候，“同時” 把視頻的 URL 播放地址也拉取下來，在用戶點擊視頻后無需再向服務(wù)器申請播放地址，即可立即開始播放了。

3.2 優(yōu)化 DNS 解析時間

視頻資源的 URL 地址，往往是包含域名的，比如：

http://jhuster.com/video/movie.mp4

播放器在播放前，需要先進(jìn)行 DNS 解析，把 jhuster.com 這個域名解析為一臺服務(wù)器的 IP 地址，然后才能通過 TCP 連接上去，發(fā)送資源請求。

我們在 17CE 網(wǎng)站上簡單測測這個域名解析的時間：

可以看到，平均 DNS 解析時間在 673ms 左右，但是在很多地區(qū)（比如：佛山市電信，北京市電信）解析時間都超過 2s 了，可想而知，在這些地區(qū) DNS 解析緩慢對播放器首開時間是致命的傷害。

為了確保所有地區(qū)的視頻播放不過于受 DNS 解析速度的影響，除了為視頻資源的域名購買付費的專業(yè) DNS 解析服務(wù)外，播放器層面也可以針對性地做一些優(yōu)化，如下圖所示：

播放器內(nèi)部新增一個 DNS 結(jié)果緩存模塊

1. 在異步線程定時執(zhí)行 DNS 解析，并把 “域名 & IP 表” 緩存在內(nèi)存中

2. 視頻播放時，直接查表，取出域名對應(yīng)的 IP 地址，送入播放器

注意事項：

1. 一個 APP 的資源域名個數(shù)是收斂的，不是無限個，所以可以在 APP 啟動的時候，送入播放器提前去完成 DNS 解析和緩存

2. 未提前配置的域名，在第一次解析的時候，依然會首開慢，但該域名第二次即可從本地緩存中取了

3. 需要注意緩存的 IP 地址的刷新：

• DNS 解析有一個 TTL 超時時間，到期前要記得重新解析刷新

• 監(jiān)測手機(jī)網(wǎng)絡(luò)切換事件，比如：WiFi 切換到 4G 后，需要清空緩存

舉個例子：

DNS Cache Map:  

如果要播放 URL：http://jhuster.com/video/movie.mp4

可直接替換為播放： http://185.199.108.153/video/moive.mp4

坑在哪 ？

當(dāng)我們真的用 ip 地址去播放的時候，會發(fā)現(xiàn)服務(wù)器會拒絕訪問，例如報如下錯誤：

原因：視頻資源的 CDN 服務(wù)商需要知道是 “誰” 在申請這個視頻資源 -> 為了計量和計費，服務(wù)商的判斷訪問依據(jù)是“域名”，所以直接使用 IP 訪問會遇到上述問題。

怎么解決 ？

1. HTTP  協(xié)議：有個 HOST 字段，記錄了服務(wù)器的域名

2. RTMP 協(xié)議：有個 tcUrl 參數(shù)，記錄了完整的播放器地址（含 服務(wù)器的域名）

其實 CDN 服務(wù)商并不是從 URL 取的域名，而是從 HTTP/RTMP 協(xié)議中的上述字段中 “提取” 的域名，因此，我們需要改造播放器底層的 HTTP/RTMP 代碼模塊，提供一個接口，可以把 URL 中原始的域名填入到上述協(xié)議字段中即可。

3.3 優(yōu)化服務(wù)器連接和數(shù)據(jù)傳輸時間

播放器通過 DNS 解析拿到了服務(wù)器的 IP 地址，下一步就是通過 TCP 連接服務(wù)器，然后發(fā)送請求讀取數(shù)據(jù)了。在這個過程中，與服務(wù)器的連接速度以及數(shù)據(jù)的傳輸時間非常重要，直接影響著首開體驗。

這個因素并不是在播放器層面可以執(zhí)行的優(yōu)化，因此就簡單提一下，優(yōu)化的關(guān)鍵因素在于服務(wù)器的負(fù)載、CDN 的節(jié)點分布和帶寬情況了。這也是為什么一般的 APP 公司會采購和使用 CDN 服務(wù)的原因了。

3.4 優(yōu)化媒體信息的讀取策略

視頻的媒體信息里都有啥 ？

1. 是否包含：音頻、視頻

2. 音頻、視頻的編碼格式，如 H.264，AAC 等

3. 視頻的信息，如 分辨率、幀率、碼率

4. 音頻的信息，如 采樣率、位寬、通道數(shù)

5. 碼流的總時長

6. 其他附加信息，如 作者、日期等

可見，媒體信息對于初始化播放器還是非常重要的。不同的音視頻封裝格式，媒體信息存放的位置也不太一樣，像 flv 格式，媒體信息往往直接存放在開頭，因此是比較容易第一時間讀取到的。而 mp4 格式，常常會遇到 moov 在尾部的情況，這種是播放器優(yōu)化的重點，如圖所示：

對于這種把媒體信息存放到了尾部的 mp4 文件，默認(rèn)的播放器需要把整個 mp4 全部下載下來才能拿到媒體信息，對首開是極其不友好的。

如何優(yōu)化呢 ？—— 雙 IO 技術(shù)

如圖所示，對于 moov 媒體信息在尾部的 mp4 文件，播放器讀取一定數(shù)據(jù)后，如果判斷 moov 在尾部，則可以暫停這個線程，同時啟動第二線程通過 http range 字段讀取尾部的 moov，從而拿到關(guān)鍵的媒體信息，這樣的技術(shù)策略的好處是：

1. 無需下載整個 mp4 即可播放 moov 在尾部的視頻

2. 第一個 IO 已下載的部分可繼續(xù)利用，不用丟棄

3.5 優(yōu)化媒體信息的解析時間

媒體信息解析的工作量在哪 ？

1. 判斷碼流的封裝格式，比如 mp4，flv，m3u8 等等

2. 根據(jù)封裝格式的協(xié)議約定，提取數(shù)據(jù)中的媒體信息

為了提高對非標(biāo)準(zhǔn)碼流的兼容性，ffmpeg 使用了一套非常復(fù)雜的解析策略，即使從碼流中已經(jīng)提取到了 metadata，依然會做各種 double check，比如，多次 try_decode_frame 測試是否真的可以成功解碼數(shù)據(jù)，從而導(dǎo)致底層基于 ffmpeg 的播放器，首開速度會在這里降下來。

如何優(yōu)化呢 ？如果是基于 ffmpeg 內(nèi)核的播放器，那么常用的手段如下：

1. 減小 probesize

2. 減小 analyzeduration

3. 預(yù)設(shè)碼流的音視頻格式

3.6 優(yōu)化首幀解碼和渲染

我們知道，編碼后的視頻幀是分 I、B、P 幀的，I 幀是關(guān)鍵幀，可獨立解碼出圖像；B/P 幀分別是前向預(yù)測幀/雙向參考幀，是需要參考 I 幀或前后幀才能解碼出圖像的。

因此，為了盡快解碼出首幀畫面，需要確保送入編碼器的首幀即是 I 幀。

如圖所示，在直播場景下，如果觀眾在 C 時間點拉流，則正好可以拉取到一個 I 幀，迅速完成解碼播放，實現(xiàn)秒開。但是如果不巧，正好在 A 時間點或者 B 時間點拉流，則會導(dǎo)致無法解碼，一直要等到下一個 I 幀才能完成解碼渲染。

因此，一般的直播云廠商，都會在服務(wù)端緩存一個 GOP 的數(shù)據(jù)，無論任何時候，播放器申請播放，都會首先下發(fā)這樣一個以 I 幀開頭的 GOP 數(shù)據(jù)，從而加快了播放器的解碼和首開。

對于播放器而言，需要注意的時候，當(dāng)?shù)谝粠€沒有渲染之前，先不要主動緩沖，而是盡快先渲染首幀。

4 總結(jié)

當(dāng)然，還有很多其他的播放器首開時間的優(yōu)化策略，測速選線、解碼算法性能等，用的不是很廣泛，這里就不展開介紹了。關(guān)于播放器的首開時間優(yōu)化，就分享這么多了，如有疑問的小伙伴歡迎來信 lujun.hust@gmail.com 交流。另外，也歡迎大家關(guān)注我的新浪微博 @盧_俊 或者 微信公眾號 @Jhuster 獲取最新的文章和資訊。

標(biāo)題名稱：播放器技術(shù)分享（4）：首開時間-創(chuàng)新互聯(lián)
URL網(wǎng)址：http://weahome.cn/article/csihdd.html