For one continuous cloud-hosted feed sent to YouTube, estimate monthly data transfer by multiplying its average bitrate by the seconds it runs, then converting bits to bytes. For a 30-day month, each 1 Mbps of continuous bitrate represents 324 decimal GB of payload.
That result is arithmetic, not an exact provider bill: it excludes protocol overhead, retransmissions, restarts and unrelated traffic. It also describes only the cloud-to-YouTube feed, not a separately hosted delivery to viewers. Those distinctions make the estimate useful without pretending it is a full network-usage forecast.
Identify the bitrate you are estimating
The input is the average bitrate of the traffic leg you want to count. If a cloud system sends one encoded contribution feed to YouTube, use that feed's average bitrate in Mbps. If you have the encoder's configured rate, start there; if your platform reports actual stream health or bitrate over time, its observed average is more representative of the operating setup.
Resolution by itself is not a bandwidth figure. Two 1080p videos can use different bitrates because frame rate, codec, encoder settings and image complexity differ. A mostly still devotional image with a song, a moving street scene and a local news loop with changing footage need not produce identical rates at the same resolution.
YouTube's live encoder settings guidance publishes recommended H.264 ingest settings, including 4 Mbps for 240p–720p at 30 fps, 6 Mbps for 720p at 60 fps, 10 Mbps for 1080p at 30 fps and 12 Mbps for 1080p at 60 fps. Treat these as recommendations for encoder ingest, not as measurements of your stream or as promises that a rate will be sustained. YouTube also advises testing before going live and monitoring stream health.
If you are planning before a channel is running, the recommended setting can be a provisional input. Replace it with the actual encoder rate once you have tested the stream. For a channel with a stable configured bitrate, using that value makes the estimate repeatable; for a variable-bitrate encoder, take care to use an average rather than assuming the highest moment is sustained all month.
Use the monthly volume formula
A megabit contains eight megabits? No: a megabit is eight times smaller than a megabyte because a byte contains eight bits. Keep that conversion explicit. With bitrate in megabits per second and runtime in seconds, the decimal formula is:
Decimal GB = Mbps × seconds streamed ÷ 8 ÷ 1,000.
The division by eight converts bits to bytes. Division by 1,000,000,000 converts bytes to decimal gigabytes; the expression shown as ÷ 8 ÷ 1,000 is a convenient way to get GB when starting with Mbps and seconds. For example, at 4 Mbps for one hour, calculate 4 × 3,600 ÷ 8 ÷ 1,000 = 1.8 decimal GB of payload. The same calculation can be done for any run length, including a partial month.
Write down the assumptions alongside the result: bitrate, hours or seconds online, and whether the output is decimal GB or binary GiB. If a channel pauses overnight, include only the time it actually sends data; for a 24/7 stream, use the full number of seconds in the month. This simple record lets you reproduce the estimate when the bitrate or schedule changes.
A 24/7 service may be described as bandwidth even when the practical question is monthly transfer volume. The formula estimates volume over time. It does not tell you whether a hosting plan includes that amount, how an egress charge is calculated, or whether a provider counts traffic in decimal GB, GiB or another unit.
Apply the 30-day shortcut
Thirty days contain 2,592,000 seconds. Substituting that runtime in the full formula reduces the calculation to Mbps × 324 = decimal GB for 30 days. The multiplier is a shortcut derived from the formula, not a separate rule or a provider allowance.
| Continuous average bitrate | 30-day payload estimate, decimal GB | Approximate binary GiB |
|---|---|---|
| 1 Mbps | 324 GB | 302 GiB |
| 4 Mbps | 1,296 GB | 1,207 GiB |
| 10 Mbps | 3,240 GB | 3,017 GiB |
| 15 Mbps | 4,860 GB | 4,526 GiB |
For example, a 4 Mbps contribution feed running continuously for a 30-day month gives 4 × 324 = 1,296 decimal GB. This is the feed's payload arithmetic before overhead, retransmissions, restarts and unrelated traffic. It is not a forecast of a particular provider's bill.
The shortcut is useful for comparing settings. If you consider moving a study stream from 4 Mbps to 6 Mbps, the arithmetic difference for a 30-day month is 2 × 324, or 648 decimal GB of payload. Whether the higher setting is worthwhile depends on the picture you need and the rest of the service path, not on the transfer estimate alone.
Adjust for 28- or 31-day months
A calendar month is not always 30 days. Use the actual month length for a closer arithmetic estimate, or use a 30-day planning month when you want a stable comparison between configurations. For 28 days, there are 2,419,200 seconds and the multiplier is 302.4. For 31 days, there are 2,678,400 seconds and the multiplier is 334.8.
| Month assumed | Seconds streamed continuously | Shortcut to decimal GB |
|---|---|---|
| 28 days | 2,419,200 | Mbps × 302.4 |
| 30 days | 2,592,000 | Mbps × 324 |
| 31 days | 2,678,400 | Mbps × 334.8 |
At 4 Mbps, the 28-day calculation is 4 × 302.4 = 1,209.6 decimal GB. The 31-day calculation is 4 × 334.8 = 1,339.2 decimal GB. These values are not rounded billing predictions; retaining a decimal place shows how the multiplier works, while a planning spreadsheet can round to a sensible whole-GB estimate.
For a stream that starts or stops part-way through a month, do not apply a full-month multiplier. Put the actual streamed seconds into the full formula, or calculate the number of active days and multiply by 86,400 seconds per day. If the stream is scheduled for fewer than 24 hours on each active day, use its actual runtime instead of counting every calendar day as continuous.
Compare decimal GB with binary GiB
Data providers and monitoring tools do not always use the same unit labels. Decimal GB means 1,000,000,000 bytes. Binary GiB means 1,073,741,824 bytes. The same payload therefore has a numerically lower GiB value than GB: divide decimal GB by about 1.074 to convert to GiB, or multiply GiB by about 1.074 to express it as decimal GB.
For the 30-day, 4 Mbps example, 1,296 decimal GB is about 1,207 GiB. The difference is a unit convention, not data that has disappeared. When comparing your estimate with a usage dashboard or a plan allowance, check the provider's own unit definitions and the labels shown on its page.
Keep the unit visible in notes and spreadsheets. Writing just “1,296” makes a later comparison ambiguous; writing “1,296 decimal GB payload, 30 days, 4 Mbps” retains the assumptions. If a provider specifies an allowance in GiB, convert before comparing rather than treating the numbers as interchangeable.
A useful way to work is to preserve the unrounded formula result and show a rounded planning figure separately. That avoids small rounding differences accumulating when you compare several months, while still producing a readable estimate for choosing an allowance. Neither figure adds the overhead or other traffic that the payload calculation leaves out.
Account for overhead, retransmissions and restarts
The bitrate-times-runtime estimate counts encoded payload at a steady average rate. Real network transfer can be higher because packets and transport protocols add overhead, lost data may be retransmitted, and restarts or reconnections can create additional traffic. The estimate intentionally does not assign a universal percentage to those effects; their size depends on the stream path and operating conditions.
For a practical plan, keep the formula result as the baseline, then use measured usage from a comparable running period if it is available. A cloud usage dashboard may show total outbound transfer for the machine or service, which can help reveal the difference between the feed arithmetic and recorded traffic. Check that its period and units match the calculation before drawing a conclusion.
A restart does not necessarily add a large amount of transfer, but repeated interruption and recovery can make actual usage depart from a perfectly continuous payload model. Equally, an hour-long outage reduces transmitted payload for that hour but may coincide with retries or other traffic. Do not quietly treat the simple formula as a guarantee or use it as a substitute for monitoring.
On a self-managed setup, there is another operational question beside transfer volume: a script that stops after one loop or loses its encoder session may not behave like the continuous runtime assumed. The troubleshooting steps in this guide to a YouTube stream stopping after one loop are relevant when a looped source is expected to run unattended. They do not change the arithmetic; they help you test whether the assumed runtime reflects the actual process.
If the stream's purpose is to remain live while your own computer is off, the operational burden may also include keeping a local machine and its connection running. StreamNeo removes that specific need by letting you upload the video and provide the YouTube stream key, with the broadcast running in the cloud and watched for interruption. That addresses the question of a home computer needing to stay on; it does not turn payload arithmetic into a bill estimate or remove the need to check the relevant service terms.
Add unrelated server traffic separately
Count only the traffic leg that matches the question. A cloud-to-YouTube contribution feed is one outbound stream from the cloud. YouTube then transcodes a live stream into formats for viewers, as explained in its live encoder documentation. Those viewers' playback traffic is not the same as the single feed's transfer from your cloud host to YouTube.
If your cloud service also serves viewers directly through its own player or CDN, estimate that leg separately. A first-order calculation is viewers × average delivered Mbps per viewer × viewing seconds ÷ 8, followed by conversion from bytes to GB or GiB. In practice, audience transfer depends on viewer-hours, which quality each viewer receives, and the delivery architecture and cache behaviour. Do not multiply one viewer's rate by every quality in an adaptive-bitrate ladder: a viewer generally receives a selected rendition at a time. But when a service ingests or packages several renditions simultaneously, add those rates for that service leg.
AWS's MediaPackage pricing page illustrates why the legs matter: its example adds five rendition rates to an aggregate 9.5 Mbps before calculating ingest volume. It is a provider-specific example, not a universal estimate for a YouTube contribution feed. Likewise, the AWS live-streaming deployment guide models viewer delivery with assumptions about audience, average bitrate and caching. Treat those materials as examples of accounting paths, not as a substitute for your own service design or current provider pricing.
Other server use belongs in a separate line in your estimate: file uploads and downloads, control-panel activity, backups, software updates, or another service on the same host. Some may be inbound, some outbound, and a provider may count them differently. Ask which direction and service types count against the allowance before combining them with the stream's payload figure.
Monthly transfer is not the whole cloud bill. Depending on the path, charges may involve compute or encoding, ingest, packaging, storage, CDN delivery or internet egress, as well as transfer allowances and overage terms. Compare the provider, region, audience assumptions, cache assumptions and whether a quote covers only the feed to YouTube or direct viewer delivery too. Check current official pricing before choosing a plan; do not infer a bill from a GB calculation alone.
For a broader decision about whether a recorded-file service or a self-managed route suits a continuous channel, see the overview of services for 24/7 YouTube streaming from pre-recorded video. If you are weighing a VPS workflow instead, the practical implications of updating videos on a stream running on a VPS may help you account for activity beyond the ongoing feed. These are operational comparisons, not traffic guarantees.
The calculation is most useful as a reproducible starting point: state the bitrate, month length and unit, then keep overhead and other service legs distinct.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is 324 GB the exact monthly use at 1 Mbps?
No. It is the decimal payload calculation for a continuous 1 Mbps stream over 30 days. It excludes overhead, retransmissions, restarts and unrelated traffic, and it is not an exact provider bill.
Should I use the configured bitrate or the resolution?
Use the encoder's average or configured bitrate when you have it. Resolution alone does not determine transfer because frame rate, codec, content and settings affect bitrate; a YouTube recommendation is a starting point, not a measurement of your particular stream.
Does this include viewers watching on YouTube?
No. It estimates the contribution feed sent from the cloud to YouTube. YouTube handles delivery of its playback formats; if your cloud setup separately serves viewers, estimate that viewer-delivery traffic as another leg.
How do I compare the estimate with a hosting allowance?
First check whether the allowance is expressed in decimal GB or binary GiB and whether it covers outbound egress, CDN traffic or other services. Convert units if needed, then compare like with like and check the provider's current terms; the arithmetic alone cannot establish the bill.