某直播App問題分析

一. 出現問題

• 觀看自己開播的直播間，經常出現卡頓，而且畫面一卡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所需時間較長。
  

4. 其他分析

• 在buffer方面，ijkplayer至少有2類buffer，一是上面提到的IO buffer，另外一類是顯示buffer。
  
• IO線程把數據讀到后，再把數據喂給顯示線程，上述2類buffer分別屬於這2個線程。
• 在使用App過程中，當log中輸出D/AudioTrack﹕ start()后，畫面馬上更新（可能伴隨跳幀），且無延遲，所以推測：
  • 該App顯示buffer相當小
  • 有做額外的丟幀處理
• 這估計是導致該應用播放頻繁卡頓、且跳幀的原因!!!

三. 分析過程中的一些坑

1. Shawdowsocks

• 本次翻牆在OpenWrt上直接部署ss-local進行全局翻牆，在抓包時候發現 推流 與 拉流 服務器皆為國內服務器，作為一個海外直播App，國外用戶要翻牆過來訪問牆內服務器實在費解，遂在ss-server上ping相關域名獲取ip，發現ss-server獲取的ip是國外，按ss原理，DNS解析應在ss-server執行。后面經過排查，發現問題出在OpenWrt上，OpenWrt處理流程是：接到請求，DNS解析（此時，域名對應ip已經解析完畢），出口時走ss-local，到ss-server，訪問之前DNS解析后的ip，所以之前是走了一圈國外再回國內，蛋疼！