For a mostly static event replay, start with 1080p30, CBR, a 2-second keyframe interval, RTMPS and normal latency. Use the bitrate recommended for the codec you select only when your stable upload connection can sustain it.
Test the complete replay loop before going public, including audio, reconnects and loop joins. Do not rely on one 24-hour YouTube broadcast to preserve a complete archive: YouTube says a stream longer than 12 hours may not be captured, and DVR rewind can be limited or unavailable beyond 12 hours.
Choose a sensible baseline output profile
OBS has two resolution settings that are easy to confuse. The base canvas is the workspace in which you arrange sources. The output, or scaled, resolution is what OBS sends to YouTube. They can match, but they do not have to.
For a replay that was produced in Full HD, begin with:
| Setting | Starting choice | When to change it |
|---|---|---|
| Base canvas | Match the source, usually 1920×1080 | Change it when your sources need a different working layout |
| Output resolution | 1920×1080 | Use 1280×720 when the source or connection cannot support Full HD reliably |
| Frame rate | 30 fps | Use 60 fps when the source has motion that benefits from it and upload capacity is stable |
| Aspect ratio | Keep the source ratio | Correct the source or layout rather than stretching it |
| Audio | AAC stereo, 44.1 kHz, 128 kbps | Adjust only when your production or YouTube's current guidance requires it |
A static replay does not automatically need 60 fps. A devotional programme with still artwork, a conference recording with occasional speaker movement, or a property tour can often be presented comfortably at 30 fps. A sports replay, dance performance or event with quick camera movement may look better at 60 fps, but the higher frame rate also increases the amount of data you must send consistently.
Do not upscale a 720p source to 1080p expecting it to gain detail. You would be asking the encoder and connection to carry a larger frame without adding information to the image. Keep the original aspect ratio and watch for cropped edges, stretched people or black bars before you spend time tuning bitrate.
If the source is a long video file, make sure its loop point is deliberate. A fade, title card or a short piece of silence may be useful between programme segments. An accidental flash, audio click or abrupt cut becomes more noticeable when viewers encounter it every time the loop returns.
For examples of the operational issues around a long prerecorded source, see this guide to turning real-estate tour videos into a continuous YouTube live stream. The subject is different, but the questions about source preparation and unattended playback are much the same.
Set CBR and a 2-second keyframe interval
In OBS, open Settings, then Output, and select the streaming output mode. Choose constant bitrate, usually shown as CBR. A constant rate does not make every scene identical, but it gives the ingest connection a predictable target instead of allowing complex scenes to create sudden bursts.
Set the keyframe interval to 2 seconds. YouTube's encoder guidance recommends 2 seconds and says not to exceed 4 seconds. A keyframe is a complete reference image from which later frames can be decoded. Regular keyframes help the platform and viewers join or recover the stream without waiting through an unnecessarily long chain of dependent frames.
Do not compensate for an unstable connection by changing the keyframe interval to an unusual value. First check whether the chosen bitrate is beyond the reliable capacity of the upload connection. If the connection still drops frames at a sustainable bitrate, investigate the network path, Wi-Fi, other traffic and the selected ingest server.
Your encoder preset and profile depend on the hardware available in OBS. For a long unattended broadcast, a setting that your computer can maintain continuously is more useful than a demanding preset that produces a slightly smaller file or a marginally cleaner image. Watch CPU or GPU load during a representative test rather than assuming that a short preview proves the system is ready for an overnight run.
Audio deserves its own check. YouTube documents AAC or MP3 for RTMP and RTMPS, with stereo guidance that includes 44.1 kHz and 128 kbps. Listen at the beginning, middle and loop join. A replay can appear visually healthy while its audio is silent, delayed, distorted or missing after a scene changes.
Select bitrate by codec and upload capacity
There is no single best bitrate for a 24/7 replay. The correct target depends on the output resolution, frame rate, codec and the stable upload capacity available to OBS.
YouTube's current encoder table gives these recommended ingestion bitrates:
| Output | AV1 or H.265 recommended | H.264 recommended |
|---|---|---|
| 1080p30 | 10 Mbps | 14 Mbps |
| 1080p60 | 12 Mbps | 17 Mbps |
| 720p30 | 6 Mbps | 8 Mbps |
| 720p60 | 6 Mbps | 8 Mbps |
The same table lists minimum rates of 4 Mbps for AV1 or H.265 at 1080p30, compared with 5 Mbps for H.264, and 4 Mbps compared with 6 Mbps at 1080p60. These are platform guidance figures, not a promise that a particular source will look good or that your connection will remain stable.
Use the recommendation for the codec OBS is actually sending. H.264 is widely supported and is often the straightforward choice when your hardware encoder or workflow is familiar with it. YouTube also documents H.265, or HEVC, and AV1, but their availability depends on your encoder, graphics hardware and current software support. For HDR, YouTube recommends H.265 over RTMP or RTMPS and notes that AV1 is not supported for HDR. Check YouTube's encoder settings and bitrates guidance before choosing a less familiar codec.
Then compare that target with your connection, not merely with a speed-test result. A connection that briefly reaches a high upload speed may still be unsuitable if it varies, shares capacity with other users or loses packets overnight. OBS describes dropped frames as a sign that the connection to the remote server is unstable or cannot keep up with the set bitrate. Its troubleshooting guidance uses 75% of total upload as a starting point, but that is a troubleshooting rule of thumb rather than a universal guarantee.
For example, if your measured upload is only just above the H.264 recommendation for 1080p30, moving to 720p30 may be the more reliable decision. A steady 720p broadcast is usually easier to watch than a Full HD stream that repeatedly buffers or disconnects. If the upload is shared with a video call, cloud backup or several household users, leave more practical headroom rather than treating the entire connection as available to OBS.
Do not lower bitrate while keeping an ambitious resolution and frame rate simply because the number fits in the settings box. You may get a soft or blocky image without solving the underlying instability. Change one variable at a time, test it, and record the result.
Configure RTMPS and normal latency
Choose RTMPS when it is available for the YouTube destination. YouTube recommends RTMPS because the stream data is encrypted into and through Google's servers. In OBS, select YouTube as the service or enter the current YouTube server details supplied by YouTube Studio, then paste the stream key carefully.
Treat the stream key as a credential. Do not publish it in a screenshot, paste it into a public document or reuse it in a workflow where many people can see it. If you think it has been exposed, replace it in YouTube Studio and update OBS before the next test.
Normal latency is the sensible starting point for an unattended replay. It gives YouTube more room to buffer playback than a lower-latency mode, which matters when nobody is available to react to a brief network variation. Lower latency can be useful for a live discussion or event where viewers need to interact quickly, but that is not usually the priority for a prerecorded loop.
Ultra-low latency has additional trade-offs. YouTube says that it excludes resolutions above 1080p and does not support closed captions. Lower latency can also make buffering more visible when the viewer's connection or your ingest path is inconsistent. Review the current YouTube guidance on latency and live broadcast controls before selecting it for a particular event.
Enable DVR if viewers should be able to pause or rewind during the live broadcast, but regard it as a viewing feature rather than an archive plan. Automatic start and stop also need thought. Auto-start can begin the broadcast when OBS connects, while auto-stop can end it when the source stops. For a looping file, a brief interruption or failed reconnect can produce a result that is different from what you intended, so test the exact handoff.
Use an unlisted event for testing. Confirm the visibility, audience declaration, title and description in YouTube Studio before changing the real event to public. Account options and interface labels can change, so check the current controls rather than relying on an old OBS screenshot.
Test the complete replay loop
A short test of a static scene is not enough. The test should resemble the broadcast you plan to run, including the real source, audio, output settings and network path.
Start an unlisted broadcast and check it from a separate device or network. Watching only the OBS preview can hide problems between OBS and YouTube. On the separate device, inspect:
- whether the video begins at the expected resolution and frame rate
- whether speech, music and programme audio remain continuous
- whether the first and last frames of the source join cleanly
- whether titles, lower thirds and captions remain inside the visible area
- whether playback buffers or quality changes during complex scenes
- whether the stream reconnects after a brief network interruption
If the replay contains a long event file, test near the most demanding sections rather than only the opening title card. A quiet slide may use little data, while a fast montage, confetti shot or detailed crowd scene can expose encoder and upload limits.
Test the loop itself. Let the source reach its end and return to its beginning while you watch both the local output and the YouTube playback. Listen for a gap, click or duplicate audio. Check whether OBS continues to run, whether the scene changes as expected and whether YouTube reports a healthy incoming signal after the transition.
Also test the failure that matters most for an unattended broadcast. Temporarily disconnect the network if you can do so safely, restore it, and observe whether OBS reconnects. A reconnection test is not proof that every interruption will recover, but it reveals whether your selected settings and local workflow behave as expected.
If the computer must remain on for the broadcast, prevent sleep and automatic updates from interrupting it. Check power, cooling and storage. A local OBS recording can also be useful during this test because it lets you compare what left the computer with what YouTube delivered.
A cloud workflow removes the need to leave your own computer encoding all night. For that specific problem, StreamNeo lets you upload the replay once, connect it to your YouTube stream key and have the broadcast run while your computer is switched off, with automatic monitoring and restart if the stream drops.
For a longer discussion of moving an existing stream away from a personal computer, read how to move a 24/7 stream off your own PC without going dark. The same principle applies whether the source is an event replay, a music loop or a channel schedule.
Monitor YouTube stream health
During the test and the first public run, keep YouTube Studio's Live Control Room open on a separate device where possible. Look at the stream health messages, not just the fact that OBS says it is connected.
A healthy connection should not be accumulating dropped frames. If OBS reports dropped frames, first treat the problem as a capacity or stability issue. Lower the bitrate to a level the connection can sustain, check whether another device is using the upload, and consider whether a wired connection or different network path is more stable. Do not immediately increase resolution or switch codecs in the middle of a public event without testing.
Separate network problems from encoder problems. If OBS shows high CPU or GPU load, frames may be delayed locally even when the connection is fine. If OBS is encoding normally but reports dropped network frames, the connection or ingest path deserves attention. YouTube's diagnostic messages can help identify whether the incoming signal is missing, unstable or below the selected quality.
Watch the actual viewer playback as well. A green status indicator does not tell you whether your audio is too quiet, the source is cropped or the loop has an unwanted pause. A viewer on a different connection may see buffering that does not appear on the computer running OBS. This is why a separate monitoring device should be part of the operating plan, not an emergency measure.
For an unattended channel, alerts are useful only when they reach someone who can act. Decide who will receive a notification, what counts as an urgent problem and what they will do first. The practical approach to monitoring a 24/7 stream with alerts that actually reach you is more valuable than collecting a dashboard that nobody checks.
Plan for the archive and DVR limits
The most important limitation for a 24/7 event replay is not an OBS checkbox. It is what YouTube may retain after a long live broadcast.
YouTube Help says that streams under 12 hours can be automatically archived, but warns that if a stream exceeds 12 hours, it may not be captured at all. YouTube also says DVR rewind may be limited or unavailable beyond 12 hours. That means a continuous 24-hour event should not be treated as a guaranteed 24-hour replay recording, even if the live picture looked healthy throughout.
If the archive matters, use shorter broadcast segments below the 12-hour boundary and confirm the current behaviour in YouTube's official archive live streams guidance. Segmenting adds operational work: you need a handoff plan, new event settings or a deliberate restart, and a way to tell viewers what happened. It may nevertheless be preferable to discovering after the event that the single long broadcast is not available as a complete replay.
Keep a local recording of the source or the outgoing programme whenever the replay is important. A local file does not guarantee that the YouTube upload will be complete, but it gives you a separate copy to edit, upload or use to investigate a missing section. Check that the recording is actually being written and that the storage has enough room for the planned duration.
DVR and archive are different. DVR helps someone watching the live event pause or rewind within the available live window. An archive is the recording left after the broadcast. Turning on DVR does not guarantee unlimited rewind or permanent retention, and recording-from-start settings do not cancel YouTube's warning about streams longer than 12 hours.
The right plan depends on what the event needs. If the priority is a continuous live presence, one long broadcast may be operationally simpler, but it carries the archive caveat. If the priority is a complete replay, shorter events plus local recording provide more control. State this choice before launch so that the person running the channel is not relying on an assumption made by an old tutorial.
Choose reliability over a larger number
The strongest baseline is not the highest resolution OBS offers. It is the highest output your source, encoder and upload can maintain without intervention.
For many event replays, 1080p30 with H.264, the codec-specific recommended bitrate, CBR, 2-second keyframes, RTMPS and normal latency is a reasonable first test. If the connection cannot sustain that target, 720p30 may be the better production setting. If the source contains important fast motion and the connection is stable, test 60 fps rather than selecting it automatically.
Write down the working settings after the unlisted test. Include the output resolution, frame rate, codec, bitrate, keyframe interval, latency, stream visibility and whether DVR is enabled. Also note the source file, loop behaviour and the person responsible for checking health. This turns a successful test into a repeatable handover rather than a collection of settings remembered from a previous 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
Should a 24/7 replay use 60 fps?
Not by default. Start with 30 fps for a mostly static replay, then use 60 fps when the source has motion that benefits from it and your stable upload can sustain the codec-specific bitrate.
Is H.264 always the best codec for OBS?
No. H.264 is widely applicable, but YouTube also documents H.265 and AV1 where your hardware and software support them. Select the codec you can encode reliably, then use the bitrate guidance for that codec rather than copying an H.264 figure.
Can YouTube guarantee a 24-hour archive?
No. YouTube warns that a stream exceeding 12 hours may not be captured at all, and DVR rewind may be limited or unavailable beyond 12 hours. Use shorter broadcasts and keep a local recording when a complete replay matters.
Is ultra-low latency useful for a prerecorded event replay?
Usually not. Normal latency is a better starting point for an unattended replay because it gives playback more buffering room, while lower latency can increase buffering and restrict some features.