To estimate the data your internet radio station uploads to YouTube, multiply its total outgoing bitrate in Mbps by the number of streaming hours, then by 0.45. The result is approximate decimal GB, not an exact bill or a measurement of every byte your connection transfers.
The key is to use the bitrate the station actually sends. If the stream includes a still image, visualiser or other video, count its bitrate as well as the audio; an audio-only calculation would understate usage.
Find the outgoing bitrate you need to count
This calculation concerns your station’s upload to YouTube, not the data viewers use to watch or listen. YouTube processes live streams into multiple output formats so viewers can watch across devices and networks. Those viewer copies are not additional uploads from your station, and their playback data should not be added to your estimate.
Start with the encoder or streaming software settings for the stream that is sent to YouTube. If it reports one combined bitrate, use that value. If it reports separate audio and video bitrates, add them together first. Keep the units consistent: the formula below expects megabits per second (Mbps), not kilobits per second (kbps).
YouTube’s live encoder settings guidance lists 128 kbps as a recommended stereo audio setting. That is an audio-track recommendation, not the total bitrate of every radio stream. It does not include video, and it may not describe the configuration your station actually uses. Treat the encoder’s outgoing rate as the relevant input rather than assuming that a published recommendation is your stream’s rate.
If you use OBS or another encoder, look for the configured output rates and check what is actually being sent during a test. The configured rate is a useful starting point, but a stream may not behave exactly as a single fixed number throughout a session. YouTube recommends testing upload bitrate and stream quality and monitoring stream health. Its guidance also lists constant bitrate encoding among its recommended advanced settings. These recommendations can help make the stream’s rate easier to plan around; they do not turn a usage estimate into a precise measurement.
For troubleshooting a stream that reaches YouTube late, the guide to diagnosing RTMP ingest delay from OBS or FFmpeg addresses a related but different question. Ingest delay concerns how the stream arrives and is processed, while this calculation concerns how much data your station sends over time.
Apply the bitrate-and-hours formula
The calculation is:
Approximate decimal GB = total outgoing bitrate in Mbps × streaming hours × 0.45
The 0.45 factor is a unit conversion. One megabit per second sustained for an hour transfers about 450 megabytes, or 0.45 decimal gigabytes, before allowing for factors such as protocol overhead. In practical terms, each sustained Mbps adds about 0.45 GB for every hour the station streams.
First work out the total bitrate in Mbps. Then multiply by the number of hours you plan to stream. Multiply that result by 0.45 to estimate decimal GB. For a part-time schedule, use the actual scheduled hours rather than treating each day as a full 24-hour broadcast.
For example, if the outgoing rate is 1 Mbps and you stream for 10 hours, the arithmetic is 1 × 10 × 0.45, giving an estimate of 4.5 decimal GB. If the station sends at 2 Mbps for those same hours, the estimate doubles to 9 GB. The calculation scales with both inputs: twice the bitrate or twice the duration gives twice the estimated transfer, provided the other input stays the same.
You can also reverse the calculation for planning. If you have a data allowance in decimal GB and want to estimate how many hours it might cover at a known total bitrate, divide the allowance by 0.45 and then divide by the bitrate in Mbps. Treat that result as a planning aid, not a promise that the connection will stay within the allowance: actual usage may differ, and the units shown by your provider matter.
If you are rotating audio programmes or recordings, the content organisation itself does not change the formula; the outgoing bitrate and airtime still control the estimate. The advice on organising podcast files for an always-on YouTube stream can help with the programme side, while this page focuses on the network transfer.
Convert the result to decimal GB
The formula gives decimal gigabytes. In decimal units, 1 GB is 1,000 MB. That makes 450 MB equal to 0.45 GB, which is the basis for the multiplier. Many internet data allowances are shown in decimal GB, but not every monitoring tool uses the same convention, so check the unit before comparing your estimate with a dashboard or cap.
Some software may instead display binary gibibytes (GiB), where one GiB is 1,073,741,824 bytes. Decimal GB and binary GiB are different units, even though displays sometimes label both as “GB”. If you have a byte count and want binary GiB, divide the bytes by 1,073,741,824. Do not compare a decimal-GB estimate directly with a binary-GiB reading as if they were identical.
A sensible comparison follows three steps: keep the bitrate in Mbps, calculate the decimal-GB estimate, then confirm whether the provider’s allowance or monitoring page uses decimal GB, binary GiB, or another label. This prevents a unit mismatch from being mistaken for a change in the stream’s behaviour. If your provider is unclear, consult its current explanation of how it reports data usage.
Work through one day of streaming
For a continuous 24-hour stream at 1 Mbps, the estimate is 1 × 24 × 0.45, or about 10.8 decimal GB. This is a calculated estimate from bitrate, duration and unit conversion. It is not a published measurement of a particular station’s traffic, nor an exact amount that every internet provider will record.
The calculation is easy to adapt. At 0.5 Mbps for 24 hours, it is 0.5 × 24 × 0.45, or about 5.4 GB. At 1.5 Mbps for the same duration, it is 1.5 × 24 × 0.45, or about 16.2 GB. In each case, use the total outgoing rate, not just the audio rate if the broadcast also carries video.
For a schedule that runs for only part of the day, replace 24 with the actual number of hours. A station that streams for 12 hours at 1 Mbps has an estimate of 5.4 GB for that session. If its schedule changes from day to day, calculate each day separately and add the results. That approach makes the assumptions visible: you can see whether a larger estimate comes from more airtime, a higher bitrate, or both.
These values are useful for checking whether a connection plan deserves closer attention, but they are not a reason to ignore monitoring. Reconnects, variable output rates and protocol traffic can move the real total away from the simple arithmetic. If you are already running a loop channel, the discussion of free software for a YouTube loop stream in India may help you review the broadcasting setup; use the encoder’s actual outgoing rate for this particular estimate.
Estimate a week of continuous streaming
For a full week, use 168 streaming hours: seven days multiplied by 24 hours. At a sustained 1 Mbps, the estimate is 1 × 168 × 0.45, or about 75.6 decimal GB. As with the daily figure, this is a calculation rather than a measured weekly total.
A small change in bitrate becomes more noticeable when it continues for a full week. At 1.5 Mbps for 168 hours, the estimate is 1.5 × 168 × 0.45, or about 113.4 GB. That does not mean every 1.5 Mbps station will use exactly that amount: the result assumes the rate is sustained and does not include a measured allowance for overhead or variation.
For a weekly schedule that includes breaks, count only the hours that the station actually sends a stream. For instance, a station that runs on weekdays but not over the weekend should total the relevant daily hours rather than use 168. If its bitrate changes between programmes, estimate each portion separately using that portion’s rate and duration, then add the estimates.
| Schedule or stream rate | Calculation | Approximate decimal GB |
|---|---|---|
| 1 Mbps for 24 hours | 1 × 24 × 0.45 | 10.8 |
| 1 Mbps for 168 hours | 1 × 168 × 0.45 | 75.6 |
| 1.5 Mbps for 168 hours | 1.5 × 168 × 0.45 | 113.4 |
The table is a quick reference for these stated assumptions, not a set of universal usage figures. To estimate your own schedule, substitute your measured or configured total bitrate and the hours you expect to stream. That produces a result you can recalculate when either the programme schedule or stream settings change.
Include video as well as audio
An internet radio station on YouTube may have a visual component, even if the audience mainly listens. A still image, animated visualiser, album artwork or camera feed can mean that the outgoing stream contains video data as well as audio. The calculation must reflect the whole outgoing stream. Do not calculate combined usage from the audio bitrate alone.
If the encoder reports separate track rates, add them before applying the formula. Suppose a configuration reports an audio rate of 128 kbps and a video rate of 1,000 kbps. Together they represent 1,128 kbps, or 1.128 Mbps, before considering other stream components. You can then multiply that combined rate by the scheduled hours and by 0.45. This illustration shows how to combine rates; it is not a claim that a particular station uses those settings or that its total will match the estimate exactly.
For comparison, YouTube’s recommended 128 kbps stereo audio rate alone would work out to about 57.6 MB per hour, or 1.38 decimal GB over 24 hours, before overhead. That estimate describes the audio track only. If video is sent too, add its bitrate to the audio rate before calculating total usage. It would be a mistake to label the audio-only result as the total data use of a radio stream that also sends video.
Do not pick a video rate from a video-resolution table simply because your channel has a picture on screen. YouTube’s bitrate tables primarily address video ingestion resolutions and frame rates; an audio-focused station should use the actual audio and video configuration of its encoder. The YouTube Help encoder guidance is the place to check its current settings advice. Google’s HLS ingestion documentation also directs readers to YouTube’s bitrate guidance; ingestion documentation is not a substitute for knowing the rate your own encoder sends.
If your encoder gives you a single combined stream bitrate, you do not need to reconstruct separate audio and video rates for this arithmetic. Use the combined figure it reports. If it provides only separate settings, add them carefully and make sure both values describe the outgoing stream rather than unrelated playback or processing settings.
Allow for overhead and rate changes
The formula is deliberately transparent, but it is not an exact bill or measurement. It converts a sustained bitrate and duration into an approximate payload volume. Actual network traffic may be higher because protocols add overhead, and it may differ when the outgoing bitrate varies. Reconnects and changes in stream behaviour can also make a simple constant-rate estimate diverge from a connection’s recorded total.
There are three useful ways to plan, depending on what information you have. An encoder-reported combined rate gives you a direct calculation when the stream rate is known. A measured average from network monitoring can reflect what happened during a representative test. A conservative allowance for overhead or bitrate variation gives you more room when planning a data cap, although you should not treat an arbitrary extra amount as a universal rule.
| Planning input | What it tells you | Limitation |
|---|---|---|
| Encoder-reported total bitrate | A straightforward estimate based on the stream settings or reported output | A configured rate may not capture every change in actual traffic |
| Measured average from monitoring | A record of usage over the period monitored | A short test may not represent a full day or a changing programme schedule |
| Conservative planning allowance | A way to avoid relying on the bare arithmetic alone | The appropriate margin depends on the stream and is not a fixed value supplied here |
To make monitoring useful, compare like with like. Record the stream’s total rate and the length of the test, then compare the observed upload with the estimate using consistent units. Test the audio-only or audio-and-video setup you plan to run, not a different configuration. YouTube recommends testing upload quality before a live event and watching stream health during it; those checks help identify delivery problems, even though they do not themselves establish a precise data-cap total.
If continuous operation is part of your plan, separate data usage from the question of what keeps the broadcast running. A setup that depends on a home computer has different operating considerations from one that can run with your computer off. StreamNeo is relevant to the specific burden of leaving that computer on: it turns an uploaded video into a YouTube live stream, so you can avoid keeping your own machine running for the broadcast. The bitrate calculation still applies to the outgoing stream, and you should plan data based on the total rate and hours rather than assume a hosting approach changes the arithmetic.
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
How do I calculate data usage from bitrate?
Multiply the total outgoing bitrate in Mbps by streaming hours and by 0.45 to estimate decimal GB. If your encoder reports audio and video separately, add those rates first. The result is an estimate, not an exact measurement or bill.
How much data does streaming use for 24 hours at 1 Mbps?
The calculation is 1 × 24 × 0.45, which gives about 10.8 decimal GB. It assumes a sustained 1 Mbps stream and does not include a measured allowance for protocol overhead or rate variation. Use your stream’s total rate if it includes video.
Does a still image count as video for this estimate?
If the outgoing stream carries a video track, include its bitrate even if the picture is still or the audience mainly listens. Add the video and audio rates, then use the combined total in the formula. Audio bitrate alone would undercount a stream that also sends video.
Is this the data viewers use to watch the radio stream?
No. This estimates the station’s outgoing upload to YouTube, not the playback data consumed by every viewer. YouTube transcodes live streams into multiple output formats, so viewer playback is a separate part of the delivery process.