If a YouTube playlist plays continuously for viewers, that does not mean you need to save a month of playback on your own computer. You need to plan for month-long storage only if you also want a continuous local recording; at a constant recording bitrate of 1 Mbps, 30 days produces about 324 GB decimal, before overhead.
The useful estimate depends on the bitrate of that local recording and how many hours you keep it. YouTube’s upload bitrate can be a planning proxy when you do not know the recording rate, but the two are not automatically the same.
First separate playback from recording
A playlist looping on YouTube is a viewing arrangement. The video files that make up the playlist are already uploaded, and viewers receive playback through YouTube. That alone does not create a local recording on your computer for every hour the channel is live. So there is no month-long local file to size unless your setup is actually recording the broadcast.
A local recording may still be useful. You might need an archive of a devotional programme, a clean copy of a local news loop, or a record of what was broadcast if a source file is changed later. That is a separate job from keeping the live channel playing, and it has a separate storage cost. For the distinction between running a loop and how delivery works, see how OTT streaming works.
Do not assume YouTube will provide a complete recording of one uninterrupted month-long session. YouTube says streams shorter than 12 hours can be automatically archived, but warns that streams over 12 hours may not be captured at all. It recommends making a local archive backup if you need one. Read its current live-stream archive guidance before relying on an archive, and check any local copy rather than assuming it is intact.
A quick estimate for 30 days
For constant bitrate video, the payload calculation is straightforward. A megabit is a unit of bits, while file sizes are normally shown in bytes; eight bits make one byte. Multiply bitrate by seconds, then divide by eight to convert bits to bytes.
For 30 days, there are 720 hours, or 2,592,000 seconds. At 1 Mbps, the calculation is 1,000,000 bits per second × 2,592,000 seconds ÷ 8, which is 324,000,000,000 bytes. That is 324 GB in decimal units, or approximately 302 GiB in binary units.
You can use either of these forms:
- Storage in decimal TB ≈ bitrate in Mbps × hours × 0.00045.
- For 30 days: decimal TB ≈ bitrate in Mbps × 0.324.
These are estimates of the video payload at the stated constant bitrate. They do not include container overhead, filesystem formatting, any variation in a variable-bitrate recording, or room for other files. A result of 2.59 TB therefore means the calculated payload is about 2.59 TB, not that a drive advertised at exactly that capacity is a sensible purchase.
The hourly version can be handy when planning shorter captures: 1 Mbps uses about 0.45 GB per hour in decimal units. Multiply 0.45 by the actual local recording bitrate in Mbps. For example, at 8 Mbps the payload is roughly 3.6 GB per hour. This is still an arithmetic estimate, not a prediction of an encoder’s variable output.
Use the recording bitrate, not a guessed upload rate
The bitrate that matters for local storage is the bitrate at which the recording is written. A local recorder may encode a separate copy at a different rate from the stream sent to YouTube. Some setups may save a stream copy, while others encode a local file with different settings. Work from the recording setting or inspect a representative output file if you have one.
YouTube publishes recommended ingest settings for different resolutions, frame rates and codecs. Those recommendations describe what to send to YouTube, not the measured size of a local archive. If you do not know your recording bitrate, its ingest recommendations can serve as a transparent planning proxy, provided you label the assumption. The YouTube encoder settings and bitrate guidance lists the recommended rates by format.
For example, YouTube’s H.264 recommendations include 14 Mbps for 1080p30, while the listed AV1/H.265 recommendation for that resolution is 10 Mbps. If your local file is actually being recorded at 8 Mbps, use 8 Mbps in the storage formula, not 14 Mbps just because that rate appears in an ingest table. Conversely, if the local recording is 14 Mbps, calculate on 14. Codec, resolution and encoder choices affect the rate; the label “1080p” alone does not determine file size.
If you use OBS or another recorder, look at the recording output settings separately from the stream output settings. It is possible for them to match, but verify rather than infer it. Our OBS resolution and frame-rate guide can help with the video settings side of the decision; for storage, the value to carry into the calculation is still the local recording bitrate.
Worked estimates at common rates
The table applies the 30-day formula to several rates. Rows based on YouTube H.264 ingest settings are included as planning examples only. They are not a claim that every local recording at that resolution will have that size.
| Example rate | 30-day payload estimate | How to read it |
|---|---|---|
| 1 Mbps | 324 GB (about 302 GiB) | Baseline for scaling the calculation |
| 5 Mbps | 1.62 TB | Arithmetic at this constant local rate |
| 8 Mbps | 2.59 TB | YouTube H.264 720p30 ingest recommendation, used only as a proxy |
| 14 Mbps | 4.54 TB | YouTube H.264 1080p30 ingest recommendation, used only as a proxy |
| 17 Mbps | 5.51 TB | YouTube H.264 1080p60 ingest recommendation, used only as a proxy |
| 21 Mbps | 6.80 TB | YouTube H.264 1440p30 ingest recommendation, used only as a proxy |
| 42 Mbps | 13.61 TB | YouTube H.264 2160p30 ingest recommendation, used only as a proxy |
The arithmetic scales linearly under the constant-bitrate assumption. Double the local rate and the estimated payload doubles; halve the recording hours and it halves. The 5 Mbps row is simply 5 × 0.324 TB. It does not establish that 5 Mbps will give suitable quality for your material. For a Hindi bhajan stream with a mostly static image, your visual requirements may differ from a detailed news loop or moving study background, and the encoder’s actual settings should guide the choice.
A useful way to apply the table is to substitute your own value. If your encoder records at 6 Mbps, then 6 × 0.324 gives 1.944 TB for 30 days. Treat that as roughly 1.94 TB of payload before overhead, then decide how much extra space to keep free. If your measured output is variable bitrate, an observed file from a representative period may be a better guide than multiplying a nominal target rate.
What changes in a 31-day month?
The same recording rate running for 31 days takes 31/30 as much space as the 30-day estimate. In practice, multiply the 30-day number by about 1.033. The extra day is one twenty-fourth of a 30-day period, so it is a modest increase, but it matters when capacity is already close to full.
At 1 Mbps, 31 days works out to 334.8 GB decimal before overhead. At 8 Mbps, the estimate is about 2.68 TB; at 14 Mbps, about 4.69 TB. These remain payload estimates under constant bitrate, not guaranteed drive requirements. If your “month” has a different number of days or you only record during scheduled hours, use the actual number of hours instead: bitrate in Mbps × hours × 0.00045 gives decimal TB.
That hours-based form is also useful if a channel runs 24/7 but the archive is not needed continuously. For example, recording only the main programme hours changes the storage plan in direct proportion to those hours. Do not multiply by the full month if your recorder is set to save only selected segments.
Leave room for overhead and other files
The calculated amount is not the same as usable drive capacity. A formatted drive has slightly less available space than its advertised capacity, and the file container, recording process and other content consume additional room. Variable-bitrate files can also differ from an estimate based on an average or target setting. For this reason, treat the arithmetic as a floor for the expected payload and avoid choosing a drive whose advertised size merely matches it.
Before buying storage, write down the recording rate, the hours to retain, and whether the archive is one long file or many smaller files. Then compare the calculated payload with usable formatted capacity and leave practical free space for other files and a recording that runs longer than planned. No universal allowance applies to every workflow; a drive shared with source videos, thumbnails or exports needs more capacity than one dedicated to a single archive.
Also consider write performance and the role of the drive. Sustained writing at the actual recording bitrate is the relevant task; the source material does not establish one required drive type or rating. A large external HDD or SSD can be useful for a local archive, but it is not something YouTube requires. If the recording is your only copy, a second copy on separate storage protects against losing the archive if that drive fails. It does not replace checking that the file is growing and can be opened.
YouTube’s creator tips advise checking the integrity of local archive files and confirming that the file size is increasing. Follow the current live streaming tips while testing your process. If you record into separate chunks rather than a single file, add their sizes for the retention period and ensure the recorder has enough working room to finish a segment. A restart, a full drive or a broken output file can make an otherwise adequate capacity plan useless.
Do not confuse a network upload margin with extra disk capacity. YouTube’s streaming tips discuss leaving headroom for upload bandwidth; that concerns the connection carrying the live signal. It is not a percentage to add to the local recording estimate. Keep bandwidth planning and storage planning as separate checks.
Choose the recording approach around the archive you need
If you only need the playlist to keep playing for viewers, a local month-long recording may be unnecessary. If you need a dependable record, decide whether you need the whole broadcast, selected programme windows, or the original source files. Recording a continuous output captures what was actually sent, but it also creates a much larger file than retaining only the uploaded loop assets.
A practical test is to record a representative portion using the intended local settings, inspect its bitrate and file size, and extrapolate to the hours you intend to retain. That test can expose differences between the stream bitrate and local file rate, as well as whether the chosen quality is acceptable. Keep the assumptions written down so that you can update the estimate if you change resolution, codec or schedule.
If the recurring problem is keeping a loop live without leaving a computer running beside the recording task, StreamNeo can remove that specific always-on-computer burden: upload the video, provide the YouTube stream key, and the stream continues with your computer switched off. That solves the playback operation, not the separate question of whether you need a local archive or how much disk it takes.
For a playlist built from multiple files, check that the loop itself behaves as intended before deciding to retain a full broadcast. The FFmpeg playlist command guide addresses continuous playback from files; it does not change the storage calculation for an independently recorded month-long copy.
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 space does a 24/7 livestream use?
There is no single storage figure for a stream without the local recording bitrate and retention hours. At a constant local rate of 1 Mbps, a 30-day recording is about 324 GB decimal before overhead; multiply that base by your actual Mbps rate. If you mean only a playlist playing on YouTube, that playback does not by itself require you to keep a month-long local recording.
Will YouTube save a stream that runs for a month?
Do not rely on one uninterrupted month-long session being archived. YouTube says streams shorter than 12 hours can be automatically archived and warns that a stream exceeding 12 hours may not be captured. Its guidance recommends a local archive backup when you need a dependable copy, so check the current official archive guidance and verify your file.
Is YouTube’s stream bitrate the same as my recording size?
Not necessarily. The ingest bitrate is the rate sent to YouTube, while a local recording can use a different encoding setting or rate. Use the local recording bitrate when you know it; use YouTube’s ingest recommendation only as an explicitly labelled planning proxy when you do not.
How many GB per hour should I plan for?
At 1 Mbps, constant-bitrate payload is approximately 0.45 GB per hour in decimal units. Multiply 0.45 by your local recording bitrate in Mbps: at 8 Mbps, for instance, the estimate is about 3.6 GB per hour before overhead. Variable-bitrate recordings can depart from that estimate.