To loop a 720p video on YouTube Live, add it to OBS as a Media Source, enable Loop, and send the resulting live feed to YouTube with your stream URL and key. The loop repeats playback; it does not reduce the continuous upload needed to keep the broadcast online.
There is no upload speed that guarantees 720p will work in every setup. Choose an encoder bitrate from YouTube’s current guidance, include audio and room for network variation, then test the actual connection before relying on it.
How a local loop becomes a YouTube Live broadcast
OBS plays the video file on your computer, encodes its picture and sound, and sends that encoded feed over your internet connection to YouTube. YouTube receives it as a live broadcast, even though the pictures originally came from a recording. The viewer sees a live stream, not a file playing directly from your computer to each viewer.
These are two separate jobs: repeating the file and transmitting the broadcast. OBS can restart playback when the file reaches its end, but the computer, OBS, power and internet connection still need to keep working. If the network drops, the local video may continue playing while YouTube stops receiving a reliable live feed.
That distinction matters when you have limited upload capacity. Loop is a playback control, not a bandwidth-saving mode. The stream’s bitrate, audio, connection stability and other traffic on your network determine whether the encoder can keep sending the feed. A 720p source file does not itself dictate the live output resolution or bitrate; those are choices in your encoder settings.
If you have not connected an encoder to YouTube before, the beginner’s guide to starting a YouTube live stream can help you understand the broadcast setup around this specific looping task. Keep the basic model in mind: OBS sends one continuous stream, and YouTube distributes it to viewers.
Add the file in OBS and enable Loop
In OBS, add a Media Source to the scene that will carry your broadcast. Give it a recognisable name, such as “Bhajan programme” or “shop tour”, and browse to the local video file. Size and position the source in the scene so it fills the frame as intended. OBS’s Media Sources documentation explains the source controls, including the option to loop playback.
Select Loop in the Media Source properties. With this enabled, OBS starts the file again when it reaches the end. Check that the file plays in the preview and that its sound is audible if it includes audio. If you use a separate audio source, confirm that it also behaves as intended when the video restarts; a picture loop does not automatically make every other source repeat in sync.
For a single video, the Media Source loop control is usually the most direct setup. If you are rotating through several files, a VLC Video Source can use a looping playlist instead, but VLC must be installed and the playlist itself needs to be checked. A playlist is useful when you want varied material; a single source has fewer moving parts to diagnose.
Before a long broadcast, play the source through at least one complete cycle. Look for a blank interval, an unexpected transition, a frozen frame or a sound gap at the restart. The file’s end and beginning may not join seamlessly, and enabling Loop does not edit or crossfade them. If the join is distracting, change the edit or choose a different loop point before using the file on air.
For a sequence intended to keep viewers engaged, the advice on organising a 24/7 YouTube stream playlist can help with the content order. That is a separate question from making the encoder repeat a file reliably.
Connect OBS using the stream URL and key
In YouTube Studio, create or schedule a live broadcast and open its encoder or stream settings. YouTube provides a stream URL and stream key for the connection. In OBS, open Settings, then Stream, select YouTube as the service where available, and enter or connect the credentials using the method shown in your version of OBS. If OBS asks for a server and key separately, copy each value into its matching field.
The URL tells OBS where to send the feed; the key identifies which broadcast it should connect to. Treat them as credentials, especially the key. Avoid pasting them into public notes, screenshots or a message channel that other people can read. You can follow YouTube’s steps in its guide to creating a live stream with an encoder.
Once the encoder is connected, YouTube Studio’s Live Control Room should show a preview when it receives the feed. The preview is not the same as making the broadcast public. Use a private or unlisted test when possible, and verify the selected audience and visibility settings before scheduling or starting a public stream. If live streaming is new to the channel, YouTube says first-time enablement can take up to 24 hours, so do not leave activation until the planned start time.
Some YouTube settings are detected from the encoder, while manual settings can be available with a custom stream key. Use the option that matches your workflow and check what the Live Control Room actually reports. Connecting OBS successfully does not, by itself, prove that the stream is stable or that the chosen output is suitable for the available connection.
Check YouTube’s current settings guidance
YouTube’s published encoder guidance is the right starting point for codec and bitrate choices, but it is guidance rather than a promise that a connection will carry a particular stream. Its current table lists the following 720p video bitrate recommendations. Audio is additional.
| 720p frame rate | Codec | Minimum video bitrate listed | Recommended video bitrate listed |
|---|---|---|---|
| 30 or 60 fps | H.264 | 3 Mbps | 8 Mbps |
| 30 or 60 fps | AV1 or H.265/HEVC | 2 Mbps | 6 Mbps |
These are figures in YouTube’s encoder settings, bitrates and resolutions guidance, not upload-speed guarantees. The table separates codecs and gives both minimum and recommended video rates. A stream encoded at a lower rate may have a different picture result, and a connection that briefly reaches a number is not necessarily stable enough to sustain it.
YouTube also lists RTMP or RTMPS as connection protocols, H.264, H.265 or AV1 encoding, constant bitrate (CBR), keyframes every two seconds without exceeding four seconds, and AAC or MP3 audio in its encoder guidance. Prefer RTMPS where the encoder and YouTube settings support it. The relevant choice depends on what your encoder can use and what the control room expects; avoid changing several settings at once during troubleshooting.
For audio, YouTube’s advanced settings list 128 kbps stereo. That rate must be counted alongside video, not mistaken for part of the video figure. If you use a different audio configuration, the total can differ. This is one reason a speed-test result that appears close to a video bitrate alone can still be inadequate for the complete live feed.
Match output settings to upload capacity
Measure upload capacity, not download speed. Many internet plans and connections can download faster than they upload, and it is the upstream path from your encoder to YouTube that carries the broadcast. Run a speed test under conditions similar to your intended stream, then consider whether other people, devices, backups or uploads will be using the same connection.
YouTube’s streaming tips say to leave room for network activity, with 20% recommended. Treat that as headroom to preserve rather than capacity to consume: the stream’s total bitrate should remain below the available upload bandwidth. Actual capacity can vary, so a single favourable reading is not enough to establish that a stream will remain stable overnight.
For an example calculation, a 3 Mbps video stream plus 128 kbps stereo audio totals 3.128 Mbps. Adding 20% headroom gives roughly 3.75 Mbps of upload capacity for the stream before allowing for other network use or fluctuations. This is arithmetic using the example settings, not a YouTube-published benchmark or a guarantee that a connection at that speed will work.
The practical choice depends on your measured upload, codec support, the motion in the source and whether 30 or 60 frames per second is genuinely needed. A lower frame rate can be a sensible way to reduce the chosen output demand, but it does not guarantee a particular picture quality for every video. If your connection cannot reliably support the intended 720p settings with audio and headroom, lower the bitrate, choose a lower resolution, or both. A stable lower-resolution broadcast is more useful than an unstable 720p feed.
| What you can sustain in testing | Setting decision to consider | Trade-off to check |
|---|---|---|
| The recommended bitrate for your chosen codec, plus audio and headroom | Try the intended 720p output and frame rate | Confirm stability over a representative test, not just a brief preview |
| Less capacity than the recommended rate, but enough for a lower target | Reduce bitrate and consider 30 fps rather than 60 fps | Inspect the picture for softness or motion artefacts |
| Not enough reliable capacity for a 720p target with audio and headroom | Lower resolution and set a correspondingly suitable bitrate | Prioritise a continuous, watchable feed over the 720p label |
The table is a decision framework, not a list of speed thresholds. No row says a particular upload speed guarantees success. YouTube’s own streaming tips advise allowing bandwidth room and lowering resolution when the available connection is insufficient. If other household or business traffic is important, test while that traffic is present rather than assuming the stream has the full measured capacity to itself.
Preview and test before going public
Make a private or unlisted test broadcast using the actual video, audio and network conditions you expect to use. Give the test enough time to include normal motion and a file restart if practical. A static title card may be easy to encode, while a video with movement, fine detail or changing scenes can expose problems that a quiet opening does not.
Check the Live Control Room preview for picture, sound and warnings. Watch OBS as well: dropped frames or connection messages there can point to a transmission issue, while a clean preview with an awkward jump at the file boundary may point to the source or loop itself. YouTube’s live-stream error guidance can help interpret messages shown during a broadcast.
If the preview stalls, the stream health reports a problem, or the picture repeatedly degrades, change one setting at a time. Reduce the output bitrate first if the connection is the likely constraint, or lower resolution if you cannot keep a sensible bitrate for 720p. Then repeat the test. Changing codec, frame rate, audio and bitrate all together makes it harder to tell which adjustment helped.
A test should also cover the operating routine. Confirm that the correct scene is active, the file is available locally, audio is not muted, the stream is scheduled for the intended time, and visibility is set correctly. If the channel is expected to run continuously, plan how someone will notice a stopped encoder or network problem. A playback loop alone cannot restart an internet connection or keep a powered-off computer broadcasting.
Protect the key and plan for interruptions
A stream key should be handled like a password. Do not put it in a public tutorial screenshot, share it with people who do not need broadcast access, or leave it visible in a screen recording. Keep access to the Google account and YouTube Studio limited to trusted people, and use a distinct key or settings where your workflow supports that separation.
If you believe the key has been exposed, reset it in YouTube Studio and update the encoder with the replacement. YouTube’s live stream settings help describes managing stream settings. Once you reset a key, the old value should no longer be used for the broadcast; check that OBS is using the current credential before the next test.
For a channel intended to operate around the clock, decide who will check stream health and what to do if the broadcast drops. The person monitoring it should know how to inspect OBS and the Live Control Room, verify the connection, and restart the encoder if needed. Your content plan and your transmission plan are different: the local-storage OBS workflow covers the file-to-encoder side, while this article’s central caution is that the network must still carry the outgoing stream continuously.
If keeping a local computer and connection running is the part that makes the schedule difficult, a cloud-based workflow can remove that particular burden: StreamNeo turns an uploaded video into a YouTube Live broadcast, so you do not have to leave your own computer switched on for the stream. It does not change YouTube’s bitrate guidance or make an inadequate upload connection suitable for a local OBS broadcast; choose the operating arrangement that fits the problem you actually have.
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 do I loop a prerecorded video on YouTube Live?
Add the local video as a Media Source in OBS and enable Loop in its properties. Connect OBS to the YouTube broadcast using the stream URL and key, then check the preview in Live Control Room. OBS repeats the file, while your connection continues to send the live feed.
What upload speed do I need for 720p YouTube Live?
There is no universal upload-speed figure that guarantees a stable 720p stream. Use YouTube’s bitrate guidance for your codec and frame rate, add audio bitrate, leave room for network use, and test under realistic conditions. If your measured upload cannot sustain the selected total, reduce bitrate or resolution.
Does looping reduce the bandwidth needed?
No. Looping restarts local playback after the file ends; it does not reduce the bitrate of the encoded live feed or remove the need for continuous upload. Viewers still receive a stream sent from the encoder to YouTube.
Should I use 30 fps or 60 fps on a limited connection?
Use the frame rate that suits the content and the upload capacity you can sustain. YouTube’s 720p table gives bitrate guidance by codec and frame rate, but it does not promise a particular quality result on every connection. Test the actual source and choose a lower-demand setting if the feed is unstable.