A continuous FFmpeg stream sends data from your VPS to YouTube, and its estimated monthly egress is the outgoing bitrate multiplied by the time it runs. Divide bits by eight to get bytes, then compare the resulting transfer estimate with the outbound allowance and billing rules for your exact VPS plan.
That calculation gives you a planning figure, not an exact bill. The measured total can differ because of encoding variation, protocol overhead, reconnects, other traffic and the way your provider counts transfer.
What VPS egress means for an FFmpeg stream
Egress is data leaving the VPS. When FFmpeg sends a live feed to YouTube, that upload is outbound traffic from the machine, so it may count towards the plan’s outbound transfer allowance. It is separate from the data viewers receive from YouTube: your VPS sends the feed to YouTube, and YouTube handles delivery to viewers.
This distinction matters when a stream grows an audience. You do not multiply the VPS estimate by the number of viewers. You do need to account separately for any other traffic the VPS sends, such as a second stream, file transfers or monitoring services that upload data.
Egress volume and network capacity are related but different. A stream’s bitrate indicates the rate at which data is sent; its total egress accumulates over time. A plan may have a large transfer allowance but a port or sustained-throughput limit that cannot reliably carry your chosen bitrate. Conversely, adequate network capacity does not mean the plan includes unlimited monthly transfer.
For a practical starting point, identify the feed FFmpeg sends to YouTube, then estimate its volume across the actual billing period. The VPS location and routing considerations for a 24/7 stream are a separate part of reliability: a nearby location may affect the route, but does not change the arithmetic for a given bitrate and duration.
Find the actual outgoing bitrate
Use the configured outgoing video and audio bitrates, not the resolution by itself. Resolution is a clue to likely settings, but it does not determine a unique bitrate. Encoder settings, frame rate, codec and content affect what you configure and what the stream sends.
If your FFmpeg command sets video to 6 Mbps and stereo audio to 128 Kbps, express both in the same unit before adding them. Since 1 Mbps is 1,000 Kbps, 128 Kbps is 0.128 Mbps; the nominal combined rate is therefore 6.128 Mbps. Use the combined rate for the estimate, because both tracks are part of the outgoing feed.
YouTube Help’s live encoder settings and bitrate guidance gives H.264 examples of 10 Mbps for 1080p at 30 fps and 12 Mbps for 1080p at 60 fps, with 128 Kbps listed as an advanced stereo-audio setting. These are guidance values, not a claim that every stream at those resolutions uses those rates. If you use an example from the page, include audio if it is sent and make clear whether you are calculating video-only or a combined feed.
Check the actual FFmpeg output settings, and where possible verify the running stream’s observed bitrate. A configured target may not equal an exact steady rate at every moment. YouTube’s LiveStreams API documentation describes stream-health feedback, including bitrate and keyframe-related conditions. This can help diagnose a feed; it does not replace the VPS provider’s transfer counter for billing measurement.
If your source is a playlist with separate language or programme tracks, only count the tracks actually sent in the outgoing stream. A guide to prerecorded playlists with multiple audio tracks can help distinguish the source media’s tracks from the single feed configured for YouTube.
Convert bits per second to bytes per second
Bitrate is measured in bits per second, while data allowances are commonly shown in bytes, gigabytes or tebibytes. There are eight bits in a byte, so divide a bit rate by eight to convert it to bytes per second. Keep the decimal prefixes and units clear as you continue the calculation.
For example, 6.128 megabits per second is 6,128,000 bits per second if Mbps uses the decimal convention. Dividing by eight gives 766,000 bytes per second. That is the nominal data rate before network overhead or other traffic.
A useful compact formula is:
transfer_bytes = outgoing_bits_per_second × streaming_seconds ÷ 8
You can also work in megabits per second and hours. With decimal units, multiplying bitrate in Mbps by hours and by 0.45 gives an approximate volume in decimal gigabytes:
transfer_GB ≈ bitrate_Mbps × hours × 0.45
The factor comes from converting megabits into bytes and seconds into hours, then expressing the result in billions of bytes. A decimal GB is 1,000,000,000 bytes. Some providers show a different unit, such as TiB, or define their counters differently. Convert the estimate to the provider’s stated unit before comparing; do not silently treat GB and GiB or TB and TiB as interchangeable.
These conversions estimate media transfer from a steady average rate. Actual traffic can be higher because of transport overhead, retries or reconnections, and the VPS may send unrelated data. The formula is still useful for sizing, provided you leave room above the arithmetic result.
Multiply by streaming duration
The longer the stream runs, the more transfer accumulates. For a continuous stream, count the actual number of hours in the billing cycle rather than assuming every month has the same length. A 30-day period contains 720 hours; a 31-day period contains 744 hours. Use the cycle dates in the plan, which may not match a calendar month.
For continuous operation over 30 days, the decimal-GB shortcut becomes:
transfer_GB ≈ bitrate_Mbps × 30 × 24 × 0.45
That simplifies to about 324 decimal GB per sustained Mbps for 30 days. For 31 days, the corresponding multiplier is about 334.8 GB per Mbps. These are arithmetic results from the formula, not provider measurements or promises about a bill.
If a stream runs only part of each day, use its real hours. For example, if you broadcast for 12 hours daily over a 30-day period, multiply the rate by 360 hours rather than 720. For a stream that drops or is deliberately paused, a precise planning estimate should use expected on-air duration, while a cautious capacity check can assume it runs continuously.
A second feed needs its own calculation. If two destinations receive separate full-rate outputs at the same time, count both outgoing feeds. A backup ingestion address alone does not double traffic; only sending another copy does. YouTube’s live streaming API documentation documents ingestion stream resources and health information, while your FFmpeg configuration determines what you actually send.
Work through a monthly estimate
Suppose an FFmpeg configuration sends 6 Mbps of video plus 128 Kbps of audio, continuously for 30 days. First convert the audio rate: 128 Kbps is 0.128 Mbps. Add it to the video rate to get 6.128 Mbps. Then multiply by the 30-day factor:
6.128 × 324 ≈ 1,985.5 GB
That is approximately 1.99 decimal TB of estimated media transfer for the period, before overhead, retries, reconnects and unrelated VPS traffic. It is not an exact bill. The value is useful as a baseline when you look at the specific plan’s included transfer and observed usage.
For comparison, a video-only 10 Mbps feed running continuously for 30 days estimates to 10 × 324, or 3,240 decimal GB. If 128 Kbps audio is also sent, add 0.128 Mbps to the input: 10.128 × 324 is about 3,281 GB. YouTube’s recommended H.264 example for 1080p at 60 fps is 12 Mbps for video; with that same audio setting, the estimate is 12.128 × 324, about 3,929 GB. These figures are calculations from the inputs and duration, not published usage statistics.
The same arithmetic works for any cycle. If a provider’s period is 31 days and your combined feed averages 6.128 Mbps, use 6.128 × 334.8, which is about 2,052 GB. For a short cycle, use its hours in the general formula instead. A simple spreadsheet can hold bitrate, daily hours, cycle length and resulting transfer so you can change one assumption without recalculating by hand.
Keep the assumptions beside the answer. Note whether the rate includes audio, whether operation is continuous, whether another feed is sent, and whether the volume uses decimal GB. That makes the number useful when you revisit it after changing the encoder or plan.
Compare estimated transfer with plan allowances
Once you have a baseline, compare it with the exact plan’s included outbound transfer for the relevant billing period. Do not compare it with the provider’s headline port speed as if the two were the same. An allowance is a volume over a period; port speed is a rate that affects whether traffic can be sustained.
A 30-day continuous 10 Mbps video feed, for instance, gives a baseline of 3,240 decimal GB before audio and operational margin. If the plan states a monthly allowance in a different unit, convert consistently. Then leave a margin above the estimate for overhead, reconnects, brief bitrate changes and other VPS traffic. The right margin depends on how much other traffic you generate and how close the stream runs to its configured target; there is no universal percentage that fits every host.
| Estimate input | Example | What to check |
|---|---|---|
| Combined outgoing rate | 6.128 Mbps | Video plus audio actually sent |
| Continuous 30-day duration | 720 hours | The plan’s actual cycle may differ |
| Decimal transfer estimate | About 1,985.5 GB | Before overhead and unrelated traffic |
| Plan allowance | Use the plan’s stated amount | Confirm unit and outbound counting policy |
If you are choosing between plans, calculate the transfer for each stream you intend to run and add other expected outbound traffic. A plan with a lower cost is not necessarily suitable if its transfer allowance, sustained throughput or network policy cannot support the use case. A plan with ample transfer may still need enough continuous capacity for the feed.
For a local news loop, devotional channel or study stream, the feed may run through long unattended periods. Consider testing the configuration before relying on it overnight and keeping an eye on the stream-health indicators. The YouTube Live bitrate guide can help you choose an encoder target, while the egress calculation tells you what that target implies for transfer volume.
Check provider billing and overage terms
The arithmetic cannot tell you how a host will bill. Read the exact plan terms, not a general hosting overview, and verify the region and plan variant you intend to use. Providers may differ in whether they count only outbound traffic or both directions, how they measure a billing cycle, and what happens when an allowance is reached.
Before committing, find answers to these questions:
- What outbound transfer amount is included, and is the unit GB, TB, GiB or TiB?
- Does the allowance reset on a calendar date or on the account’s billing anniversary?
- Is inbound traffic excluded, or does the plan count both directions?
- What happens after the included amount is used: additional billing, throttling, suspension or another policy?
- Is there a sustained port or throughput limit that could affect a constant feed?
- Can you view a transfer counter for the instance or account, and how often does it update?
Treat any stated overage price or allowance as a vendor-specific term. Check the provider’s own current plan page or support documentation before relying on it; do not infer a charge from the estimate, or assume that an allowance is shared or per-instance without confirmation. Since terms and prices can change, record what you checked and when. A transfer estimate remains separate from a price quote.
Once the stream is running, compare the estimate with the provider’s counter over a representative period. Do not expect a short test to reveal a monthly total exactly, particularly if the stream is intermittent or other services use the VPS. Longer observation can show whether your assumed average rate and usage pattern are reasonable. Keep an allowance above the observed trend rather than planning to land exactly on the limit.
YouTube recommends testing before going live and monitoring stream health. Its encoder settings guidance and API health feedback can help you identify feed problems, but neither page defines a VPS host’s egress accounting. If the maintenance burden is the issue—keeping a computer on and dealing with restarts—a workflow that runs a prepared file without your computer being left on can remove that particular task; it does not change the need to understand YouTube and hosting limits. StreamNeo turns an uploaded video into a YouTube-only continuous stream, so you do not need to keep your own computer running for that file-based broadcast.
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 much data does a 24/7 YouTube livestream use?
It depends on the outgoing bitrate and how long the stream runs. As a planning shortcut, each sustained 1 Mbps is about 324 decimal GB over 30 days, before overhead and other VPS traffic; include audio in the bitrate if it is sent.
How do I calculate VPS bandwidth for FFmpeg?
Add the video and audio rates in bits per second, multiply by the number of streaming seconds, then divide by eight to convert bits to bytes. Convert the byte total to the unit your provider uses, and compare it with the plan’s outbound allowance and accounting terms.
How much egress does a 10 Mbps stream use per month?
A continuous 10 Mbps feed over 30 days estimates to 3,240 decimal GB, using 10 Mbps multiplied by 324. This is a baseline for media transfer, not an exact bill; audio, overhead, other traffic and the provider’s counting rules can change measured usage.
Does YouTube’s viewer quality options multiply VPS egress?
No. Your VPS sends its configured feed to YouTube; YouTube’s viewer-side transcoding does not mean the VPS sends every playback rendition. Count another feed only if your setup actually sends a duplicate stream to another destination.