An Nginx RTMP relay needs roughly the encoded stream bitrate on each network leg carrying the feed. For one encoder, one relay and one YouTube destination, the relay host receives one copy and sends one copy, so count both when estimating its combined traffic.
That is a planning estimate, not an exact bill or a fixed bandwidth requirement created by Nginx. Your encoder bitrate, topology, duration and other network use determine the result; transport overhead adds some traffic beyond the simple calculation.
Start with the encoded stream bitrate
The bitrate is the amount of encoded audio and video data sent each second. It is the useful starting point whether you publish directly from an encoder to YouTube or send the feed through a relay first. For example, a steady 5 Mbps stream carries about 5 megabits of encoded media each second on a network leg that transports it.
Resolution alone does not tell you the bitrate. Frame rate, codec, motion, image detail, audio and the quality you want all matter. A static devotional image with a bhajan track may compress differently from a fast-moving local news segment, even at the same resolution. The encoder's configured bitrate, rather than the label “1080p”, is the input for a transfer estimate.
YouTube's live encoder settings and bitrate guidance lists recommendations by codec, resolution and frame rate. These are YouTube's recommended ingest settings, not universal minimum internet speeds and not a claim that every stream must use a particular value. Choose a setting appropriate to your codec and content, then verify how the actual stream behaves.
If you need to choose a bitrate for a continuous music channel, the practical question is both whether your connection can sustain it and how much data it moves over time. Our guide to upload speed for a 24/7 YouTube music stream in India covers the connection-capacity side. This article focuses on separating the traffic on each leg and estimating the resulting transfer.
Count the encoder-to-relay leg
When an encoder publishes to an Nginx RTMP relay, the encoder sends one stream to that relay. If the encoder is configured for a steady 5 Mbps output, plan for approximately 5 Mbps of upload capacity on this leg, before allowing for protocol overhead and other traffic using the same connection.
This figure describes the encoded stream rate, not the whole household or office connection. A computer uploading backups, a camera sending a separate feed, or other people using the same internet connection can reduce the available capacity. A connection advertised at a particular speed also does not guarantee that all of that capacity will be available continuously at the encoder's location.
The encoder needs upload headroom because a stream that occupies all available capacity can become unstable when conditions vary. Do not convert the recommended bitrate into a supposed guaranteed connection speed. Instead, check the actual upload capacity at the encoder location and test with the same resolution, frame rate, codec and representative audio and motion that the live channel will use.
If there is no relay, this is not an encoder-to-relay leg at all: the encoder sends directly to YouTube, and its one outgoing stream uses approximately its encoded bitrate. A relay changes the path and who sends the next copy; it does not automatically require the encoder to send several copies to YouTube viewers.
Count the relay-to-YouTube leg
The relay forwards the feed to YouTube over a separate network leg. For a simple forwarding setup that does not transcode the video, the relay's outgoing stream is approximately the same bitrate as its incoming stream. A 5 Mbps feed therefore calls for about 5 Mbps of outgoing capacity from the relay for that YouTube destination.
The incoming and outgoing requirements belong to different network interfaces or connection directions. The encoder's upload requirement is set by the first leg. The relay's upload requirement is set by the second leg. If you are checking a home encoder connection, do not add the relay's outgoing traffic to that home's upload estimate; if you are assessing the relay host's traffic, do include both directions.
YouTube recommends RTMPS for ingest. Its RTMPS ingestion documentation explains the secure RTMP option and the ingestion endpoint. Using RTMPS does not mean that the broadcaster sends one stream per viewer. YouTube distributes the live programme to viewers; the relay's destination count is based on the destinations you configure, not on the channel's audience size.
A workflow that transcodes or creates several renditions is different from simple forwarding. Each output may have its own bitrate, so estimate the relay's outgoing traffic from those outputs rather than assuming one unchanged copy. Likewise, forwarding to more than one platform or destination creates another outgoing copy for each destination. There is no universal Nginx multiplier that covers those different arrangements.
Estimate combined relay traffic
For one input and one output, think of the relay as handling two legs: one incoming and one outgoing. If both carry the same steady bitrate, the relay's combined network traffic, counting received and sent data, is approximately twice that bitrate. This combined figure is useful for considering a host's total transfer; it is not the upload speed required on either individual leg.
| Bitrate of one stream | Encoder to relay | Relay to YouTube | Relay combined, received plus sent |
|---|---|---|---|
| 5 Mbps | about 5 Mbps | about 5 Mbps | about 10 Mbps across both directions |
| 10 Mbps | about 10 Mbps | about 10 Mbps | about 20 Mbps across both directions |
| 14 Mbps | about 14 Mbps | about 14 Mbps | about 28 Mbps across both directions |
| 17 Mbps | about 17 Mbps | about 17 Mbps | about 34 Mbps across both directions |
These are bitrate-based estimates for a one-input, one-destination relay, not exact totals including transport overhead. The “combined” column adds the receive and send rates as a way to describe traffic crossing the relay host. It should not be read as a requirement that one network interface upload at the combined rate: the receive leg and send leg each carry roughly one stream bitrate in their respective directions.
If a relay sends the same feed to two destinations, count roughly one outgoing copy per destination. For instance, the incoming leg remains one copy, while the relay has two outgoing legs. If the destination outputs have different bitrates, add their individual rates rather than multiplying a single number blindly. The NGINX RTMP module documentation describes RTMP functionality and related delivery formats, but it does not set a fixed traffic multiplier for every deployment.
This distinction is especially useful when a hosting provider reports transfer allowances. Compare the provider's definition of inbound, outbound and billable traffic with the traffic you estimate; providers can treat directions differently. The guide to Hetzner traffic limits for continuous YouTube streaming is relevant if that is your provider, but the same accounting question applies elsewhere.
Compare YouTube ingest bitrate examples
YouTube's recommendations show why an estimate should use the configured bitrate rather than resolution alone. The table below gives selected H.264 recommendations from YouTube's current encoder guidance. They are useful reference points for calculation, not mandatory settings for every channel.
| YouTube video setting | H.264 recommended ingest bitrate | Approximate traffic per hour on one leg |
|---|---|---|
| 1080p at 30 fps | 14 Mbps | 6.3 GB |
| 1080p at 60 fps | 17 Mbps | 7.65 GB |
| 4K at 30 fps | 42 Mbps | 18.9 GB |
| 4K at 60 fps | 50 Mbps | 22.5 GB |
The hourly figures use decimal gigabytes and the conversion described in the next section. They show transfer on one copy of the stream, not combined relay traffic. A relay host with one incoming and one outgoing leg would handle approximately twice the per-leg data before overhead. The source encoder, meanwhile, uploads just its outgoing leg to the relay.
Codec also changes the reference value. YouTube's table lists separate recommendations for AV1 and H.265; for example, the listed 1080p30 recommendation is 10 Mbps for those codecs, compared with 14 Mbps for H.264. Use the recommendation for the codec actually configured, and do not infer a codec from resolution. YouTube's LiveStreams API health documentation describes health information that can flag stream issues such as low bitrate, frame-rate mismatch or missing audio.
The stream's content matters when you decide whether to adopt a recommended setting. A mostly still image may not need the same quality choices as detailed moving footage, but any reduction should be judged by viewing the resulting picture and checking the live health indication. Avoid changing several encoder settings immediately before a long unattended run; test a representative stream first, then keep a note of the working configuration.
Convert bitrate into daily and monthly transfer
For a steady bitrate, a practical decimal conversion is GB per hour ≈ bitrate in Mbps × 0.45. This comes from converting megabits each second into bytes transferred over an hour. It is a unit calculation, not a reading from a particular internet provider or an exact forecast of a bill.
At 5 Mbps, one stream copy transfers approximately 2.25 GB per hour. Over a full day, that is about 54 GB, and over a 30-day planning month, about 1,620 GB. At 14 Mbps, the corresponding estimate is about 6.3 GB per hour, 151.2 GB per day and 4,536 GB over 30 days, again for one leg and before overhead.
For another example, a 17 Mbps leg is approximately 7.65 GB each hour. That is about 183.6 GB over a day and 5,508 GB across 30 days. These large monthly totals are a consequence of continuous operation, not a special property of Nginx. A stream that runs only part of each day should be calculated using its actual hours, not a full-month assumption.
For a relay host with one incoming and one outgoing copy at the same bitrate, double the per-leg transfer estimate to describe combined received plus sent traffic. Thus, the 5 Mbps example is roughly 108 GB combined per day and 3,240 GB for 30 days. That does not mean the encoder itself uploads twice as much: its leg remains one copy. It also does not determine whether a provider bills inbound traffic, outbound traffic, or both.
A simple worksheet keeps these quantities separate:
| What you are estimating | Calculation for a steady one-copy stream |
|---|---|
| Encoder upload while publishing to relay | bitrate × approximately 0.45 GB per hour |
| Relay outgoing transfer to YouTube | bitrate × approximately 0.45 GB per hour |
| Relay combined incoming and outgoing | add the incoming and outgoing per-leg estimates |
| Multiple outgoing destinations | add one estimate for each destination's output bitrate |
The approximate monthly figure uses whatever number of operating hours you expect. If a channel is intended to run all day, multiply the hourly result by 24 and then by the number of days in your chosen planning period. If it runs on a schedule or is sometimes stopped for maintenance, substitute the real operating hours. For provider billing, check the current provider terms rather than treating this arithmetic as a quotation.
Allow for overhead and other traffic
The bitrate conversion describes encoded media at a steady rate. Real network traffic also includes transport and protocol data, and a connection may carry other traffic at the same time. The sources cited here do not give a fixed overhead percentage that can be safely applied to every RTMP or RTMPS deployment, so do not present a calculated total as an exact bill.
RTMPS uses the RTMP feed through a secure connection. The additional protocol data is a reason to leave headroom, but the precise amount depends on details not captured by a simple bitrate calculation. There is also variation if the configured bitrate changes, if the encoder is variable rather than steady, or if the relay creates outputs with different bitrates.
Capacity and monthly transfer are related but different questions. Capacity is about whether each leg can sustain its rate at the same time as other demands. Transfer is the cumulative data over hours and days. A relay could have enough capacity at a moment but still exceed a provider's transfer allowance over a month; conversely, a large transfer allowance does not solve an upload bottleneck at the encoder.
YouTube advises operators to run a speed test and test the actual stream. Its encoder guidance also recommends monitoring stream health during the event. Make the test resemble the real channel: use the planned bitrate, audio, movement, frame rate, encoder and path through the relay. Check the stream health rather than relying only on a speed test, since a speed test does not exercise the full ingest path for an entire unattended broadcast.
If a stream is unstable, check which leg is constrained before reducing quality indiscriminately. The encoder-to-relay path may be limited by the local connection, while relay-to-YouTube capacity may be the issue on the second path. A YouTube warning can also point to a bitrate, frame-rate or audio setting rather than raw bandwidth. The troubleshooting guide for unstable YouTube stream health on wired Ethernet offers checks for that kind of symptom.
For a channel where leaving a computer running overnight is the operational pain, StreamNeo can take an uploaded video and keep the YouTube broadcast running with your computer switched off; that removes the need to keep a home encoder sending its leg continuously, though you should still estimate the service's outbound stream and check the terms for any hosting plan you use.
When choosing a topology, be clear about what problem you are solving. Direct publishing has one outgoing stream from the encoder to YouTube. A relay separates the encoder's outgoing leg from the relay's outgoing leg and can be useful when the encoder and destination path need to be managed separately. More destinations or renditions add traffic in a way that should be counted explicitly. None of these arrangements makes viewer count a multiplier on the relay's YouTube ingest stream.
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
Does Nginx RTMP double my upload requirement?
Not on the encoder's own connection in a one-relay setup. The encoder uploads one copy to the relay, while the relay separately uploads a copy to YouTube. Count both legs when estimating the relay host's combined received and sent traffic, not as a doubled encoder upload.
How many gigabytes does a 10 Mbps stream use per hour?
A steady 10 Mbps stream is approximately 4.5 decimal GB per hour on one network leg, before protocol overhead. A one-input, one-output relay handles about one such amount received and another sent, so its combined traffic is roughly twice that estimate.
Does YouTube's viewer count change the relay bandwidth estimate?
Not when the relay sends one feed to YouTube and YouTube distributes it to viewers. The relay's outgoing traffic depends on the number and bitrate of configured destinations, not the number of people watching on YouTube.
How much headroom should I add for overhead?
There is no single sourced percentage that applies to every setup, so treat the bitrate conversion as a baseline rather than a guaranteed transfer total. Leave practical capacity headroom, test the real stream and monitor its health; check your provider's billing rules separately.