简介：面向计算机视觉与智能交通方向的开发者，这份基于YOLOv5与DeepSort的车流量统计项目资料包，专门应对密集车流场景下的车辆检测、跟踪与计数问题，适合算法学习者、毕设选题者及工程落地人员快速起步。包内共117个文件，以55个Python源码为核心，配套20个YAML配置、7个Markdown说明、4个MP4演示视频、预训练模型权重等，涵盖模型训练、目标跟踪、计数逻辑与部署配置（如Dockerfile）等环节，压缩包约79.17MB，便于离线使用与二次开发。目前已有288人学习，项目结构清晰，从数据处理到结果可视化均有对应模块，可直接运行或按需修改。通过源码与演示视频，能直观理解YOLOv5检测与DeepSort跟踪协同工作的原理，并快速复现一套可适应密集交通流的统计方案。同时提供Jupyter Notebook示例与容器化环境配置，方便逐步调试与部署。
1. 密集车流下，YOLOv5+DeepSort 还够用吗：这套方案能解决的问题和它的边界
傍晚的城市快速路，车流被压缩成一条缓慢蠕动的铁链，小轿车连续变道，大巴车体把后面的几辆车挡得严严实实。同一个目标在画面里被追成一串断裂的碎片：ID 182 变成了 ID 193，统计面板上的车流量数字跟着疯涨。这套基于 YOLOv5+DeepSort 的车流量统计算法，解决的就是这个场景下的流量统计问题——先由 YOLOv5 把每一帧里的车辆检测出来，再由 DeepSort 在帧间把同一个车连成轨迹，最后借助虚拟检测线做方向判定和计数。它适合城市快速路、高速匝道、交叉口和园区出入口的流量统计项目，也能给速度估计、排队长度分析打底。需要先说清楚：很多人把这类项目当成“训练完就能直接投产”的库，真实项目中密集车流恰恰会把 DeepSort 的弱点全逼出来，理解它的边界比跑通 demo 更重要。
2. 检测、跟踪与计数盯的是同一件事：YOLOv5+DeepSort 的原理和分工
一套车流量统计系统里，检测器、跟踪器、计数器各管一段：YOLOv5 负责在单帧画面里回答“哪里有车、车有多大”，DeepSort 负责跨帧回答“这辆车是谁、它上一帧在哪”，最后统计模块回答“它从哪条线经过、方向是什么、算不算一次通过”。很多项目把精力全花在检测精度上，实际做出来才发现，车流量统计的误差大头往往出在跟踪器的身份切换和计数逻辑的去重上。
2.1 YOLOv5 在车流检测里的位置：选它不是因为“新”
先讲一个容易被忽略的事实：车流量统计的检测目标相对固定，就是轿车、卡车、公交车这几类，场景也相对单一——固定的监控视角、固定的道路区域。这种任务对检测器的要求不是“什么都能认得”，而是“在目标小、遮挡多、夜间光线差的情况下尽量少漏、少错”。YOLOv5 在这个定位下依然是很划算的选择，网上搜 YOLOv5 网络结构图，Backbone、Neck、Head 三段式布局很清楚，改起来不费劲，导出 ONNX、TensorRT 的案例也多，训练部署的“后悔药”比新框架多得多。
我一般会拿 YOLOv5s 或 YOLOv5m 做起步，座舱摄像头分辨率如果偏低，s 模型就够；如果是 4K 画面截取 ROI 再送检，m 甚至 l 的召回率会明显更好。近两年的 YOLOv8、YOLOv11 检测精度更高，但配套的 DeepSort 整合代码、前后处理细节在网上远不如 v5 积累厚实。车流统计项目里“稳定复现”的价值大于“版本新”，这是我选型的第一原则。
2.2 DeepSort 的跟踪链路：卡尔曼预测、级联匹配与 ReID 特征
DeepSort 的核心链路分三段。第一段是卡尔曼滤波，它在 8 维状态空间里维护每个目标的运动状态，包括 bbox 中心坐标、宽高比、高度以及它们的速度，用它预测目标在下一帧的位置。第二段是级联匹配，优先给那些连续出现、轨迹稳定的目标做匹配，再处理刚丢了几帧的轨迹。第三段是外观特征，DeepSort 通过一个小的 ReID 网络提取车辆外观特征，用余弦距离判断两个框是不是同一辆车。
这三段合起来，就是 DeepSort 比原始 Sort 强的地方：Sort 只靠 IoU 和运动预测，一旦遮挡导致框跳变就切换身份；DeepSort 多了一层外观特征，能扛住短时间的遮挡。但密集车流恰恰是它的压力测试——车辆外观相似度高，黑色轿车和深灰轿车在 ReID 特征空间里几乎挤在一起，余弦距离分不开；车辆互相遮挡时，卡尔曼预测的位置和真实位置偏差变大，马氏距离也失效。后面避坑章会专门展开这些问题，这里先记住一个结论：DeepSort 不是万能的，它在稀疏车流里表现优秀，在密集车流里需要调参数、改逻辑。
2.3 三个模块怎么分工：检测输出、跟踪更新与统计入口
从工程代码的角度看，主循环一般长这样：
# 主循环：检测 -> 跟踪 -> 统计 cap = cv2.VideoCapture(video_path) while cap.isOpened(): ret, frame = cap.read() if not ret: break # 1. YOLOv5 检测：返回 xyxy、置信度、类别 dets = detect_model(frame, conf_thres=0.4, iou_thres=0.5) # 2. DeepSort 更新：用当前帧检测结果更新跟踪器 tracks = deepsort.update(dets, frame) # 3. 统计模块：用轨迹信息做跨线计数 counter.update(tracks) # 4. 绘制画面：检测框、ID、计数结果 draw_result(frame, tracks, counter)这段代码是整套系统的骨架。注意 detect_model 返回的是检测框列表，DeepSort 的 update 方法同时接收检测结果和原始图像，因为它内部既要运动匹配也要提取外观特征。tracker 返回的 tracks 里包含每个目标的 bbox、ID 和确认状态，计数逻辑只应该使用 is_confirmed 为 True 的轨迹，否则刚出现一两帧的噪声框也会被计入流量。我见过有人直接拿检测框数量去当车流量的，那会把同一辆车在连续帧里重复计数，属于最典型的统计口径错误。
3. 用 YOLOv5 训练自己的车辆检测器：数据、超参数与后处理调优
检测器是整套系统的底层，它的召回率直接决定跟踪器能拿到多少有效输入。密集车流里最怕的是漏检：一辆车被遮住两秒钟，DeepSort 的轨迹就会断掉，断掉再出现就会产生新的 ID，计数自然翻倍。所以训练阶段的目标不是“mAP 好看”，而是“在遮挡和拥挤条件下依然能稳定检出”。
3.1 数据集从哪来：公开数据集与自建标注的取舍
做车流量统计，公开数据集首选车辆目标密集、带真实交通场景的。UA-DETRAC 是常见选择，它包含城市道路的车辆检测和跟踪标注，画面里车流密度不小；SODA 系列和 BDD100K 也覆盖城市道路，夜间和恶劣天气样本相对全。直接用它们训练的问题是视角差异：很多公开数据是车载视角或高点俯拍，而你的项目大概率是路杆上的固定监控视角，俯拍角度下车辆是“顶视+侧视”混合形态，直接用公开集训练出来的模型，在目标小而密集时召回会掉。
我一般会采用“公开集预训练 + 自建场景微调”的路线：先用 COCO 或 UA-DETRAC 预训练权重起步，再拿自己现场拍摄的 3 到 5 段视频，每段抽几百帧做标注。标注工具用 LabelImg 或 X-AnyLabeling 都可以，输出 YOLO 格式的 txt。目录结构按 YOLOv5 的习惯组织：
datasets/vehicles/ ├── images/ │ ├── train/ # 现场视频抽帧，约 2000 张 │ └── val/ # 另一时段视频抽帧，约 300 张 ├── labels/ │ ├── train/ # 与 images/train 一一对应的 txt │ └── val/ # 与 images/val 一一对应的 txt └── vehicles.yaml # 数据配置labels 里每行是一个目标：类别 ID、归一化中心 x、归一化中心 y、归一化宽 w、归一化高 h。类别尽量控制在 car、bus、truck 三类，摩托车和行人单独建类，避免混在一起干扰车辆计数。标注的难点在遮挡：两辆车重叠时，被遮挡严重的车要不要标？我的做法是“能看出完整轮廓就标，只剩一条边就不标”，这样可以减少训练时的噪声标签，让模型把精力放在能有效检测的目标上。
3.2 训练自己的数据集：目录结构、data yaml 与常用超参数
先看 vehicles.yaml 的写法：
train: datasets/vehicles/images/train val: datasets/vehicles/images/val nc: 3 names: ['car', 'bus', 'truck']然后跑训练命令。YOLOv5 官方仓库的 train.py 是入口，下面是我在车流项目里比较稳的一组参数：
python train.py \ --data vehicles.yaml \ --weights yolov5s.pt \ --img 1280 \ --batch 16 \ --epochs 150 \ --hyp hyp.scratch-low.yaml \ --patience 30这里有几个参数值得展开。--img 是训练分辨率，密集车流里目标普遍小，用 640 起步时小车的召回率往往不够，提到 1280 能明显改善远处小车的检出，但显存占用和推理时间都会上涨，如果现场摄像头画面里车辆占比较高，可以先从 640 训练，再用 1280 微调几个 epoch。--batch 受显存限制，训练 1280 分辨率时 batch 16 需要约 16GB 显存，显存小就降到 8。--hyp 是 YOLOv5 超参数文件，hyp.scratch-low.yaml 比较稳，不要一上来就开高增强，密集车流场景里 mosaic 增强会大量制造“车辆挤在一起”的训练样本，反而对遮挡鲁棒性有帮助，但如果你的验证集是稀疏车流，mosaic 过多会让模型在真实稀疏场景下误检。
超参数调优是车流项目里最像“玄学”的部分，但有几个规律可以遵循：学习率 lr0 保持默认的 0.01，不要调大，密集小目标场景下调大学习率很容易发散；anchors 参数可以不开自动锚框，用默认值；数据增强里的 hsv_h、hsv_s 可以稍微调低，因为车辆颜色是计数时不敏感的信息，过度改变颜色反而让模型学到不真实的外观。
3.3 推理后处理调优：conf_thres、iou_thres 和 NMS 的取舍
模型训完，真正决定上线效果的还有检测后处理。YOLOv5 的后处理包含置信度阈值和 NMS，--conf-thres 和 --iou-thres 这两个参数在密集车流里的影响比很多人想象的大。conf-thres 设得太低，路牌、护栏、树影会被误检成车，跟踪器会为这些假目标维护轨迹，消耗算力也污染计数；设得太高，被遮挡的车辆尾部、夜间只露出半个车身的车就会被漏掉。
iou-thres 管 NMS 的合并力度，在并排行驶的车流里尤其敏感。两辆轿车并排且部分重叠，iou-thres 设成 0.5 时可能被合并成一个框，跟踪器只追到一个 ID，流量少计一辆；调到 0.3 左右，重叠目标更容易被保留为两个独立框。我一般从 conf=0.4、iou=0.5 起步，再用验证视频逐帧检查，重点看三类错检：护栏被当车、相邻车辆被合并、远处小车漏检。调参没有捷径，抽 200 帧数出“应该检出多少车”作为基准，把误检和漏检量化后再改阈值，比自己盯着屏幕感觉要可靠。
3.4 把检测结果交给 DeepSort：从 bbox 到轨迹的最小代码
训练的模型推理输出是 xyxy 格式的检测框，DeepSort 的 update 方法期望的输入一般也是 xyxy 加置信度加类别信息。接口转换是新手最容易翻车的位置，下面这段是我在项目里固定用的适配写法：
from deep_sort.deep_sort import DeepSort deepsort = DeepSort( model_path="weights/osnet_x1_0_msmt17.pth", max_dist=0.2, max_iou_distance=0.7, max_age=70, n_init=3, nn_budget=100, ) def detect_to_tracks(frame, results): dets = [] for *xyxy, conf, cls in results: # results 是 YOLOv5 的推理输出 if int(cls) not in (0, 2, 5): # 只保留 car、bus、truck continue if conf < 0.4: continue x1, y1, x2, y2 = map(int, xyxy) dets.append([x1, y1, x2, y2, conf, int(cls)]) if len(dets) == 0: return [] return deepsort.update(dets, frame)注意这段代码里有三个关键过滤：类别过滤保证行人、摩托车不会进入车辆计数；置信度过滤在跟踪前去掉低质量检测，减少假轨迹；deepsort.update 必须在每帧调用一次，即使没有检测结果也要传空列表调用，否则跟踪器内部的时间戳和轨迹状态不会推进。max_dist 是外观特征的最大余弦距离，密集车流里可以放宽到 0.3，但放宽后不同车辆的误匹配也会增加。n_init 控制一个目标连续出现多少帧后才被确认为正式轨迹，我习惯保持 3，太低会把闪烁的误检当成真车。
4. 车流量统计核心落地：虚拟检测线、方向判定与跨帧去重
检测和跟踪都跑通之后，车流量统计本身反而是整个项目里最需要想清楚的部分。统计口径是什么？按车道分别计数还是加总？要不要区分方向？这些问题直接决定了计数逻辑的复杂度。下面我把常用做法拆开讲，代码可以直接抄到自己的项目里改。
4.1 三种主流统计方案对比：检测线、检测区域与轨迹计数
| 统计方式 | 适用场景 | 优点 | 缺点 | 我的建议 |
|---|---|---|---|---|
| 虚拟检测线 | 断面流量统计、方向统计 | 实现简单，方向判定直观 | 车辆在线上停留时可能误判 | 多数项目首选 |
| 检测区域 | 交叉口排队、区域密度 | 能统计区域存在数量 | 无法区分方向，密集时重叠严重 | 辅助统计，不单独用 |
| 轨迹计数 | 车速估计、车道级分析 | 信息量最大，可做速度 | 对跟踪稳定性要求高 | 与检测线结合使用 |
虚拟检测线的本质是在画面里画一条线段，当车辆的跟踪轨迹穿过这条线时，车辆方向、通过时间、车道信息都能记录下来。检测区域适合统计“某个路口排队长度”或者“区域内车辆数”，但它统计不出流量——车辆在区域内停多久都算存在，不形成“通过”事件。轨迹计数则是把完整轨迹作为计数依据，理论上最准，但在密集车流里轨迹频繁断裂会让计数严重失真。我的项目里几乎都是“检测线计数 + 轨迹辅助计算车速”的组合。
4.2 用虚拟检测线做方向判定：直线方程与跨线判断
画检测线时，最实用的一条经验：用车辆 bbox 的底部中心点作为车辆位置，而不是 bbox 中心点。原因在于透视关系，摄像头俯拍时，车辆整体在地面的投影是梯形，bbox 底部中心最接近车辆与地面的实际接触点，用它做跨线判定，误差远小于用框中心。下面这段代码是检测线最小实现：
class VirtualLine: def __init__(self, p1, p2): # 线段端点 p1, p2 在画面像素坐标下 self.p1 = p1 self.p2 = p2 # 直线方程 ax + by + c = 0 self.a = p2[1] - p1[1] self.b = p1[0] - p2[0] self.c = p2[0] * p1[1] - p1[0] * p2[1] def side(self, pt): # pt 为 (x, y)，返回值正负代表点在线的哪一侧 return self.a * pt[0] + self.b * pt[1] + self.c # 在画面上选一条横向检测线，端点根据实际场景标定 line = VirtualLine((200, 720), (1680, 720))每帧拿到跟踪轨迹后，取轨迹里车辆的底部中心点，计算它相对检测线是哪一侧，和上一帧做比较。符号变化说明车辆跨过了线。这里有一个容易被忽略的细节：车辆跨线的过程中，底部中心点在某一帧可能恰好落在线上，side 值接近 0，此时不要立即判定跨线，而是等下一帧确认符号已经翻转，避免车辆在线上缓慢移动时反复触发。
方向判定依赖检测线的两个端点位置。比如一条从左到右的横向线，如果车辆底部中心从线的“上方”移动到“下方”，说明它在画面里向下行驶；从“下方”到“上方”则相反。如果你想统计对向两车道车流，就画两条方向相反的检测线，或者一条线两侧各计一个方向。
4.3 跨帧去重与计数循环：一个 ID 只算一次
跨帧去重是车流量统计的核心。视频流里同一辆车出现在几十帧画面中，如果每帧都计数，一辆车会被重复统计几十次。依赖 DeepSort 的 ID 去重是最直接的方案：每个 track 在生命周期内跨过检测线时只触发一次计数。我在代码里给每个 track 加一个 crossed_line 的标记状态，跨线后立即置位，轨迹销毁前不会再计。
class TrafficCounter: def __init__(self, line): self.line = line self.up_count = 0 # 向上方向车辆数 self.down_count = 0 # 向下方向车辆数 self.crossed_ids = set() # 已经跨线计数的 track ID def update(self, tracks): for track in tracks: if not track.is_confirmed(): continue track_id = track.id if track_id in self.crossed_ids: continue # 取 bbox 底部中心点作为车辆位置 x1, y1, x2, y2 = track.to_ltrb() bottom_center = ((x1 + x2) / 2, y2) prev_side = track.prev_line_side cur_side = self.line.side(bottom_center) if prev_side is not None and prev_side * cur_side < 0: if prev_side > 0: # 从正侧跨到负侧 self.down_count += 1 else: self.up_count += 1 self.crossed_ids.add(track_id) track.prev_line_side = cur_side这段代码有四个关键点。第一，只有 is_confirmed 的轨迹才参与计数，避免噪声轨迹污染。第二，crossed_ids 用集合去重，一个 ID 全生命周期只计一次，停车排队时车辆在检测线上来回蠕动也不会重复计。第三，prev_line_side 需要作为轨迹的状态保存，每帧更新，不能只靠全局变量，多目标场景下每个车的侧边状态必须独立。第四，计数方向用 prev_side 的符号判断，prev_side > 0 跨到负侧计为 down，反之为 up，方向定义你可以按照实际场景里的上下关系调整。
这个方案的瓶颈在 DeepSort 的 ID 稳定性。如果一辆车中途 ID 切换，crossed_ids 里记录的是旧 ID，新车 ID 跨线时会再计一次，这就是我在第 5 章重点讲的问题。项目上线前，我会在计数循环里顺带记录每一辆车的跨线时刻和车道位置，方便后续和人工计数做逐车比对。
5. 密集车流避坑指南：ID 跳变、遮挡漏检与重复计数
这一章是我反复调试后积累下的踩坑记录，每一条都是在真实项目里遇到过、并且能用参数和逻辑解决的。现象、原因、解决方式分开写，方便你对照排查。
5.1 跟踪 ID 频繁跳变：外观特征失效和卡尔曼预测漂移
现象：同一辆车在画面里行驶时 ID 从 182 变成 193，计数器被重复触发；两辆并排行驶的黑车，ID 在它们之间来回交换。
原因：密集车流里车辆外观相似，ReID 特征区分度差，DeepSort 依靠外观余弦距离匹配时置信度不够；同时车辆近距离交错时，卡尔曼滤波预测的 bbox 和真实位置偏差变大，运动马氏距离也失效，最终匈牙利算法把两辆车的 ID 互相匹配。这是 DeepSort 在密集场景下的先天短板。
解决：我一般从三方面入手。一是把 max_iou_distance 从默认 0.7 调到 0.5 左右，让遮挡严重的框更不容易被错误关联；二是把 max_age 适当调大（70 到 100），给短时遮挡的轨迹更多存活时间，但注意不要超过 120，否则轨迹丢失后会带着旧位置错误参与匹配；三是用更强的 ReID 权重替换默认的 ckpt.t7，项目里我换成过 osnet 系列的权重，密集车流的 ID Switch 减少一半以上。如果场景极端密集，上面这些都不够，我会直接考虑 ByteTrack 这类以检测框关联为主、不依赖 ReID 的跟踪器。
5.2 检测线附近漏计、重计：遮挡、静止车辆与轨迹中断
现象：一辆小车被大巴挡住，轨迹中断，出现后变成新 ID，跨线时被计了两次；堵车时车辆长时间停在检测线上，反复触发计数或者完全漏计。
原因：轨迹中断后 DeepSort 重新初始化轨迹，新 ID 不认得旧 ID，计数去重失效。静止车辆在检测线上停留时，它可能在 n_init 帧内被反复确认和丢失，产生重复事件；或者车辆还没跨线就被判定为丢失，等它再次出现时已经跨过线，漏计。
解决：检测线的位置要尽量避开遮挡严重的区域，放在车道中段而不是路口停止线附近。逻辑上，我把“跨线”事件改成“进入确认区再跨线”：车辆从进入检测线附近区域开始，只有轨迹连续存活超过 5 帧且跨线方向一致，才允许计数。对于静止车辆，我会引入速度判断，track 的位移速度低于阈值时不计入流量，只计入排队状态。注意这需要产品定义支持：车流量统计一般统计“通过断面的车辆”，不是“存在车辆”。
5.3 夜间、逆光与摄像头抖动：检测器掉点后的连锁反应
现象：夜间车灯过曝，车体轮廓模糊，检测框时有时无；逆光时车辆变成剪影，检测框全丢；大风或货车经过时摄像头抖动，画面里所有目标的坐标整体偏移，计数在检测线上反复横跳。
原因：检测器在低照度、过曝、逆光条件下的召回率下降，跟踪器拿不到稳定的检测框输入，轨迹自然断；摄像头抖动相当于给所有坐标加了高频噪声，跨线判定在边界附近反复触发。
解决：数据层面，训练集里加入夜间、逆光和雨雾样本，用图像增强模拟低照度和过曝，比只跑白天数据有效。工程层面，检测线不要贴着画面边缘，给抖动留出余量；在线侧边各加一条“缓冲区”，只有从缓冲区外进入缓冲区再跨线才算有效，可以过滤掉抖动造成的小幅坐标波动。最彻底的办法是做帧间运动补偿，用 ORB 特征点估计全局平移量，把坐标对齐后再送检测，但这是额外工作量，我只有摄像头固定不牢的项目才做。
5.4 数据可信度怎么自检：人工复核与误差评估
现象：程序给出的车流量和人工数出来的对不上，但看画面又觉得程序挺合理，不知道信谁。
原因：计数误差的来源是多级的，检测漏检、跟踪 ID 切换、跨线判定时机、统计口径不一致，任何一级的微小偏差在长时间统计下都会被放大。项目上线前如果没建立误差基线，后续优化没有抓手。
解决：我的做法是取一段 15 分钟原始视频，找两个人数出分方向的车流量，再和程序输出做逐车比对。最终误差率控制在 5% 以内算合格，超过 5% 就用比对结果定位是检测掉了还是 ID 切了。下面这段是误差评估的简化脚本：
def evaluate_count(manual_count, system_count): if manual_count == 0: return 0.0 return abs(system_count - manual_count) / manual_count # 示例：人工数出单向 100 辆，程序数出 106 辆 manual = 100 system = 106 print(f"误差率: {evaluate_count(manual, system) * 100:.1f}%")真实项目里，我会把误差按方向分别统计，因为不同方向的误差原因不同，合在一起会掩盖问题。误差超过 5% 时，优先看跟踪器输出里 ID Switch 的次数，如果 ID Switch 频繁，问题在 DeepSort 的参数；如果 ID Switch 不多但总数仍不对，再回头排查检测器的漏检检。
6. 从 DeepSort 改进到多断面验证：项目的进阶形态和验收方法
如果你按前面的步骤跑通了计数，下一步就是考虑如何让这套系统在更严苛的场景站住脚。密集车流的改进方向通常分两条线：一条在跟踪器层面，把 DeepSort 的 ReID 主干换成更强的模型，或者直接切换成 ByteTrack 这类不依赖外观特征的跟踪器；另一条在统计逻辑层面，用多检测线交叉验证来校正单线误判。
先讲跟踪器改进。我在一个双向六车道的项目中试过把 DeepSort 的 ReID 权重从默认 ckpt.t7 换成 osnet_x1_0_msmt17，ID Switch 降低了约四成，但特征提取耗时增加，帧率下降 10% 左右。如果车流密度高到车辆互相贴住，DeepSort 的级联匹配会频繁失手，ByteTrack 反而更合适——它只用检测框和 IoU 关联，低置信度框也保留参与匹配，对遮挡的容忍度更高。代价是车辆快速交错时可能把两辆车缝成一个轨迹。具体选哪套，我用一段包含严重拥堵的视频做评测，分别跑出计数误差率再决定，不凭感觉。
多断面验证是我强烈建议加的一层保险。在车流方向上设置两道检测线，两线相距一定像素，车辆先过线 A 再过线 B，只有依次经过两条线且轨迹连续的目标才进入最终计数。这样做有两个好处：一是单线误判可以被第二道线纠正；二是两线距离和跨线时间可以直接推算出车速，送给下游做超速统计。注意两道线的间距要足够大，密了没有验证意义，疏了会让轨迹中断概率上升。
验收阶段的最后一项是统计口径确认。做项目之前先问清楚甲方要什么：是“通过量”“断面流量”还是“存在数量”？高峰期的数据是否需要按 5 分钟粒度汇总？夜间最低照明亮度是多少？这些问题直接决定你调参的方向。我现在做新项目时会先拿一小段原始视频和两个人分别数一遍，先定出允许误差再谈模型参数，这套习惯帮我少走了很多弯路，希望帮到你。
本文还有配套的精品资源，点击获取
