2026-06-02 → 2026-06-03 · 验证 codec MV / dense optical flow 能否给击球检测提供时空 ROI 信号
TL;DR — 在 broadcast cricket 视频(CricketVision P1_V33)上跑了 4 轮 spike,把"motion → batsman ROI"这条路线从 codec MV raw 升级到 codec MV + overlay mask + affine compensation,再切换到 RAFT-small dense flow。四轮 spatial IoU 都没超过 0.01(target ≥ 0.20),且 keyframe heatmap 反复表明 batsman 是画面里 motion 最少的区域。问题不是算法、不是 codec,是 broadcast 拍摄方式让 batsman 局部 motion 信号天然不存在。Controlled 4K 数据集独立失败:HEVC 高码率 near-all-intra 编码,bitstream 里就没 MV(RAFT 不受影响,但还没测)。结论:broadcast 域 motion-based ROI 路线 close,回 pose-only;controlled 4K 仍可试 RAFT。
从 E6 v3.2 复盘(2026-05-26)得出:pose-only 路线对 partial body、umpire+far bat 等场景脆弱。设计的替代架构是把 motion 信号 拆为时空双轴:
┌─ Stage 1: 廉价时空粗筛(全 video) ──────────────────────────┐
│ 时序:per-frame motion 全局统计 → MV burst → 击球候选 ts list │
│ 空间:每候选 ts 上 motion 残余 cluster → batsman ROI bbox │
│ 输出:N 个 (t, bbox) 候选 │
└──────────────────────────────────────────────────────────────┘
↓
┌─ Stage 2: ROI pose 细判 (只跑 N 次,贵但少) ─────────────────┐
│ ROI crop 上 YOLO-pose vs 12-tpl v3.2 mirror pool → pose_sim │
└──────────────────────────────────────────────────────────────┘
↓
┌─ Stage 3: 高光综合分 = α·pose_sim + β·motion_in_roi + γ·burst │
└──────────────────────────────────────────────────────────────┘
关键假设:Stage 1 的 motion 信号能在 broadcast 视频上聚焦到 batsman 区域。这次 spike 全程在验证这个假设。
| 视频源 | codec | 分辨率/fps | 时长 | GT |
|---|---|---|---|---|
CricketVision P1_V33(broadcast) | H.264 High | 1280×720 / 25fps | 372s | VIA project format:78 phase 区间 + 79 keyframe bbox + stroke type + handedness + per-body-part 评分 |
| Batting Pose 测试集(controlled) | HEVC Main | 3840×2160 / 120fps | ~22s × 8 | 无 GT |
Wild YouTube KExVvhIESKA | H.264 High | 1280×720 / 60fps | ~12 min | 无 GT |
| 轮次 | 信号源 | 改进点 | IoU (target ≥ 0.20) | Temporal hit | # peaks | Phase margin |
|---|---|---|---|---|---|---|
| v1 | codec MV | raw + global median | 0.001 / 0.000 | 26/26 = 100% noise | ~700 | 1.45× |
| v2 | codec MV | + overlay mask (顶/底/左下) | 0.000 / 0.000 | 26/26 = 100% | 688 | 1.43× |
| v3 | codec MV | + affine 相机运动补偿 | 0.005 / 0.000 | 26/26 = 100% | 672 | 1.40× |
| E8 v1 | RAFT-small | dense flow,360p inference | 0.008 / 0.000 | 23/26 = 88% | 501 | 1.32× |
基线 codec MV baseline(v3 mask+affine):IoU 0.005;target(声明 ROI 可用)是 0.20。RAFT 把 peak 数量从 ~670 压到 501、temporal hit 从 100% 降到 88%(信号 sharper 了)、但 spatial IoU 几乎没动。
信号被广播 overlay 完全淹没 — cluster bbox 全部落在左下 scoreboard。100% 时序对齐其实是 noise:peak 太密集,任意 ±0.3s 窗口都会撞上。
| IoU mean / median | 0.001 / 0.000 |
|---|---|
| Temporal hit | 26/26 (100%) (false positive) |
| # peaks (≥ 0.4s apart) | ~700 |
| Phase margin (Exec / Buildup) | 1.45× (18.0 / 12.4) |
顶部 banner + 底部 ticker + 左下 scoreboard 三个矩形 mask 掉 29.7% cells,但 IoU 没救。Root cause 不是 overlay,而是镜头切换 + camera motion 在未 mask 区域 uniform-burst。
| IoU mean / median | 0.000 / 0.000 |
|---|---|
| Temporal hit | 26/26 (100%) (still false positive) |
| # peaks (≥ 0.4s apart) | 688 |
| Phase margin (Exec / Buildup) | 1.43× (20.8 / 14.5) |
per-frame estimateAffinePartial2D + RANSAC 拟全局相机仿射并 subtract,timeline 噪声地板从 ~15 压到 ~5 — 数值上有效,但 batsman cluster 仍找不到。这一轮证明 affine 拿掉的是 *camera*,batsman 局部 motion **本来就不在 codec MV 里**。
| IoU mean / median | 0.005 / 0.000 |
|---|---|
| Temporal hit | 26/26 (100%) (still noise) |
| # peaks (≥ 0.4s apart) | 672 |
| Phase margin (Exec / Buildup) | 1.40× (9.79 / 6.98) |
完全换信号源(torchvision RAFT-small pixel-level dense flow,720p → 360p inference)。Peak 数量降到 501、temporal margin 略升,但 keyframe heatmap 显示 batsman 区域是 *冷色*,fielders 和远处场地反而是亮色。Confirm 不是 codec 限制 — 是数据本质。
| IoU mean / median | 0.008 / 0.000 |
|---|---|
| Temporal hit | 23/26 (88%) (sharper but same shape) |
| # peaks (≥ 0.4s apart) | 501 |
| Phase margin (Exec / Buildup) | 1.32× (8.19 / 6.20) — Exec ≈ FT |
反复看 keyframe overlay 后得出的核心观察:broadcast cricket video 里,GT bbox 标定的 batsman 位置,恰好是画面 motion *最少* 的区域。这是 codec MV 和 RAFT 同时失败的根本原因,跟 algorithm 完全无关。
这解释了为什么 mask scoreboard、affine 拿相机、换 RAFT 都没改善 spatial IoU:不是 motion 信号不准,是 motion 信号本身就不在 batsman 上。
探查 codec MV 时发现 Batting Pose 4K 视频 frames_with_mv = 0/2687。ffprobe 显示:
| Batting Pose 4K | broadcast P1_V33 | wild KExVvhIESKA | |
|---|---|---|---|
| codec | HEVC | H.264 | H.264 |
| profile | Main | High | High |
| has_b_frames | 0 | 1 | 1 |
| bitrate | 81 Mbps | ~4 Mbps | 2.3 Mbps |
| MV in bitstream? | 0% | 99% + | 99.7% |
HEVC Main + has_b_frames=0 + 80+ Mbps 是 phone 录制为剪辑友好的 near-all-intra 编码(类似 ProRes / DNxHR 思路)。这不是 codec_mv 实现 bug,是 source 视频里就没存 inter-frame motion vector。RAFT 不受 codec 约束(它在 pixel 层算),controlled 4K 的 RAFT spike 仍可一试 — 但本轮没做,因为 broadcast 域的 negative 结论已经够强。
cricket_highlight/scripts/spike_mv_vs_cv_gt.py--mask + --affine):cricket_highlight/scripts/spike_mv_v2.pycricket_highlight/scripts/spike_raft_v1.pyreport.md + plots:cricket_highlight/results/{spike_mv_cv_gt, spike_mv_v2, spike_raft_v1}/(.gitignore 排除)docs/archive/results/2026-06-03-codec-mv-cricket-batting-spike-three-rounds.mddocs/TODO.md E8 — Dense optical flow (RAFT) backlog