Downloads that start at once, whatever the film's size

A finished film can weigh tens of megabytes. Passing all of that through the web service that also draws the pages is the classic way for a large download to go wrong: on a slow or mobile connection, a long stream stalls, gets cut short or runs into a time limit.

Think of where a film goes next: a sales email, a launch post, a slide in tomorrow's meeting. People often download on a phone or a hotel connection, minutes before they need the file. A download that stalls near the end costs more than time; it costs the moment. That is the case we designed for, and the one we test against.

We wanted a download that never depends on how much our web servers can carry. The film already lives in media storage, the same place the player on its page streams from. The browser should simply fetch it from there.

So the rule is now simple: downloading a film is always a redirect, never a relay. When you press Download MP4, our server answers in an instant with an address, and your browser downloads the film directly from storage.

That changes three things for you:

• the download starts right away, with nothing in between to slow it down;
• size stops mattering, so a long film behaves exactly like a short one;
• the pages of the app stay fast, because they are no longer busy carrying video.

The first choice is a short-lived signed link. It lets the file arrive with a proper name taken from the video's title, instead of an anonymous string of characters, so it is easy to find in your downloads folder.

When a signed link is not available, the redirect points to the stored file itself, the same one the watch page plays. Before any redirect, the server checks that the address really belongs to our own media storage, so a download link can never be turned into a door to somewhere else. Only a small file, under 24 MB, may still pass through our servers, and when that happens it is noted in the logs.

We check the result the right way round, too: by seeing redirects on the download route, not merely the absence of errors.

The same release fixed a quieter kind of surprise. Sometimes an AI visual for a scene cannot be made, is skipped, or is not part of the plan. The film still finishes and can be watched, but until now it said nothing about it.

Now a finished film carries warnings in plain sentences that name the scenes concerned, through the API and for assistants alike, and the finished-video message opens with “Ready, with warnings”. The status stays “done” on purpose: the film exists and plays, and the person who ordered it also knows exactly what is missing. Scenes in those messages are counted from 1, as people count them, not from 0 as code does.

For anyone making a film, the last click now does what it promises: the MP4 arrives directly, named after the video, whether it lasts thirty seconds or three minutes. For assistants and developers, a film no longer looks complete when it is not, so they can relay an honest message instead of a silent one.

Behind both changes sits one idea we now hold firmly: a film never passes through the web tier, and a result always says what it contains. You can download any of your films from its page; plans and download options are on the pricing page, and the API is described in the developer docs.