1. 從一次直播卡頓說起為什么我們還在談RTMP去年我?guī)鸵粋€(gè)朋友調(diào)試他的線上教育直播平臺(tái)高峰期用戶反饋卡頓嚴(yán)重。他用的是一套基于WebRTC的現(xiàn)代架構(gòu)理論上延遲更低。一通排查下來問題出在源站到邊緣節(jié)點(diǎn)的傳輸鏈路上他們?yōu)榱俗非蟮脱舆t在長(zhǎng)距離公網(wǎng)傳輸上直接用了WebRTC的P2P式傳輸結(jié)果網(wǎng)絡(luò)稍有波動(dòng)就瘋狂丟包重傳體驗(yàn)雪崩。最后我們?cè)谠凑竞瓦吘壒?jié)點(diǎn)之間換回了RTMP推流整個(gè)直播流的穩(wěn)定性立刻上了一個(gè)臺(tái)階。這個(gè)經(jīng)歷讓我再次意識(shí)到在流媒體這個(gè)領(lǐng)域新技術(shù)層出不窮但像RTMP這樣的“老將”因其設(shè)計(jì)的特定優(yōu)勢(shì)和廣泛的生態(tài)支持在很多核心場(chǎng)景下依然不可替代理解它遠(yuǎn)未過時(shí)。RTMP全稱Real-Time Messaging Protocol實(shí)時(shí)消息協(xié)議。這個(gè)名字聽起來有點(diǎn)“古早”它誕生于Flash盛行的年代由Macromedia公司后被Adobe收購(gòu)制定。隨著Flash的落幕很多人以為RTMP也該進(jìn)博物館了。但事實(shí)恰恰相反它從一種“端到端”的協(xié)議轉(zhuǎn)型成為了流媒體服務(wù)器內(nèi)部、以及從推流端到服務(wù)器之間最主力的“生產(chǎn)協(xié)議”或“傳輸協(xié)議”。你今天看到的絕大多數(shù)直播無論是手機(jī)開播還是專業(yè)導(dǎo)播臺(tái)輸出推流到云服務(wù)商的第一站大概率還是RTMP。它就像物流體系中的“集裝箱”標(biāo)準(zhǔn)、可靠雖然不一定直接送到用戶家門口最終用戶觀看可能通過HLS、DASH、FLV等協(xié)議但在干線運(yùn)輸上效率極高。掌握RTMP對(duì)于從事音視頻開發(fā)、運(yùn)維、架構(gòu)設(shè)計(jì)的工程師來說是理解整個(gè)直播鏈路基石的關(guān)鍵。它不僅僅是一套報(bào)文格式更蘊(yùn)含了設(shè)計(jì)實(shí)時(shí)流媒體系統(tǒng)時(shí)關(guān)于連接、分包、同步、容錯(cuò)的核心思想。接下來我會(huì)結(jié)合協(xié)議原理和大量實(shí)踐中的細(xì)節(jié)帶你重新認(rèn)識(shí)這個(gè)經(jīng)典的協(xié)議。2. RTMP協(xié)議棧解剖一個(gè)基于TCP的“有序消息快遞系統(tǒng)”要理解RTMP不能孤立地看它本身得把它放在一個(gè)分層模型里。RTMP本身是一個(gè)應(yīng)用層協(xié)議它通常運(yùn)行在TCP協(xié)議之上。你可以把它想象成建立在可靠物流TCP基礎(chǔ)上的、一套專門用于傳輸音視頻等實(shí)時(shí)數(shù)據(jù)的“定制化快遞規(guī)則”。2.1 核心概念消息、塊流與時(shí)間戳RTMP協(xié)議的核心設(shè)計(jì)圍繞三個(gè)關(guān)鍵概念展開理解它們就理解了RTMP的工作模式。第一消息Message。這是RTMP中邏輯上完整的數(shù)據(jù)單元。比如一個(gè)音頻幀、一個(gè)視頻幀、一條控制命令如“開始播放”、“停止”都是一個(gè)獨(dú)立的消息。每個(gè)消息有自己的類型、長(zhǎng)度、時(shí)間戳和負(fù)載Payload。消息可能很大比如一個(gè)關(guān)鍵視頻幀可能達(dá)到幾十KB。第二塊Chunk。這是RTMP在網(wǎng)絡(luò)上實(shí)際傳輸?shù)臄?shù)據(jù)單元。為了解決TCP的“粘包”問題以及實(shí)現(xiàn)不同優(yōu)先級(jí)的消息交錯(cuò)傳輸比如不能讓一個(gè)大的視頻幀阻塞緊急的音頻幀RTMP引入了“分塊”機(jī)制。一個(gè)大的消息在發(fā)送前會(huì)被分割成多個(gè)大小固定的“塊”。每個(gè)塊帶有一個(gè)小的塊頭Chunk Header里面包含了流ID、時(shí)間戳、消息類型ID等信息用于在接收端重新組裝出原始消息。這個(gè)機(jī)制是RTMP實(shí)現(xiàn)低延遲和靈活性的基礎(chǔ)。第三塊流Chunk Stream。這是承載消息流的邏輯通道。一個(gè)RTMP連接上可以同時(shí)存在多個(gè)塊流每個(gè)塊流承載一類消息比如音頻流、視頻流、控制流。每個(gè)塊都有一個(gè)唯一的塊流IDChunk Stream ID接收端根據(jù)這個(gè)ID將收到的塊歸類到正確的流上進(jìn)行重組。這類似于在一條TCP連接上虛擬出的多條子通道。時(shí)間戳Timestamp是RTMP的“心跳”。它記錄了每個(gè)音視頻數(shù)據(jù)幀相對(duì)于流開始的相對(duì)時(shí)間單位是毫秒。音視頻的同步、DVR數(shù)字錄像時(shí)的打點(diǎn)、以及播放端的緩沖控制都嚴(yán)重依賴準(zhǔn)確的時(shí)間戳。這里有個(gè)關(guān)鍵點(diǎn)RTMP的時(shí)間戳是32位無符號(hào)整數(shù)這意味著它大約每49.71天2^32 / 1000 / 3600 / 24 ≈ 49.71會(huì)回繞一次。對(duì)于超長(zhǎng)直播服務(wù)器和客戶端都需要處理回繞邏輯否則會(huì)導(dǎo)致同步錯(cuò)亂這是實(shí)踐中一個(gè)隱蔽的坑。2.2 握手看似簡(jiǎn)單實(shí)則暗藏玄機(jī)RTMP連接始于一個(gè)三次握手過程。它不像TCP的SYN/ACK那么復(fù)雜但有自己的格式。C0C1客戶端發(fā)送客戶端首先發(fā)送一個(gè)字節(jié)的C0指明RTMP版本通常是3。緊接著發(fā)送1536字節(jié)的C1。C1分為兩部分前4字節(jié)是時(shí)間戳后1528字節(jié)是隨機(jī)數(shù)據(jù)。這個(gè)隨機(jī)數(shù)據(jù)在早期用于簡(jiǎn)單的身份驗(yàn)證現(xiàn)在主要是為了填充和對(duì)齊。S0S1S2服務(wù)器回復(fù)服務(wù)器回復(fù)S0版本、S1自己的時(shí)間戳和隨機(jī)數(shù)和S2。S2的內(nèi)容是對(duì)客戶端C1的“回聲”具體是取C1的時(shí)間戳和隨機(jī)數(shù)經(jīng)過一個(gè)固定的算法計(jì)算后返回。這個(gè)設(shè)計(jì)是為了驗(yàn)證兩端都能正確理解協(xié)議格式。C2客戶端確認(rèn)客戶端發(fā)送C2內(nèi)容是對(duì)服務(wù)器S1的“回聲”。注意很多初學(xué)者在自實(shí)現(xiàn)RTMP服務(wù)器或客戶端時(shí)容易在S2/C2的“回聲”計(jì)算上出錯(cuò)。實(shí)際上RTMP規(guī)范定義的計(jì)算方式一個(gè)簡(jiǎn)單的摘要算法并不用于安全校驗(yàn)更多是一種兼容性測(cè)試?，F(xiàn)在大多數(shù)開源實(shí)現(xiàn)如nginx-rtmp, SRS都采用了一種簡(jiǎn)化處理S2直接等于C1C2直接等于S1。這種“簡(jiǎn)單回聲”被廣泛接受為事實(shí)標(biāo)準(zhǔn)。如果你的實(shí)現(xiàn)需要與主流軟件互通建議采用這種簡(jiǎn)化模式否則可能會(huì)握手失敗。握手成功后雙方會(huì)通過connect命令建立網(wǎng)絡(luò)連接然后通過createStream命令創(chuàng)建邏輯上的流之后才是publish推流或play播放等操作。2.3 消息類型協(xié)議的靈魂RTMP定義了十幾種消息類型其中幾個(gè)最為關(guān)鍵命令消息Command Message, ID20或17承載AMF編碼的遠(yuǎn)程調(diào)用命令。這是RTMP的控制中樞。connect,createStream,publish,play,pause,onStatus狀態(tài)回調(diào)等都是命令消息。AMFAction Message Format是一種二進(jìn)制序列化格式效率比JSON高。音頻消息Audio Message, ID8承載音頻數(shù)據(jù)。消息頭會(huì)指明音頻編碼格式如AAC、MP3、采樣率、位深、聲道數(shù)等信息。視頻消息Video Message, ID9承載視頻數(shù)據(jù)。消息頭包含視頻編碼格式如H.264、H.265、幀類型關(guān)鍵幀I、預(yù)測(cè)幀P等等信息。識(shí)別關(guān)鍵幀I幀對(duì)于播放器快速啟動(dòng)和服務(wù)器切片生成HLS至關(guān)重要。數(shù)據(jù)消息Data Message, ID15或18承載元數(shù)據(jù)Metadata或自定義數(shù)據(jù)。例如onMetaData命令就通過數(shù)據(jù)消息發(fā)送里面包含了視頻的寬度、高度、幀率、音頻編碼信息等播放器必須先收到這個(gè)信息才能正確初始化解碼器。共享對(duì)象消息Shared Object和用戶控制消息User Control Message前者用于多客戶端狀態(tài)同步現(xiàn)在較少用后者用于發(fā)送流開始、緩沖區(qū)長(zhǎng)度等控制事件。3. 推流與拉流全流程拆解以O(shè)BS推流到自建服務(wù)器為例理論說得再多不如一次實(shí)際操作。我們以最常用的開源推流軟件OBS Studio推流到一個(gè)自建的Nginx RTMP模塊服務(wù)器然后用VLC播放器拉流觀看來完整走一遍RTMP的流程。這個(gè)場(chǎng)景非常普遍無論是個(gè)人主播還是企業(yè)內(nèi)網(wǎng)直播都會(huì)用到。3.1 搭建RTMP服務(wù)器Nginx with nginx-rtmp-module雖然現(xiàn)在有更專業(yè)的SRS、ZLMediaKit等流媒體服務(wù)器但Nginx搭配RTMP模塊依然是快速搭建、理解原理的最佳選擇。首先你需要一個(gè)Linux環(huán)境如Ubuntu。安裝依賴并編譯Nginx# 安裝編譯依賴 sudo apt-get update sudo apt-get install build-essential libpcre3 libpcre3-dev libssl-dev zlib1g-dev # 下載nginx和nginx-rtmp-module源碼 wget http://nginx.org/download/nginx-1.24.0.tar.gz wget https://github.com/arut/nginx-rtmp-module/archive/refs/tags/v1.2.2.tar.gz # 解壓 tar -zxvf nginx-1.24.0.tar.gz tar -zxvf v1.2.2.tar.gz # 編譯安裝 cd nginx-1.24.0 ./configure --add-module../nginx-rtmp-module-1.2.2 --with-http_ssl_module make sudo make install編譯成功后Nginx通常安裝在/usr/local/nginx。接下來配置RTMP服務(wù)。編輯/usr/local/nginx/conf/nginx.conf在末尾的http區(qū)塊外添加rtmp配置塊rtmp { server { listen 1935; # RTMP默認(rèn)端口 chunk_size 4096; # 塊大小影響傳輸效率 application live { # 定義一個(gè)名為live的應(yīng)用 live on; # 開啟直播 record off; # 關(guān)閉錄制按需開啟 # 允許所有推流和播放生產(chǎn)環(huán)境需要加鑒權(quán) allow publish all; allow play all; # 一個(gè)很有用的功能將流入的RTMP流轉(zhuǎn)推relay到其他服務(wù)器 # push rtmp://other-server/live/stream_key; } } }保存配置后啟動(dòng)Nginxsudo /usr/local/nginx/sbin/nginx?，F(xiàn)在一個(gè)監(jiān)聽在1935端口的RTMP服務(wù)器就運(yùn)行起來了。你可以用netstat -tlnp | grep 1935命令檢查端口是否監(jiān)聽成功。3.2 OBS推流配置與協(xié)議交互窺探在OBS中設(shè)置推流打開OBS進(jìn)入設(shè)置-推流。服務(wù)選擇自定義。服務(wù)器欄填寫rtmp://你的服務(wù)器IP/livelive對(duì)應(yīng)Nginx配置里的application名。串流密鑰填寫任意字符串比如test_stream。這個(gè)密鑰會(huì)作為流名稱。點(diǎn)擊確定然后點(diǎn)擊開始推流。此時(shí)OBS客戶端會(huì)與你的服務(wù)器你的服務(wù)器IP:1935建立TCP連接并開始RTMP握手。握手成功后會(huì)發(fā)生以下關(guān)鍵命令交互Connect:OBS發(fā)送connect命令附帶一個(gè)對(duì)象參數(shù)包含app應(yīng)用名這里是live、flashVer客戶端版本、tcUrl連接URL等信息。Window Acknowledgement Size Set Peer Bandwidth:服務(wù)器和客戶端會(huì)協(xié)商確認(rèn)窗口大小和帶寬。這是RTMP的流量控制機(jī)制防止發(fā)送方過快地淹沒接收方。onStatus (NetConnection.Connect.Success):服務(wù)器回復(fù)連接成功。createStream:OBS請(qǐng)求創(chuàng)建一個(gè)邏輯流。onStatus (NetStream.CreateStream.Success):服務(wù)器回復(fù)流創(chuàng)建成功。publish:OBS發(fā)送publish命令聲明要發(fā)布一個(gè)流流名就是之前填的串流密鑰test_stream并指定模式為live。onStatus (NetStream.Publish.Start):服務(wù)器回復(fù)發(fā)布開始。發(fā)送onMetaData:OBS緊接著會(huì)通過一個(gè)數(shù)據(jù)消息Message Type ID18發(fā)送onMetaData里面包含了視頻的編碼器如obs-x264、寬度、高度、幀率、音頻的編碼器如aac、采樣率、聲道等關(guān)鍵信息。播放器必須收到這個(gè)消息后才能正常解碼。持續(xù)發(fā)送音視頻數(shù)據(jù):此后OBS開始持續(xù)發(fā)送音頻消息ID8和視頻消息ID9。視頻消息中關(guān)鍵幀I幀的報(bào)文頭會(huì)有特殊標(biāo)記。如果你想直觀地看到這些報(bào)文可以使用Wireshark抓包工具。在Wireshark中過濾tcp.port 1935就能看到所有的RTMP交互。通過分析包內(nèi)容你能清晰地看到握手過程、命令的AMF編碼內(nèi)容、以及音視頻數(shù)據(jù)塊的流動(dòng)這對(duì)深度調(diào)試協(xié)議問題有巨大幫助。3.3 VLC拉流與播放器行為推流成功后就可以用播放器拉流了。打開VLC播放器選擇媒體-打開網(wǎng)絡(luò)串流輸入地址rtmp://你的服務(wù)器IP/live/test_stream點(diǎn)擊播放。VLC作為RTMP客戶端其連接流程與OBS類似但在play命令之后行為不同它會(huì)先接收服務(wù)器下發(fā)的onMetaData。然后開始接收音視頻數(shù)據(jù)。播放器會(huì)等待第一個(gè)視頻關(guān)鍵幀I幀才開始渲染畫面。如果推流端一直不發(fā)I幀或者播放器從中間一個(gè)非I幀的位置開始接流就會(huì)一直黑屏或卡住。這就是為什么很多直播系統(tǒng)強(qiáng)調(diào)“GOP”關(guān)鍵幀間隔不宜過長(zhǎng)通常建議2-4秒以保證新觀眾能快速進(jìn)入。播放器會(huì)根據(jù)時(shí)間戳對(duì)音視頻進(jìn)行同步播放并維護(hù)一個(gè)小的緩沖區(qū)Jitter Buffer來對(duì)抗網(wǎng)絡(luò)抖動(dòng)。4. RTMP的現(xiàn)代應(yīng)用場(chǎng)景與優(yōu)劣辯證盡管HLS和DASH在終端播放領(lǐng)域占據(jù)主導(dǎo)WebRTC在超低延遲互動(dòng)場(chǎng)景鋒芒畢露但RTMP在以下幾個(gè)場(chǎng)景中依然是中流砥柱這是由它的協(xié)議特性決定的。4.1 核心應(yīng)用場(chǎng)景推流“入口”與服務(wù)器間“干線”推流采集端到云服務(wù)/源站這是RTMP當(dāng)前最主流的用途。幾乎所有直播云服務(wù)商如阿里云、騰訊云、七牛云都首要支持RTMP推流地址。專業(yè)硬件編碼器、OBS、FFmpeg、移動(dòng)端SDK都將RTMP作為標(biāo)準(zhǔn)推流協(xié)議。原因在于它基于TCP提供可靠、有序的傳輸保證采集的每一幀數(shù)據(jù)都能到達(dá)服務(wù)器避免源頭丟幀。同時(shí)它的協(xié)議開銷相對(duì)固定易于服務(wù)器端進(jìn)行高效解析和分發(fā)。流媒體服務(wù)器內(nèi)部中轉(zhuǎn)Relay/Origin-Edge在大規(guī)模直播架構(gòu)中源站Origin產(chǎn)生流邊緣節(jié)點(diǎn)Edge就近服務(wù)用戶。源站和邊緣節(jié)點(diǎn)之間經(jīng)常使用RTMP進(jìn)行流傳輸。因?yàn)樗鼙３至鞯牡脱舆t特性相對(duì)于HLS同時(shí)又是標(biāo)準(zhǔn)的、被所有流媒體服務(wù)器廣泛支持的協(xié)議兼容性極佳。本文開頭提到的案例正是這個(gè)場(chǎng)景。編碼器到本地服務(wù)器的低延遲直播在企業(yè)內(nèi)網(wǎng)、活動(dòng)現(xiàn)場(chǎng)、廣電制播領(lǐng)域從攝像機(jī)/編碼器到本地直播服務(wù)器RTMP因其低延遲通常1-3秒和廣泛硬件支持仍是首選。4.2 優(yōu)勢(shì)與局限性在技術(shù)選型時(shí)如何權(quán)衡RTMP的優(yōu)勢(shì)基于TCP可靠傳輸不丟包不亂序保證數(shù)據(jù)完整性。對(duì)于需要存檔或二次處理的源流這是必須的。低延遲端到端延遲可以做到1-3秒滿足大多數(shù)直播互動(dòng)需求如彈幕、打賞。生態(tài)成熟工具鏈完善幾乎所有編碼工具、服務(wù)器軟件、播放庫都支持RTMP開發(fā)和調(diào)試成本低。協(xié)議狀態(tài)豐富通過命令消息可以精確控制流的生命周期發(fā)布、播放、暫停、停止并獲取明確的狀態(tài)反饋。支持動(dòng)態(tài)碼率切換雖然不如HLS的ABR那么普遍但RTMP本身可以通過多個(gè)音視頻流實(shí)現(xiàn)簡(jiǎn)單的碼率切換。RTMP的局限性原生不支持HTTP/HTTPS使用單獨(dú)的1935端口可能在企業(yè)防火墻或某些嚴(yán)格網(wǎng)絡(luò)環(huán)境下被阻斷。雖然可以通過WSWebSocket封裝成RTMP over WebSocket來解決但增加了復(fù)雜性。不適合大規(guī)模CDN分發(fā)到終端用戶TCP的隊(duì)頭阻塞問題在擁塞網(wǎng)絡(luò)下會(huì)影響多個(gè)用戶每個(gè)用戶一個(gè)長(zhǎng)連接服務(wù)器連接數(shù)壓力大。因此面向海量觀眾的分發(fā)通常會(huì)在邊緣服務(wù)器將RTMP轉(zhuǎn)換為HLS或DASH等基于HTTP的協(xié)議。協(xié)議較復(fù)雜報(bào)文頭有冗余相比一些更現(xiàn)代的協(xié)議RTMP的握手和分塊機(jī)制顯得有些“重”。對(duì)瀏覽器支持不友好原生需要FlashFlash淘汰后瀏覽器端播放需依靠MSEMedia Source Extensions將FLV格式RTMP的傳輸格式進(jìn)行解封裝或者通過服務(wù)器轉(zhuǎn)協(xié)議。技術(shù)選型建議推流/上行采集 - 服務(wù)器優(yōu)先選擇RTMP。穩(wěn)定可靠生態(tài)無敵。服務(wù)器源站 - 邊緣服務(wù)器視情況選擇RTMP或SRT。RTMP兼容性好SRT在對(duì)抗惡劣網(wǎng)絡(luò)如公網(wǎng)長(zhǎng)傳方面更有優(yōu)勢(shì)但生態(tài)稍弱。邊緣服務(wù)器 - 終端用戶Web/H5選擇HLS或DASH。兼容性好支持自適應(yīng)碼率穿透性強(qiáng)。終端用戶超低延遲互動(dòng)如連麥選擇WebRTC。5. 進(jìn)階實(shí)踐使用FFmpeg進(jìn)行RTMP流分析與故障排查作為“音視頻領(lǐng)域的瑞士軍刀”FFmpeg是處理RTMP流不可或缺的工具。它不僅能推拉流更是強(qiáng)大的分析和排查利器。5.1 使用FFmpeg作為RTMP客戶端1. 拉流并保存為文件ffmpeg -i rtmp://server/live/stream -c copy output.flv-c copy表示直接復(fù)制流不重新編碼速度最快能保留原始質(zhì)量。保存為FLV格式是因?yàn)镽TMP傳輸?shù)姆庋b格式就是FLV Tag。2. 推流到服務(wù)器ffmpeg -re -i input.mp4 -c copy -f flv rtmp://server/live/stream_key-re以原始幀率讀取輸入文件模擬實(shí)時(shí)流。沒有這個(gè)參數(shù)FFmpeg會(huì)以最快速度推流服務(wù)器可能因?yàn)榻邮者^快而丟包。-c copy音視頻流直接復(fù)制。-f flv指定輸出格式為FLV這是RTMP推流需要的封裝格式。5.2 深度分析流信息與排查問題FFmpeg的-v參數(shù)可以控制日志級(jí)別debug級(jí)別會(huì)打印出極其詳細(xì)的信息是排查協(xié)議問題的神器。1. 檢查流基本信息ffmpeg -i rtmp://server/live/stream這個(gè)命令會(huì)嘗試連接并解析流輸出視頻編碼格式、分辨率、幀率、音頻編碼格式、采樣率、碼率等核心信息。如果連接失敗會(huì)直接報(bào)錯(cuò)這是檢查推流地址是否有效、服務(wù)器是否可達(dá)的最快方法。2. 調(diào)試模式分析握手與交互ffmpeg -v debug -i rtmp://server/live/stream -f null -這個(gè)命令會(huì)輸出海量的調(diào)試日志。你可以從中看到[rtmp]開頭的行顯示了RTMP握手handshake、連接connect、創(chuàng)建流createStream、播放play等全過程。[flv]開頭的行顯示了接收到的FLV Tag即RTMP消息的詳細(xì)信息包括類型audio/video/script data、大小、時(shí)間戳dts/pts。如果連接失敗日志會(huì)精確地停在出錯(cuò)的那一步比如“握手超時(shí)”、“服務(wù)器返回錯(cuò)誤NetStream.Play.StreamNotFound”等。3. 一個(gè)典型排查案例流存在但播放黑屏假設(shè)你能用FFmpeg成功-i獲取到流信息但用播放器打開卻黑屏或有聲無畫。第一步檢查關(guān)鍵幀。用FFmpeg檢查流的前幾秒是否有視頻幀ffmpeg -v quiet -i rtmp://server/live/stream -map v:0 -c copy -f null - 21 | grep frame如果輸出顯示很快有幀數(shù)增加說明有視頻數(shù)據(jù)。進(jìn)一步可以檢查關(guān)鍵幀間隔是否過長(zhǎng)。一個(gè)簡(jiǎn)單粗暴的方法是使用ffprobe分析ffprobe -v error -select_streams v -show_entries packetpts_time,flags -of csv rtmp://server/live/stream | grep -n K這會(huì)列出所有關(guān)鍵幀flags中包含K及其時(shí)間戳。如果第一個(gè)關(guān)鍵幀出現(xiàn)在幾十秒之后那播放器自然要緩沖幾十秒才能看到畫面。解決方案是調(diào)整推流端如OBS的輸出設(shè)置將“關(guān)鍵幀間隔”Keyframe Interval設(shè)置為2秒相當(dāng)于GOP2*幀率。第二步檢查元數(shù)據(jù)。在FFmpeg的debug日志中搜索onMetaData。如果沒有找到或者元數(shù)據(jù)中缺少width/height信息播放器也無法初始化視頻渲染窗口。這可能是推流端未正確發(fā)送元數(shù)據(jù)。在OBS中這通常是默認(rèn)發(fā)送的但某些自定義推流程序可能會(huì)遺漏。第三步檢查時(shí)間戳。在debug日志中注意音視頻包的dts解碼時(shí)間戳是否連續(xù)遞增。如果出現(xiàn)時(shí)間戳回跳或巨大跳躍會(huì)導(dǎo)致播放器同步混亂。這通常是推流端編碼器的問題。通過FFmpeg這把手術(shù)刀你可以深入到RTMP流的每一個(gè)細(xì)節(jié)絕大多數(shù)推流、拉流問題都能找到根因。掌握這些命令是流媒體工程師調(diào)試能力的體現(xiàn)。