：從拉流到推理的完整鏈路與避坑指南)
簡介這是一份面向計算機視覺開發(fā)者與視頻監(jiān)控、智能交通、工業(yè)自動化方向工程師的實戰(zhàn)資源圍繞 YOLOv8 與 RTSP 實時視頻流的結合展開幫助讀者搭建可實時處理網(wǎng)絡攝像頭視頻流并識別畫面目標物的檢測系統(tǒng)。壓縮包共 467 個文件約 169.25MB以 145 個 py 源碼與 215 個 pyc 編譯文件為主體輔以 80 個 yaml 模型與數(shù)據(jù)配置、6 個 pt 權重文件以及少量 jpg 測試圖、sh 啟動腳本、md 說明文檔和前端頁面資源覆蓋從模型推理到結果展示的完整鏈路。資源內(nèi)含 camera.html 等可視化頁面與示例圖片便于快速驗證檢測效果。目前已有 220 人學習下載。通過源碼與配置文件的組合讀者可掌握 RTSP 拉流、幀預處理、YOLOv8 推理、結果處理與前端反饋等關鍵環(huán)節(jié)并參考權重與 yaml 配置進行微調(diào)適合具備一定 Python 與深度學習基礎、希望將目標檢測落地到實時視頻場景的開發(fā)者。1. YOLOv8 接 RTSP 流從拉流到畫框一條能跑通的鏈路長什么樣手里有一臺?？祷虼笕A的網(wǎng)絡攝像頭想用 YOLOv8 做實時目標檢測這件事聽起來只是「讀視頻 推理」兩步實際動手會發(fā)現(xiàn)卡點全在中間RTSP 地址拼不對、OpenCV 拉流延遲越跑越大、斷流之后程序直接卡死、GPU 利用率上不去。YOLOv8 基于 RTSP 流目標檢測本質(zhì)是把「網(wǎng)絡攝像頭的實時視頻流」當成輸入源替代本地 mp4 文件讓檢測模型持續(xù)消費幀并輸出帶框的結果。它適合做安防周界、工地安全帽、園區(qū)車輛統(tǒng)計這類需要 7×24 小時跑的現(xiàn)場也適合 RK3588、Orin、GTX1660Ti 這類邊緣設備做本地推理。這篇不聊論文只講一條我實際跑通過、能復現(xiàn)的鏈路怎么拿到 RTSP 地址、怎么用 OpenCV 或 FFmpeg 拉流、YOLOv8 怎么接、參數(shù)怎么調(diào)、斷流和延遲怎么處理。2. RTSP 拉流與 YOLOv8 推理的對接方式三種方案怎么選2.1 先搞清楚 RTSP 地址的構成和主輔碼流RTSP 地址不是隨便拼的它由協(xié)議頭、認證信息、IP、端口、路徑幾段組成。以?？低暈槔Ｒ姼袷绞莚tsp://用戶名:密碼IP:554/Streaming/Channels/101其中101的規(guī)則是「通道號 碼流號」1是主碼流2是子碼流。大華的結構不同通常是rtsp://用戶名:密碼IP:554/cam/realmonitor?channel1subtype0subtype0是主碼流1是子碼流。這里有個血淚經(jīng)驗做 YOLOv8 檢測時優(yōu)先用子碼流。主碼流常見是 2560×1440 甚至 4K幀率 25fps直接喂給模型會先把解碼和縮放吃滿GPU 反而閑著。子碼流一般是 704×576 或 1280×720YOLOv8 輸入本來就是 640用子碼流畫質(zhì)損失可接受端到端延遲能降一半以上。品牌主碼流地址特征子碼流地址特征默認端口?？低旵hannels/101Channels/102554大華subtype0subtype1554宇視/media/video1/media/video2554提示地址里的用戶名密碼如果含、#、:等字符必須做 URL 編碼否則解析會失敗這是最常見的「地址明明對卻連不上」原因。2.2 三種拉流方案OpenCV、FFmpeg 子進程、GStreamer方案一OpenCV 直接cv2.VideoCapture(rtsp_url)。優(yōu)點是代碼最短缺點是默認走 FFmpeg 后端時緩沖不可控延遲會隨時間累積。必須加cv2.CAP_FFMPEG并設置CAP_PROP_BUFFERSIZE1但 OpenCV 對 RTSP 的緩沖參數(shù)支持并不完整長跑還是容易漲延遲。方案二FFmpeg 子進程拉流輸出 rawvideo 到管道Python 讀管道。這是我在生產(chǎn)環(huán)境最常用的方式因為可以精確控制-rtsp_transport tcp、-fflags nobuffer、-flags low_delay這些參數(shù)延遲穩(wěn)定。方案三GStreamer 管線。適合需要硬解碼如 RK3588 的 MPP、Jetson 的 NVDEC的場景性能最好但管線調(diào)試成本高gsteamer rtsp服務器這類工具鏈要單獨裝。選型建議驗證階段用方案一快速跑通上線用方案二邊緣設備追求幀率用方案三。2.3 用 FFmpeg 子進程拉流的最小可跑代碼import subprocess import numpy as np import cv2 RTSP_URL rtsp://admin:password192.168.1.64:554/Streaming/Channels/102 W, H 1280, 720 # 必須和子碼流實際分辨率一致否則畫面錯位 # -rtsp_transport tcp 強制 TCP避免 UDP 丟包花屏 # -fflags nobuffer 關閉輸入緩沖-flags low_delay 走低延遲解碼 cmd [ ffmpeg, -rtsp_transport, tcp, -fflags, nobuffer, -flags, low_delay, -i, RTSP_URL, -f, rawvideo, -pix_fmt, bgr24, -an, # 不要音頻 - ] proc subprocess.Popen(cmd, stdoutsubprocess.PIPE, bufsize10**8) frame_size W * H * 3 while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: print(流中斷或分辨率不匹配) break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) # 到這里 frame 就是可直接送 YOLOv8 的 BGR 圖像邏輯說明FFmpeg 把 RTSP 解碼成 rawvideo 從 stdout 吐出來Python 按固定字節(jié)數(shù)讀取湊夠一幀就 reshape。參數(shù)上-rtsp_transport tcp是必加項UDP 在弱網(wǎng)下會花屏-fflags nobuffer和-flags low_delay一起用才能壓住延遲W、H必須和攝像頭子碼流實際輸出一致寫錯會導致 reshape 出來的畫面是斜的這個坑我踩過不止一次。2.4 把幀送進 YOLOv8 并控制推理節(jié)奏from ultralytics import YOLO model YOLO(yolov8n.pt) # 邊緣設備用 n服務器可用 s/m while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) # imgsz640 是 YOLOv8 默認輸入conf 按場景調(diào)0.25 偏寬松 results model.predict(frame, imgsz640, conf0.25, verboseFalse) annotated results[0].plot() cv2.imshow(rtsp-yolov8, annotated) if cv2.waitKey(1) 0xFF ord(q): break參數(shù)說明imgsz決定推理分辨率攝像頭子碼流是 720p 時設 640 會縮放設 1280 精度略高但速度掉一半conf是置信度閾值安防場景漏檢代價高就調(diào)到 0.150.2誤報多就提到 0.4verboseFalse關掉每幀日志否則控制臺會被刷爆。model.predict每幀調(diào)用一次如果幀率高于推理速度管道會積壓解決辦法是加一個「只取最新幀」的丟棄邏輯而不是每幀都推理。3. 參數(shù)調(diào)優(yōu)與性能壓榨讓 GTX1660Ti 和 RK3588 都跑滿3.1 模型選型n/s/m 在 RTSP 場景下的取舍YOLOv8 提供 n、s、m、l、x 五檔。RTSP 實時檢測的核心矛盾是「幀率要跟上攝像頭的 25fps」。GTX1660Ti 上yolov8n 用 TensorRT FP16 能跑到 200fps 以上yolov8s 大約 100fpsyolov8m 掉到 40fps 左右。如果單路攝像頭s 是精度和速度的平衡點如果要多路4 路以上共用一張卡必須用 n 并做批處理。RK3588 這類 NPU 設備更敏感官方 RKNN 工具鏈對 yolov8n 支持最好m 以上量化后精度掉得明顯。Orin 系列有 NVDEC 硬解 TensorRT可以上 s。注意換模型后必須重新導出.pt不能直接給 RKNN 或 TensorRT 用要走model.export(formatrknn)或formatengine。3.2 抽幀策略不是每一幀都值得推理攝像頭 25fps模型只能跑 15fps硬扛的結果是延遲越堆越高。正確做法是主動丟幀維護一個「最新幀」變量推理線程只取最新的一幀處理完再取下一幀中間過期的幀直接扔。import threading latest_frame None lock threading.Lock() def reader(): global latest_frame while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) with lock: latest_frame frame # 覆蓋舊幀天然丟幀 def infer(): while True: with lock: frame latest_frame if frame is None: continue results model.predict(frame, imgsz640, conf0.25, verboseFalse) # 后續(xù)畫框、推流這樣做的效果是無論模型多慢顯示的永遠是最新畫面延遲不會累積。代價是丟掉了中間幀對「玩手機目標檢測」「目標檢測舉手數(shù)據(jù)集」這類需要連續(xù)動作判斷的場景要改成保留關鍵幀或做跟蹤補償。3.3 硬解碼與零拷貝把 CPU 占用降下來純 FFmpeg 軟解 720p 25fps 大約吃 12 個核4 路就頂不住了。Jetson 上用nvv4l2decoderRK3588 上用mppvideodec能把解碼放到硬件單元。零拷貝是指解碼后的幀直接在 GPU/NPU 顯存里不經(jīng)過 CPU 內(nèi)存往返TensorRT 和 RKNN 都支持這種綁定。如果暫時上不了硬解至少把 FFmpeg 的-threads限制一下別讓它把 CPU 全占了給推理留出余量。3.4 多路 RTSP 的并發(fā)組織多路場景不要開多個 Python 進程各拉各的內(nèi)存和句柄會爆。常見做法是一個拉流進程池 一個推理隊列或者用 GStreamer 的uridecodebin做多路合流。每路單獨記錄狀態(tài)某一路斷了不影響其他路重連邏輯按路獨立。4. 避坑與排查RTSP YOLOv8 最容易翻車的五個點4.1 現(xiàn)象程序跑幾分鐘后畫面卡住不動原因OpenCV 或 FFmpeg 的輸入緩沖在累積網(wǎng)絡抖動時幀堆積讀的速度跟不上寫的速度。解決加-fflags nobufferOpenCV 方案設CAP_PROP_BUFFERSIZE1并且用上面的「只取最新幀」邏輯從消費端強制丟棄。4.2 現(xiàn)象報錯Could not find codec parameters或直接連不上原因RTSP 地址錯誤、認證失敗、或者攝像頭沒開子碼流。解決先用ffplay -rtsp_transport tcp 地址單獨驗證地址能播再進代碼。?？档?01/102、大華的subtype寫錯都會報這個。密碼含特殊字符要做 URL 編碼。4.3 現(xiàn)象畫面顏色不對或圖像是斜的原因W、H和實際碼流分辨率不一致reshape 時錯位。解決先用ffprobe查實際分辨率或者用 OpenCV 讀一幀打印frame.shape把真實值填進代碼。子碼流分辨率各廠商默認不同別想當然。4.4 現(xiàn)象GPU 利用率只有 20%幀率上不去原因瓶頸在解碼或 Python 讀管道不在推理。解決換硬解碼或者把 FFmpeg 輸出改成-pix_fmt nv12直接喂給 TensorRT省掉 BGR 轉換。也可能是model.predict每幀都重新做預處理改用model的 warmup 和固定輸入尺寸。4.5 現(xiàn)象斷流后程序不退出也不重連原因proc.stdout.read在流斷開時可能阻塞或返回空沒有超時機制。解決給讀取加超時或者用select監(jiān)聽管道檢測到連續(xù) N 幀讀取失敗就 kill 子進程并重新拉起。生產(chǎn)環(huán)境必須寫重連攝像頭重啟、網(wǎng)絡閃斷都是常態(tài)。5. 進階把檢測結果推回 RTSP 或轉 FLV以及驗證延遲的土辦法單機畫框只是第一步實際項目往往要把帶框的視頻再推出去給前端看。常見做法是用 FFmpeg 把annotated幀重新編碼推成 RTSP或者轉成 FLV 給網(wǎng)頁播放。推流命令的核心是-f rtsp -rtsp_transport tcp rtsp://...輸入用-f rawvideo -pix_fmt bgr24 -s WxH -r 25 -i -注意幀率要和你實際推理輸出的幀率匹配寫死 25 但實際只有 12播放端會加速或卡頓。ffmpeg -f rawvideo -pix_fmt bgr24 -s 1280x720 -r 15 -i - \ -c:v libx264 -preset ultrafast -tune zerolatency \ -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/out-r 15要和你推理線程實際產(chǎn)出幀率一致-tune zerolatency關掉編碼器緩沖-preset ultrafast換速度。如果前端要 FLV把輸出改成-f flv rtmp://...或直接寫 FLV 文件。驗證延遲別靠感覺用土辦法拿手機秒表對著攝像頭同時截屏檢測畫面兩個時間差就是端到端延遲。我一般要求控制在 300ms 以內(nèi)超過就說明緩沖沒壓干凈。另一個辦法是在畫面里疊加時間戳看時間戳和當前時間的差值。最后說個習慣每次改完拉流參數(shù)或模型先跑 30 分鐘壓力測試看內(nèi)存有沒有緩慢上漲、延遲有沒有漂移。RTSP 流的坑大多是「跑十分鐘沒事跑兩小時才炸」短測看不出來。這套鏈路我在園區(qū)車輛統(tǒng)計上跑過半年最大的教訓就是重連邏輯和丟幀策略必須一開始就寫進去后期補的代價是重構整個讀取線程。希望幫到你。本文還有配套的精品資源點擊獲取 YOLOv8接RTSP流實戰(zhàn)：從拉流到推理的完整鏈路與避坑指南
簡介這是一份面向計算機視覺開發(fā)者與視頻監(jiān)控、智能交通、工業(yè)自動化方向工程師的實戰(zhàn)資源圍繞 YOLOv8 與 RTSP 實時視頻流的結合展開幫助讀者搭建可實時處理網(wǎng)絡攝像頭視頻流并識別畫面目標物的檢測系統(tǒng)。壓縮包共 467 個文件約 169.25MB以 145 個 py 源碼與 215 個 pyc 編譯文件為主體輔以 80 個 yaml 模型與數(shù)據(jù)配置、6 個 pt 權重文件以及少量 jpg 測試圖、sh 啟動腳本、md 說明文檔和前端頁面資源覆蓋從模型推理到結果展示的完整鏈路。資源內(nèi)含 camera.html 等可視化頁面與示例圖片便于快速驗證檢測效果。目前已有 220 人學習下載。通過源碼與配置文件的組合讀者可掌握 RTSP 拉流、幀預處理、YOLOv8 推理、結果處理與前端反饋等關鍵環(huán)節(jié)并參考權重與 yaml 配置進行微調(diào)適合具備一定 Python 與深度學習基礎、希望將目標檢測落地到實時視頻場景的開發(fā)者。1. YOLOv8 接 RTSP 流從拉流到畫框一條能跑通的鏈路長什么樣手里有一臺?？祷虼笕A的網(wǎng)絡攝像頭想用 YOLOv8 做實時目標檢測這件事聽起來只是「讀視頻 推理」兩步實際動手會發(fā)現(xiàn)卡點全在中間RTSP 地址拼不對、OpenCV 拉流延遲越跑越大、斷流之后程序直接卡死、GPU 利用率上不去。YOLOv8 基于 RTSP 流目標檢測本質(zhì)是把「網(wǎng)絡攝像頭的實時視頻流」當成輸入源替代本地 mp4 文件讓檢測模型持續(xù)消費幀并輸出帶框的結果。它適合做安防周界、工地安全帽、園區(qū)車輛統(tǒng)計這類需要 7×24 小時跑的現(xiàn)場也適合 RK3588、Orin、GTX1660Ti 這類邊緣設備做本地推理。這篇不聊論文只講一條我實際跑通過、能復現(xiàn)的鏈路怎么拿到 RTSP 地址、怎么用 OpenCV 或 FFmpeg 拉流、YOLOv8 怎么接、參數(shù)怎么調(diào)、斷流和延遲怎么處理。2. RTSP 拉流與 YOLOv8 推理的對接方式三種方案怎么選2.1 先搞清楚 RTSP 地址的構成和主輔碼流RTSP 地址不是隨便拼的它由協(xié)議頭、認證信息、IP、端口、路徑幾段組成。以?？低暈槔Ｒ姼袷绞莚tsp://用戶名:密碼IP:554/Streaming/Channels/101其中101的規(guī)則是「通道號 碼流號」1是主碼流2是子碼流。大華的結構不同通常是rtsp://用戶名:密碼IP:554/cam/realmonitor?channel1subtype0subtype0是主碼流1是子碼流。這里有個血淚經(jīng)驗做 YOLOv8 檢測時優(yōu)先用子碼流。主碼流常見是 2560×1440 甚至 4K幀率 25fps直接喂給模型會先把解碼和縮放吃滿GPU 反而閑著。子碼流一般是 704×576 或 1280×720YOLOv8 輸入本來就是 640用子碼流畫質(zhì)損失可接受端到端延遲能降一半以上。品牌主碼流地址特征子碼流地址特征默認端口?？低旵hannels/101Channels/102554大華subtype0subtype1554宇視/media/video1/media/video2554提示地址里的用戶名密碼如果含、#、:等字符必須做 URL 編碼否則解析會失敗這是最常見的「地址明明對卻連不上」原因。2.2 三種拉流方案OpenCV、FFmpeg 子進程、GStreamer方案一OpenCV 直接cv2.VideoCapture(rtsp_url)。優(yōu)點是代碼最短缺點是默認走 FFmpeg 后端時緩沖不可控延遲會隨時間累積。必須加cv2.CAP_FFMPEG并設置CAP_PROP_BUFFERSIZE1但 OpenCV 對 RTSP 的緩沖參數(shù)支持并不完整長跑還是容易漲延遲。方案二FFmpeg 子進程拉流輸出 rawvideo 到管道Python 讀管道。這是我在生產(chǎn)環(huán)境最常用的方式因為可以精確控制-rtsp_transport tcp、-fflags nobuffer、-flags low_delay這些參數(shù)延遲穩(wěn)定。方案三GStreamer 管線。適合需要硬解碼如 RK3588 的 MPP、Jetson 的 NVDEC的場景性能最好但管線調(diào)試成本高gsteamer rtsp服務器這類工具鏈要單獨裝。選型建議驗證階段用方案一快速跑通上線用方案二邊緣設備追求幀率用方案三。2.3 用 FFmpeg 子進程拉流的最小可跑代碼import subprocess import numpy as np import cv2 RTSP_URL rtsp://admin:password192.168.1.64:554/Streaming/Channels/102 W, H 1280, 720 # 必須和子碼流實際分辨率一致否則畫面錯位 # -rtsp_transport tcp 強制 TCP避免 UDP 丟包花屏 # -fflags nobuffer 關閉輸入緩沖-flags low_delay 走低延遲解碼 cmd [ ffmpeg, -rtsp_transport, tcp, -fflags, nobuffer, -flags, low_delay, -i, RTSP_URL, -f, rawvideo, -pix_fmt, bgr24, -an, # 不要音頻 - ] proc subprocess.Popen(cmd, stdoutsubprocess.PIPE, bufsize10**8) frame_size W * H * 3 while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: print(流中斷或分辨率不匹配) break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) # 到這里 frame 就是可直接送 YOLOv8 的 BGR 圖像邏輯說明FFmpeg 把 RTSP 解碼成 rawvideo 從 stdout 吐出來Python 按固定字節(jié)數(shù)讀取湊夠一幀就 reshape。參數(shù)上-rtsp_transport tcp是必加項UDP 在弱網(wǎng)下會花屏-fflags nobuffer和-flags low_delay一起用才能壓住延遲W、H必須和攝像頭子碼流實際輸出一致寫錯會導致 reshape 出來的畫面是斜的這個坑我踩過不止一次。2.4 把幀送進 YOLOv8 并控制推理節(jié)奏from ultralytics import YOLO model YOLO(yolov8n.pt) # 邊緣設備用 n服務器可用 s/m while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) # imgsz640 是 YOLOv8 默認輸入conf 按場景調(diào)0.25 偏寬松 results model.predict(frame, imgsz640, conf0.25, verboseFalse) annotated results[0].plot() cv2.imshow(rtsp-yolov8, annotated) if cv2.waitKey(1) 0xFF ord(q): break參數(shù)說明imgsz決定推理分辨率攝像頭子碼流是 720p 時設 640 會縮放設 1280 精度略高但速度掉一半conf是置信度閾值安防場景漏檢代價高就調(diào)到 0.150.2誤報多就提到 0.4verboseFalse關掉每幀日志否則控制臺會被刷爆。model.predict每幀調(diào)用一次如果幀率高于推理速度管道會積壓解決辦法是加一個「只取最新幀」的丟棄邏輯而不是每幀都推理。3. 參數(shù)調(diào)優(yōu)與性能壓榨讓 GTX1660Ti 和 RK3588 都跑滿3.1 模型選型n/s/m 在 RTSP 場景下的取舍YOLOv8 提供 n、s、m、l、x 五檔。RTSP 實時檢測的核心矛盾是「幀率要跟上攝像頭的 25fps」。GTX1660Ti 上yolov8n 用 TensorRT FP16 能跑到 200fps 以上yolov8s 大約 100fpsyolov8m 掉到 40fps 左右。如果單路攝像頭s 是精度和速度的平衡點如果要多路4 路以上共用一張卡必須用 n 并做批處理。RK3588 這類 NPU 設備更敏感官方 RKNN 工具鏈對 yolov8n 支持最好m 以上量化后精度掉得明顯。Orin 系列有 NVDEC 硬解 TensorRT可以上 s。注意換模型后必須重新導出.pt不能直接給 RKNN 或 TensorRT 用要走model.export(formatrknn)或formatengine。3.2 抽幀策略不是每一幀都值得推理攝像頭 25fps模型只能跑 15fps硬扛的結果是延遲越堆越高。正確做法是主動丟幀維護一個「最新幀」變量推理線程只取最新的一幀處理完再取下一幀中間過期的幀直接扔。import threading latest_frame None lock threading.Lock() def reader(): global latest_frame while True: raw proc.stdout.read(frame_size) if len(raw) ! frame_size: break frame np.frombuffer(raw, np.uint8).reshape((H, W, 3)) with lock: latest_frame frame # 覆蓋舊幀天然丟幀 def infer(): while True: with lock: frame latest_frame if frame is None: continue results model.predict(frame, imgsz640, conf0.25, verboseFalse) # 后續(xù)畫框、推流這樣做的效果是無論模型多慢顯示的永遠是最新畫面延遲不會累積。代價是丟掉了中間幀對「玩手機目標檢測」「目標檢測舉手數(shù)據(jù)集」這類需要連續(xù)動作判斷的場景要改成保留關鍵幀或做跟蹤補償。3.3 硬解碼與零拷貝把 CPU 占用降下來純 FFmpeg 軟解 720p 25fps 大約吃 12 個核4 路就頂不住了。Jetson 上用nvv4l2decoderRK3588 上用mppvideodec能把解碼放到硬件單元。零拷貝是指解碼后的幀直接在 GPU/NPU 顯存里不經(jīng)過 CPU 內(nèi)存往返TensorRT 和 RKNN 都支持這種綁定。如果暫時上不了硬解至少把 FFmpeg 的-threads限制一下別讓它把 CPU 全占了給推理留出余量。3.4 多路 RTSP 的并發(fā)組織多路場景不要開多個 Python 進程各拉各的內(nèi)存和句柄會爆。常見做法是一個拉流進程池 一個推理隊列或者用 GStreamer 的uridecodebin做多路合流。每路單獨記錄狀態(tài)某一路斷了不影響其他路重連邏輯按路獨立。4. 避坑與排查RTSP YOLOv8 最容易翻車的五個點4.1 現(xiàn)象程序跑幾分鐘后畫面卡住不動原因OpenCV 或 FFmpeg 的輸入緩沖在累積網(wǎng)絡抖動時幀堆積讀的速度跟不上寫的速度。解決加-fflags nobufferOpenCV 方案設CAP_PROP_BUFFERSIZE1并且用上面的「只取最新幀」邏輯從消費端強制丟棄。4.2 現(xiàn)象報錯Could not find codec parameters或直接連不上原因RTSP 地址錯誤、認證失敗、或者攝像頭沒開子碼流。解決先用ffplay -rtsp_transport tcp 地址單獨驗證地址能播再進代碼。?？档?01/102、大華的subtype寫錯都會報這個。密碼含特殊字符要做 URL 編碼。4.3 現(xiàn)象畫面顏色不對或圖像是斜的原因W、H和實際碼流分辨率不一致reshape 時錯位。解決先用ffprobe查實際分辨率或者用 OpenCV 讀一幀打印frame.shape把真實值填進代碼。子碼流分辨率各廠商默認不同別想當然。4.4 現(xiàn)象GPU 利用率只有 20%幀率上不去原因瓶頸在解碼或 Python 讀管道不在推理。解決換硬解碼或者把 FFmpeg 輸出改成-pix_fmt nv12直接喂給 TensorRT省掉 BGR 轉換。也可能是model.predict每幀都重新做預處理改用model的 warmup 和固定輸入尺寸。4.5 現(xiàn)象斷流后程序不退出也不重連原因proc.stdout.read在流斷開時可能阻塞或返回空沒有超時機制。解決給讀取加超時或者用select監(jiān)聽管道檢測到連續(xù) N 幀讀取失敗就 kill 子進程并重新拉起。生產(chǎn)環(huán)境必須寫重連攝像頭重啟、網(wǎng)絡閃斷都是常態(tài)。5. 進階把檢測結果推回 RTSP 或轉 FLV以及驗證延遲的土辦法單機畫框只是第一步實際項目往往要把帶框的視頻再推出去給前端看。常見做法是用 FFmpeg 把annotated幀重新編碼推成 RTSP或者轉成 FLV 給網(wǎng)頁播放。推流命令的核心是-f rtsp -rtsp_transport tcp rtsp://...輸入用-f rawvideo -pix_fmt bgr24 -s WxH -r 25 -i -注意幀率要和你實際推理輸出的幀率匹配寫死 25 但實際只有 12播放端會加速或卡頓。ffmpeg -f rawvideo -pix_fmt bgr24 -s 1280x720 -r 15 -i - \ -c:v libx264 -preset ultrafast -tune zerolatency \ -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/out-r 15要和你推理線程實際產(chǎn)出幀率一致-tune zerolatency關掉編碼器緩沖-preset ultrafast換速度。如果前端要 FLV把輸出改成-f flv rtmp://...或直接寫 FLV 文件。驗證延遲別靠感覺用土辦法拿手機秒表對著攝像頭同時截屏檢測畫面兩個時間差就是端到端延遲。我一般要求控制在 300ms 以內(nèi)超過就說明緩沖沒壓干凈。另一個辦法是在畫面里疊加時間戳看時間戳和當前時間的差值。最后說個習慣每次改完拉流參數(shù)或模型先跑 30 分鐘壓力測試看內(nèi)存有沒有緩慢上漲、延遲有沒有漂移。RTSP 流的坑大多是「跑十分鐘沒事跑兩小時才炸」短測看不出來。這套鏈路我在園區(qū)車輛統(tǒng)計上跑過半年最大的教訓就是重連邏輯和丟幀策略必須一開始就寫進去后期補的代價是重構整個讀取線程。希望幫到你。本文還有配套的精品資源點擊獲取