For a common 1080p30 live stream, start with YouTube’s recommended 14 Mbps when sending H.264, or 10 Mbps when sending AV1 or H.265. Those figures apply to the live feed going to YouTube, not automatically to the pre-recorded file stored on your computer.
A smaller source file can save disk space and upload time without reducing the bitrate of the live broadcast. Likewise, choosing a lower live-ingest bitrate does not automatically make the original file smaller or determine the size of every viewer’s playback stream.
Which thing are you trying to make smaller?
The phrase “best bitrate” can refer to three different things in an always-on channel:
- the bitrate used to encode the file saved on your computer or cloud storage
- the video bitrate sent continuously to YouTube during the live broadcast
- the bitrate YouTube uses for a viewer’s selected playback resolution
These values can be different. YouTube receives your live output and creates multiple versions for viewers. A person watching at a lower quality may receive a smaller playback stream, while another viewer may watch a higher-resolution version. That viewer-side delivery is not controlled simply by shrinking your original loop file.
For example, suppose you export a devotional video at 8 Mbps and save it locally. Your streaming software may still send the same content to YouTube at 14 Mbps as a 1080p30 H.264 live feed. The source file is smaller, but the live upload requirement has not fallen because of that export alone.
The reverse is also possible. You can keep a high-bitrate master file for editing while configuring the live encoder to send a lower-bitrate output. That may reduce outbound bandwidth, but it does not reduce the size of the master file on disk.
Before changing anything, identify the problem you are solving:
| Your actual problem | Setting to examine | What it changes |
|---|---|---|
| The loop occupies too much storage | Source-file bitrate, codec, resolution and duration | File size on disk |
| The broadband connection struggles overnight | Live video bitrate and output format | Upload demand during the broadcast |
| Viewers see buffering or quality changes | Live stability, stream health and YouTube’s delivered versions | Playback experience |
| The exported file takes too long to prepare | Export codec, preset and resolution | Encoding time and file size |
If you are building the channel for the first time, the practical distinction is covered in more detail by this guide to creating an always-on YouTube channel with pre-recorded videos. It helps to decide whether you need a local playout computer at all before spending time optimising files for it.
How bitrate and duration determine file size
Bitrate is the amount of data used for each second of media. It is usually written in bits per second, while file storage is measured in bytes. Since one byte contains eight bits, you divide the bitrate by eight when estimating the file size.
The basic estimate is:
file size in bytes = bitrate in bits per second × duration in seconds ÷ 8
For a quick storage estimate, you can use megabits and hours:
file size in gigabytes ≈ bitrate in Mbps × duration in hours × 0.45
That shortcut uses decimal gigabytes and describes the video stream alone. A complete file also contains audio, metadata and container overhead, so the result is an estimate rather than a promise about the final file size.
Duration matters just as much as bitrate. Halving the bitrate roughly halves the data used per second, but halving the duration also halves the file size. A 30-minute clip at a particular bitrate uses about half as much media data as a one-hour clip at the same bitrate.
This is why a modest reduction in bitrate can matter for an overnight loop. A single short bhajan may not be large enough to worry about, while a long collection of local news segments or study visuals can occupy substantial storage when kept as separate files.
The calculation applies to constant bitrate and average bitrate in slightly different ways. With constant bitrate, the stream is designed to use approximately the same number of bits per second. With variable bitrate, complex scenes receive more data and simple scenes receive less, so the average bitrate is the useful figure for estimating the final size.
Do not confuse the bitrate written in a media player’s information panel with the exact size of the complete file. A file may report separate video and audio rates, and the container adds a small amount of additional information around those streams.
Estimate the size per hour before exporting
YouTube’s live-ingest recommendation for 1080p30 H.264 is 14 Mbps. If you stored one hour of video at exactly that video bitrate, the arithmetic would be:
14 Mbps × 3,600 seconds ÷ 8 = 6,300 megabytes
That is approximately 6.3 GB of video data using decimal units, before adding audio and container overhead. The final file will therefore be a little larger than the simple video-only estimate.
The same calculation gives a useful comparison for other source-file choices:
| Average video bitrate | Approximate video data per hour | Approximate video data for 8 hours |
|---|---|---|
| 4 Mbps | 1.8 GB | 14.4 GB |
| 6 Mbps | 2.7 GB | 21.6 GB |
| 8 Mbps | 3.6 GB | 28.8 GB |
| 10 Mbps | 4.5 GB | 36 GB |
| 14 Mbps | 6.3 GB | 50.4 GB |
These are arithmetic estimates, not measured file sizes. Add the audio bitrate separately when you need a closer result. For example, 128 Kbps stereo audio contributes additional data over the hour, and the file also includes the MP4 or other container’s metadata. A video with a quiet, mostly static background may also be encoded efficiently at a lower average bitrate than footage with rapid movement, even when both use the same resolution.
For a 24/7 channel, multiply the hourly estimate by the total duration of the material you want to keep locally. If your playlist contains eight hours of source video at an average 6 Mbps video bitrate, the video portion is about 21.6 GB. That is not the same as saying the live broadcast needs only 6 Mbps: it describes the stored source material.
You can use the calculation before exporting rather than discovering the problem after a long render. Check the intended resolution, frame rate, video bitrate and audio bitrate in your encoder, then estimate the storage requirement for the complete loop.
A source file does not have to match the live output bitrate. It needs enough quality for the planned use and enough headroom to avoid visible damage after any later processing. If the file will only be played back and sent through a live encoder once, exporting a very large master may provide little practical benefit compared with a well-made delivery file.
Reduce the source-file size with a suitable export workflow
Start with the material you actually have. If the original is 720p, exporting it as 1080p does not create new detail. It can increase processing and storage demands without improving the picture. If your source is 1080p30, keep that resolution and frame rate unless there is a clear reason to change them.
For a straightforward file-based loop, H.264 in an MP4 container is often a practical compatibility choice. It is widely supported by editing and playback software, and it avoids making the playout process depend on a newer codec that your chosen software may not handle reliably. The best source export is the one your complete workflow can decode continuously, not merely the one with the smallest file.
A sensible workflow is:
- Keep an untouched master if you may edit the video again.
- Create a separate delivery copy at the actual output resolution and frame rate.
- Choose a measured average video bitrate rather than an unnecessarily large one.
- Use a suitable audio setting and remove audio if the content genuinely has no audio.
- Play the entire delivery file from beginning to end before adding it to the 24/7 schedule.
- Inspect difficult sections such as scrolling text, watermarks, smoke, confetti, water and fast camera movement.
Do not judge the export only from a still frame. A low bitrate can look acceptable on a static temple image and then break up around moving lamps, falling rain or a scrolling ticker. Watch the file at its intended viewing size and listen for audio problems as well.
If storage is the main constraint, test a lower source bitrate on a representative section first. Compare small text, faces, moving backgrounds and dark scenes. A lower bitrate is useful when the visual loss is acceptable, but it is not automatically better because the file is smaller.
If you are looping several files, consistent resolution and frame rate can make the playout stage simpler. Mixed formats may require extra conversion, and that conversion can introduce scaling, frame-rate changes or audio timing problems. If the stream goes out of sync, this guide to fixing audio out of sync when streaming pre-recorded video is a useful troubleshooting path.
A compressed source file also does not repair poor source quality. Re-encoding a file that already contains blocking, banding or ringing may preserve those defects or make them more obvious. If the original footage is important, keep a higher-quality master separately and use the smaller copy only for playout.
Choose live bandwidth settings separately
For the live feed, use YouTube’s live encoder guidance for the actual incoming resolution, frame rate and codec. YouTube’s current table recommends 14 Mbps for 1080p at 30 frames per second with H.264. For the same 1080p30 format using AV1 or H.265, it recommends 10 Mbps.
Those are live-ingest recommendations. They are not a special requirement for pre-recorded content, and YouTube does not publish a separate live bitrate table merely because the source is a loop or the broadcast runs continuously. A pre-recorded file becomes a live broadcast once your encoder sends its output to YouTube, so the incoming live format is what matters.
The table below shows the main comparison points from YouTube’s published live settings:
| Incoming format | AV1 or H.265 | H.264 |
|---|---|---|
| 1080p30 | 10 Mbps | 14 Mbps |
| 1080p60 | 12 Mbps | 17 Mbps |
| 1440p30 | 15 Mbps | 21 Mbps |
| 1440p60 | 24 Mbps | 34 Mbps |
| 2160p30 | 30 Mbps | 42 Mbps |
| 2160p60 | 35 Mbps | 50 Mbps |
| 720p30 | 6 Mbps | 8 Mbps |
| 720p60 | 6 Mbps | 8 Mbps |
Use the row for what you actually send, not what the original file could theoretically support. If your source is a 4K file but your live encoder outputs 1080p30 H.264, the 1080p30 H.264 row is the relevant starting point.
YouTube recommends CBR for live encoding and lists a two-second keyframe interval, with the interval not exceeding four seconds. It also lists RTMP or RTMPS, progressive scanning, square pixels, CABAC and Rec. 709 for SDR. Audio guidance includes AAC or MP3 at 128 Kbps for stereo, with AAC required for the listed 5.1 audio support over RTMP or RTMPS. Check the official live encoder settings and bitrate table before changing a production stream, because supported settings can change.
The upload connection must be able to send the selected live video and audio continuously. Run an upload speed test, then test with movement and audio similar to the real channel. YouTube specifically advises testing before going live and monitoring stream health and messages during the event. The official YouTube streaming tips are useful when checking the connection rather than guessing from a short successful test.
Do not invent a universal bandwidth margin and treat it as a YouTube rule. Your connection may also carry other traffic, and wireless links can behave differently at different times of day. Test the actual route and watch the health indicators during a long run.
If your home connection is unreliable, reducing the source-file size will not by itself solve the live upload problem. The live encoder still sends its configured output. For an India-based setup, investigate packet loss and route instability separately with this guide to troubleshooting YouTube Live packet loss on an Indian ISP.
Codec choice changes the trade-off
A codec can achieve similar visual quality at a different bitrate, but the bitrate number alone does not tell you whether the workflow is suitable. H.264 is familiar and broadly supported. AV1 and H.265 may offer better compression for some material, but they can require more processing and may not be supported by every part of your editing, playback or live-encoding chain.
YouTube lists H.264, H.265 and AV1 as live video options in its encoder guidance. If you select AV1 or H.265 for the live output, use the corresponding row in the live-ingest table rather than applying the H.264 number. If the software actually sends H.264, the AV1 or H.265 recommendation does not apply just because the source file was compressed with another codec.
The same separation applies to a file’s codec. You might store a source in H.265 to reduce disk usage, then decode it and send H.264 as the live output for compatibility. In that case, the file-size choice and the live-bandwidth choice are related by processing, but they are not the same setting.
Consider the full cost of a codec:
- storage required for the source files
- time needed to encode them
- processing required to decode them continuously
- compatibility with your playout software
- live output codec and bitrate
- recovery behaviour if a file or application fails overnight
For a small devotional or ambience channel, a slightly larger H.264 delivery file may be preferable if it plays reliably on the chosen computer. For a larger library, a more efficient codec may save storage, provided you test the complete path rather than assuming the file will decode smoothly.
Container overhead and long-run reliability
The MP4, MKV or another container is the wrapper that holds the video, audio, timing information and metadata. The container is not the main driver of file size; video and audio bitrate usually dominate. It does, however, mean that a simple bitrate calculation will not exactly match the final file shown by your operating system.
A container can also affect how easily software seeks, recovers and reads a file. For a long loop, avoid treating a file as ready merely because it opens once. Seek through it, play its beginning and end, and run it for long enough to expose audio drift or a damaged section.
Long-running channels have failure modes that are unrelated to the chosen bitrate. A playlist transition can stop a stream, a local disk can fill, an encoder can lose its output device, or a connection can drop. This guide to fixing a 24/7 stream that goes offline during playlist transitions deals with one of those operational problems directly.
If you use a computer, disable sleep and automatic restarts that would interrupt the encoder, while still applying security updates through a planned maintenance window. Keep enough free storage for temporary exports and logs. Test the exact files and settings you intend to use, not a short sample with easier content.
A cloud-based workflow can remove the need to leave your own computer running. StreamNeo is useful here when the specific pain is keeping a pre-recorded file playing and sending it to YouTube after you have switched off your local machine. It does not change YouTube’s live bitrate recommendations, and it does not make a source file smaller; it removes the need to operate the local playout computer continuously.
A practical bitrate decision for your channel
Use this order when setting up the stream:
- Choose the viewer-facing resolution and frame rate you can produce consistently.
- Choose the codec your live encoder and YouTube workflow support reliably.
- Select the matching YouTube live-ingest recommendation.
- Set CBR and the recommended keyframe interval.
- Confirm that the actual upload connection can sustain the live output.
- Export source files separately for sensible storage and playback.
- Test the full loop, including transitions, audio and overnight operation.
- Monitor stream health after the broadcast begins.
For a typical 1080p30 H.264 channel, the starting point is 14 Mbps live video. For 1080p30 AV1 or H.265, it is 10 Mbps. If you change resolution, frame rate or codec, change the live setting to match the new row rather than carrying over the old number.
For source files, calculate the storage requirement from the file’s own average bitrate and duration. If you need an eight-hour loop to fit on limited storage, reduce the source export bitrate only after checking the difficult scenes. Do not expect that reduction to lower the live upload requirement unless you separately configure a lower live output and confirm that the new live format is suitable.
YouTube also publishes separate file-upload recommendations. For example, its H.264 upload guidance gives different 1080p targets for standard and high frame rates. Those figures apply to uploaded videos, not the live-ingest table, so do not substitute the upload number for the 14 Mbps 1080p30 H.264 live recommendation. Check the official YouTube upload encoding guidance when preparing a file for the video library rather than a live 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
Is 14 Mbps the best bitrate for every pre-recorded 24/7 stream?
No. It is YouTube’s recommended live video bitrate for 1080p30 H.264. The appropriate figure changes with the live codec, resolution and frame rate, and it does not change merely because the source video was pre-recorded.
If I compress the source file, will my internet usage fall?
Not automatically. Compressing the stored file reduces disk space and may reduce the data needed to read that file, but the live encoder still sends its configured output bitrate to YouTube. Internet usage falls only if you separately lower the live output and the resulting format remains suitable.
Should I use the live bitrate when exporting the source video?
You can, but you do not have to. Exporting the source at a different average bitrate affects its stored size and visual quality; the live encoder then creates the outgoing format. Keep the source compatible with your playout software and test fast movement, text and dark scenes before using it in a continuous loop.
How do I know whether the bitrate is too high?
Look at storage, encoding time, upload capacity and stream health together. A source bitrate may be unnecessarily large if it uses storage without visible benefit, while a live bitrate is too demanding if the connection cannot sustain it. Test the complete setup and monitor YouTube’s stream messages rather than relying on a short successful preview.