How to upload 2 GB video files
Large uploads fail for boring reasons: a sleeping laptop, a flaky Wi-Fi hop, a file that was never going to be accepted. Here is how to get a big file up in one go, and what to do when it stops.
Check that the file is under the size limit and in an accepted format. Use a wired or strong connection. Keep the browser tab open and the computer awake. Upload through a resumable uploader, so a break continues from where it stopped instead of starting over. On VideoBB the limit is 4 GB, and uploads resume by themselves.
Two gigabytes is where video uploads stop being casual. At that size a typical home connection needs most of half an hour of unbroken upstream. That is longer than most laptops stay awake on their own. It is longer than many Wi-Fi networks go without a hiccup, and longer than some proxies will hold a request open. Getting the file up is less about speed than about not being interrupted, and about recovering cleanly when you are.
This guide is the practical checklist. It covers what to check before you start and how to set up the upload so it is likely to succeed. It shows what a resumable uploader does for you when it does not, and how to confirm the result. The protocol details are in resumable uploads explained. This page is about getting the job done. For the wider picture, from file formats to upload times, see the uploading video hub.
Before you start: three checks that prevent most failures
The first check is size. VideoBB accepts files up to 4 GB, and other services differ. An upload that will be rejected for size is often rejected only after you have waited. Look at the file's size in your file manager rather than trusting the editor's estimate. The second check is the container. VideoBB accepts mp4, mkv, avi, mov, webm, m4v, mpg, wmv, flv, ts and 3gp. A project file, an image sequence, a zipped folder or a file with a misleading extension is not a video and will be rejected at the probing stage. The third check is that the file is complete. A cancelled export or an interrupted copy leaves a truncated file that plays for a while and then ends. If the duration your player reports is shorter than expected, re-export before uploading. Prepare video for upload covers export settings that make the file smaller and cleaner in the first place.
Uploading a large file, step by step
The order matters: the environment first, then the upload, then verification.
Plug in
Use a wired Ethernet connection if there is any way to. Wi-Fi adds packet loss and brief dropouts that a long upload is exposed to for its whole duration. If wireless is unavoidable, sit near the access point and disconnect other heavy devices.
Stop the competition
Pause cloud backups, sync clients, other uploads and any video calls. Upstream bandwidth is scarce, and a photo library sync will happily take half of it.
Keep the machine awake
Set the computer not to sleep for the duration, plug in the power, and keep the browser tab in the foreground or at least open. A sleeping laptop drops the connection; a closed tab ends the upload.
Start the upload
On the upload page, drag the file in or pick it. The uploader sends the file in chunks over the tus protocol, so it never loads the whole file into memory and never depends on a single long request.
If it stops, let it resume
After a dropped connection the uploader asks the server how many bytes it has and continues from there. Do not refresh in a panic; give it a moment. If you did close the tab, reopen the upload page and the upload resumes.
Wait for processing
When the last chunk lands, the server verifies the file and begins transcoding. Lower renditions usually appear first. The video is complete when the full ladder is available.
Verify
Play the result and scrub to the end. Check that the duration matches the source and that audio and video are in sync throughout. A truncated source shows up here, not during upload.
What the resumable uploader is doing for you
A traditional form upload sends the whole file as one HTTP request. The server sees nothing usable until the request completes, and any interruption discards everything. A tus uploader works differently. It first creates an upload on the server. Then it sends the file as a series of PATCH requests, each carrying one chunk and stating the offset it starts at. The server records how far it has got. If the connection breaks, the client sends a HEAD request, reads the current offset from the response, and resumes from that byte. That is the entire trick, and it is why a 2 GB upload interrupted at 90 percent costs you one chunk rather than 1.8 GB. The protocol is public at tus.io. Browsers read the file in slices with Blob.slice, so memory use stays flat whatever the file size.
How long a 2 GB upload takes at common upstream speeds
File size times 8, divided by upload bandwidth, with nothing else on the connection. Real uploads run somewhat slower.
| Upload speed | 2 GB | 4 GB |
|---|---|---|
| 5 Mbps | About 53 minutes | About 1 hour 47 minutes |
| 10 Mbps | About 27 minutes | About 53 minutes |
| 20 Mbps | About 13 minutes | About 27 minutes |
| 50 Mbps | About 5 minutes | About 11 minutes |
| 100 Mbps | Under 3 minutes | About 5 minutes |
When the file is over the limit
If the export is larger than 4 GB, the wrong instinct is to drop the resolution. The better fix is to re-encode more efficiently. In an editor, choose a slightly lower target bitrate or a slower encoder preset. In FFmpeg, raise the CRF by one or two points or use a slower preset, as the FFmpeg documentation describes. A 1080p file at 12 Mbps and the same file at 8 Mbps are hard to tell apart after the host transcodes them. But one is a third smaller. Without an editor, the free video compressor can bring a file down to a target size in megabytes.
If the recording is very long, split it at a natural break and upload two files. The trim video tool cuts each part by its start and end time. The bitrate guide has sensible targets per resolution.
Things that look like upload problems but are not
- The progress bar reaches 100 percent and then nothing happens for a while: the server is verifying the file and starting transcoding. This is normal.
- The video is playable but only at low quality: the higher rungs are still encoding. Check back after a few minutes.
- The upload finished but the video ends early: the source file was truncated before upload. Re-export and upload again.
- The upload is rejected immediately with a format error: the file is not a video in an accepted container, whatever its extension says. Convert AVI to MP4 shows a safe re-mux.
If it keeps failing
A resumable upload that fails again and again at the same point usually means a problem with the file or with something on the network path. The uploader itself is rarely at fault. Try the same file from a different network (a phone hotspot is a useful test), and try a different, known-good file on the same network. Whichever variable changes the outcome is the culprit. Why video uploads fail goes through the causes in detail, and the help centre lists what to include if you need to report a persistent failure.
Frequently asked questions
Can I close the browser during a large upload?
Closing the tab stops the upload, but it does not lose the progress. Return to the upload page and select the same file. The resumable uploader checks how much the server already holds and continues from that point. On VideoBB this works within 48 hours in the same browser, as the help page on resuming an interrupted upload explains. For the fastest result, keep the tab open and the computer awake until the upload completes.
Is it faster to upload from my phone?
Only if the phone's connection has more upstream bandwidth than your computer's, which is sometimes true on a good mobile network. The phone must stay awake with the browser in the foreground for the whole upload, and mobile data caps make a multi-gigabyte upload expensive. A wired computer is the more predictable option.
Should I compress the video before uploading?
Only to bring it under the size limit or to shorten a slow upload. The host transcodes the file into a ladder of renditions anyway, so a moderately compressed source loses nothing visible. Avoid heavy compression: artefacts in the source are inherited by every rendition and cannot be recovered.
Why does the upload slow down partway through?
Upload speed varies with everything else on the connection and on the network path. A backup client starting, someone else streaming, or Wi-Fi interference will all slow it. The uploader is still working; the chunk rate has dropped. If speed collapses to zero for a long period, the connection has probably dropped and the uploader will resume once it returns.
Sources
- tus resumable upload protocol — How chunked uploads resume after an interruption.
- MDN: Blob.slice() — Reading a file in chunks in the browser.
- FFmpeg documentation — Re-encoding a file that is over the size limit.
Related guides
Resumable uploads explained
A resumable upload is a conversation, not a single request. The client sends pieces and the server keeps count. After a break, they agree on where to continue. This is how the tus protocol does it.
Why video uploads fail
An upload that stops, stalls, restarts or is rejected is almost always one of a short list of causes. Learn to tell them apart from what the browser shows you, and fix the right one.
Prepare video for upload
The right export is smaller, uploads faster, is accepted without complaint and transcodes cleanly. It is not the highest possible quality and it is not the smallest file. Here is the middle.
Video upload speed and time
Upload time is file size divided by upload speed, and upload speed is the number nobody checks. Here are the sums, a reference table and the few changes that really help.