A podcast playlist can run repeatedly as a YouTube Live broadcast with FFmpeg. The important detail is that -stream_loop -1 and -re are input options, so they belong before the input file's -i in the command.
The command below is a schematic starting point, not a tested command that will work unchanged for every file. You still need to choose the correct streams, codecs, video source, bitrate and YouTube ingest settings for your media and connection.
Prepare the podcast files and sequence
Start by deciding whether you are looping one finished programme or a sequence of separate episodes. These are different jobs even though both can appear to viewers as a repeating live channel.
For one file, FFmpeg can read the file and loop that input indefinitely. For several episodes, first create a reliable sequence. You might prepare one combined media file, use a playlist workflow, or concatenate compatible files before sending the result to YouTube. The correct choice depends on how the episodes were encoded and how much control you need over transitions.
Do not assume that arbitrary MP4, MKV or audio files can be joined with stream copy. The files may have different sample rates, channel layouts, frame sizes, frame rates, codecs or time bases. Even small differences can produce a failed concat operation, a timestamp problem or an abrupt transition. If the media is not compatible, re-encoding the combined result may be necessary.
A single prepared file is often the easiest arrangement for a small channel. It gives you one item to inspect, one duration to understand and one point at which to replace the programme. A multi-file arrangement is more flexible when you publish new episodes regularly, but it creates more opportunities for an unexpected format change between items.
Before encoding, listen and watch through the sequence. Check for silence at the start or end of an episode, a missing cover image, a different loudness level, clipped speech and long gaps. If the podcast is audio-only, decide what viewers should see during playback. A still cover image, a branded background or a simple visualiser can turn the audio into a valid video programme, but each choice changes the video mapping and encoding settings later.
Keep the original files in a separate folder and make a working copy of the playlist or combined file. This makes it easier to return to a known sequence when you need to replace one episode. If you are building a regular queue rather than one fixed broadcast, the workflow described in how to create an automated podcast episode queue may be more suitable than repeatedly rebuilding one large file.
You also need the right to rebroadcast every part of the programme. A podcast being publicly available does not automatically grant permission to use its audio, music, guest clips, artwork or advertisements in a continuous YouTube Live broadcast. Check the agreements that cover your episodes and any music or third-party material.
YouTube says that live streams are scanned for third-party content. A match can lead to a placeholder image, an interruption or termination. YouTube also explains that licensed third-party content may require the rights holder to add your channel to a Content ID allowlist. That is a rights-holder and creator matter, not something FFmpeg can resolve. Read the current YouTube Help guidance on live-stream copyright before scheduling the broadcast.
Create an encoder stream in YouTube Studio
Open YouTube Studio and create or select a live stream in Live Control Room. Choose the encoder workflow rather than a webcam or mobile workflow, then copy the stream URL and stream key shown for the broadcast.
Treat the stream key like a password. Do not put it in a public article, paste it into a screenshot, commit it to a shared script or leave it in a log that other people can read. If you need to show someone the command, replace the real key with a placeholder such as STREAM_KEY.
The destination is normally formed from YouTube's ingest URL and your stream key. Keep the two values in a protected environment variable or a local configuration file where practical. You can also paste them into the final command at run time, but take care not to expose the command through shell history, screen sharing or process listings.
YouTube recommends RTMPS for encoder-based live streaming. Its Help page describes RTMPS as a secure extension of the RTMP video protocol. For this FFmpeg workflow, RTMPS is the straightforward default because it is designed for a continuous encoder connection.
YouTube also documents HLS ingestion, but it is a separate workflow. HLS requires segmented media and rolling playlists, and YouTube describes it as having higher latency than RTMP. It can be appropriate for an encoder that is built around HLS output, but it is not a simple replacement for the RTMPS destination in the example below.
Before starting FFmpeg, check the stream's visibility and scheduled start arrangements. For a first test, unlisted is usually easier than sending an unverified experiment to a public audience. Confirm which stream you are editing in Live Control Room so that the key, title and intended broadcast are aligned.
For a wider explanation of the practical choices between a local process and hosted playback, see this guide to the best software for streaming prerecorded videos on YouTube 24/7. The right choice depends on whether you want to maintain the machine, network connection and restart process yourself.
Put loop and realtime options before the input
The central FFmpeg detail is option placement. For a local file, -re asks FFmpeg to read the input at its native media rate instead of processing it as quickly as the computer can. -stream_loop -1 tells FFmpeg to repeat the input indefinitely. Both options appear before -i in the schematic below because they describe how the input is read.
ffmpeg -re -stream_loop -1 -i "episode.mp4" [video options] [audio options] [output options] "RTMPS_INGEST_URL_WITH_STREAM_KEY"
The order of the two input options can be written as shown or reversed, but they must remain in the input-options part of the command. The important boundary is the input declaration:
ffmpeg -re -stream_loop -1 -i "episode.mp4" ...
Do not read this as a complete, ready-to-run broadcast command. It deliberately leaves the video and audio handling unspecified. A file may contain one video stream and one audio stream, several audio languages, attached artwork, subtitles or no video at all. Your FFmpeg build, operating system, shell quoting and YouTube settings also affect the final command.
-stream_loop -1 loops the input rather than creating a queue of separately monitored episodes. If the input is already a prepared combined programme, FFmpeg reaches its end and starts that same input again. The loop boundary may be noticeable if the final and first frames do not join naturally. A short silence, a changed cover image or a timestamp discontinuity can make the restart audible or visible.
-re is particularly relevant when reading local prerecorded media. Without rate control, FFmpeg can consume a file faster than real time and send data in bursts until the input ends. With it, the process follows the media clock more closely. This is a pacing instruction, not a guarantee that the output meets YouTube's ingest requirements or that the connection will remain stable.
If you use a separate playlist mechanism instead of one combined input, the option placement and loop behaviour may differ. Read the documentation for the exact demuxer or playlist method you choose. Do not add -stream_loop -1 to a command merely because the word playlist appears in the workflow; first establish which input FFmpeg is actually opening.
The official FFmpeg documentation explains its command-line structure and option scope. When troubleshooting, look at whether an option is global, input-specific or output-specific rather than moving flags around at random.
Configure codecs, mapping and the video source
After the input is defined, decide what FFmpeg should send. This is where a generic recipe becomes configuration-dependent.
Mapping selects the streams that enter the output. A simple file may allow automatic selection, but automatic selection can be wrong when the input contains multiple audio tracks, cover art or commentary. An explicit map can make the result predictable, but only if you know the stream indexes and types. For example, a file might expose a video stream as 0:v:0 and an audio stream as 0:a:0, while an audio-only source has no video stream to map.
A conceptual output section might therefore contain choices such as:
-map 0:v:0 -map 0:a:0 -c:v [video encoder] -c:a [audio encoder]
This is a schematic, not a claim that those maps exist in your file. Inspect the input first with a media-information tool or an FFmpeg probe, then choose mappings that match the actual streams. If you use a still image or generated visual as the video source, it becomes a multi-input command and the mapping must be redesigned.
YouTube's general encoder guidance lists H.264, H.265/HEVC and AV1 among supported video codecs, and AAC or MP3 among supported audio codecs. That does not mean every FFmpeg build, input, hardware encoder or YouTube configuration can use every combination. It also does not mean that copying an existing stream is always appropriate.
Re-encoding is often the more predictable route when you need to normalise frame size, frame rate, pixel format, audio sample rate or channel layout. Stream copying can avoid another generation of quality loss, but it leaves the source properties intact and may not produce an output YouTube accepts consistently. If you copy a stream, confirm that its codec and container behaviour suit the destination.
For bitrate, use YouTube's current encoder table rather than copying a value from an old command. YouTube says to consider resolution, frame rate, codec and realistic upload capacity. It also recommends constant bitrate encoding for its general live settings. Your upload connection must sustain the encoded output, protocol overhead and ordinary network variation; an advertised line speed is not the same as dependable capacity.
YouTube recommends a two-second keyframe interval and says it should not exceed four seconds in the general settings guidance. Treat this as an output encoder setting, not as a property you can assume from the source file. A keyframe setting that is unavailable or ignored by your chosen encoder needs a different solution.
If the podcast has no video, create a deliberate visual source rather than assuming YouTube will turn audio into video for you. A static cover can be adequate for a spoken-word station, while a restrained waveform or branded scene may help viewers understand that the stream is active. Make sure you have permission to use the artwork and that the visual does not introduce a second input with mismatched duration or timing.
The YouTube Live settings guide is the proper reference for current codec, bitrate, frame-rate and keyframe recommendations. If your channel uses a higher resolution or frame rate, compare those settings with this 1440p 60fps YouTube Live guide, but verify the platform's current table before applying any value.
Send the output to YouTube over RTMPS
Once the input and output decisions are made, place the RTMPS destination at the end of the command. A fuller schematic looks like this:
ffmpeg -re -stream_loop -1 \
-i "prepared-podcast.mp4" \
-map 0:v:0 -map 0:a:0 \
-c:v [chosen-video-encoder] [video-rate-and-keyframe-options] \
-c:a [chosen-audio-encoder] [audio-options] \
-f flv "RTMPS_INGEST_URL_WITH_STREAM_KEY"
The line breaks are for readability. On a single-line shell command, remove the continuation characters and keep the quoting appropriate for your operating system. The -f flv shown here is part of the common RTMP-family output pattern, but the exact output requirements depend on your FFmpeg build and the current YouTube encoder instructions. Do not treat the template as tested.
Replace every bracketed value. The video encoder might be a software encoder or an available hardware encoder. The audio encoder depends on the source, build and destination requirements. The mappings depend on the input. The ingest URL and stream key come from your YouTube Live Control Room session, not from this article.
Check the terminal output after starting the process. FFmpeg should report the input streams, selected output streams, encoding speed and connection activity. A speed close to the intended playback rate is more useful than a command that runs through the file immediately. Warning messages about timestamps, dropped frames, missing streams or failed reconnections deserve attention before you make the stream public.
A local FFmpeg process leaves you responsible for the computer, power, operating system updates, network path and process recovery. If the machine sleeps, loses its network connection or stops after an error, YouTube cannot recreate the missing encoder feed. For a channel where the main problem is keeping a prepared file running while your own computer is switched off, StreamNeo removes that particular operating burden by taking an uploaded video and maintaining the YouTube broadcast for you, with automatic monitoring and restart handling.
That convenience does not decide your content rights, YouTube settings or stream design. You still need to prepare material you are allowed to broadcast and check the resulting live feed. If you prefer to operate your own process, document the command, protect the key and create a restart procedure another person can follow.
Verify playback and stream health
Do not judge the setup solely by whether FFmpeg prints that it connected. Open the preview in YouTube Live Control Room and inspect the actual picture and sound. Confirm that speech is clear, the visual is present, the stream is not showing an unexpected crop and the selected broadcast has the correct title and visibility.
Listen through the beginning, the end and the restart boundary. For a multi-episode sequence, check at least one transition between files. A stream can remain connected while a particular episode has silence, a missing audio track or an unsuitable video format. A test that only checks the first minute will not reveal those problems.
Watch YouTube's stream-health indicators while the test is running. The YouTube encoder help page recommends testing and monitoring stream health. Look for warnings about the incoming bitrate, keyframes, resolution, frame rate or connection. Use the warning's description to change one relevant setting at a time rather than replacing the whole command blindly.
Check the outgoing network from the same place where FFmpeg will run. If the connection is shared with other users or devices, upload capacity can change during the day. This matters particularly for a home connection in which a scheduled backup, video call or large upload competes with the live feed.
Plan what happens after a disconnect. FFmpeg may exit, reconnect according to the options you have configured, or remain running while the input and network states change. The behaviour depends on the command and build. Test your chosen recovery method by stopping the network briefly in a controlled, unlisted test rather than discovering it during a public broadcast.
A long-running stream also needs an archive plan. YouTube Help says streams under 12 hours are automatically archived. That is a platform rule, not a promise that an indefinitely long stream will become one complete, usable recording. If individual episode archives matter, plan deliberate stops and restarts, or keep your own source files and recordings.
For viewers in India and elsewhere, the encoder's outgoing connection is only one part of playback. Viewer-side buffering can have different causes, including local network conditions and the selected bitrate. The practical checks in this guide to YouTube stream buffering for viewers in India can help separate an ingest problem from a viewer delivery problem.
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
Does -stream_loop -1 loop a playlist or only one input?
It loops the input that FFmpeg opens. If you give it one prepared file containing several episodes, the complete file repeats. A separate multi-file playlist needs a compatible playlist or concat workflow, and its transition and loop behaviour must be checked independently.
Why must -re come before -i?
-re controls how FFmpeg reads an input, so it belongs with the input options before the input declaration. In ffmpeg -re -stream_loop -1 -i "episode.mp4", both flags apply to that input. Their presence does not replace the need to configure output codecs, mappings or bitrate.
Can I use an audio-only podcast file directly?
YouTube Live normally needs a video programme, so an audio-only file needs a video source such as a still image or visualiser. That adds another input and changes the mapping and timing choices. Test the result with the actual artwork, audio and encoder settings you intend to use.
Is FFmpeg guaranteed to keep the stream online all night?
No. A local process can be affected by power, sleep settings, software failures, network interruptions and changes in the input. Test recovery, protect the stream key and monitor the Live Control Room; no command template guarantees an uninterrupted broadcast.