視頻為什么會卡頓？
造成播放端卡頓的原因主要有三種：
原因1：推流幀率太低
如果主播端手機性能較差，或者有很占 CPU 的后臺程序在運行，可能導致視頻的幀率太低。正常情況下 FPS 達到每秒15幀以上的視頻流才能保證觀看的流暢度，如果 FPS 低于10幀，可以判定為幀率太低，這會導致全部觀眾的觀看體驗都很卡頓。當然如果主播端畫面本身變化就很少，如靜態(tài)畫面或 PPT 播放等場景，則不受該原因影響。
原因2：上傳阻塞
主播的手機在推流時會源源不斷地產(chǎn)生音視頻數(shù)據(jù)，但如果手機的上傳網(wǎng)速太小，那么產(chǎn)生的音視頻數(shù)據(jù)都會被堆積在主播的手機里傳不出去，上傳阻塞會導致全部觀眾的觀看體驗都很卡頓。
國內(nèi)運營商提供的寬帶上網(wǎng)套餐中，下載網(wǎng)速雖然已經(jīng)達到了10Mbps、20Mbps甚至是100Mbps、200Mbps，但上傳網(wǎng)速卻還一直限制的比較小，很多小城市的上行網(wǎng)速最快是512Kbps（也就是每秒最多上傳64KB的數(shù)據(jù)）。
Wi-Fi 上網(wǎng)遵循 IEEE 802.11 規(guī)定的載波多路偵聽和沖突避免標準，簡言之就是一個 Wi-Fi 熱點同時只能跟一個手機通訊，其它手機在跟熱點通訊前都要先探測或詢問自己是否能夠通訊，所以一個 Wi-Fi 熱點使用的人越多就越慢。同時 Wi-Fi 信號受建筑墻體的屏蔽干擾很嚴重，而一般的中國普通家庭很少在裝修時考慮好 Wi-Fi 路由器和各個房間的信號衰減問題，可能主播本人也不清楚自己做直播的房間離家里的路由器究竟穿了幾堵墻。
原因3：下行不佳
就是觀眾的下載帶寬跟不上或者網(wǎng)絡很波動，例如直播流的碼率是2Mbps的，也就是每秒鐘有2M比特的數(shù)據(jù)流要下載下來，但如果觀眾端的帶寬不夠，就會導致觀眾端體驗非?？D。 下行不佳只會影響當前網(wǎng)絡環(huán)境下的觀眾。
查看SDK狀態(tài)提示信息如果您使用的是騰訊云移動直播 SDK 來推流，該 SDK 提供了一種狀態(tài)反饋機制，每隔1秒 - 2秒就會將內(nèi)部各種狀態(tài)參數(shù)反饋出來，您可以通過注冊 TXLivePushListener 監(jiān)聽器來獲取這些狀態(tài)。相關(guān)狀態(tài)的說明如下：
| 推流狀態(tài) |
含義說明 |
| NET_STATUS_CPU_USAGE |
當前進程的 CPU 使用率和本機總體的 CPU 使用率。 |
| NET_STATUS_VIDEO_FPS |
當前視頻幀率，也就是視頻編碼器每條生產(chǎn)了多少幀畫面。 |
| NET_STATUS_NET_SPEED |
當前的發(fā)送速度（單位：kbps）。 |
| NET_STATUS_VIDEO_BITRATE |
當前視頻編碼器輸出的比特率，也就是編碼器每秒生產(chǎn)了多少視頻數(shù)據(jù)，單位： kbps。 |
| NET_STATUS_AUDIO_BITRATE |
當前音頻編碼器輸出的比特率，也就是編碼器每秒生產(chǎn)了多少音頻數(shù)據(jù)，單位： kbps。 |
| NET_STATUS_CACHE_SIZE |
音視頻數(shù)據(jù)堆積情況，這個數(shù)字超過個位數(shù)，即說明當前上行帶寬不足以消費掉已經(jīng)生產(chǎn)的音視頻數(shù)據(jù)。 |
| NET_STATUS_CODEC_DROP_CNT |
全局丟包次數(shù)，為了避免延遲持續(xù)惡性堆積，SDK 在數(shù)據(jù)積壓超過警戒線以后會主動丟包，丟包次數(shù)越多，說明網(wǎng)絡問題越嚴重。 |
| NET_STATUS_SERVER_IP |
連接的推流服務器的 IP，一般應該是離客戶端跳數(shù)比較少的就近服務器。 |
解決幀率太低問題1. 幀率太低的評判通過 移動直播 SDK 的 TXLivePushListener 的 VIDEO_FPS 的狀態(tài)數(shù)據(jù)，我們可以獲得當前推流的視頻幀率。正常來說每秒15幀以上的視頻流才能保證觀看的流暢度，常規(guī)推流如果 FPS 在10幀以下，觀眾就會明顯的感到畫面卡頓。
2. 針對性優(yōu)化方案
2.1 觀察 CPU_USAGE 的大小
通過移動直播 SDK 的 TXLivePushListener 的 CPU_USAGE 的狀態(tài)數(shù)據(jù)，我們可以獲得當前推流 SDK 的 CPU 占用情況和當前系統(tǒng)的 CPU 占用情況。如果當前系統(tǒng)的整體 CPU 使用率超過80%，那么視頻的采集和編碼都會受到影響，無法正常發(fā)揮作用；如果 CPU 使用率達到100%，那么主播端本身就已經(jīng)很卡，觀眾端要有流暢的觀看體驗顯然是不可能的。
2.2 確認誰在消耗 CPU
一款直播 App 中使用 CPU 的不可能只有 推流 SDK，彈幕、飄星、文本消息互動等都有可能會消耗一定的 CPU，這些都是不可避免的。如果單純要測試推流 SDK 的 CPU 占用情況，可以使用我們的 精簡版 DEMO 來觀察和評估。
2.3 不盲目追高分辨率
過高的視頻分辨率并不一定能帶來清晰的畫質(zhì)：首先，較高的分辨率要配合較高的碼率才能發(fā)揮效果，低碼率高分辨的清晰度很多時候比不上高碼率低分辨率。其次，像1280 x 720這樣的分辨率在平均5寸左右的手機屏幕上并不能看出優(yōu)勢，要想跟960 x 540的分辨率拉開差距，只有在 PC 上全屏觀看才能有明顯的感官差異。但較高的分辨率會顯著提升 SDK 的 CPU 使用率，因此常規(guī)情況下推薦使用 移動直播 SDK 中 TXLivePusher 的 setVideoQuality 設置高清檔即可，盲目追高分辨率有可能達不到預期的目標。
2.4 適當使用硬件加速
現(xiàn)在的智能手機都支持硬件編碼來降低視頻編碼對 CPU 的依賴，如果您發(fā)現(xiàn)您的 App 的 CPU 使用率過高，可以開啟硬件編碼來降低 CPU 使用率。TXLivePusher 的 setVideoQuality 的高清檔默認使用的是軟件編碼（硬件編碼在部分 Android 手機上的編碼效果不佳，馬賽克感很強），如果要使用硬件編碼，可以使用 TXLivePushConfig 的 enableHWAcceleration 選項開啟。
解決上傳阻塞問題據(jù)統(tǒng)計，視頻云客戶群80%以上的直播間卡頓問題，均是由于主播端上傳阻塞所致。
1. 上傳阻塞的評判
1.1：BITRATE 與 NET_SPEED 的關(guān)系
BITRATE( = VIDEO_BITRATE + AUDIO_BITRATE ) 指的是編碼器每秒產(chǎn)生了多少音視頻數(shù)據(jù)要推出去，NET_SPEED 指的是每秒鐘實際推出了多少數(shù)據(jù)，所以如果 BITRATE == NET_SPEED 的情況是常態(tài)，則推流質(zhì)量會非常良好；而如果 BITRATE >= NET_SPEED 這種情況的持續(xù)時間比較長，推流質(zhì)量就很難有什么保障。
1.2：CACHE_SIZE 和 DROP_CNT 的數(shù)值
BITRATE >= NET_SPEED 的情況一旦出現(xiàn)，編碼器產(chǎn)生的音視頻數(shù)據(jù)就會在主播的手機上積壓起來，積壓的嚴重程度以 CACHE_SIZE 這個狀態(tài)值展示出來，如果 CACHE_SIZE 超過警戒線，SDK 會主動丟棄一些音視頻數(shù)據(jù)，從而觸發(fā) DROP_CNT 的增長。下圖所示就是一個典型的上行阻塞，途中 CACHE_SIZE 始終在紅色警戒線以上，說明上行網(wǎng)絡不足以滿足數(shù)據(jù)的傳輸需求，也就是上行阻塞嚴重：
說明：
您可以在【直播控制臺】>【統(tǒng)計分析】里看到類似上圖的圖表。
2. 針對性優(yōu)化方案
2.1 主動提示主播
對于注重清晰度的場景下，通過合適的 UI 交互提示主播“當前網(wǎng)絡質(zhì)量很糟糕，建議您拉近離路由器的距離，避免 Wi-Fi 穿墻”是最好的選擇。
移動直播 SDK 的推流功能文檔中有涉及事件處理的介紹，您可以利用它來做到這一點，推薦的做法是：如果 App 在短時間內(nèi)連續(xù)收到移動直播 SDK 的多個 PUSH_WARNING_NET_BUSY 事件，則提示主播網(wǎng)絡關(guān)注一下當前網(wǎng)絡質(zhì)量，因為對于上行阻塞這種情況而言，主播本人是沒辦法通過視頻的表現(xiàn)感知到的，只能通過觀眾的提醒或者 App 的提醒來了解。
2.2 合理的編碼設置
如下是我們推薦的編碼設置（適合美女秀場，更多信息請參見 如何實現(xiàn)更好的畫質(zhì)？），可以通過 TXLivePusher 里的 setVideoQuality 接口進行相應檔位的設置：
| 檔位 |
分辨率 |
FPS |
碼率 |
使用場景 |
| 標清 |
360 * 640 |
15 |
400kbps - 800kbps |
如果您比較關(guān)注帶寬成本，推薦選擇該檔位，畫質(zhì)會偏模糊，但帶寬費用較高清檔要低 60%。 |
高清
（推薦） |
540 * 960 |
15 |
1200kbps |
如果您比較關(guān)注畫質(zhì)，推薦選擇該檔位，能確保絕大多數(shù)主流手機都能推出很清晰的畫面。 |
| 超清 |
720 * 1280 |
15 |
1800kbps |
慎用：如果您的場景多是小屏觀看不推薦使用，如果是大屏幕觀看且主播網(wǎng)絡質(zhì)量很好可以考慮。 |
優(yōu)化播放端
1. 卡頓與延遲如上圖，下行網(wǎng)絡的波動或者下行帶寬不夠，都會導致在播放過程中出現(xiàn)一段段的饑餓期（App 這段時間內(nèi)拿不到可以播放的音視頻數(shù)據(jù)）。如果想要讓觀看端的視頻卡頓盡量少，就要盡可能地讓 App 緩存足夠多的視頻數(shù)據(jù)，以保證它能平安度過這些“饑餓期”，但是 App 緩存太多的音視頻數(shù)據(jù)會引入一個新的問題，即高延遲，這對互動性要求高的場景是很壞的消息，同時如果不做延遲修正和控制，卡頓引起的延遲會有累積效應，就是播放時間越久，延遲越高，延遲修正做得好不好是衡量一款播放器是否足夠優(yōu)秀的關(guān)鍵指標。所以延遲和流暢是一架天平的兩端，如果過分強調(diào)低延遲，就會導致輕微的網(wǎng)絡波動即產(chǎn)生明顯的播放端卡頓。反之，如果過分強調(diào)流暢，就意味著引入大量的延遲（典型的案例就是 HLS（m3u8） 通過引入20秒 - 30秒的延遲來實現(xiàn)流暢的播放體驗）。
2. 針對性優(yōu)化方案為了能夠讓您無需了解過多流控處理知識就能優(yōu)化出較好的播放體驗，騰訊云 移動直播 SDK 經(jīng)過多個版本的改進，優(yōu)化出一套自動調(diào)節(jié)技術(shù)，并在其基礎(chǔ)上推出了三種比較優(yōu)秀的 延遲控制方案：
自動模式：如果您不太確定您的主要場景是什么，可以直接選擇這個模式。
說明：
把 TXLivePlayConfig 中的 setAutoAdjustCache 開關(guān)打開，即為自動模式。在該模式下播放器會根據(jù)當前網(wǎng)絡情況，對延遲進行自動調(diào)節(jié)（默認情況下播放器會在1秒 - 5秒這個區(qū)間內(nèi)自動調(diào)節(jié)延遲大小，您可以通過 setMinCacheTime 和 setMaxCacheTime 對默認值進行修改），以保證在足夠流暢的情況下盡量降低觀眾跟主播端的延遲，確保良好的互動體驗。
極速模式：主要適用于秀場直播等互動性高，并且對延遲要求比較苛刻的場景。
說明：
極速模式設置方法是 setMinCacheTime = setMaxCacheTime = 1s ，自動模式跟極速模式的差異只是 MaxCacheTime 有所不同 （極速模式的 MaxCacheTime 一般比較低，而自動模式的 MaxCacheTime 則相對較高 ），這種靈活性主要得益于 SDK 內(nèi)部的自動調(diào)控技術(shù)，可以在不引入卡頓的情況下自動修正延時大小，而 MaxCacheTime 反應的就是調(diào)節(jié)速度：MaxCacheTime 的值越大，調(diào)控速度會越發(fā)保守，卡頓概率就會越低。
流暢模式：主要適用于游戲直播等大碼率高清直播場景。
說明：
- 當把播放器中的 setAutoAdjustCache 開關(guān)關(guān)閉，即為流暢模式，在該模式下播放器采取的處理策略跟 Adobe Flash 內(nèi)核的緩存出策略如出一轍：當視頻出現(xiàn)卡頓后，會進入 loading 狀態(tài)直到緩沖區(qū)蓄滿，之后進入 playing 狀態(tài)，直到下一次遭遇無法抵御的網(wǎng)絡波動。默認情況下緩沖大小為5秒，您可以通過 setCacheTime 進行更改。
- 在延遲要求不高的場景下，這種看似簡單的模式會更加可靠，因為該模式本質(zhì)上就是通過犧牲一點延遲來降低卡頓率。
|
