Clip Radar

Desktop View
Mobile View
Clip Radar App

Inspiration

Both of us have sat in the same chair a hundred times: a 45-minute podcast or stream sitting in a folder, and a nagging feeling that three or four minutes of it would do numbers as Shorts or reels if only someone had the time to scrub through, find those minutes, cut them, reframe them vertically, caption them, and write titles and hashtags for each one. That's an hour of repetitive, low-creativity work for maybe five finished clips.

We looked at what already exists in this space and kept running into the same two failure modes: tools that just detect silence or scene changes and call whatever's left a "highlight," and tools that pipe a transcript into an LLM and hand back a timestamp with zero explanation of why it was chosen. Both leave the creator doing the real work anyway watching every candidate clip to decide if the tool's judgment can be trusted. Neither one earns confidence.

That gap is where we come in by creating a repurposing tool you could actually trust without re-watching its output was the idea we wanted to build for this hackathon: not just "Tool picks your clips," but tool that shows its work.

What it does

Drop a YouTube/podcast link or upload a file, and ClipRadar hands back the top 3–5 moments as ready-to-post vertical clips each one already burned-in captioned, thumbnailed, titled, described, and hashtagged. The part we built the whole product around is the line underneath each clip explaining why it made the cut: which factors drove its score, in plain language, not a black-box confidence number.

That score comes from eight independent, weighted signals computed directly from the transcript and audio hook strength, emotional language, narrative arc, filler-word density, how close the clip lands to an ideal short-form length, novelty against the rest of the transcript, speaking pace, and vocal energy. Nothing here is an LLM guessing; it's a scoring engine a creator could open up and audit, which is exactly the point.

How we built it

We split the work roughly along the seam you'd expect: Samod owned the pipeline and scoring engine, Stephen owned the interface layer and getting it in front of people.

The backend is Python, built around faster-whisper for fully local transcription with word-level timestamps ; no API key, no per-minute billing, works offline once the model's cached. Those timestamps feed the eight-factor scoring engine, which segments the transcript into candidate clips and ranks them with a greedy non-max-suppression pass so the top picks don't overlap. Selected clips get reframed to vertical 9:16 with a blurred-background composite via an ffmpeg filter_complex, with karaoke-style pop-up captions burned in through a hand-tuned ASS/libass subtitle track. Thumbnails are generated with PIL in a "viewfinder" style that matches the rest of the product's visual identity, and a metadata pass produces titles, descriptions, and hashtags per clip.

On top of that pipeline sit two interchangeable front-ends, because free hosting turned out to be a moving target (as students): a Gradio app for Colab/Cloud Run/Oracle/local use, and a Streamlit port for Streamlit Community Cloud's permanent free tier both thin UI layers over the exact same pipeline code, so nothing about the scoring or rendering logic forks between them.

The landing page is hand-built HTML/CSS/JS with no framework a broadcast-monitor, editing-timeline visual language (live timecodes, a scrubbing playhead, tiered score bars) meant to look like the product it's selling, deployed to Vercel with a matching favicon.

Challenges we ran into

The pipeline itself came together cleanly; the deployment story is where we actually got tested. We built our first "free hosting" plan around Hugging Face Spaces' CPU Basic tier under the Gradio SDK confirmed it was free, built the whole app around it and then discovered, that both the Gradio and Docker SDKs are now paid-only for new accounts. We had to re-plan the entire hosting strategy mid-hackathon: a Colab-tunnel path for a fast temporary demo link, a full Streamlit Community Cloud port for a permanent free URL, a Google Cloud Run path for anyone with a GCP account, and an Oracle Cloud Always Free VM walkthrough for the most generous free compute available and then found, while writing the Oracle steps, that Oracle had quietly halved its own "Always Free" allowance a few months earlier with no public announcement. Twice in one hackathon, a platform's advertised free tier turned out to be stale by the time we went to use it which taught us to verify against the live product UI, not documentation, before committing to a plan.

Two bugs cost real time on the media side: captions were initially overflowing the frame edges, traced back to a no-wrap subtitle setting combined with an oversized, wrongly-resolved font; and early thumbnails showed double, overlapping caption text because we were grabbing the preview frame from the already-captioned rendered clip instead of the clean source video.

The most instructive problem showed up after deployment, not before it: once the Streamlit app was live, video URLs stopped producing clips while file uploads kept working fine. That asymmetry pointed straight at the cause YouTube's bot-detection blocking requests from shared cloud IP ranges, a real and currently unsolved problem across the yt-dlp ecosystem, not a bug in our code. We couldn't engineer our way out of that one, so we treated it honestly: added clear error messages that explain what's happening instead of failing silently, and made file upload the reliable primary path for a live demo rather than overselling a fix we couldn't guarantee.

We also had to validate the entire pipeline without live network access during development our own sandbox blocked YouTube and model-hub downloads which pushed us to build a fully offline synthetic test fixture (generated narration plus hand-built transcript timestamps) just to prove the pipeline worked end to end before we ever touched a real video.

Accomplishments that we're proud of

The scoring engine is the thing we'd point judges to first every ranked clip comes with a genuine, auditable reason, not a confidence score bolted on after the fact. Getting the vertical reframing, burned captions, and thumbnail generation all production-quality (not "good enough for a demo") took real iteration, and it shows in the output. And rather than shipping one fragile "free" deploy link, we ended up with four independently verified, honestly-documented hosting paths which meant that when our first plan collapsed under us, we weren't stuck; we had already stress-tested the alternatives.

We're also proud of how we handled the YouTube blocking issue once it surfaced live: instead of quietly hoping judges wouldn't hit it, we shipped a fix that turns a confusing failure into a clear explanation, and documented the honest workaround rather than claiming a fake guarantee.

What we learned

"Free" is a claim you verify against the live product, not a blog post or a doc page we got burned by stale free-tier information twice , from two different platforms. We also came away convinced that explainability is a feature in its own right, not a nice-to-have: a short, honest "why this clip" line did more for how trustworthy the tool felt than a marginally higher score ever could have. And we learned, the hard way, that "works when I upload a file" and "works when I paste a URL" are two very different reliability guarantees once your app leaves your laptop for a shared cloud host the failure modes only show up in production, not in local testing.

What's next for Clip Radar

Multi-language transcription and scoring, so the tool isn't limited to English-language source video. Direct-publish integrations with TikTok, YouTube Shorts, and Reels so the loop closes without a manual download-and-upload step. Persistent storage and accounts, since every one of our current free hosts wipes output between sessions fine for a demo, not for a daily workflow. And a "coach mode" that explains why the runner-up clips didn't make the cut, not just why the winners did, so creators start to build an intuition for what the model is actually rewarding.