轉載地址
一. 出現問題
觀看自己開播的直播間，經常出現卡頓，而且畫面一卡6，7s，重新播放時會出現跳幀，卡頓頻率也較高，導致該App可用性極低。
二. 分析
1. 直播架構分析
根據log與抓包分析，其使用協議與後端架構如下：
直播server
國內：福建泉州（聯通）、廣東佛山、肇慶（電信）
國外：如果ss登陸韓國，則訪問韓國機房
拉流CDN
國內：潮州（聯通）、揭陽（電信）
國外：如果ss登陸韓國，則訪問韓國機房
推流協議
RTMP
拉流協議
Http-flv
觀看端播放器
bilibili-ijkplayer
2. log分析
跟進log，發現每當視頻卡住和播放時日誌如下：
04-06 16:43:27.027 19089-25159/? D/IJKMEDIA﹕ ffp_toggle_buffering_l: start
04-06 16:43:27.028 19089-25158/? D/AudioTrack﹕ pause() mState 0
04-06 16:43:27.028 19089-25123/? D/IJKMEDIA﹕ FFP_MSG_BUFFERING_START:
…
04-06 16:43:33.502 19089-25125/? D/IJKMEDIA﹕ ffp_toggle_buffering_l: end
04-06 16:43:33.503 19089-25123/? D/IJKMEDIA﹕ FFP_MSG_BUFFERING_END:
04-06 16:43:33.504 19089-25158/? D/AudioTrack﹕ start() mState 2
部分ijk-player源碼（ff_ffplay.c）
ijkplayer處理流程爲
read_thread—> stream_component_open—> decoder_start—> video_thread—>ffplay_video_thread
log中，觸發pause原因是：ffplay_video_thread在frame_decode時，如果不能從buffer中拿到新的frame，則觸發pause，直到buffer滿足播放要求後再start。
分析結果
按上面的代碼，應用卡頓直接原因：本地buffer爲空導致播放停止。但從主播端->觀看端整個流程看，網絡狀況、服務器性能都可能導致/加劇問題。
3. TCP抓包分析
由於App經常卡頓、且卡頓時間較長，爲確定是否網絡導致，在dump log同時，也抓了包：
雖然有所卡頓，這段時間內數據包還是陸續有來的，卡6、7s不是很正常！根據上述代碼，極有可能是App設置的IO buffer比較大，在網絡環境較差情況下，觸發start所需時間較長。
- 其他分析
在buffer方面，ijkplayer至少有2類buffer，一是上面提到的IO buffer，另外一類是顯示buffer。
IO線程把數據讀到後，再把數據餵給顯示線程，上述2類buffer分別屬於這2個線程。
在使用App過程中，當log中輸出D/AudioTrack﹕ start()後，畫面馬上更新（可能伴隨跳幀），且無延遲，所以推測：
該App顯示buffer相當小
有做額外的丟幀處理
這估計是導致該應用播放頻繁卡頓、且跳幀的原因!!!
三. 分析過程中的一些坑
1. Shawdowsocks
本次FQ在OpenWrt上直接部署ss-local進行全局FQ，在抓包時候發現 推流 與 拉流 服務器皆爲國內服務器，作爲一個海外直播App，國外用戶要FQ過來訪問牆內服務器實在費解，遂在ss-server上ping相關域名獲取ip，發現ss-server獲取的ip是國外，按ss原理，DNS解析應在ss-server執行。後面經過排查，發現問題出在OpenWrt上，OpenWrt處理流程是：接到請求，DNS解析（此時，域名對應ip已經解析完畢），出口時走ss-local，到ss-server，訪問之前DNS解析後的ip，所以之前是走了一圈國外再回國內，蛋疼！