WanganTrim
Automatically preparing arcade race recordings for upload.
I built WanganTrim for fun to help a local arcade racing community spend less time editing footage. One pipeline identifies complete races, trims downtime, generates chapters and a session scoreboard, prepares a thumbnail and metadata, and safely hands the finished package to YouTube.
The challenge
The source footage comes from a phone camera pointed at two arcade cabinets. The framing moves, glare softens text, both screens can show different states, and players can join midway through a race. Fixed screen crops and simple timestamps were not reliable enough.
I treated the game interface as structured evidence. The pipeline reads visible text and its position, separates the two cabinets, recognizes lineup and result screens, pairs complete races, and drops interrupted or unfinished attempts.
What the pipeline does
- Finds races: samples the full recording and uses OCR, layout, fuzzy matching, and game-state rules to locate real starts and finishes.
- Builds the story: extracts course and player details, creates chapters, and calculates a session scoreboard from multiple on-screen signals.
- Produces the video: removes downtime, joins the races into one clean file, and generates timestamps that match the trimmed timeline.
- Prepares publishing: creates a thumbnail and validated upload manifest, publishes privately by default, and verifies the stored metadata.
- ScanOCR the footage
- InterpretPair complete races
- ProduceTrim and score
- PublishUpload and verify
The expensive OCR result is cached, so detection rules can be refined and replayed in seconds without rescanning the video.
Engineering refinements
A full-recording review exposed an important failure mode: an early pass returned six races while 19 complete result clusters were present. I added completeness checks that compare lineups, results, paired races, dropped candidates, and orphan results; every detected race is then checked against source frames before the publishing package is accepted.
I tested competing visual markers against real frames, kept thresholds only where true and false cases separated cleanly, and combined signals according to what each could reliably prove. I also optimized the OCR model and worker layout, preserved intermediate scan data, detected partial runs, and namespaced outputs so processing a second recording cannot reuse or overwrite the first.
The publishing component has a deliberately narrow permission surface. Destructive and unrelated capabilities are absent, credentials stay outside the content pipeline, repeat runs update an existing upload instead of creating duplicates, and a partial upload is reported as a failure until its thumbnail and metadata are verified.
What I learned
Imperfect OCR became reliable enough for this workflow once I combined it with layout, color, timing, and game-specific rules. That approach worked better than treating OCR output as a complete transcript.