一. 出現(xiàn)問題

  • 觀看自己開播的直播間，經(jīng)常出現(xiàn)卡頓，而且畫面一卡6，7s，重新播放時(shí)會(huì)出現(xiàn)跳幀，卡頓頻率也較高，導(dǎo)致該App可用性極低。

二. 分析

1. 直播架構(gòu)分析

  • 根據(jù)log與抓包分析，其使用協(xié)議與后端架構(gòu)如下：
    seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)

  • 直播server

    • 國內(nèi)：福建泉州（聯(lián)通）、廣東佛山、肇慶（電信）

    • 國外：如果ss登陸韓國，則訪問韓國機(jī)房

  • 拉流CDN

    • 國內(nèi)：潮州（聯(lián)通）、揭陽（電信）

    • 國外：如果ss登陸韓國，則訪問韓國機(jī)房

  • 推流協(xié)議

    • RTMP

  • 拉流協(xié)議

    • Http-flv

  • 觀看端播放器

    • bilibili-ijkplayer

2. log分析

  • 跟進(jìn)log，發(fā)現(xiàn)每當(dāng)視頻卡住和播放時(shí)日志如下：

    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）
    seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)
    seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)
    seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)

  • ijkplayer處理流程為

    • read_thread---> stream_component_open---> decoder_start---> video_thread--->ffplay_video_thread

    • log中，觸發(fā)pause原因是：ffplay_video_thread在frame_decode時(shí)，如果不能從buffer中拿到新的frame，則觸發(fā)pause，直到buffer滿足播放要求后再start。

  • 分析結(jié)果

    • 按上面的代碼，應(yīng)用卡頓直接原因：本地buffer為空導(dǎo)致播放停止。但從主播端->觀看端整個(gè)流程看，網(wǎng)絡(luò)狀況、服務(wù)器性能都可能導(dǎo)致/加劇問題。

3. TCP抓包分析

  • 由于App經(jīng)常卡頓、且卡頓時(shí)間較長，為確定是否網(wǎng)絡(luò)導(dǎo)致，在dump log同時(shí)，也抓了包：
    seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)

  • 雖然有所卡頓，這段時(shí)間內(nèi)數(shù)據(jù)包還是陸續(xù)有來的，卡6、7s不是很正常！根據(jù)上述代碼，極有可能是App設(shè)置的IO buffer比較大，在網(wǎng)絡(luò)環(huán)境較差情況下，觸發(fā)start所需時(shí)間較長。
    seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)

4. 其他分析

  • 在buffer方面，ijkplayer至少有2類buffer，一是上面提到的IO buffer，另外一類是顯示buffer。
    seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)

  • IO線程把數(shù)據(jù)讀到后，再把數(shù)據(jù)喂給顯示線程，上述2類buffer分別屬于這2個(gè)線程。

  • 在使用App過程中，當(dāng)log中輸出D/AudioTrack﹕ start()后，畫面馬上更新（可能伴隨跳幀），且無延遲，所以推測：

    • 該App顯示buffer相當(dāng)小

    • 有做額外的丟幀處理

  • 這估計(jì)是導(dǎo)致該應(yīng)用播放頻繁卡頓、且跳幀的原因!!!

三. 分析過程中的一些坑

1. Shawdowsocks

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

作者：hyddd
出處：http://www.cnblogs.com/hyddd/
本文版權(quán)歸作者所有，歡迎轉(zhuǎn)載，演繹或用于商業(yè)目的，但是必須說明本文出處（包含鏈接）。

http://www.cnblogs.com/hyddd/p/6678930.html