1、問題背景網絡
問題表現:近期一客戶用網絡攝像頭推流到觀止雲,但推上來的視頻老是一卡一卡的,排除了我方CDN自身問題後,咱們把排查視線轉移到客戶推上來的rtmp流。運維
須要的工具:srs_rtmp_dump、tcpdump、wiresharktcp
客戶推流工具:網絡攝像頭,推送RTMP流工具
2、問題排查過程url
工具:srs_rtmp_dump,srs_rtmp_dump的語法以下:視頻
./srs_rtmp_dump -r url [-o output] [-s swfUrl] [-t tcUrl] [-p pageUrl] [-C conndata] [–complex] [-h]直播
經常使用參數:class
最簡單的用法:stream
./srs_rtmp_dump -r rtmp://127.0.0.1:1935/live/livestream -o output.flv終端
固然也可使用重定向符號」>」把輸出內容輸出到文本文件。
OK,let’s go
返回以下結果:
從時間戳上來看,貌似看不出什麼問題。但總感受哪裏怪怪的,你看出什麼問題來了嗎?
工具:tcpdump wireshark
用到的tcpdump的參數:
使用以下命令開始抓包:
用wireshark開始分析數據:
看序號爲545的這個包和以前的幾個包,時間戳是正常的,545包的時間戳是:7855535,咱們繼續往下看。
序號547的包時間戳是16777215,(此處省略一個字),時間戳跳變了,咱繼續。
這幾個包有問題,而後呢?
而後時間戳恢復了,從出問題的時間戳到恢復的時間戳,時間差大約0.07s。繼續看看下面的包,重複該過程。
OMG,大坑啊,真相大白了,問題就是這個時間戳跳變引發的卡頓!
可是,處理又怎麼處理呢?客戶辛辛苦苦淘的二手高端大氣的攝像頭總不能扔了吧?開門,放程序猿……
下面是從給客戶反饋問題緣由到解決問題過程的對話:
雖然程序猿解決這個問題也就不到一個小時,可是對於客戶來講但是解決了大問題。
3、結語
以上實例講述的過程其實在直播推流環節可能會常常遇到的問題,最主要緣由是推流工具終端的不規範,其它還有諸如sps的問題、音視頻混合非單增問題等,觀止雲團隊都會基於自身在直播領域的運維和服務經驗,對其一一扼殺。
推流環節在整個直播過程當中其實只是冰山一角,後續觀止雲運維GG們會陸續爲你們實例分享直播流程中遇到的更多奇葩問題以及解決辦法。咱們不試圖獲得您的掌聲,唯願安靜的撫慰每個直播人操勞的心,您的順手轉發就是給咱們最大的慰藉。