Delivery planning
High Bandwidth Video Hosting
If you are searching for high-bandwidth hosting, you probably have a number in mind — or you are about to discover you need one. Delivery is one of the two dimensions a plan band is priced against here, and it is the one people underestimate, because it depends less on how many videos you have than on how much of them gets watched. This page shows how to size it from your own inputs, and how to test the worst case rather than the best one.
Start here
What delivery actually measures
Not the size of your library — the amount of video sent to viewers.
Storage is what you keep; delivery is what goes out. They move independently, which is why a modest library on a popular launch page can consume far more delivery than a large archive nobody opens. When an estimate goes wrong, it is almost always because the library was counted and the audience was not.
Delivery is also not simply length multiplied by viewers. A viewer who watches two minutes of a forty-minute recording consumes two minutes of delivery; a viewer who scrubs back and forth through a tutorial can consume more than its full length. Both are ordinary behaviour, and an estimate that ignores them is an estimate you will revisit.
Your inputs
The four things that decide your delivery
All four are yours to measure, which is what makes the estimate trustworthy.
Source bitrate, and the rendition actually served
What leaves the platform is the rendition a viewer's player selects, not your master file. A high-bitrate source pushes every rendition up, so the encoding decision you made at upload is quietly a delivery decision too.
Audience size, at its peak
Use your busiest expected month rather than an average one, because a plan band has to hold in the month a launch or a term start lands — not in a quiet one.
Watch time per viewer
How much of each video is actually watched, which for most libraries is a fraction of its length. Your own completion figures are the honest input here; assuming full watch-through inflates the estimate, and assuming a glance deflates it.
Seeking and replays
Tutorials, training and reference material get scrubbed, rewound and rewatched, and every one of those requests is delivery. This is the input people leave out, and it is the one that turns a comfortable estimate into an uncomfortable invoice.
Do this
Sizing delivery, then testing the worst case
Five steps. The first four produce a number; the fifth tells you whether the number is the only thing that matters.
- 01
Take the rendition your viewers actually get
- 02
Multiply by real sessions in a peak month
- 03
Apply real watch time, not duration
- 04
Add a margin for seeking and replays
- 05
Measure the worst case, not the best
Common questions
Bandwidth and delivery questions
Answered without a performance promise.
Will high-bandwidth hosting stop my videos buffering?
Not on its own, and this page will not promise otherwise — an earlier version did, and it has been removed. An allowance governs how much delivery your plan covers; whether an individual viewer stalls depends on the renditions that exist for that video, the page and player, the network in between and that viewer's own device and connection. Check whether a low fallback rendition exists for the video in question first: it is the most common cause of stalling that gets blamed on bandwidth.
How much bandwidth do I need?
Take the bitrate of the rendition most of your viewers receive, multiply by realistic sessions in your busiest month, apply the proportion of each video that is actually watched, then add a margin for seeking and replays. That figure — yours, not ours — is what to compare against the current bands on the pricing page. The estimator linked below does the arithmetic once you have the inputs.
Can I stream 4K?
High-resolution renditions are produced only if the project is configured to produce them and the source supports it, and every viewer who receives one consumes delivery accordingly. So the honest framing is a trade rather than a feature: higher resolutions cost delivery, and it is worth confirming that your audience is really watching at that resolution before you plan a band around it.
What happens during a traffic spike?
Delivery moves with your audience, so a spike consumes more of the allowance in less time. We are not going to claim consistent performance through any peak, because that depends on conditions we do not control. What you can do is plan for the peak rather than the average, and if your usage is likely to sit outside the published bands, ask about a custom plan before the spike rather than after it.
Will better delivery improve engagement or conversions?
That is a claim about your audience, and we have no evidence for it about yours — the previous version of this page asserted it anyway, which is why it has been removed. What you can do is measure it: aggregate reporting gives plays, watch seconds and completion rate, so if a delivery change genuinely alters behaviour, your own completion figures before and after are the honest place to see it.
Put this on your own pages, under your own rules
Size delivery from your own four inputs, compare it against the current bands, then watch your heaviest video on a constrained connection before you commit.