Three waits, three different causes
Publishing a video is not one delay but three, and they respond to completely different fixes.
The export is a compute problem. Its duration is your timeline runtime multiplied by an encoding multiple — how many minutes of wall clock each minute of video costs. That multiple is a property of your machine, your codec and how much work the effects on the timeline demand. A hardware encoder on straight cuts may run below 1×, finishing before the video would have played. The same machine with noise reduction, warp stabilisation and a heavy grade may run at 8× or worse.
The file size is pure arithmetic. Bitrate multiplied by duration, converted to bytes. Nothing about your computer affects it: a 50 Mbps export of a twelve-minute video is 4.5 GB on any machine ever built. This is the one term you control directly and precisely.
The upload is a throughput problem. File size divided by your upload speed. Your computer is irrelevant here; only the connection matters, and only its upload direction — which on most consumer connections is a small fraction of the download figure the plan advertises.
Then there is a fourth wait nobody plans for: the platform's own processing after your upload completes. Large uploads are typically available at low resolution quickly and at full quality some time later, which matters if you are publishing to a scheduled time. The calculator includes it as an input because it varies enormously with file size and platform load.
Measuring the encoding multiple instead of guessing it
The encoding multiple is the only input here you cannot look up, and it is the one that most affects the answer. Do not estimate it. Take a recent export, divide the wall-clock time it took by the runtime of the timeline, and use that. A 20-minute export of a 10-minute video is 2.0×. Measure it once per project type — an interview cut and a heavily graded piece are different machines as far as the encoder is concerned.
Three things move it. Effects dominate: temporal effects such as noise reduction, optical flow retiming and stabilisation require the encoder to wait on frames being generated, and they can multiply export time several-fold. Codec and preset come next: a hardware encoder is dramatically faster than a software one at the same bitrate, at some cost in efficiency, while slow software presets buy quality with time. Output resolution matters roughly with pixel count, so a 4K export is around four times the work of a 1080p one on the same timeline.
The bitrate term is worth pausing on because it does double duty. It sets the file size, and therefore it sets the upload time, but it does not meaningfully change the export time — the encoder does approximately the same analysis whatever budget it is spending. So lowering the bitrate shortens the upload and leaves the render alone, which is exactly the right lever when the upload is the bottleneck and exactly the wrong one when the render is.
Measure the upload speed, do not read it off the contract. Consumer connections are asymmetric by design, and the upload figure is frequently a tenth of the download figure or less. Test on the machine you will upload from, wired if possible, at the time of day you will publish. The same measurement feeds the livestream bitrate calculator, where the consequence of getting it wrong is dropped frames rather than a missed deadline.
Worked example: a 12-minute video, two versions
Exporting at 50 Mbps, an encoding multiple of 1.5×, a measured 20 Mbps upload, and 10 minutes of platform processing per version.
- Export time. 12 min × 1.5 = 18 minutes.
- File size. 50 Mbps × 720 seconds = 36,000 megabits. ÷ 8 = 4,500 MB. ÷ 1,000 = 4.5 GB.
- Upload time. 4.5 GB × 8,000 = 36,000 megabits ÷ 20 Mbps = 1,800 seconds ÷ 60 = 30 minutes.
- Per version. 18 + 30 + 10 = 58 minutes.
- Two versions. 58 × 2 = 116 minutes, just under two hours.
Upload is the largest single component at 30 ÷ 58 = 52% of the wait, so this is a connection problem rather than a computer problem. Halving the export bitrate to 25 Mbps halves the file to 2.25 GB and the upload to 15 minutes, cutting the per-version total to 43 minutes and the whole job to 86 minutes — a 30-minute saving from one preset change. Buying a faster computer that renders at 0.75× instead of 1.5× saves only 9 minutes per version by comparison.
Reverse the situation and the advice reverses with it. On a 100 Mbps upload the same 4.5 GB file uploads in 6 minutes, the export at 18 minutes becomes the dominant term, and lowering the bitrate now saves almost nothing while a faster encode saves a lot. Always identify which of the two is larger before choosing what to change — the calculator states which one it is.
Planning a publish deadline from the result
Work backwards from the scheduled time, not forwards from when you finish editing. If a video goes live at 4pm and the total here is 116 minutes, the last frame must be locked by 2pm — and that assumes nothing fails. Add a margin: a failed export, a dropped upload that has to restart, or a platform processing queue longer than usual are all ordinary events rather than disasters.
Treat the platform-processing figure as the least predictable term. It depends on your file size, the platform's current load and how many resolutions it generates. Videos are typically watchable at low resolution long before the highest quality finishes processing, which means an early publish shows some viewers a soft picture. If you have a premiere or a scheduled release, upload well in advance and use the platform's own scheduling rather than publishing manually at the last moment.
For recurring work, look at the total across a month rather than per video. Two versions of a weekly video at 116 minutes each is about eight hours a month of waiting — a full working day spent watching progress bars. That is a real cost, and it belongs in the same accounting as production hours, which is what the cost per finished minute calculator is for. It is also the argument for exporting overnight rather than in working hours.
One caution on file size: platforms re-encode whatever you send, so the export bitrate is not what viewers receive. Sending a reasonable master gives the platform good material to work from; sending an enormous one mostly buys you upload time. There is a point of diminishing returns and it is well below the maximum your editor will offer.
File size and upload time by export bitrate
| Export bitrate | File size | Upload time at 25 Mbps | Upload time at 100 Mbps |
|---|---|---|---|
| 8 Mbps | 0.60 GB | 3.2 min | 0.8 min |
| 16 Mbps | 1.20 GB | 6.4 min | 1.6 min |
| 25 Mbps | 1.88 GB | 10.0 min | 2.5 min |
| 50 Mbps | 3.75 GB | 20.0 min | 5.0 min |
| 80 Mbps | 6.00 GB | 32.0 min | 8.0 min |
| 100 Mbps | 7.50 GB | 40.0 min | 10.0 min |
| 150 Mbps | 11.25 GB | 60.0 min | 15.0 min |
| 200 Mbps | 15.00 GB | 80.0 min | 20.0 min |
The 25 Mbps row is the tidy one: a 25 Mbps export uploaded over a 25 Mbps connection takes exactly as long as the video runs, ten minutes. Above that ratio the upload takes longer than the video; below it, less.
What the estimate does not include
- Cache and conform renders. Many editors pre-render effects before the final export begins. That time is real and is not counted in the encoding multiple unless your measured export already included it.
- Thermal throttling. A laptop sustaining a long export slows down as it heats, so a multiple measured on a two-minute clip understates a forty-minute one.
- Upload protocol overhead and retries. Real transfers achieve somewhat less than the raw line rate, and a dropped connection may restart a chunk or the whole file.
- Competing traffic. The upload shares the connection with everything else in the building, so a household on a video call will not deliver the tested throughput.
- Variable-bitrate exports. A VBR preset produces a file whose size depends on content, so the size here is an estimate for anything other than a constant-bitrate export.
- Platform queue times. Processing is not a fixed duration — it varies with file size, resolution count and how busy the service is when you upload.
- Everything after upload. Thumbnails, captions, descriptions, chapters, end screens and scheduling all take human time that dwarfs the processing wait on a well-optimised video.
Where this fits in the publishing pipeline
Export and upload are the last two links in a chain whose earlier links are usually far more expensive. The shoot generates footage sized by the video project storage calculator; the edit consumes the hours costed by the cost per finished minute calculator; and only then does anything need rendering. Knowing the publish wait matters not because it is large but because it is the part that sits between a finished video and a deadline, and because it is invisible until you are in it.
The bitrate decision here is the same one made in every other part of the pipeline, with a different constraint each time. Live streaming is bounded by sustained upload throughput — see the livestream bitrate calculator. Acquisition is bounded by card capacity and sustained write speed. Distribution of audio is bounded by hosting transfer, worked through in the podcast hosting bandwidth and cost calculator. In each case the arithmetic connecting bits per second to bytes on disk is identical; only the thing that runs out first changes.
If the total here is uncomfortably large every week, the two structural fixes are scheduling and specification. Export overnight so the wait costs sleeping hours rather than working ones, and choose an export preset matched to what the platform will actually do with the file rather than to the largest number your editor offers.
Key terms
- Encoding multiple
- Wall-clock minutes of export per minute of timeline. Below 1× the export finishes faster than the video plays; above 1× it takes longer. Measure it from a real export rather than estimating.
- Export bitrate
- The data rate written to the output file. It determines file size and therefore upload time exactly, and it has little effect on how long the export itself takes.
- Asymmetric connection
- A link whose upload speed is far below its download speed, which describes most consumer broadband. Only the upload figure matters for publishing.
- Platform processing
- Transcoding performed by the service after upload, generating the multiple resolutions viewers receive. Higher resolutions typically become available later than lower ones.