一场5分钟的比赛直播，60帧每秒，总共18000帧画面。如果把这18000帧全部塞进机器学习模型，结果只有一个：帧越堆越多，延迟越拖越长，比分表反而更慢出来。一支4人团队的做法是，先砍掉其中99.3%，只留132帧送进模型。
他们做的是一个开源、可本地运行的赛事计分工具。起因很具体：去年组织BGBO（一项高校级别的BGMI赛事）时，赛后统计积分表要花大量时间，观众的观赛情绪被这段等待消耗掉了。他们接触到的不少本地训练赛组织者也遇到同样的问题。另一个体验痛点是，比赛进行中观众只能靠脑子记各队战况。
问题的根源在于，BGMI没有开放可供解析的API，没法直接读取数据去更新积分表。这也是市面上迟迟没有同类应用的主要原因。团队选择的路径是：读取直播流，识别击杀信息（kill feed）中的新事件，在毫秒级内更新实时积分表，并以叠加层的形式显示在直播画面上。
使用流程并不复杂。开赛前，主办方在面板里录入队伍名称和各自队员的游戏ID；启动OBS推流后，创建一个虚拟摄像头并运行该应用。应用会检测直播流，寻找击杀信息中的新事件，按官方标准计算积分，再把更新推送到前端叠加层。叠加层还会显示最高击杀数、排名等额外信息。
技术上的关键，是那层位于机器学习管线之前的过滤机制。团队把60帧全部送进模型视为瓶颈，因此需要一个确定性、计算开销低的过滤层，把不含击杀信息的无用帧先扔掉。
过滤分两级。第一级是感兴趣区域裁剪，只从每帧中裁出需要计算的区域，因为像素总数与图像尺寸的平方成正比。第二级是级联帧过滤：先比较相邻帧的平均像素强度差，低于阈值就丢弃；通过这一关的帧，再进入二值字形模板匹配，判断画面中是否含有击杀信息文本。
效果用数字说话。5分钟、60帧的直播共18000帧，第一层预处理后只剩347帧，剔除约98.1%；第二层进一步压缩到132帧，整体降幅约99.3%。最终只有132帧进入后续环节，机器学习管线的负担被大幅削减。
进入模型的部分采用两阶段处理：PaddleOCR负责读取玩家名称，也就是击杀事件中的行为主体；微调过的YOLOv11负责分类击杀信息里对计分逻辑必要的重要图标。两者都是开放权重模型。
团队强调，这套方案走的是多模态路线，把像素变化检测、字形匹配、OCR和目标检测组合在一起。如果换成输出结果预先固定的封闭API，这种组合会很难实现。这也是他们所说的开放创新的价值所在。
在首次实际使用中，团队在校内办了一场真实比赛来验证：能否在直播中检测到击杀信息，同时处理积分分配的复杂度。反馈是正向的——比赛结束后几秒内就生成了积分表。
需要说明的是，这个仓库目前定位为AI辅助的研究原型，面向赛事工具开发者、直播制作团队、计算机视觉贡献者和Hacktoberfest参与者，而不是一个已经部署上线的计分服务。目前实现最完整的路径是“AI候选事件到事件”的管线；名单初始化、转换为可发布积分表以及界面集成，仍有待接通。
项目由4名成员共同完成：@satviksingh192、@pushpam345、@urastogi2048、@shreyas_prajapati_7911096。