My wedding footage is 60GB of phone clips. Mostly guests filming on their phones. Some of it is great, most of it isn't, and a decent chunk is under two seconds of pocket noise.
Watching all of it would take hours. So I'm building a tool (cullify.io) that watches it for you and hands back the best bits, with timestamps and a reason for each pick. Hand an editor 30 minutes of gold instead of 60GB of "figure it out yourself."
Today was the day it got real. I started with a Python script that sends every clip to a vision model and asks three questions: what's happening here, is it worth keeping, and where's the good part. Then ffmpeg cuts the keepers. The model started throwing out the junk immediately. That part felt like cheating, it worked so fast.
Then came the actual product work. Server, domain, Stripe, a page where you watch the job progress, a page where you download the clips. That was most of the day.
The server has a 40GB disk. The wedding footage is 60GB. It doesn't fit. Which forced the rule the whole product now runs on: download one clip, process it, delete it, repeat. Never hold more than one file on disk at a time. It turned a hardware limit into a design principle.
Files over 2GB nearly killed the box twice. First my database column for file size maxed out at 2.1GB. A 5.5GB iPhone video broke it instantly. Then uploading a 2.9GB file loaded the whole thing into memory and the kernel killed the server. My own wedding footage took down my own server. Uploads now stream to disk in chunks instead of sitting in RAM.
The pipeline works end to end. Right now a benchmark is chewing through a test batch of 52 files and it's sorting the junk from the keepers with nobody watching. That's the thing I wanted to prove today: it works at scale without me in the loop.
What's left:
Went from a Python script to a live product in one day:
If you've got 15 hours of wedding footage sitting in a folder, you know exactly why this needs to exist.