很多朋友一上來(lái)就是那句話“我用MQTT能不能直接拉無(wú)人機(jī)的視頻流” 我去年被問(wèn)過(guò)不下十次其中有做巡檢項(xiàng)目的有做直播的還有在學(xué)校做畢設(shè)的。說(shuō)實(shí)話第一次聽到這個(gè)問(wèn)題時(shí)我愣了一下因?yàn)镸QTT和視頻流之間的關(guān)系一開始就存在一個(gè)巨大的誤解。如果你正準(zhǔn)備用某頭部無(wú)人機(jī)廠商的SDK做類似的事這篇文章就是給你排雷的。搞清楚MQTT在視頻鏈路里到底能干什么、不能干什么以及正確的接入姿勢(shì)能幫你少走至少兩周彎路。先說(shuō)結(jié)論MQTT不是一個(gè)用于傳輸實(shí)時(shí)視頻幀的協(xié)議它最擅長(zhǎng)的場(chǎng)景是傳遞“控制指令”和“狀態(tài)信息”。但MQTT確實(shí)可以成為無(wú)人機(jī)實(shí)時(shí)視頻流方案里的關(guān)鍵一環(huán)——它負(fù)責(zé)告訴你“視頻流在哪里、如何訪問(wèn)、當(dāng)前是否可用”真正的畫面數(shù)據(jù)則通過(guò)RTSP、RTMP這類流媒體協(xié)議走。這個(gè)分工一旦理順后面很多事情就都順了。1. 先潑一盆冷水MQTT天生不是用來(lái)傳視頻流的很多人把MQTT理解成“又快又輕的實(shí)時(shí)消息通道”然后天然覺(jué)得它也能傳視頻。這個(gè)想法可以理解但實(shí)際一算賬就知道完全不現(xiàn)實(shí)。1.1 協(xié)議定位MQTT是“消息”協(xié)議不是“流媒體”協(xié)議MQTT全稱Message Queuing Telemetry Transport設(shè)計(jì)的初衷是給低帶寬、高延遲網(wǎng)絡(luò)下的傳感器和小數(shù)據(jù)包用的。它圍繞的是“發(fā)布/訂閱”模型一條消息就是一個(gè)獨(dú)立的、有界的字節(jié)塊。發(fā)布者發(fā)出消息Broker轉(zhuǎn)發(fā)給訂閱者。這套機(jī)制用來(lái)傳溫度、坐標(biāo)、狀態(tài)碼、命令指令非常合適。但視頻流是什么是一路持續(xù)不斷的、有強(qiáng)時(shí)序關(guān)系的海量數(shù)據(jù)。以1080p、30幀/秒、H.264編碼的畫面為例碼率通常在2Mbps到8Mbps之間。哪怕取中等偏低的4Mbps一秒鐘就是512KB一分鐘就是30MB。MQTT的消息模型會(huì)把每一幀或每一個(gè)數(shù)據(jù)塊打包成獨(dú)立消息。如果在每個(gè)包里塞太多數(shù)據(jù)消息會(huì)變得巨大如果塞得太少消息數(shù)量又會(huì)爆炸。無(wú)論哪種情況MQTT的協(xié)議開銷和Broker轉(zhuǎn)發(fā)邏輯都在為它本不該承擔(dān)的職責(zé)付出代價(jià)。1.2 算一筆賬為什么視頻幀塞不進(jìn)MQTT我們來(lái)做點(diǎn)具體計(jì)算。假設(shè)你非要用MQTT傳一幀畫面。一幀1080p的H.264關(guān)鍵幀可能達(dá)到50KB到150KB普通P幀也要幾KB到幾十KB。按照MQTT over TCP的機(jī)制每個(gè)PUBLISH包除了Payload本身外還有固定頭、主題名、報(bào)文標(biāo)識(shí)符以及QoS確認(rèn)報(bào)文。這些額外開銷雖然小但在高頻小包場(chǎng)景下會(huì)被顯著放大。更麻煩的是TCP的隊(duì)頭阻塞問(wèn)題。MQTT默認(rèn)跑在TCP上一旦某個(gè)包丟了或者延遲后續(xù)包全都要等在緩沖區(qū)里。視頻流恰恰是不能容忍這種“排隊(duì)”的畫面會(huì)突然卡住然后又猛地跳一下。你可以把TCP上跑MQTT傳視頻幀理解成讓一輛三輪車在早高峰去拉一整個(gè)集裝箱——能走但極其痛苦。我們?cè)偎阋唤M局域網(wǎng)內(nèi)的實(shí)驗(yàn)數(shù)字。用MQTT傳320x240的JPEG幀質(zhì)量稍微壓低一點(diǎn)單幀大小約15KB到30KB。按每秒5幀算就是每秒75KB到150KB勉強(qiáng)能接受。但如果你需要真正意義上的“實(shí)時(shí)視頻”比如30幀每秒的720p畫面單幀至少30KB到80KB消息量瞬間到每秒1MB以上再加上Base64編碼的膨脹很快就會(huì)觸到Broker和客戶端的處理瓶頸。1.3 流媒體協(xié)議才是干這行的真正用來(lái)傳視頻的協(xié)議是RTSP、RTMP、WebRTC、SRT這一類。RTSP負(fù)責(zé)會(huì)話控制RTP負(fù)責(zé)承載媒體數(shù)據(jù)它們對(duì)時(shí)間戳、丟包重傳、擁塞控制都有專門設(shè)計(jì)。拿某個(gè)攝像頭模塊舉例廠商SDK通常會(huì)把機(jī)載相機(jī)的視頻流以RTSP地址的形式暴露給開發(fā)者比如“rtsp://192.168.1.10:8554/live”。你只要用支持RTSP的播放器或庫(kù)去拉這個(gè)地址就能看到實(shí)時(shí)畫面。所以你要做的不是我能不能用MQTT傳視頻而是讓MQTT回到它該待的位置——信令層。它是“傳令兵”不是“搬運(yùn)工”。2. 無(wú)人機(jī)實(shí)時(shí)視頻的真實(shí)鏈路從機(jī)載推流到地面接收弄明白MQTT的定位之后我們來(lái)梳理一下某頭部無(wú)人機(jī)廠商設(shè)備上實(shí)時(shí)視頻到底是怎么從相機(jī)走到你的屏幕前的。這個(gè)鏈路清楚了MQTT該插在哪里就一目了然。2.1 相機(jī)畫面怎么變成網(wǎng)絡(luò)流無(wú)人機(jī)機(jī)載相機(jī)采集到的是裸的傳感器數(shù)據(jù)經(jīng)過(guò)ISP處理后再由編碼器編成H.264或H.265碼流。在開發(fā)者模式下這個(gè)碼流會(huì)被封裝成一個(gè)RTSP Server運(yùn)行在無(wú)人機(jī)的通信模塊上。部分機(jī)型也可以通過(guò)SDK拿到“推流地址”主動(dòng)把視頻推給指定的媒體服務(wù)器。這里有個(gè)關(guān)鍵點(diǎn)很多機(jī)型默認(rèn)的視頻流地址并不是固定不變的它會(huì)隨著設(shè)備啟動(dòng)、連接狀態(tài)、碼率檔位的變化而變化。所以你的程序不能寫死一個(gè)RTSP地址必須在運(yùn)行時(shí)動(dòng)態(tài)拿到當(dāng)前可用的地址。這個(gè)“動(dòng)態(tài)獲取”的動(dòng)作就是MQTT登場(chǎng)的時(shí)機(jī)。2.2 典型的圖傳鏈路舉個(gè)例子常見的鏈路是這樣的無(wú)人機(jī) - 遙控器/圖傳模塊 - 地面端電腦或手機(jī)App - 上層業(yè)務(wù)系統(tǒng)在這條鏈路里無(wú)人機(jī)和遙控器之間通常是點(diǎn)對(duì)點(diǎn)的私有圖傳協(xié)議。到了地面端廠商SDK會(huì)把流以RTSP或私有回調(diào)的形式開放出來(lái)。如果你的業(yè)務(wù)系統(tǒng)跑在服務(wù)器上一般做法是地面端先拉取RTSP流再轉(zhuǎn)推給內(nèi)部的流媒體服務(wù)或者直接通過(guò)FFmpeg處理后落地存儲(chǔ)。我見過(guò)一個(gè)做電力巡檢的項(xiàng)目地面端部署在車上無(wú)人機(jī)在外面飛畫面通過(guò)遙控器傳到車上的電腦電腦通過(guò)RTSP地址拉流識(shí)別算法處理后再把結(jié)果上傳。整個(gè)鏈路里MQTT只用來(lái)傳“當(dāng)前RTSP地址”“是否在線”“開始/停止推流”這些控制信息視頻本身沒(méi)進(jìn)MQTT。2.3 為什么需要信令協(xié)調(diào)光有視頻流地址還不夠。無(wú)人機(jī)不是攝像頭它隨時(shí)可能起飛、懸停、返航、切換鏡頭、調(diào)整云臺(tái)。你得有一個(gè)可靠的方式讓地面端隨時(shí)知道無(wú)人機(jī)在線讓地面端向無(wú)人機(jī)請(qǐng)求“我現(xiàn)在要看實(shí)時(shí)畫面”讓無(wú)人機(jī)在畫面推流地址改變時(shí)及時(shí)通知地面端讓地面端的視頻播放器知道該去連哪個(gè)地址、帶什么token。這些場(chǎng)景都有一個(gè)共同特點(diǎn)消息小、頻率中等、要求實(shí)時(shí)性但不能靠不斷輪詢。HTTP輪詢也能做但在弱網(wǎng)環(huán)境下體驗(yàn)很差。MQTT的優(yōu)勢(shì)在于長(zhǎng)連接、低開銷、雙向推送、自帶心跳和離線感知。所以把MQTT放在這個(gè)位置屬于“把合適的人放到合適的崗位上”。3. 用MQTT做信令通道正確獲取視頻流地址的設(shè)計(jì)我接下來(lái)詳細(xì)講一下我實(shí)際項(xiàng)目中用MQTT作為信令通道去引導(dǎo)視頻流的方式。這套設(shè)計(jì)可以套用在大部分某頭部無(wú)人機(jī)廠商SDK的接入場(chǎng)景上。3.1 Topic結(jié)構(gòu)設(shè)計(jì)MQTT里Topic就是“郵遞地址”。設(shè)計(jì)得好不好直接影響后續(xù)的權(quán)限控制和排錯(cuò)。我建議按下面的方式組織dji/v1/{device_id}/stream/request地面端向設(shè)備請(qǐng)求建立視頻流會(huì)話時(shí)發(fā)布到這個(gè)Topic。dji/v1/{device_id}/stream/response設(shè)備端返回拉流地址、結(jié)果、token時(shí)發(fā)布到這個(gè)Topic。dji/v1/{device_id}/stream/status設(shè)備端主動(dòng)上報(bào)當(dāng)前推流狀態(tài)空閑、推流中、失敗到該Topic。dji/v1/{device_id}/telemetry設(shè)備心跳、電量、信號(hào)強(qiáng)度等狀態(tài)信息。設(shè)備端訂閱request和status地面端訂閱response和telemetry。如果你有多個(gè)設(shè)備把{device_id}換成具體序列號(hào)就能做到相互隔離。為什么用dji/v1開頭而不是直接用一個(gè)簡(jiǎn)單Topic因?yàn)橐坏╉?xiàng)目從一臺(tái)設(shè)備擴(kuò)展到幾十臺(tái)設(shè)備你必須能在Topic層面做權(quán)限隔離。比如只允許某一臺(tái)設(shè)備訂閱它自己的request不讓它監(jiān)聽別的設(shè)備的響應(yīng)。沒(méi)有統(tǒng)一前綴和版本號(hào)的Topic后面ACL配置會(huì)非常痛苦。3.2 消息體設(shè)計(jì)請(qǐng)求消息示例{ msg_id: uuid-xxxx, type: start_stream, params: { channel: camera_1, width: 1920, height: 1080, fps: 30, bitrate_mbps: 4 } }設(shè)備端收到后根據(jù)廠商SDK的接口創(chuàng)建視頻流然后返回{ msg_id: uuid-xxxx, type: stream_response, result: 0, data: { rtsp_url: rtsp://192.168.1.100:8554/live?tokenab12cd34, expire_at: 1710000000, session_id: sess-001 } }這里有個(gè)細(xì)節(jié)msg_id必須由請(qǐng)求方生成并且響應(yīng)里原樣帶回。為什么因?yàn)橥粋€(gè)設(shè)備可能同時(shí)收到多個(gè)地面端的請(qǐng)求只有帶上唯一ID請(qǐng)求方才能確認(rèn)這條響應(yīng)對(duì)應(yīng)的是自己發(fā)出的那一次請(qǐng)求。這其實(shí)就是給MQTT消息加了一個(gè)“請(qǐng)求追蹤號(hào)”長(zhǎng)期用下來(lái)會(huì)少踩很多坑。3.3 完整的協(xié)商流程我把一次從“想看圖”到“看到圖”的流程拆解一下地面端連接MQTT Broker訂閱dji/v1/{device_id}/stream/response。地面端發(fā)布一條start_stream請(qǐng)求到request。設(shè)備端收到后通過(guò)廠商SDK拿到或創(chuàng)建RTSP流。設(shè)備端向response發(fā)布響應(yīng)消息包含RTSP地址和一次性token。地面端收到RTSP地址后立即用FFmpeg或播放器去拉流。畫面開始播放后地面端發(fā)布keepalive消息定期續(xù)約防止設(shè)備端主動(dòng)斷開。設(shè)備端如果在設(shè)定時(shí)間內(nèi)沒(méi)收到續(xù)約則主動(dòng)停止推流回收資源。這個(gè)流程里MQTT只承擔(dān)了“握手”和“維持”兩個(gè)職責(zé)真正的畫面數(shù)據(jù)由RTSP承載。這是最穩(wěn)妥、最生產(chǎn)可用的模式。4. 從理論到代碼MQTT信令加RTSP拉流的完整Demo紙上談兵沒(méi)意思。我直接把一個(gè)最小可跑的Demo骨架放出來(lái)你可以照著搭一遍。這里用開源的Mosquitto作為BrokerPython的paho-mqtt作為MQTT客戶端FFmpeg作為RTSP拉流工具。4.1 搭建環(huán)境先安裝依賴sudo apt install mosquitto mosquitto-clients pip install paho-mqtt sudo apt install ffmpegMosquitto默認(rèn)監(jiān)聽1883端口。本地測(cè)試不用改配置直接啟動(dòng)服務(wù)sudo systemctl start mosquitto為了調(diào)試開一個(gè)終端用mosquitto_sub監(jiān)聽響應(yīng)Topicmosquitto_sub -t dji/v1/dev001/stream/response -v4.2 模擬設(shè)備端下面這段代碼模擬設(shè)備端收到請(qǐng)求后返回一個(gè)模擬的RTSP地址。真正接入SDK時(shí)把fake_rtsp_url換成廠商SDK返回的真實(shí)地址即可。import json import time import uuid import paho.mqtt.client as mqtt BROKER 127.0.0.1 DEVICE_ID dev001 def on_message(client, userdata, msg): try: req json.loads(msg.payload) except json.JSONDecodeError: return # 只處理 start_stream 命令 if req.get(type) ! start_stream: return session_id str(uuid.uuid4()) fake_rtsp_url frtsp://192.168.1.100:8554/live?session{session_id} resp { msg_id: req.get(msg_id), type: stream_response, result: 0, data: { rtsp_url: fake_rtsp_url, expire_at: int(time.time()) 30, session_id: session_id } } client.publish( fdji/v1/{DEVICE_ID}/stream/response, json.dumps(resp), qos1 ) print(f[device] published rtsp url for session {session_id}) def on_connect(client, userdata, flags, rc): print([device] connected to broker) client.subscribe(fdji/v1/{DEVICE_ID}/stream/request, qos1) client mqtt.Client() client.on_connect on_connect client.on_message on_message client.connect(BROKER, 1883, 60) client.loop_forever()4.3 模擬地面端地面端這邊連接MQTT、訂閱響應(yīng)Topic、發(fā)布請(qǐng)求拿到RTSP地址后調(diào)用FFmpeg拉流。import json import uuid import subprocess import paho.mqtt.client as mqtt BROKER 127.0.0.1 DEVICE_ID dev001 def on_connect(client, userdata, flags, rc): print([client] connected to broker) client.subscribe(fdji/v1/{DEVICE_ID}/stream/response, qos1) req { msg_id: str(uuid.uuid4()), type: start_stream, params: {channel: camera_1, fps: 30} } client.publish( fdji/v1/{DEVICE_ID}/stream/request, json.dumps(req), qos1 ) def on_message(client, userdata, msg): resp json.loads(msg.payload) if resp.get(result) ! 0: print(start stream failed) return rtsp_url resp[data][rtsp_url] print(f[client] got rtsp url: {rtsp_url}) # 啟動(dòng) ffplay 播放實(shí)際項(xiàng)目中可以用 ffmpeg 轉(zhuǎn)封裝 subprocess.Popen([ffplay, -fflags, nobuffer, rtsp_url]) client mqtt.Client() client.on_connect on_connect client.on_message on_message client.connect(BROKER, 1883, 60) client.loop_forever()跑通這個(gè)流程后你會(huì)發(fā)現(xiàn)MQTT在中間更像一個(gè)“接線員”它負(fù)責(zé)把兩端連接起來(lái)但真正的話務(wù)數(shù)據(jù)走的卻是另外一條線路。這套模式在生產(chǎn)環(huán)境里經(jīng)過(guò)檢驗(yàn)穩(wěn)定性遠(yuǎn)高于“用MQTT一包一包塞視頻幀”。4.4 為什么要用QoS 1而不是QoS 2信令場(chǎng)景我建議QoS 1。QoS 2雖然“恰好一次”但它的四步握手在多線程、弱網(wǎng)環(huán)境下容易出現(xiàn)消息重投或卡頓。QoS 0又可能丟消息對(duì)于“開始推流”“停止推流”這種關(guān)鍵指令不太合適。QoS 1能保證至少一次送達(dá)絕大多數(shù)情況足夠用。至于視頻幀——如果真有人拿MQTT傳幀我建議QoS 0原因后面細(xì)說(shuō)。5. 如果非要通過(guò)MQTT傳視頻幀實(shí)驗(yàn)方案的極限有人可能會(huì)說(shuō)我信號(hào)不好RTSP拉不動(dòng)我就想用MQTT傳壓縮圖片行不行答案是可以但只適合特定場(chǎng)景。5.1 可行的實(shí)現(xiàn)方式核心思路是不傳編碼后的整個(gè)視頻流而是每隔固定時(shí)間抓一幀壓縮成JPEG再通過(guò)MQTT發(fā)出去。相當(dāng)于把“視頻”降級(jí)成“幻燈片”只做低幀率的畫面同步。代碼邏輯大致是這樣import cv2 import base64 import paho.mqtt.client as mqtt cap cv2.VideoCapture(rtsp://192.168.1.100:8554/live) client mqtt.Client() client.connect(127.0.0.1, 1883, 60) while True: ret, frame cap.read() if not ret: continue # 壓低分辨率壓縮質(zhì)量 small cv2.resize(frame, (320, 240)) _, buf cv2.imencode(.jpg, small, [cv2.IMWRITE_JPEG_QUALITY, 50]) payload base64.b64encode(buf.tobytes()) client.publish(dji/v1/dev001/video/frame, payload, qos0)這段代碼能跑但你要清楚它的代價(jià)。5.2 實(shí)測(cè)數(shù)據(jù)我搭過(guò)一個(gè)最小系統(tǒng)做對(duì)比測(cè)試結(jié)果如下分辨率JPEG質(zhì)量單幀大小5fps下帶寬開銷端到端延遲320x2405015-30KB75-150KB/s50-150ms640x4807060-120KB300-600KB/s200-500ms1280x72070200-400KB1-2MB/s不可控這里還沒(méi)算Base64編碼造成的33%額外體積。如果換成二進(jìn)制直發(fā)能省一點(diǎn)但很多MQTT客戶端庫(kù)在傳輸二進(jìn)制時(shí)處理起來(lái)不如文本Payload順手。結(jié)論很清楚320x240、5幀每秒還能用用來(lái)做“縮略圖預(yù)覽”或“關(guān)鍵幀回傳”可以但要說(shuō)“實(shí)時(shí)視頻流”那談不上。720p以上就會(huì)把Broker打滿TCP背壓一來(lái)延遲直接飆升畫面變成PPT。5.3 什么時(shí)候值得這么用有一種場(chǎng)景值得用MQTT傳幀設(shè)備在極低帶寬的蜂窩網(wǎng)絡(luò)下無(wú)法維持RTSP長(zhǎng)連接但業(yè)務(wù)系統(tǒng)只需要每隔幾秒看到一張畫面來(lái)做人工確認(rèn)。這本質(zhì)上不是視頻流而是“周期性快照”。把業(yè)務(wù)預(yù)期定清楚技術(shù)上完全可行。但如果你的業(yè)務(wù)需要連續(xù)流暢的畫面還是老老實(shí)實(shí)回到RTSP。6. 實(shí)戰(zhàn)中繞不開的坑NAT、Topic隔離、斷線重連與安全認(rèn)證最后這部分我不講理論只講我實(shí)際踩過(guò)的坑。每一條都有真實(shí)的項(xiàng)目背景每一條都可能讓你白加班好幾天。6.1 NAT和防火墻讓RTSP地址成了“假地址”設(shè)備端返回的RTSP地址往往是內(nèi)網(wǎng)地址比如192.168.1.100:8554。地面端如果和它在同一個(gè)局域網(wǎng)沒(méi)問(wèn)題。但如果你把MQTT Broker放在云端地面端在另一個(gè)城市那么這個(gè)內(nèi)網(wǎng)地址根本連不上。我遇到過(guò)的解決辦法有兩種。第一種讓設(shè)備端所在的網(wǎng)關(guān)做端口映射把RTSP端口映射到公網(wǎng)然后返回公網(wǎng)地址。第二種用一個(gè)媒體網(wǎng)關(guān)設(shè)備端主動(dòng)把RTSP流推給公網(wǎng)上的媒體服務(wù)器地面端從媒體服務(wù)器拉流。第二種更穩(wěn)因?yàn)闊o(wú)人機(jī)設(shè)備和地面端之間的網(wǎng)絡(luò)拓?fù)淠愀究刂撇涣恕?.2 Topic權(quán)限沒(méi)隔離設(shè)備間會(huì)串臺(tái)早期我把所有設(shè)備共用同一套Topic比如dji/v1/stream/request。結(jié)果A設(shè)備能收到B設(shè)備的控制指令一個(gè)地面端發(fā)起的拉流請(qǐng)求局域網(wǎng)上所有設(shè)備都開始推流畫面亂成一鍋粥。后來(lái)改成dji/v1/{device_id}/...并加了ACL才徹底解決。Topic權(quán)限不是錦上添花而是必須做的。6.3 斷線重連后狀態(tài)不同步MQTT客戶端掉線重連后默認(rèn)會(huì)重新執(zhí)行訂閱回調(diào)。但如果設(shè)備端在掉線期間已經(jīng)停止了推流地面端重連后還傻等著之前拿到的RTSP地址播放器就會(huì)一直轉(zhuǎn)圈。我現(xiàn)在的做法是重連成功之后地面端主動(dòng)向設(shè)備端發(fā)一次query_stream_status請(qǐng)求強(qiáng)制同步一次當(dāng)前狀態(tài)。設(shè)備端收到后如果是“空閑”就重新走一遍建流流程。6.4 安全認(rèn)證不能只靠“不公開”RTSP地址帶上token是個(gè)好習(xí)慣但很多操作者會(huì)忘記給MQTT本身的連接加TLS。MQTT報(bào)文明文傳輸時(shí)任何人只要在局域網(wǎng)抓包就能看到你的RTSP地址和token視頻流地址直接泄露。經(jīng)驗(yàn)之談把MQTT端口從1883換成8883并啟用TLS流量費(fèi)不了多少安全性提升一個(gè)量級(jí)。再配合賬號(hào)密碼或雙向證書認(rèn)證基本就能擋住絕大多數(shù)亂入。6.5 QoS級(jí)別選錯(cuò)視頻幀和信令一起卡如果你按我前面的方案把信令和視頻幀分開了這一步?jīng)]什么問(wèn)題。但萬(wàn)一你沒(méi)分開視頻幀大量積壓會(huì)把Broker連接占滿信令消息排隊(duì)排到懷疑人生。我在測(cè)試中見過(guò)一次同一個(gè)連接里又發(fā)信令又發(fā)視頻幀結(jié)果是信令延遲從20毫秒漲到3秒。后來(lái)把所有視頻幀單獨(dú)拆到一個(gè)獨(dú)立Topic并把QoS降到0才算解決。最后分享一個(gè)我自己常用的調(diào)試順序先從mosquitto_sub確認(rèn)MQTT消息有沒(méi)有到再?gòu)膄fprobe確認(rèn)RTSP地址能不能解析出流信息最后才輪到看播放器畫面。很多你看似“MQTT把視頻傳丟了”的問(wèn)題其實(shí)都是RTSP地址本身就不通。按這個(gè)順序排查十個(gè)問(wèn)題里能少走九次彎路。