Choose the highest resolution and frame rate your server can encode steadily and your outbound connection can sustain. For a common H.264 setup, YouTube recommends 14 Mbps for 1080p at 30 fps and 17 Mbps for 1080p at 60 fps.
Use constant bitrate, set keyframes every two seconds, prefer RTMPS when your encoder supports it, and leave around 20% upload headroom. For a stream that runs beyond 12 hours, keep a local recording if the complete footage matters because YouTube warns that a stream exceeding 12 hours may not be captured in its archive.
Choose resolution and frame rate
Resolution controls how much detail viewers can see. Frame rate controls how often the picture is updated. A higher setting can look better, but it also asks more of the server encoder and the network connection.
For a mostly static devotional loop, bhajan channel, rainfall scene, study screen or local information board, 1080p at 30 fps may be sufficient. For sports, moving camera footage, dance, traffic or other content where motion is important, 60 fps can make movement appear smoother. That does not make 60 fps automatically the better choice for every channel.
Start with the source material. If the video is 720p, sending it as 1080p does not create new detail. It can increase encoding and upload work without improving the original picture. Likewise, if the source contains little motion, a higher frame rate may add load without adding much that viewers can see.
A practical order is:
- Check the source video's native resolution and frame rate.
- Decide whether the content benefits from smoother motion.
- Select a setting the server can encode without sustained overload.
- Confirm that the connection can upload the selected stream with headroom.
YouTube recommends automatic resolution and frame-rate detection by default. Manual settings are available through a custom stream key with manual settings enabled. If you choose manually, make the decision from the actual server and content rather than selecting the largest number available.
| Use case | Sensible starting point | Main reason to change it |
|---|---|---|
| Static devotional or ambience loop | 720p30 or 1080p30 | Move up for more visible detail, or down if the connection is constrained |
| Study or information channel | 1080p30 | Small text may benefit from more resolution; check that it remains readable after YouTube processing |
| Music video with ordinary movement | 1080p30 | Use 60 fps only if smoother motion is valuable and the server can sustain it |
| Fast movement or camera footage | 1080p60 | Reduce frame rate if encoding load or upload capacity is not steady |
These are starting points, not guarantees of picture quality. YouTube's bitrate recommendation must match the exact codec, resolution and frame rate that the server sends.
If you are unsure whether viewers are seeing the intended loop, check the stream itself rather than relying only on the encoder process. The guide on how to check whether a YouTube Live stream is actually looping covers checks that are useful after the broadcast is live.
Match the bitrate to YouTube's recommendation
Bitrate is the amount of encoded video data sent each second. For this decision, use YouTube's live ingest recommendations, not advice intended for uploaded video files. The value also depends on whether the server sends H.264, H.265, or AV1.
YouTube's current recommended ingest values are:
| Ingest resolution and frame rate | AV1 or H.265 | H.264 |
|---|---|---|
| 360p at 30 fps | 3 Mbps | 4 Mbps |
| 480p at 30 fps | 3 Mbps | 4 Mbps |
| 720p at 30 fps | 6 Mbps | 8 Mbps |
| 720p at 60 fps | 6 Mbps | 8 Mbps |
| 1080p at 30 fps | 10 Mbps | 14 Mbps |
| 1080p at 60 fps | 12 Mbps | 17 Mbps |
| 1440p at 30 fps | 15 Mbps | 21 Mbps |
| 1440p at 60 fps | 24 Mbps | 34 Mbps |
| 2160p at 30 fps | 30 Mbps | 42 Mbps |
| 2160p at 60 fps | 35 Mbps | 50 Mbps |
For H.264, YouTube lists minimum ingest bitrates of 3 Mbps for 720p30, 3 Mbps for 720p60, 5 Mbps for 1080p30 and 6 Mbps for 1080p60. For AV1 or H.265, the corresponding minimums are 2 Mbps, 2 Mbps, 4 Mbps and 4 Mbps. A minimum is not the same as the recommended target. It may be useful when diagnosing a constrained setup, but it should not be treated as proof that the resulting picture will be suitable for your content.
For example, if your server sends H.264 at 1080p30, set the video bitrate to 14 Mbps. If it sends H.264 at 1080p60, use 17 Mbps. If you select H.264 at 720p30, the listed recommendation is 8 Mbps. Do not select the AV1 or H.265 number unless the encoder is actually sending that codec.
You can read the current values in YouTube's official live encoder settings. Check that page again when you change your encoder because recommendations and supported formats can change.
The table is not a promise that a particular stream will look good or remain connected. A source with fine text, smoke, leaves or fast movement can be harder to encode than a still image at the same resolution. The server may also have to decode, scale, loop or composite the source before it encodes the outgoing feed.
Configure CBR, keyframes and transport
Set the video rate control to constant bitrate, usually shown as CBR. With CBR, the encoder aims to send data at the configured rate rather than making large swings according to the complexity of each scene. That makes capacity planning more predictable for a continuous broadcast.
Set the keyframe interval to two seconds. YouTube recommends a two-second keyframe frequency and says not to exceed four seconds. A keyframe is a complete reference picture; other frames can describe changes from it. The interval affects how the stream can be decoded and how quickly playback can recover after a seek or interruption.
For a 30 fps stream, a two-second interval commonly corresponds to a keyframe interval of 60 frames. For 60 fps, it commonly corresponds to 120 frames. Some encoders ask for seconds, while others ask for a frame count. Use the form required by your encoder and confirm that the resulting interval is two seconds.
For SDR content, YouTube's advanced guidance includes square pixels, progressive scan, two B-frames, one reference frame, CABAC entropy coding, Rec. 709 colour and 8-bit depth. Not every encoder exposes each setting, so do not invent a different value simply because a field is available. Match the encoder's documented settings to YouTube's requirements.
For audio, YouTube lists AAC or MP3 as supported choices and gives stereo audio at 128 Kbps and 44.1 kHz in its encoder guidance. Keep audio settings stable throughout the broadcast. A devotional channel with a silent section should still send a valid audio stream if the encoder expects one, rather than changing formats mid-stream.
Use RTMPS when the server encoder supports it. RTMPS is RTMP over a TLS or SSL connection, which encrypts the connection between the encoder and YouTube. Get the RTMPS server URL and stream key from Live Control Room. You can review the setup process in YouTube's official live streaming setup guidance.
Treat the stream key as a credential. Do not place it in a public script, screenshot, tutorial, shared document or log file. If it is exposed, replace it through YouTube rather than continuing to use a key that other people may have copied.
Measure upload capacity and leave headroom
The relevant network figure is sustained outbound capacity from the server. Download speed does not establish how much data the server can upload to YouTube. A provider may advertise a fast connection while the route available to your server, or the capacity available at busy times, is different.
YouTube recommends leaving 20% headroom and counting primary and backup streams in the total. The calculation is straightforward:
required upload capacity = total stream bitrate ÷ 0.8
For one H.264 stream at 14 Mbps, that is 17.5 Mbps of sustained available upload capacity. For one H.264 stream at 17 Mbps, it is about 21.25 Mbps. These figures are arithmetic applications of the 20% headroom recommendation, not separate bitrate recommendations from YouTube.
If you send a second stream for failover, add its bitrate before applying the margin. For example, a primary stream at 14 Mbps and a backup stream at 8 Mbps have a combined video rate of 22 Mbps. Planning around the primary stream alone would ignore the bandwidth used by the backup.
Also account for audio, protocol overhead and any other process using the same connection. The 20% calculation is a planning margin, not a guarantee that a connection will remain stable. Short speed-test peaks are less useful than a sustained test from the server's actual network path.
Run an upload test from the server that will broadcast. If the test is performed from your home broadband connection while the live stream will run from a data-centre server, it does not answer the relevant question. Repeat the test at times when the connection is likely to be busy, and observe the live stream's health during a test broadcast.
A lower resolution can be the correct decision when the connection is limited. Moving from H.264 1080p30 at 14 Mbps to H.264 720p30 at 8 Mbps reduces the planned video rate. It does not make a weak connection reliable by itself, but it gives the network less work to carry. If you are investigating network-related loss, the guide on how to fix dropped frames in a 24/7 FFmpeg YouTube stream is relevant to the diagnosis.
Test that the server can encode steadily
A server can have enough upload capacity and still fail because its encoder cannot maintain the selected frame rate. Watch the encoder's actual output rather than assuming that a high CPU count, GPU label or advertised server specification proves anything about your particular file.
The test should use the same source, resolution, frame rate, codec and filters as the planned broadcast. If the normal channel loops a long video, test that loop. If it overlays a clock, logo or local notices, include those elements. Scaling a 4K source to 1080p, decoding several files or adding text can change the load substantially.
During the test, look for:
- Frames being encoded late or dropped by the encoder.
- A growing difference between the intended and actual output frame rate.
- CPU or GPU use remaining close to its limit for long periods.
- Memory use increasing rather than settling.
- Audio drift, silence, clipping or repeated audio reconnects.
- The process stopping when the source reaches its end.
- Network retries or an ingest connection that repeatedly reconnects.
YouTube advises checking the Live Control Room preview and monitoring audio and video. It also recommends testing failover by stopping the primary encoder or disconnecting its network, and checking that local archive files are growing. Apply those checks to the deployed configuration before relying on it overnight.
If the source is a single video, a player that reaches the end may stop the encoder unless looping is explicitly configured. That is separate from bitrate. The article on how to repeat a video in OBS without restarting the YouTube stream explains the distinction between repeating the content and ending the broadcast.
Reduce the workload if the server cannot sustain the test. You might lower resolution, lower frame rate, remove an unnecessary filter or select a codec that the server handles efficiently. Choose the setting that continues to produce valid frames for the whole test, not the setting that looks strongest for the first few minutes.
If the main difficulty is keeping a computer or server running through the night, StreamNeo removes the need to keep your own computer switched on by taking an uploaded video, your YouTube stream key and the continuous broadcast as one managed workflow. You still need to prepare the source and check YouTube's current requirements, but the local machine is no longer the part that must remain running.
Plan for a 24/7 recording and archive
A live broadcast and its replay are separate concerns. YouTube may create an archive for a live stream, but its guidance warns that a stream exceeding 12 hours may not be captured at all. It also says DVR rewind may be limited or unavailable for streams longer than 12 hours.
Do not design a 24/7 channel on the assumption that viewers will always receive a complete replay. If retaining the full footage matters, record locally or use another recording arrangement that you control. Confirm that the recording file is growing during the test, and check where it is stored, how much space remains and what happens when the disk fills.
A local recording also needs its own plan. The recording may use a different bitrate from the outgoing stream, and writing it continuously can add storage and processing work. If the server is already close to its CPU, disk or memory limit, recording can affect the live encoder even when the network is healthy.
Consider whether one very long file is practical. A recording process that creates manageable segments may be easier to inspect and preserve than one file that grows indefinitely, but the exact method depends on the encoder and your retention needs. Test the complete process before the channel is unattended.
You should also distinguish a YouTube archive problem from a dropped connection. A stream that disconnects and reconnects may produce separate live events or incomplete sections. A stream that remains connected for more than 12 hours may still not be captured in full. Neither situation should be described to viewers as a guaranteed complete replay.
For the current archive and DVR behaviour, read YouTube's official live stream archive guidance. Check the official page before changing an important long-running channel because YouTube may update the way these features work.
Put the settings into an operating checklist
Once you have selected the profile, write it down rather than relying on memory. A useful record includes the source format, output resolution, frame rate, codec, video bitrate, audio format, keyframe interval, transport URL, stream-key location and the server's measured sustained upload capacity.
For a common H.264 profile, the record might say: 1920 by 1080, 30 fps, CBR at 14 Mbps, two-second keyframes, AAC stereo at 128 Kbps and RTMPS. That is a configuration example, not a recommendation for every channel. A 720p30 profile at 8 Mbps may be the more appropriate starting point when the source and connection do not support 1080p30 comfortably.
Before the first overnight run, check the following:
- The server sends the codec for which you selected the bitrate.
- The output resolution and frame rate match the intended profile.
- CBR is enabled and the keyframe interval is two seconds.
- The server's sustained outbound capacity leaves the recommended margin.
- Any backup stream is included in the capacity calculation.
- The source loops without ending the encoder process.
- The Live Control Room preview shows usable audio and video.
- Local recording is enabled if preserving the broadcast matters.
- The recording file is growing and the storage plan is understood.
- The stream key is private and can be replaced if exposed.
- A failover test has been completed rather than assumed.
If you change the source, add overlays, move to a different server or alter the network plan, repeat the relevant tests. A setting that worked for a static 720p devotional loop is not automatically suitable for a 1080p60 news camera feed.
For channels that need another delivery arrangement, YouTube-only operation may not match the requirement. The article on 24/7 YouTube streaming service comparisons can help you compare operating features, while still requiring you to verify current vendor details and YouTube requirements before committing.
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 enough for a 1080p YouTube stream?
It is YouTube's listed H.264 recommendation for 1080p at 30 fps. It is not a guarantee that every connection, encoder or type of footage will remain stable, so test the actual server and leave upload headroom.
Should I use 30 fps or 60 fps for a 24/7 channel?
Use 30 fps when the source and content do not need smoother motion, especially if reducing load helps the server and connection remain steady. Choose 60 fps only when the content benefits from it and the server can encode and upload the higher-rate profile consistently.
Can I run a 24/7 stream at the minimum bitrate?
YouTube publishes minimum ingest values for some resolutions and codecs, but those are not the same as its recommended targets. Treat them as troubleshooting information and test the resulting picture and stream health before using the profile continuously.
Will YouTube save the complete 24/7 broadcast?
YouTube warns that a stream exceeding 12 hours may not be captured in its archive, and DVR rewind may be limited or unavailable for longer streams. Keep a local recording if retaining the complete broadcast is important, and do not promise viewers a full replay.