如果 BGMI 記分板沒有延遲，會怎樣？

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

The Problem

Flashback to last year, when we organised BGBO (a college level tournament for BGMI). We faced an issue: we had to spend a lot of time compiling the final points table, which ruined our viewer's mood. They wanted the result ASAP to check whether their favourites had come out on top. This problem existed even with many local scrim organisers who are in touch with us.

Another issue we observed was that during the match, viewers had to keep track of their teams mentally, which is obviously not a good experience.
A quick overview:

What We Built

We built a solution that is open source and can run locally on the host's side. It reads the stream, detects new kill feed events, and updates a live points table in milliseconds, which is shown as an overlay on the stream itself. We chose this route because BGMI doesn't expose an API that we could simply parse to update the points table. This is one of the main reasons why there is no such existing application.

How It Works

Before a match, the host just needs to enter the team names and their respective players' player tags into our dashboard. Then, after starting their OBS stream, they need to create a Virtual Camera 1 and start our application. It detects the stream, looks for new events in the kill feed, calculates points according to the actual standards set by the officials, and sends the update to the frontend, which is an overlay on top of the stream itself. The overlay also shows more info, such as top kills and positions.

Our application is optimised to be lightweight and can easily handle a high quality 60 FPS stream. It achieves this by filtering out the majority of useless frames that don't have any kill-feed event and passing only frames that may contain useful info into the heavier ML model.

Feedback After Its First Usage

We tried hosting a real match within our college to test whether our solution could actually detect the kill feed in a live match while also handling the complexity of points distribution. The responses turned out to be in our favour: it produced the points table within seconds after the completion of the match.

Here is the feedback we received:

Demo

Try it out yourself! The README provides simple and easy steps to get started, so you can enjoy it with your friends. Happy streaming :)

Live BGMI Kill Feed Parser & Points Table Maintainer

An AI-assisted research prototype for turning BGMI kill-feed footage into structured events, then providing the building blocks for tournament scoring and live scoreboard delivery.

BGMI broadcasts expose eliminations as fast-changing HUD text and icons. Reading each event and updating a table by hand is slow and error-prone. This repository explores an assistive workflow: narrow a video to likely kill-feed changes, recognise the two names with OCR, classify feed icons with a trained detector, and represent the result as an Event that can be checked against a tournament roster.

It is aimed at tournament tools developers, stream-production teams, computer-vision contributors, and Hacktoberfest contributors—not at an already-deployed scoring service. The strongest implemented path is the AI candidate-to-event pipeline. Roster initialisation, conversion to a published table, and UI integration still need wiring.

What is here today

…

Why Does Open Innovation Matter?

As discussed earlier, the game itself does not provide any API, so the only feasible solution aligns with what we have built: an open-source, local setup that adds an overlay on an OBS stream.

Our solution uses a multimodal approach to read the kill feeds using PaddleOCR and a fine-tuned YOLOv11 (both are open-weight models).

This open innovation enabled a multimodal system that combines pixel-change detection, glyph matching, OCR, and object detection, something a closed API with predefined outputs would have made difficult.

Technical Dive

This section highlights how we actually handled a 60 FPS stream with low latency for live updates. We can't send all 60 frames every second to our ML pipeline because it would become the bottleneck: unprocessed frames would keep piling up, and it would consume excessive resources too.

So, we need a filtering layer sitting before the ML pipeline that throws away most of the useless frames that don't contain any kill feed. This layer needs to be deterministic and computationally lightweight.

Stage 1: Region of Interest (ROI) Cropping

First of all, we crop only the region of interest (ROI) from each frame, reducing the number of pixels we need to perform computations on, as the total number of pixels is proportional to the square of the image dimensions.

Stage 2: Cascading Frame Filters

1. Pixel intensity difference: We calculate the difference in mean pixel intensity between each frame and its adjacent frame. If the pixel intensity difference is below a threshold, that frame is discarded.
2. Binary glyph template matching: If the frame passes the first check, it reaches the second stage of filtering, where we perform binary glyph template matching to detect whether the frame contains any kill-feed text.

These cascading filters drastically reduce the number of frames that actually enter the ML pipeline.

Filtering Results

For reference, a 5-minute stream at 60 FPS produces 18,000 frames:

60 frames/sec × 60 sec/min × 5 min = 18,000 frames

Our filtering pipeline reduces this volume in two successive stages:

• Layer 1: Preprocessing: Reduces 18,000 frames to just 347 frames, eliminating approximately 98.1% of the incoming frames.
• Layer 2: Preprocessing: Further reduces 347 frames to just 132 frames, achieving an overall reduction of approximately 99.3%.

Final result: Only 132 out of 18,000 frames reach the next stage significantly reducing the workload for the ML pipeline while processing a 5 minute stream.

The ML Pipeline

Now, the ML pipeline performs two-stage processing:

1. PaddleOCR: It reads the player names, which are the actors of the events in the kill feed.
2. Fine tuned YOLOv11: It classifies the important icons present in the kill feed that are necessary for the point-calculation logic.

• THIS SOLUTION IS BUILT BY A TEAM OF 4 MEMBER

MEMBER 1: @satviksingh192 (self)

MEMBER 2: @pushpam345

MEMBER 3: @urastogi2048

MEMBER 4: @shreyas_prajapati_7911096