For OBS encoder settings for a non-stop YouTube loop stream, use CBR rate control and a two-second keyframe interval. Then choose the bitrate that matches your codec, resolution and frame rate, rather than copying a number without checking what your connection can sustain.
YouTube's bitrate table is an ingest recommendation, not a required home upload speed and not a guarantee of stability. A good long-running setup is the highest-quality mode your computer and connection can maintain continuously, with upload capacity left over for normal network variation.
Start with the stream's output mode
Before changing individual encoder fields, decide what the stream is meant to deliver. A devotional video with a mostly static background, a lofi station with gentle movement, a local news loop and a channel showing fast sports footage do not place exactly the same demands on the encoder. Your source, audience, computer and internet connection all matter.
For a loop stream, begin with these choices:
| Setting | Practical starting point | Why it matters |
|---|---|---|
| Transport | RTMPS | YouTube recommends RTMPS for Live broadcasts. |
| Codec | H.264, unless your complete setup supports another listed codec | It is widely supported and has a clear YouTube bitrate table. |
| Resolution | Match the source where possible | Scaling can add work and may not improve a low-resolution file. |
| Frame rate | Match the source and motion | A 30 fps source does not gain useful detail merely by being sent at 60 fps. |
| Rate control | CBR | This keeps the outgoing bitrate comparatively predictable. |
| Keyframe interval | 2 seconds | This follows YouTube's recommendation. |
| Audio | Stereo AAC or MP3, using the audio settings supported by your encoder | Audio must be tested as part of the complete broadcast. |
YouTube lists H.264, H.265/HEVC and AV1 for RTMP and RTMPS ingestion. The correct choice is the codec that your OBS encoder and YouTube configuration can use reliably together. Do not select a newer codec simply because it appears in a menu. Check the resulting image, CPU or GPU load, dropped frames and stream health during a realistic test.
For the transport, YouTube describes RTMPS as encrypting the stream to and through Google's servers. You can check the current transport and encoder guidance in YouTube's live encoder settings documentation. In YouTube Live Control Room, create or select the event, then copy the stream URL and stream key into OBS. Treat the key as a credential rather than as ordinary text, and reset it in YouTube Studio if it is exposed.
The source also affects whether your loop looks clean. If the original file is 1280 by 720 at 30 fps, sending it as 1920 by 1080 at 60 fps asks OBS to create pixels and frames that were not present in the source. That can increase work without giving viewers a more detailed picture. A source recorded at 1080p60 has a different case: preserving that mode may be worthwhile if the connection and computer can sustain it.
If you are still deciding how the video should repeat, first compare the approaches in how to loop a video on YouTube Live. Encoder settings cannot correct a loop that stops, changes scene unexpectedly or loses its audio at the join.
Set rate control to CBR
In OBS, open the output settings for the stream and look for Rate Control. For an RTMP or RTMPS feed to YouTube, set it to CBR, meaning constant bitrate. CBR does not mean that your broadband connection is constant, nor does it make dropped frames impossible. It tells the encoder to aim for a steady outgoing video rate instead of making large changes according to the complexity of each scene.
That behaviour suits a continuous broadcast. A mostly still prayer image may need less data to look acceptable than a scene with rain, leaves, text movement or several camera changes, but the stream still has to fit the ingest plan. CBR gives you a predictable target for calculating upload headroom and checking the network over time.
Do not confuse CBR with image quality by itself. A low CBR target can produce blockiness in moving footage, while a high target can overwhelm a limited upload connection. The selected resolution, frame rate, codec and content all remain relevant. You are choosing a complete mode, not just filling in one box.
OBS's guidance also supports leaving defaults alone unless you have a reason to change them. Start with the normal encoder controls, then change only settings that relate to your chosen YouTube mode or a problem you can observe. A complicated collection of custom options makes it harder to identify whether a failure comes from the encoder, the network, the source or the platform.
You must also choose between software and hardware encoding where OBS offers both. Modern hardware encoders can reduce CPU work, which may help a computer that is decoding a large file, running several sources or recording locally at the same time. However, hardware quality varies by generation and implementation. Older hardware may produce a different image at the same bitrate than a software encoder, and a lower CPU reading does not automatically mean better output.
Compare the options on the machine that will actually run overnight. Look at sustained stability at the target resolution and frame rate, CPU versus GPU load, picture quality at the chosen bitrate, codec support and whether OBS reports rendering or encoding problems. There is no universal encoder winner for every computer.
Set the keyframe interval to two seconds
Set the keyframe interval to 2 seconds. YouTube's documented recommendation is “Keyframe frequency: Recommended 2 seconds Do not exceed 4 seconds.” This is a platform ingest instruction, not a promise that the stream will remain connected.
A keyframe is a self-contained video frame. Other frames can refer to information around it, so keyframes help the receiving service begin decoding cleanly and provide regular points for recovery and stream handling. If the interval is too long, the platform may have fewer convenient points at which to process or join the video. If it is set to two seconds, the stream follows YouTube's recommended frequency for this type of feed.
In OBS, the field may appear as Keyframe Interval under the streaming output settings. Enter 2, normally interpreted as two seconds. Some encoder interfaces expose related controls or use different wording, so confirm that you are changing the interval rather than a separate frame or reference setting.
Do not set a longer interval because the loop is simple, and do not assume a shorter interval will solve a poor connection. Keyframes add their own data and are only one part of the stream. If the broadcast has connection drops, inspect upload capacity, network behaviour, encoder load and YouTube's health indicators rather than changing this field at random.
YouTube also lists advanced picture guidance such as progressive scan, square pixels, two B-frames, one reference frame, CABAC and Rec. 709 for SDR. Exact control names vary between OBS encoders. Treat those values as a compatibility reference, not as a reason to expose every advanced setting before the basic broadcast has been tested.
Choose bitrate from YouTube's table
Select the row that matches three things: the codec, the output resolution and the frame rate. YouTube's current table distinguishes recommended values from minimum values, so do not read a minimum as the target you should use for every programme.
For H.264, the research guidance lists these recommended video bitrates:
| H.264 output | YouTube recommended video bitrate |
|---|---|
| 1080p at 60 fps | 17 Mbps |
| 1080p at 30 fps | 14 Mbps |
| 720p at 60 fps | 8 Mbps |
| 720p at 30 fps | 8 Mbps |
These figures are published by YouTube for ingestion and should be read alongside the rest of the table for your chosen codec and mode. They do not mean that a home connection with exactly the same nominal upload speed is suitable. Video is not the whole network, and an advertised connection rate may not describe the sustained upload available to OBS at the time you stream.
For example, if you have a 1080p30 H.264 source, start by examining YouTube's 14 Mbps recommendation. If your connection cannot maintain that video rate while leaving reasonable room for other traffic, a stable 720p mode may be more sensible than an unstable 1080p mode. That is a practical quality trade-off, not a claim that one resolution is always better.
Frame rate should follow the source and the programme. A slow-moving bhajan visual or study timer may not need 60 fps. A fast-moving scene may look better at 60 fps if the source was produced that way and the complete system can sustain it. Choosing 60 fps for a 30 fps file increases the target requirements without restoring motion that the source never contained.
Codec choice changes the table you need to use. Do not take the H.264 figure and apply it to HEVC or AV1 without checking YouTube's current codec-specific guidance. Also confirm that the selected encoder is producing the codec you think it is producing. A menu label, a hardware encoder name and the actual stream configuration are not always identical.
Audio has its own bitrate and sample-rate settings. YouTube's guidance lists stereo audio at 44.1 kHz and 128 kbps, with AAC or MP3 supported for RTMP and RTMPS. Use settings your OBS encoder exposes and listen to the result. A silent or distorted loop can make an otherwise healthy video feed unusable, which is why a separate YouTube RTMP no-sound troubleshooting guide is useful when the picture is present but the audio is not.
Leave upload headroom
The YouTube recommendation is not your required broadband package. It is a target for the stream arriving at YouTube. Your connection must carry that traffic continuously, plus audio, protocol overhead, other devices, background uploads and the normal variation that occurs on a shared or wireless network.
YouTube advises keeping the total stream bitrate within available upload capacity and leaving 20% room. Use that as planning headroom, not as a guarantee. If the selected video and audio targets already consume nearly all of the sustained upload you can measure, the setup has little tolerance for a cloud backup, a phone update or a busy evening connection.
Run a speed test from the same location and, where possible, over the same connection that OBS will use. A speed test is a snapshot, not proof of an overnight result. Repeat it at a time representative of the planned broadcast and observe whether the upload rate changes. Wired networking may make the computer's connection more consistent, but it does not remove congestion or an unreliable service from the route.
Suppose your measured upload is comfortable for a 720p30 target but not for the recommended 1080p30 target. Choose the lower mode or improve the connection before increasing the bitrate. Do not use the YouTube recommendation as a reason to force a number your network cannot hold. YouTube's streaming tips also emphasise testing and monitoring rather than relying on a single figure.
Keep other traffic away from the streaming computer during the test. Pause large uploads, avoid changing the source file while it is being read, and check whether the router is serving several people. For a shop, prayer hall or small office, ask what else uses the connection after closing time. A quiet afternoon test may not represent the period when the rest of the building starts using the network.
Headroom must cover more than speed. If OBS is decoding a high-resolution file, scaling it, encoding it and recording a local copy, the computer may become the limiting factor even when upload is plentiful. If the computer remains idle but OBS reports dropped network frames, examine the connection. If it reports encoding lag, examine the encoder and scene workload. The symptom should determine the next change.
Test a full realistic broadcast
Do not test only the first minute of the loop. Run the complete path from source file to OBS to YouTube preview, including the point where the video returns to its beginning. A loop that looks fine at launch can reveal a missing audio source, a transition, a brief black frame or a source reload at the join.
In YouTube Live Control Room, create or select the event, enter the stream URL and key in OBS, and inspect the preview before making the event public. Keep the key private. If someone else has had access to it, reset it through YouTube Studio rather than assuming that changing the OBS profile is enough.
Make the test resemble the intended broadcast:
- Use the same resolution, frame rate, codec, CBR target and keyframe interval.
- Use the actual loop, including its return to the beginning.
- Keep the planned audio track enabled and listen for silence, clipping or a delayed restart.
- Leave the source running long enough to expose changes in computer load and network conditions.
- Watch OBS statistics and YouTube's stream health while the test is running.
- Check what happens when the connection briefly changes, without treating a forced failure as proof that automatic recovery will always work.
Record locally if the programme matters. YouTube says that streams exceeding 12 hours may not be captured as a complete archive, and DVR may be limited or unavailable for streams longer than 12 hours. The outgoing broadcast and the saved replay are separate expectations. If viewers need to rewind or you need to retain the programme, consider local recording and whether shorter, separately archived sessions fit the purpose better.
For a machine that cannot be left on, StreamNeo removes the specific burden of keeping OBS, the source file and the streaming computer running continuously: upload the video, connect the YouTube stream key, and let the broadcast continue while your computer is switched off. That does not remove the need to choose a suitable source, protect the key or check YouTube's current policies.
A long test is also the right time to verify practical recovery steps. Know where the OBS profile is saved, how to stop and restart the event, where the stream key is managed and who can act if the channel owner is unavailable. Write these steps down for a family member, shop assistant or volunteer rather than relying on memory during a night-time interruption.
Monitor stream health
Once the broadcast is live, do not judge it only by whether the YouTube watch page opens. OBS and YouTube show different parts of the path. OBS can reveal encoding overload, rendering problems and dropped frames. YouTube's health indicator can reveal whether the incoming feed is arriving as expected at the platform.
Check at the start, after the first loop return and periodically during the intended running period. For an overnight channel, review the result in the morning. Note the time of any problem and what the statistics showed then. A pattern of network drops points towards the connection; rising encoding lag points towards the computer or scene; healthy input with a silent programme points towards audio or source handling.
Avoid making several changes at once. If you reduce resolution, change codec, replace the encoder and alter bitrate together, you will not know which change helped. Change one material variable, run another representative test and compare the evidence.
A stable-looking dashboard does not promise a complete archive or uninterrupted viewer experience. YouTube may limit DVR on long streams, and an event that runs for more than 12 hours may not be fully saved. Keep a local copy when retention matters, and explain to viewers if the channel is intended to be live rather than a permanent replay.
If your concern is recovery after a crash rather than the initial encoder setup, see how to restart a YouTube lofi stream automatically after a crash. If the problem is electrical power, the guide to keeping an internet radio stream playing during a power outage addresses a different part of the chain. Neither topic changes the need for CBR, a two-second keyframe interval and a bitrate your connection can sustain.
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 CBR required for a YouTube loop stream?
YouTube recommends CBR for RTMP and RTMPS ingestion, so use it as the starting point in OBS. It makes the target bitrate more predictable, but it cannot compensate for insufficient upload capacity, an overloaded encoder or a source that fails at the loop point.
What bitrate should I use for 1080p YouTube Live?
Use the row for your codec and frame rate in YouTube's current encoder table. For H.264, YouTube lists 14 Mbps as the recommended video bitrate for 1080p30 and 17 Mbps for 1080p60, but those are ingest recommendations rather than required home upload speeds. Choose a mode that leaves upload headroom and remains stable in a realistic test.
Should the keyframe interval be two or four seconds?
Set it to two seconds because that is YouTube's recommendation. YouTube says not to exceed four seconds, so four seconds is a maximum rather than the preferred starting value.
Will YouTube save a 24-hour loop as a replay?
Do not assume it will. YouTube says streams exceeding 12 hours may not be captured at all, and DVR may be limited or unavailable beyond that duration. Keep a local recording if the programme must be retained, and plan viewer rewind separately from the continuous outgoing feed.