最開始讓我下決心折騰YOLOv12的是在一個商場客流統(tǒng)計項目里被舊模型按在地上摩擦的經(jīng)歷。鏡頭從二樓俯拍下去扶梯口密密麻麻全是人檢測框一個疊一個漏檢率直接飆到我不想看統(tǒng)計報表。后來把整體方案換成“YOLOv12 密集行人數(shù)據(jù)集 PyQt5界面 登錄注冊”的完整系統(tǒng)效果才真正穩(wěn)定下來。這篇就把整個《基于深度學習YOLOv12的密集行人識別檢測系統(tǒng)》從數(shù)據(jù)準備、模型訓練、界面聯(lián)調到現(xiàn)場排錯的過程完整翻出來項目源碼、模型、UI、登錄注冊這套東西怎么拼到一起以及我踩過的坑一次講清楚。不管你是做安防監(jiān)控、客流統(tǒng)計還是正在寫畢設/課設只要離不開“密集人群檢測”這幾個字這篇都適用。1. 密集人群檢測這個任務到底在考驗什么1.1 為什么普通模型在密集人群里“翻車”很多人覺得行人檢測就是“把行人框出來”聽起來比車輛檢測還簡單——大家都是直立行走的特征穩(wěn)定又沒有輪子。但真實項目里密集人群檢測恰恰是目標檢測里最難受的場景之一。先說遮擋。商場扶梯口、景區(qū)檢票處、演唱會散場通道那真是人貼人。目標被擋住40%到60%是常態(tài)頭部可能還在軀干已經(jīng)被前面的人蓋得嚴嚴實實。普通模型學的是“完整行人”的外觀特征一旦外觀殘缺置信度就嘩嘩往下掉。這時候不是模型笨是訓練時壓根沒見過這么多“半個人”。再說尺度。同樣的一個人在1080p畫面里距離鏡頭5米和15米像素尺寸能差三四倍。密集人群里必然混著大量小目標而小目標在特征圖下層池化幾次以后可能只剩下幾個像素的信息很容易被模型當成背景抹掉。第三是“群體上下文”的干擾。人一多背景就不干凈了到處都是胳膊、腿、背包、行李箱這些局部外觀和行人本身的局部很相似。模型如果把注意力放在這些重復紋理上就容易輸出一堆低質量框。所以密集行人檢測真正要解決的問題不是“能不能檢出人”而是“在互相遮擋、尺度變化大、背景雜亂的情況下能不能穩(wěn)定地把每個人框出來”。1.2 YOLOv12帶來的關鍵變化YOLOv12是2025年推出的新版本核心變化是把注意力機制比較系統(tǒng)地放進了YOLO架構里。傳統(tǒng)YOLO系列尤其是大家熟悉的v5、v8骨干網(wǎng)絡基本是CNN堆疊靠卷積感受野一點一點往上擴。CNN的優(yōu)點是快、穩(wěn)、部署方便缺點是對“全局關系”的建模偏弱。一個人被擋住半邊CNN看到的還是局部紋理拼湊而帶注意力機制的模型會在特征層面去建?！斑@個區(qū)域是不是一個完整目標的局部”相當于把散落的拼圖塊關聯(lián)起來。YOLOv12并不是簡單粗暴地整個Transformer搬進來而是做了工程化折中在不太犧牲推理速度的前提下把注意力模塊嵌在骨干和特征融合的關鍵位置。實際跑下來的感覺是普通街景場景下它跟v8、v11的差距沒有想象中大但一旦進入擁擠場景漏檢率和誤檢率確實能拉開一個身位。對大目標、整體輪廓被破壞的目標注意力帶來的收益尤其明顯。另外YOLOv12訓練時可以原生使用Ultralytics系列的訓練管線數(shù)據(jù)標注格式、評估指標、命令行入口基本可以無縫切換。我這次沒有用魔改分支直接基于官方代碼倉庫來跑數(shù)據(jù)格式還是熟悉的YOLO txt格式省去了很多適配成本。1.3 這套系統(tǒng)圍繞什么場景設計這套系統(tǒng)從一開始就不是給人臉檢測或者自動駕駛做的它的核心目標場景有三個第一是出入口客流統(tǒng)計比如商場出入口、地鐵閘機、展覽館門禁需要在多人同時通過的瞬間快速計數(shù)并且保留每個人的軌跡特征。第二是人群聚集預警比如景區(qū)廣場、車站候車廳當某個區(qū)域瞬時人數(shù)超過閾值時系統(tǒng)要給出提示這時候除了檢測框還需要一種簡單的區(qū)域人數(shù)統(tǒng)計算法。第三是安防檢索輔助比如事后翻查監(jiān)控錄像想快速找到“某個時間段某個人是否出現(xiàn)在畫面里”需要把檢測結果連同時間戳、畫面幀一起落盤。這三個場景決定了系統(tǒng)不能只是“跑個模型出個框”它必須有視頻源接入能力、實時畫面展示、檢測結果統(tǒng)計和存儲還要有一個讓人操作的門面。這就是為什么這套系統(tǒng)除了模型還會配套UI界面和登錄注冊。后面我會把每一塊都拆開講。2. 系統(tǒng)拆解技術棧選型與模塊邊界2.1 為什么用Python PyTorch OpenCV而不是純C部署很多做嵌入式或者C部署的朋友會問識別系統(tǒng)不是應該用TensorRT C嗎精度高、延遲低、好落地。但你要看項目階段的訴求。這套系統(tǒng)要用于算法驗證、效果演示、現(xiàn)場參數(shù)快速調整迭代速度遠比極致性能重要。Python生態(tài)的優(yōu)點在算法驗證階段太明顯了Ultralytics的檢測接口可以直接調用OpenCV負責攝像頭讀取和畫框PyQt5寫界面SQLite存賬號數(shù)據(jù)整個鏈路不需要編譯改一個閾值參數(shù)馬上能看到效果。等到算法徹底定型再考慮用ONNX或TensorRT導出到C部署也不遲。我在這個系統(tǒng)里保留了ONNX導出端口后面實測部分會細說。PyTorch的選擇沒有懸念。模型訓練、推理、遷移學習都靠它特別是torch的DataLoader和amp混合精度在訓練階段能省下大量時間。OpenCV承擔的任務比較雜讀取本地視頻、連接RTSP攝像頭、BGR與RGB轉換、圖像縮放、在畫面上疊加檢測框和文字。它雖然不是最高效的但兼容性和社區(qū)資料是最穩(wěn)的。2.2 UI層選PyQt5還是WebUI有兩條路桌面端用PyQt5/PySide6Web端用Flask/FastAPI 前端框架。我這次選擇的是PyQt5。原因并不復雜。當下的需求是單機運行、操作直觀、低延遲顯示視頻流。PyQt5的QLabel可以直接刷OpenCV的幀實時性好鼠標拖動縮放、窗口布局都很好控制不依賴瀏覽器和網(wǎng)絡服務?，F(xiàn)場項目里給安保人員一臺裝了界面的電腦打開就能用比開瀏覽器輸?shù)刂分庇^得多。如果是做遠程訪問或者多終端同時看那Web方案更合理但系統(tǒng)復雜度會上一個層級要處理并發(fā)問題。這套系統(tǒng)的定位是“本地一體機”PyQt5夠用了。如果你打算改成Web檢測引擎部分可以完全復用只把UI替換成Flask WebSocket流推送。2.3 一個干凈的目錄結構怎么設計工程最怕寫到后面文件亂飛。這個系統(tǒng)我用的目錄結構是這樣的pedestrian_detection_system/ ├── app.py # 程序入口 ├── config.yaml # 全局配置 ├── requirements.txt # 依賴包清單 ├── models/ # 訓練好的模型權重 ├── dataset/ # 原始數(shù)據(jù)集與標簽 ├── ui/ │ ├── login_window.py # 登錄注冊界面 │ ├── main_window.py # 主界面 │ └── resources/ # 圖標、樣式表 ├── core/ │ ├── detector.py # YOLOv12推理封裝 │ ├── video_source.py # 本地/RTSP視頻源管理 │ ├── stats.py # 檢測統(tǒng)計 │ └── database.py # SQLite用戶與日志 └── utils/ ├── draw.py # 畫框、畫統(tǒng)計信息 └── logger.py # 日志記錄這樣拆的好處是檢測邏輯和界面完全解耦。你想換成別的數(shù)據(jù)集重訓一個模型只需要替換models目錄下的權重和config里的模型配置你想換個UI框架core目錄完全不需要動。3. 數(shù)據(jù)準備從開源數(shù)據(jù)集到YOLO格式的真實細節(jié)3.1 哪些公開數(shù)據(jù)集值得用模型效果的上限一半是由數(shù)據(jù)決定的。我這次訓練數(shù)據(jù)主要來自三塊第一塊是COCO數(shù)據(jù)集的person類。COCO覆蓋面廣場景雜但很多圖是日常街景密集程度不算高。它適合做底料讓模型學到一個比較通用的“行人”概念。第二塊是VisDrone的部分行人類別。VisDrone是無人機視角人群密度高目標小遮擋嚴重正好補COCO的不足。它的標注是MS COCO格式需要轉一次。剛開始模型在密集場景下無力就是缺少這類“高壓數(shù)據(jù)”的毒打。第三塊是從MOT Challenge等行人跟蹤數(shù)據(jù)集中篩出來的幀。跟蹤數(shù)據(jù)集天然包含連續(xù)幀人挨著人的畫面特別多拿來補充遮擋樣本很合適。我自己的經(jīng)驗是不要只拖一個數(shù)據(jù)集用到底。把上面三個按比例混合效果最好我這里大概是COCO 6成、VisDrone 3成、MOT幀1成?；旌现跋冉y(tǒng)一類別全部只保留person這一類。3.2 YOLO標注格式和轉換腳本的坑YOLO格式的標注是每張圖一個同名txt文件每行代表一個目標格式為“類別id x_center y_center width height”全部坐標都是相對圖片寬高的歸一化數(shù)值。這個格式看起來簡單轉換時卻有三個容易出錯的點。第一個是類別id要對齊。COCO的person類是0但有些數(shù)據(jù)集person是別的id。轉換腳本里最容易翻車的就是這里訓練時發(fā)現(xiàn)模型什么都不檢先看是不是標簽標簽里混著499和500這種非法id我踩過。第二個是坐標歸一化。有些開源數(shù)據(jù)給的是左上角坐標和寬高要自己算成中心點坐標。四舍五入保留幾位也影響不大但別用int取整會損失小目標的框精度。第三個是無效標簽。有些json標注里會出現(xiàn)空標簽文件也就是一張圖沒有任何目標。訓練時如果用了多尺度、Mosaic增強空標簽會報錯。轉換腳本里統(tǒng)一過濾掉這種圖片就好。下面是我當年寫的數(shù)據(jù)轉換核心片段注釋標出了最容易錯的地方import json import os from PIL import Image def coco_to_yolo(coco_json_path, image_dir, output_dir, valid_category_ids(0,)): with open(coco_json_path, r, encodingutf-8) as f: coco_data json.load(f) image_map {img[id]: img for img in coco_data[images]} category_map {cat[id]: cat[name] for cat in coco_data[categories]} annotations_by_image {} for ann in coco_data[annotations]: if ann[category_id] not in valid_category_ids: continue annotations_by_image.setdefault(ann[image_id], []).append(ann) for image_id, ann_list in annotations_by_image.items(): img_info image_map[image_id] img_path os.path.join(image_dir, img_info[file_name]) # 注意讀取寬高時優(yōu)先從圖片本身獲取不要完全依賴json里的寬高字段 with Image.open(img_path) as img: img_w, img_h img.size txt_path os.path.join(output_dir, os.path.splitext(img_info[file_name])[0] .txt) with open(txt_path, w, encodingutf-8) as f: for ann in ann_list: x, y, w, h ann[bbox] # coco bbox給的是左上角坐標和寬高 center_x x w / 2.0 center_y y h / 2.0 # 關鍵所有坐標除以圖片寬高得到0~1之間的歸一化值 center_x_norm center_x / img_w center_y_norm center_y / img_h w_norm w / img_w h_norm h / img_h # category_id這里要映射成你自己的類別id不能直接抄寫原數(shù)據(jù)集的id f.write(f0 {center_x_norm:.6f} {center_y_norm:.6f} {w_norm:.6f} {h_norm:.6f}\n)轉換完以后我會隨機抽20張圖把標注框畫回去人工檢查一遍。這一步不能省因為腳本寫錯時數(shù)據(jù)比例往往看著正常一眼根本看不出來。3.3 針對密集場景的數(shù)據(jù)增強策略YOLO系列自帶Mosaic增強也就是把四張圖拼成一張訓練圖。這在常規(guī)場景里很好用但密集人群場景下我還額外加了兩個操作隨機貼片模擬遮擋隨機從別的圖里扣一塊行人區(qū)域貼到當前圖上蓋住部分目標。這能強迫模型學著用可見局部識別目標。隨機裁剪縮放對高密度區(qū)域按0.5到0.8的隨機比例裁剪后再縮回訓練尺寸。這能讓模型適應不同尺度的擁擠畫面也相當于做了尺度增強。增強不是越多越好。訓練后期你會發(fā)現(xiàn)增強太重會讓模型很難收斂loss降不下去。我的習慣是前一半epoch用完整增強后一半逐步降低增強強度讓模型在干凈數(shù)據(jù)上“收一收”。Ultralytics里可以用超參配置調控例如mosaic: 0.8 mixup: 0.2 fliplr: 0.5 scale: 0.5這個配置是根據(jù)我的場景定的你不用照抄但思路可以借用密集場景優(yōu)先保mosaic和scaleflip保持0.5mixup不要調太高否則動態(tài)模糊反而讓目標邊界更亂。3.4 數(shù)據(jù)劃分按場景切而不是隨機切很多新手訓練模型時會隨機把圖片分成train和val。這樣做出來的指標好看但實際部署就露餡。原因很簡單隨機劃分會讓同一視頻里的連續(xù)幀同時出現(xiàn)在訓練集和驗證集模型等于變相“看過答案”。我這套系統(tǒng)的做法是按采集場景劃分。同一個攝像頭、同一個地點、同一段時間的素材全部歸到同一個集合里絕不讓它們跨集。比如A商場的素材全部進訓練B商場的素材全部進驗證C項目現(xiàn)場素材最后拿來壓測。這樣驗證結果才能代表真實場景。另外密集人群驗證集的比例我故意調高到30%。這類任務如果驗證集里沒有大量擁擠畫面mAP再高都說明不了問題。4. 模型訓練參數(shù)、監(jiān)控與評估4.1 訓練環(huán)境配置訓練時我用的是單卡環(huán)境顯存24G跑YOLOv12的中型模型比較寬裕。如果你是學生或者在普通機器上跑建議直接選nano或small版本效果差不了太多訓練時間能省一半以上。PyTorch版本建議2.xCUDA對應裝好就行Ultralytics對版本兼容性做得比較好一般不會卡在環(huán)境上。依賴清單長這樣python3.10 torch2.1.0 torchvision0.16.0 ultralytics8.3.x opencv-python4.8.* PyQt55.15.* pyyaml6.*這里有個細節(jié)不要貪最新版本。Ultralytics家更新很快有時候新版會改默認行為你照著教程跑結果不一樣不一定是代碼錯可能是框架行為變了。我在項目里會把requirements.txt鎖死版本方便以后重建環(huán)境。4.2 訓練參數(shù)怎么定訓練命令直接用Ultralytics的CLI就行yolo detect train \ --model yolo12s.yaml \ --data dataset.yaml \ --epochs 200 \ --batch 16 \ --imgsz 1280 \ --device 0 \ --optimizer AdamW \ --lr0 0.001 \ --weight_decay 0.0005 \ --amp幾個參數(shù)我說下選擇的理由。imgsz對密集小目標影響最大。1080p畫面里的人群目標普遍偏小如果縮到640再送進網(wǎng)絡很多目標只有十幾個像素神仙模型也難救。我把訓練尺寸調到1280之后小目標的召回率提升非常明顯。代價是訓練時間翻倍、顯存壓力變大。如果機器跑不動先640跑通流程再用1280精調。batch受顯存約束不是越大越好。batch太大會導致每個epoch的迭代次數(shù)少模型反而欠擬合。16在24G顯存下配合1280輸入剛剛好。epochs我設了200但實際在140左右就用早停收工了。密集人群訓練后期很容易過擬合表現(xiàn)為訓練loss繼續(xù)降、驗證mAP不再漲甚至掉。建議開著早停patience設30。4.3 訓練過程的觀察要點訓練時不要只盯屏幕等進度條一定要看訓練曲線的三個信號第一是box_loss有沒有相對平滑地下降。如果前10個epoch loss紋絲不動先查學習率、查標簽有沒有問題不要頭鐵繼續(xù)跑。第二是驗證集mAP是否穩(wěn)步上升。如果訓練集已經(jīng)漲得很高、驗證集遲遲不漲基本就是過擬合該減epoch或者加數(shù)據(jù)增強。第三是看特定類別的AP這里只有person類所以就是整體AP。如果mAP50能到85%以上但mAP50-95偏低說明模型框的位置還不夠準可以朝調高輸入尺寸、優(yōu)化錨框/標簽分配方向想。密集行人場景我個人的手感是mAP50能到88%以上密集畫面基本可用mAP50-95到60%以上就是很好的水平了不必死磕。4.4 密集人群下的評估指標別只用mAPmAP是一個綜合指標但密集人群場景里它不夠直觀。我評估模型好不好用還會加兩個指標漏檢率也就是標注里“人”被完全漏掉的比例。統(tǒng)計一下畫面里有100個真目標模型只給出80個框漏檢率就是20%。這個數(shù)直接影響客流統(tǒng)計的準確性。誤檢率也就是模型把拉桿箱、垃圾桶、廣告牌上的假人認成人的比例。這個數(shù)直接影響預警系統(tǒng)會不會沒事亂響。某個模型mAP看起來很高但漏檢和誤檢可能同時很高——它可能輸出一堆重復框、覆蓋率高但位置漂移的框mAP計算時重復框會被NMS處理掉所以看不出來。我之前就吃過這個虧模型在COCO上mAP50有90%拿到密集現(xiàn)場一看一個人可能被框了三遍客流數(shù)直接爆表。所以代碼里除了調用evaluate得到mAP我還單獨寫了一個腳本統(tǒng)計漏檢率和誤檢率專門用來判斷“這個模型能不能上線”。5. 登錄注冊與UI一個“能用”的產(chǎn)品該有的樣子5.1 登錄注冊模塊要不要做有人會問一個本機的檢測工具搞登錄注冊是不是多此一舉我的答案是看項目交期和使用對象。如果只是自己跑著玩登錄確實可以砍掉。但如果有多個操作人員交替使用或者要把這個系統(tǒng)交給甲方驗收登錄注冊就是必要功能。它至少解決了三件事賬號權限隔離不是每個人都能改模型參數(shù)和檢測閾值。操作留痕誰在幾點登錄、運行了哪些檢測都有記錄。給人“這是一個完整系統(tǒng)”的觀感甲方看到登錄界面對項目的完成度評價會高一個檔次。5.2 本地賬號體系SQLite就夠了這個系統(tǒng)無需聯(lián)網(wǎng)賬號體系本地化最合適。我用SQLite建了一張用戶表密碼不存明文而是用哈希加鹽方式存儲。下面這段示例展示了哈希校驗的核心思路import hashlib import sqlite3 import os def hash_password(password: str, salt: str None) - str: if salt is None: salt os.urandom(16).hex() digest hashlib.sha256((salt password).encode(utf-8)).hexdigest() return f{salt}${digest} def verify_password(stored: str, password: str) - bool: salt, digest stored.split($, 1) return hash_password(password, salt) stored這里沒有使用bcrypt這類重量級庫是因為本機系統(tǒng)被攻破的風險面本來很小用SHA256加鹽已經(jīng)足夠防止“看一眼數(shù)據(jù)庫就知道密碼”的情況。系統(tǒng)越簡單越容易維護。同時我用數(shù)據(jù)庫記錄登錄日志登錄時間、登錄結果、檢測時長。運行幾次以后這套日志對排查問題很有幫助。5.3 主界面該放什么控件主界面我用PyQt5實現(xiàn)布局分成四塊區(qū)域左側視頻顯示區(qū)用來展示原始畫面和檢測結果畫框。視頻源可以切換本地文件、USB攝像頭、RTSP協(xié)議流地址。右側實時統(tǒng)計區(qū)顯示當前幀檢測人數(shù)、峰值人數(shù)、每秒幀數(shù)以及總檢測數(shù)。還可以用一個折線圖展示最近N秒人數(shù)變化趨勢。底部控制區(qū)放開始/停止按鈕、置信度閾值滑塊、IOU閾值滑塊、截圖按鈕、導出報表按鈕。菜單欄放模型選擇、日志查看、用戶管理入口。置信度閾值和IOU閾值這兩個滑塊一定要放在界面上不要寫死在代碼里。原因很簡單不同攝像頭角度、不同密度的畫面最優(yōu)閾值差別很大。比如俯拍場景置信度閾值0.3就夠平視場景可能要調到0.55才能壓住誤檢?，F(xiàn)場人員可以在不重啟程序的情況下實時調整這才是“能用”的產(chǎn)品。5.4 檢測引擎和UI解耦很多人寫PyQt界面時習慣把檢測循環(huán)直接塞進界面的槽函數(shù)里結果界面一卡一卡的拖一下窗口畫面就卡死。原因很直接檢測是耗時操作放在UI主線程里界面必然等它。正確做法是單獨開一個工作線程跑檢測通過信號把處理好的幀傳回界面。PyQt5里可以用QThread或者更輕量的QThreadPool。我把檢測循環(huán)封裝在了core/detector.py里它只依賴opencv和模型自己不知道UI的存在。UI線程只負責接收檢測結果并刷新畫面。class DetectionThread(QThread): frame_ready pyqtSignal(object, object) def __init__(self, video_source, detector, conf_thresh, iou_thresh): super().__init__() self.video_source video_source self.detector detector self.conf_thresh conf_thresh self.iou_thresh iou_thresh self.running True def run(self): for frame in self.video_source.read_frames(): if not self.running: break results self.detector.predict(frame, self.conf_thresh, self.iou_thresh) annotated self.detector.draw_boxes(frame, results) self.frame_ready.emit(annotated, results)這個線程把“讀一幀、推理、畫框”整套流程局限在工作線程里界面主線程收到frame_ready信號后只做一次label圖片更新流暢度和穩(wěn)定性都有保證。6. 實測與排錯記錄6.1 漏檢嚴重時先別急著換模型剛把YOLOv12配置跑通時我在一個商場扶梯的測試視頻上發(fā)現(xiàn)問題上半段人群稀疏檢測很好但扶梯出口處的密集區(qū)域漏檢一片。當時第一反應是“模型不行”后來一步步排查才發(fā)現(xiàn)問題出在輸入尺寸上。測試代碼里我沿用了自己習慣的imgsz640這個尺寸對普通場景夠用但對密集場景就是致命傷。扶梯出口處一個人可能只有20像素高640輸入下特征圖上的響應極弱。把推理尺寸改成1280后漏檢率肉眼可見地降下來。所以如果你也遇到密集場景漏檢先檢查輸入尺寸再檢查置信度閾值最后才輪到模型架構。6.2 幫你少走彎路的一些調參筆記置信度閾值密集人群場景建議從0.25開始調如果誤檢多就往上加到0.45左右如果漏檢多就往下減。IOU閾值建議保持在0.45到0.5之間過高比如0.7會導致同一個人的多個重疊框都保留計數(shù)虛高過低又會讓兩個人的框被合并成一個計數(shù)漏掉。推理尺寸訓練和推理尺寸要盡量一致不要訓練1280、推理640效果損失非常大。數(shù)據(jù)增強如果場景光照變化大可以在優(yōu)化階段把光照擾動、模糊擾動加上這些對行人檢測的魯棒性很有幫助。密度極高場景如果人群密集到只露出一片人頭可以考慮單獨訓練一個detection head或使用人頭檢測模型做二次過濾整體效果會明顯好過單個全身模型。6.3 GPU推理速度與界面流暢度系統(tǒng)在GTX級別顯卡上推理1280分辨率單幀大約20到40毫秒。但界面刷新幀率不高原因在畫框和圖像格式轉換。OpenCV默認是BGRPyQt顯示需要轉成RGB再轉QImage這個開銷比想象中大。優(yōu)化方式是只在結果返回時才做那個幀的格式轉換不要把視頻流每一幀都轉減少無謂開銷。另外如果推理幀率和顯示幀率不一致不要強行同步。檢測線程按自己的節(jié)奏跑界面按固定的刷新間隔顯示最新幀就能讓畫面看起來流暢。沒有必要讓UI去等待檢測速度。6.4 視頻源兼容問題本地視頻文件基本沒問題USB攝像頭要看驅動型號Windows下容易遇到權限或占用問題。RTSP流是最容易踩坑的不同廠家的攝像頭對OpenCV的兼容性不一樣有些流用H.265編碼OpenCV默認支持不好畫面根本打不開。解決辦法是先用VLC確認這個流能正常播放再在OpenCV里嘗試拉流。如果實在不行用FFmpeg轉封裝再讀也是個不錯的備選。7. 一點后續(xù)可以順手做的小擴展系統(tǒng)主體跑通以后我強烈建議你加一個“檢測結果落盤”的功能每一幀的檢測框、置信度、人數(shù)統(tǒng)計、時間戳都寫進CSV同時對超過人數(shù)閾值的關鍵幀自動截圖。這個擴展能極大提升系統(tǒng)的實用性用來做事后統(tǒng)計、軌跡分析都是現(xiàn)成的數(shù)據(jù)基礎。落盤代碼用一個簡單的格式就夠with open(detect_log.csv, a, newline, encodingutf-8) as f: writer csv.writer(f) for box in results.boxes: writer.writerow([ frame_id, datetime.now().isoformat(), box.cls.item(), box.conf.item(), box.xyxy[0, 0].item(), box.xyxy[0, 1].item(), box.xyxy[0, 2].item(), box.xyxy[0, 3].item() ])這條日志會幫你省很多事?，F(xiàn)場出了問題回看日志基本能判斷是模型漏檢、閾值設置不合適還是視頻源本身的問題。8. 項目實戰(zhàn)中最重要的幾點總結這套系統(tǒng)做下來最值得記住的經(jīng)驗有三條。第一密集人群檢測的數(shù)據(jù)比模型更重要把時間花在數(shù)據(jù)篩選、清洗和場景劃分上比反復換模型變體劃算得多。第二推理尺寸、置信度閾值、IOU閾值這些參數(shù)要根據(jù)真實場景反復試不要期望一組參數(shù)通吃所有攝像頭。第三界面和檢測邏輯一定要分層解耦用線程和信號組織數(shù)據(jù)流否則系統(tǒng)永遠卡頓也就談不上實用。如果你正在復現(xiàn)這套系統(tǒng)我建議按這個順序推進先把YOLOv12模型在公開數(shù)據(jù)上跑通推理再把數(shù)據(jù)轉換和訓練流程搭好模型效果穩(wěn)定之后再去做UI和登錄注冊。千萬不要一上來就鋪開做界面后面發(fā)現(xiàn)模型效果不行所有的界面代碼都要返工。先把“模型能不能在密集場景里站穩(wěn)”這個問題解決掉其他都是水到渠成的事。