A pre-recorded video sent to YouTube as a live broadcast still passes through a live encoder. For that reason, you should follow YouTube’s live ingestion guidance for the outgoing feed, not the settings intended for an ordinary video upload.
There is no separate YouTube live profile just because the source is pre-recorded. The file is your source material; the encoder’s output is the live stream that YouTube receives.
Understand the pre-recorded live workflow
A normal YouTube upload sends a completed file to YouTube for processing. A live broadcast works differently. Your encoder reads a file, playlist or other source, turns it into a continuous outgoing feed, and sends that feed to YouTube using the stream details from YouTube Studio.
That distinction matters even when the picture on screen never changes. A devotional loop, a lofi visual, a local news package or a sequence of recorded sermons may be finished before the broadcast begins, but YouTube receives it as an active live contribution. The encoder must therefore maintain a steady video and audio stream while the broadcast is running.
The practical sequence is:
- Enable live streaming on the channel and create or schedule the event in YouTube Studio or Live Control Room.
- Select an encoder that can play the pre-recorded source and send it as a live feed.
- Copy YouTube’s server URL and stream key into the encoder. Treat the stream key like a password.
- Set the outgoing resolution, frame rate, codec, bitrate and audio format.
- Start the encoder, check the preview and stream-health messages, then begin the public broadcast.
YouTube says first-time live-streaming activation may take up to 24 hours. Do not leave channel activation until the first evening you intend to run a 24/7 channel. Check the current requirements in YouTube’s live-streaming eligibility guidance, because channel restrictions and account requirements can change.
Scheduling the event does not remove the encoder step. A scheduled broadcast can give viewers a watch page and reminders, but the feed still needs to be sent when the event is due to start. If the encoder does not connect, the scheduled page does not create a picture by itself.
The source file also deserves a separate check. If it has a variable frame rate, missing audio, unusual dimensions or a damaged section, the encoder may struggle before YouTube sees anything. A source that plays correctly in a media player is not necessarily a source that will run unattended for a full night.
For a longer practical discussion of the operating choices, see this guide to the best free ways to stream pre-recorded videos on YouTube 24/7 in India. It is useful to keep the source-file decision separate from the live-ingestion decision described here.
Use live ingestion guidance, not upload settings
YouTube publishes separate guidance for uploading finished videos and for sending a live feed. The tables may look similar because both discuss resolution, frame rate and bitrate, but they describe different stages of the workflow.
For example, YouTube’s H.264 live guidance recommends 14 Mbps for 1080p at 30 frames per second. Its upload guidance lists 8 Mbps for a standard-frame-rate 1080p upload. The upload figure does not become the live bitrate simply because the source is a completed file. For a pre-recorded live stream, the 14 Mbps live-ingestion recommendation is the relevant one when using H.264 at 1080p30.
YouTube’s live figures also vary by frame rate. The relevant choice is not “1080p” on its own, but the combination of codec, resolution and frame rate. A 1080p30 feed and a 1080p60 feed have different live recommendations.
The official live encoder settings and bitrate page is the right starting point for the outgoing stream. YouTube’s separate video upload encoding guidance remains useful when preparing the source file, but it should not be presented as a special set of requirements for a pre-recorded live event.
For a standard RTMP or RTMPS workflow, YouTube’s reviewed live guidance lists H.264, H.265, also called HEVC, and AV1 video. It supports up to 60 frames per second. The guidance recommends constant bitrate encoding and a keyframe frequency of two seconds, with the interval not exceeding four seconds.
YouTube recommends RTMPS for live ingestion. HLS is a different ingestion path, not another name for RTMP. YouTube documents HLS for situations such as HDR or codecs that are not supported through RTMP. It has separate playlist, segment and request rules, and usually introduces more latency because the feed is delivered in segments.
Unless your encoder and production workflow specifically require HLS, do not copy HLS settings into a normal RTMP or RTMPS setup. The rest of this article assumes the more common RTMP or RTMPS path.
Choose a supported video codec
The codec determines how the outgoing picture is compressed before it travels to YouTube. It is not enough for the source file to use a codec that your computer can play. Your encoder must decode the source and produce a live output codec that YouTube accepts on the chosen ingestion path.
For RTMP or RTMPS, YouTube lists H.264, H.265 and AV1. H.264 is usually the simplest starting point when compatibility matters. It is widely supported by software encoders, hardware encoders and playback tools, and YouTube provides a detailed H.264 bitrate table for common resolutions and frame rates.
H.265 can reduce the data needed for a comparable picture in some workflows, but the encoder must support it properly and the receiving path must accept it. YouTube’s live guidance recommends H.265 for HDR over RTMP or RTMPS. AV1 is listed for live ingestion, but YouTube’s guidance states that AV1 is not supported for HDR.
For an ordinary 24/7 channel with an SDR source, H.264 is often the least complicated route. That is not a promise that it will solve every problem. A weak processor, unsuitable hardware acceleration or a source with awkward timing can still cause trouble. The useful question is whether the complete chain can decode the file, encode the chosen output and maintain it continuously.
YouTube’s additional live recommendations include square pixels, progressive scan, two B-frames, one reference frame, CABAC, Rec. 709 for SDR and 8-bit SDR. For HDR, the guidance refers to 10-bit HDR and recommends checking the codec and ingestion path carefully.
Do not force HDR merely because the source file contains HDR information. If the encoder, display workflow or ingestion path is not configured for it, a carefully prepared SDR broadcast may be more dependable. Decide first whether viewers need HDR, then confirm that every stage supports the decision.
The source and output do not have to be identical. A source may be 4K while the live output is 1080p, or a source may be encoded in a format that your encoder converts to H.264. What matters for YouTube’s live settings is the output it receives.
Set bitrate mode and keyframe interval
For RTMP and RTMPS, use constant bitrate, or CBR, when configuring the encoder. CBR keeps the outgoing data rate more predictable than a quality-driven variable bitrate mode. That predictability helps both the network connection and YouTube’s live-ingestion pipeline.
Choose the bitrate from the matching live row rather than selecting a general value that “sounds high enough”. YouTube’s H.264 recommendations are:
| Output | Recommended bitrate | Minimum bitrate |
|---|---|---|
| 720p30 | 8 Mbps | 3 Mbps |
| 720p60 | 8 Mbps | 3 Mbps |
| 1080p30 | 14 Mbps | 5 Mbps |
| 1080p60 | 17 Mbps | 6 Mbps |
| 1440p30 | 21 Mbps | 7 Mbps |
| 1440p60 | 34 Mbps | 8 Mbps |
| 2160p30 | 42 Mbps | 11 Mbps |
| 2160p60 | 50 Mbps | 14 Mbps |
These are live H.264 ingestion figures, not the upload table. They also do not describe the total internet connection required by every device in the building. Your available outbound capacity needs room for the stream, normal network activity and temporary variation. YouTube’s preparation guidance recommends about 20% upload-bandwidth headroom, so a connection that barely reaches the selected bitrate is a poor basis for an unattended broadcast.
If a 1080p30 stream is configured at the recommended 14 Mbps, the encoder should maintain that approximate video rate rather than jumping between very low and very high values. Audio uses additional bandwidth, and the connection may carry other traffic, so do not treat 14 Mbps as the complete capacity requirement.
The keyframe interval is equally important. YouTube recommends a keyframe every two seconds and says the interval should not exceed four seconds. In an encoder that asks for a keyframe interval in frames rather than seconds, the correct value depends on frame rate. At 30 fps, two seconds corresponds to 60 frames; at 60 fps, it corresponds to 120 frames.
Some encoders expose both a keyframe interval and an automatic scene-change option. Confirm what the software actually sends rather than assuming the label is enough. A pre-recorded loop can contain long still sections, fades and repeated patterns, so inspect the stream settings and the health report rather than judging only by the source’s appearance.
If the network is unstable, lowering resolution or frame rate is usually more useful than keeping a high-resolution setting with an unreliable bitrate. A steady 720p feed can be more practical for an overnight devotional or study channel than a 4K feed that repeatedly stalls. Make the decision from the channel’s purpose and the available upload capacity, not from the resolution of the original file alone.
Configure audio for ingestion
YouTube’s RTMP and RTMPS live guidance lists AAC and MP3 audio. Use the format your encoder and production chain handle reliably. AAC is the relevant choice when you need 5.1 surround audio, because YouTube states that 5.1 is supported only with AAC.
For many spoken-word, devotional, lofi and local-information channels, stereo is sufficient. That does not mean audio can be ignored. A stream can show a clean picture while the audio is silent, distorted, delayed or routed to the wrong device.
Check that the source actually contains the audio you expect. A video with several audio tracks may cause the encoder to select the wrong one. A loop assembled from clips may have different loudness, channel layouts or sample timing from one section to the next. Listen to the outgoing preview, not only to the original files on your computer.
Keep audio enabled in the encoder even when part of the programme is silent. Silence in the content is different from an audio track that disappears. Some workflows react badly when the audio stream is removed and reappears between clips.
The safest test is to listen on a second device while watching the preview. Check speech intelligibility, music balance, left and right channels, and whether the sound remains present when the video changes. For a 24/7 channel, include a transition between at least two source items in the test because many problems occur at the join rather than at the beginning.
If you use 5.1, verify the entire chain rather than assuming a multichannel source will remain multichannel. YouTube’s published support for 5.1 is tied to AAC, and your encoder must preserve the intended channel arrangement. If you cannot monitor that arrangement properly, stereo may be the more sensible operating choice.
Match settings to encoder capability
A setting is only useful if the encoder can maintain it. A software encoder may be enough for a single pre-recorded stream, while a hardware encoder may suit a production that needs dedicated controls, several inputs or less dependence on a general-purpose computer. YouTube supports both software and hardware encoders; hardware is not a requirement for sending a pre-recorded feed.
Start with the source, the required output and the actual machine or service that will run the encoder. If the source is 4K60 but the computer cannot decode and re-encode it continuously, outputting 1080p30 may be the responsible choice. If the channel only needs a static visual and spoken audio, there may be no benefit in spending processing capacity on a frame rate that the content does not use.
A local computer gives you direct control but also leaves the stream dependent on that computer, its power state, its internet connection and any overnight updates. A VPS or other remote setup can be useful for an operator who is comfortable maintaining it, but it still requires attention to software updates, storage, logs and restart behaviour. If you use a remote machine, document how to reconnect and how to confirm that the stream is really live after a restart.
For a continuous podcast workflow, the article on running a podcast stream with FFmpeg on YouTube covers a more command-line-oriented approach. If you prefer a graphical setup, connecting OBS to YouTube Live for a pre-recorded stream is the more relevant comparison.
If the main problem is that your own computer must remain on and recover from interruptions, StreamNeo removes that particular operating task by taking an uploaded video, sending it to YouTube as a live stream, and handling automatic restarts without requiring an installation on your computer. It remains YouTube-only, so it does not replace a production workflow or a setup where you need detailed live switching.
Do not choose an encoder only by its maximum advertised resolution. Check whether it can loop the source, preserve audio, set CBR, control keyframes, use RTMPS, reconnect after a network interruption and expose useful health information. Those practical controls matter more than a specification that your channel will never use.
Test the outgoing stream
Testing should use the same source, encoder settings, network and operating conditions that you plan to use during the real broadcast. A short test from a different computer or a different connection may confirm that the file plays, but it does not confirm that the overnight setup will remain stable.
Create the event in YouTube Studio, enter the stream key in the encoder and start sending the feed before making it public. Use the Live Control Room preview to check the picture and sound. YouTube’s preparation guidance recommends setting up in advance and starting the encoder at least 15 minutes before a scheduled start.
During the test, inspect more than the player window. Check the incoming bitrate, stream health messages, dropped frames, audio presence and any warnings from the encoder. Watch a section that includes a source transition, because a playlist may behave differently from a single file.
You should also confirm the following:
- The output resolution and frame rate are the values you intended.
- The codec is the one you selected, rather than an automatic fallback.
- CBR is enabled and the bitrate is appropriate for the live table.
- Keyframes are arriving at approximately two-second intervals and never more than four seconds apart.
- Audio remains present through silence, fades and file changes.
- The network has enough upload headroom for the stream and normal household or office traffic.
- The computer will not sleep, reboot for updates or lose access to the source directory.
- The encoder can reconnect if the connection drops.
- The stream key is not visible in screenshots, logs or public instructions.
For a 24/7 setup, test recovery as well as normal playback. Stop and restart the encoder, briefly interrupt the network if your circumstances allow a controlled test, and see how YouTube reports the interruption. Do not assume that an automatic reconnect has worked until you can see the incoming preview and health status again.
Keep a written record of the working settings. Include the source filename or playlist, output resolution, frame rate, codec, bitrate, keyframe interval, audio format and the date of the last successful test. This makes it easier to restore a stable configuration after an update or an accidental change.
If your stream repeatedly drops over Wi-Fi, review the practical checks in this guide to fixing YouTube stream drops on Wi-Fi. Network stability is part of encoding reliability. A correct codec and bitrate cannot compensate for an upload path that disappears during the night.
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
Can I livestream a pre-recorded video on YouTube?
Yes. You send the pre-recorded material through a live encoder, which produces the feed that YouTube receives as a live broadcast. You still need live-streaming access, a stream event or schedule, a stream key and a working outgoing connection.
Are YouTube upload settings the same as live-stream settings?
No. Upload settings describe a completed file being uploaded, while live settings describe the feed being ingested during a broadcast. For example, YouTube’s H.264 live recommendation for 1080p30 is 14 Mbps, which is different from the standard-frame-rate 1080p upload recommendation.
What bitrate do I need for 1080p on YouTube Live?
For H.264 live ingestion, YouTube recommends 14 Mbps at 1080p30 and 17 Mbps at 1080p60. Use the row matching both the resolution and frame rate, keep CBR enabled, and leave upload headroom rather than sizing the connection exactly to the video bitrate.
Do I need a hardware encoder for a pre-recorded live stream?
No. YouTube supports software and hardware encoders. Choose based on the source, required controls, processing capacity, reliability and the amount of hands-on operation you are prepared to provide.