I’ll be honest about something that annoyed me for months. If you had a two-hour recording sitting on your drive, we couldn’t just take it. We asked you to trim it down first, or compress it, or chop it into pieces. Which is a ridiculous thing to ask someone. You came to us to save time and the first thing we did was hand you homework.
That’s done now. This week we pushed a file through that would have killed every earlier version of our pipeline, and it came out the other side as 20 finished clips. The part I keep coming back to: the whole thing took about 12 minutes. Two hours of footage in, twenty shorts out, in the time it takes to make a coffee.
The file
Two gigabytes. Two hours long. Shot at 60 fps. We dropped the whole thing in through the normal file uploader, with no trimming, no splitting, and none of the “please keep it under X minutes” nonsense we used to make people deal with.
Out the other side: 20 shorts, captioned and formatted, from that one upload. One job. One file. Done.
Why this was actually hard
A two-hour file at 60 fps is not just a longer video. That distinction sounds pedantic until you’re the one writing the code. Every stage scales with it. Transcription has to stay sharp across two full hours of talking. Speaker tracking runs on something like four hundred thousand frames instead of a few thousand. And then the system has to actually find the 20 moments worth clipping in all of that, and re-encode each one.
The old way it broke was boring and predictable. Somewhere in that chain it would run out of memory or time and the whole job would just fall over, usually after it had already burned real GPU minutes, which was the part that stung. So we took the easy way out and capped file sizes. We pushed the problem back onto you.
The fix wasn’t some single clever trick I can brag about. It was unglamorous work: getting every stage to stream and chunk through the file instead of trying to swallow it whole. Once we did that, the length of the source stopped being the thing that killed us. The first time the two-hour run finished instead of falling over, and did it in twelve minutes, I watched the whole batch back just to be sure it was real.
Here are all 20
Not a hand-picked best-of. These are the shorts that came out of that one job, every one of them, on a permanent public link. No login, no sign-up wall. Here are the first few, and you can open the rest if you want to watch all 20.
Show all 20 shortsShow fewer
Worth being straight about one thing: making these public still takes us a manual step today. A proper one-click “make public” button in your library is on the way. The piece that was blocking it, the fact that download links expire after 7 days, is solved now that clips can live on a permanent public URL instead. The button is the easy part from here.
One thing I’m not going to hide from you
Jobs that come in through the MP4 upload path don’t get a thumbnail yet, which is why the clips above start on a black frame instead of a preview. The videos themselves are completely fine. It’s just the poster frame that’s missing, and only on uploaded files specifically. It bugs me too, and it’s near the top of the list. The goal is simple: an uploaded job should look exactly like every other job in your library, thumbnail and all. We’re not there yet. We will be.
What this means if you actually use Skapo
Stop prepping your footage for us. That’s the whole takeaway. A client sends you a two-hour recording? Upload the two-hour recording. The length, the frame rate, the file size, that’s our problem now, not yours. You get back a batch of clips, ready to review, in about the time of a coffee break.
That’s the entire reason we build for operators and not creators. The boring, annoying parts are supposed to land on the tool. Not on your editor at 11pm.
Upload the whole thing
Drop in a full-length recording, long, high frame rate, big file, and get a batch of ready clips back. No trimming first.
Try it freePosted by the Skapo team, June 2026