Why your video comes back exactly as you shot it

Every reel used to be rebuilt from scratch. We stretched the footage onto a tall portrait frame, forced it to 30 frames a second, and re-compressed the whole thing — even when the reel was a single clip that already looked exactly right.

Two problems came from that, and they turned out to be the same problem.

It was slow

A 60-second reel spent about 145 seconds being re-compressed on our render machine. Start to finish, clicking Create and getting a file back took over three minutes. For a tool whose pitch is “faster than editing it yourself”, that’s most of the pitch gone.

It broke on upload

Rebuilding the video meant the file Amazon received was not the file you shot. Different compression settings, a frame rate we imposed, and black bars added down the sides to squeeze landscape footage into a vertical frame. Some of those uploads had playback trouble.

The fix was to stop

For a single clip there is nothing to combine — no fade, no second angle. So now we leave the picture completely alone and lay the narration over it. Same compression, same resolution, same frame rate: the bytes that make up your picture are the ones you uploaded.

Measured on a real 55-second reel:

	Before	After
Processing time	~30.8s	1.0s
Memory used	341 MB	~13 MB
Landscape footage	black bars added	left alone

Reels built from several clips are still rebuilt, because fading between clips genuinely does require one continuous piece of video. That’s a real reason. “We always did it this way” was not.

The general lesson: we were paying a large, recurring cost to normalise files that did not need normalising. The fastest code is the code that doesn’t run.