If FFmpeg stops after one podcast episode, a likely explanation is that it has finished the finite file or playlist it was given. That is not a confirmed diagnosis without the command and logs: an output error, a missing next file or a YouTube ingest problem can look similar from the outside.
First establish where playback ended. If the input reached its end, make the intended episode sequence and loop that input; if FFmpeg is still running or reports an output error, investigate that path instead. The option -stream_loop -1 requests indefinite repetition and belongs before the -i for the input it should repeat.
Check whether FFmpeg reached end of input
A podcast episode stored as a file has a final packet. An ordered list made from several files has a final packet too. FFmpeg processes those inputs and, unless told otherwise, finishes when it has consumed them. A YouTube Live broadcast does not automatically restart a local file or ask the encoder to play it again. The upload endpoint receives what FFmpeg sends; it does not decide how the source media should repeat.
That makes ordinary end-of-input behaviour a useful first possibility to test, not a conclusion to assume. You have not established that FFmpeg reached EOF merely because the public live page stopped changing. The process might have exited at EOF, failed to open the next file, encountered a read or decode error, or remained alive while its connection to YouTube failed. Without the command, input list and visible logs, those cases remain open.
Look at the last media input FFmpeg says it opened and the last events before the process stopped. If the log shows normal packet processing up to the end of the episode, then input completion becomes plausible. If the next episode is never mentioned, inspect how it is named and supplied. If FFmpeg continues emitting output while Live Control Room reports trouble, look beyond local EOF to the output connection and stream health.
There is a useful distinction between stopping at an episode boundary and failing during a transition. A process that exits cleanly after the last listed file suggests a finite sequence. A process that opens the next file but reports stream, timestamp or decoding problems points towards compatibility or media integrity. A stream that continues locally while YouTube reports an ingest warning points towards output settings or connection health. The evidence should choose the branch before you change flags.
For a broader check on whether the public broadcast has actually ended or is merely stale, see how to check whether a recorded sermon stream is still live on YouTube. A public page alone is a poor substitute for the encoder process state and the channel's live dashboard.
Expose logs and record the exit code
Run the same command with ordinary FFmpeg log output visible. Temporarily remove -loglevel quiet, shell redirection to /dev/null, or any wrapper that discards standard error. Keep the command itself unchanged for this observation where practical; changing loop settings and output options at the same time makes the result harder to interpret.
Record three things: the last input FFmpeg opened, the final warning or error, and the process exit code. The exit code is available from the shell that launched FFmpeg, though exact syntax depends on the shell or service manager. In a simple POSIX shell, $? immediately after the process exits reports the most recent command's status. In a script, capture it before running another command or it will be overwritten.
An exit status alone does not tell you why the process ended. Read it beside the last log lines. An orderly completion after processing the final listed input differs from an error during decoding or output. FFmpeg also has -xerror, which can stop processing when an error occurs. If your existing command uses error-related options, note them before interpreting a non-zero or early exit; those options affect how errors are handled.
If FFmpeg runs under a service, scheduled task or terminal multiplexer, check that supervisor's record too. A process can be stopped by an external timeout, machine restart or operator action rather than by its own input reaching EOF. Do not infer that YouTube caused a process exit simply because the public player stopped updating. First establish whether the encoder process is still alive.
A compact log note can be practical: date and start time, command with the stream key removed, final few log lines, exit status, and whether YouTube Live Control Room showed an error at the same time. Do not publish or send a real stream key with a diagnostic. If you need help from someone else, replace the key and any private ingest details with placeholders while preserving option order and filenames.
Build the intended ordered episode input
For several episodes, make one explicit ordered input rather than hoping a shell wildcard or folder listing matches the intended programme. A concat-demuxer manifest can list relative file paths in order, for example:
ffconcat version 1.0
file 'episode-01.mp4'
file 'episode-02.mp4'
file 'episode-03.mp4'
The first line identifies the concat format. Each following line names one file, in the order it should play. Relative paths are resolved from the working directory used to run FFmpeg, so either run from the directory containing the files or use paths that resolve correctly from the actual launch location. The manifest can be stored elsewhere, but that does not change the need to make the media paths unambiguous.
A structural command for that input is:
ffmpeg -re -stream_loop -1 -f concat -i episodes.ffconcat [encoding and output options] "$YOUTUBE_RTMPS_INGEST_URL"
This illustrates input order and looping, not a complete command for an unseen channel. The output codec, mapping, dimensions, bitrate and endpoint depend on the source media and the settings shown in your current YouTube Studio setup. Replace the placeholder only with the channel's current ingest address and key, and keep the key private. Do not copy a generic command's encoding values without checking whether they suit the actual files and YouTube's current guidance.
The concat demuxer reads files sequentially as if their packets were part of a single input. That can avoid re-encoding when the files are compatible, but it does not make arbitrary episode files compatible. They need matching streams, including codecs and time bases. Differences in duration and inaccurate duration metadata can also lead to timestamp gaps or visible and audible artefacts at a boundary.
Before putting a long broadcast on air, test the manifest locally and watch or listen across every transition, including the last-to-first transition once looping is enabled. If one episode has different stream properties, identify that before broadcasting. FFmpeg's concat demuxer documentation describes the format and its constraints; its FAQ on concatenating files discusses workflows such as the concat filter where re-encoding is needed. The filter has its own stream and timestamp requirements, so normalise incompatible sources deliberately rather than expecting it to remove every difference automatically.
Place -stream_loop -1 before its input
The loop flag is an input option. Put it before the -i whose input you want repeated. For one file, the structural shape is:
ffmpeg -re -stream_loop -1 -i episode.mp4 [encoding and output options] "$YOUTUBE_RTMPS_INGEST_URL"
The position matters: options before an input generally configure that input, while options after it apply later in the command. Putting -stream_loop -1 after the relevant -i does not configure that already-opened input to repeat. For a concat manifest, put the loop option before the concat input's -i, as in the previous section. Consult the FFmpeg command-line documentation if your command has several inputs and you need to check which options belong to which one.
The -1 value requests indefinite looping. It does not turn several separate -i arguments into a playlist, repair a missing path, or make different files compatible. It repeats the input associated with the option. For multiple episodes, that input should be the ordered concat sequence if you intend the whole sequence to repeat; applied to one episode, it repeats just that episode.
For a file-based live output, -re is commonly used to read at the media's native pace rather than send the file as quickly as the machine can process it. FFmpeg documents it as equivalent to a read rate of one. That is a pacing choice, not a looping option. Do not apply a low read rate indiscriminately to an actual capture device or other live input; FFmpeg warns that limiting read speed there can cause packet loss.
Looping can make an awkward edit repeat all night. Listen to the end and beginning together: an abrupt cut, silence, an unfinished sentence or a loudness change may be more noticeable on repeat than during a single episode. For a podcast with several episodes, confirm the sequence returns to the intended first episode and does not include a temporary test file. If you need different ordering or transitions, solve that in the playlist or media edit, not by moving the loop flag.
Verify the playlist and files
When FFmpeg never reports opening the next episode, check the manifest actually passed to the running process. Confirm its name, order, spelling, extension, quoting and directory. On a Linux machine, filenames are case-sensitive; Episode-02.mp4 and episode-02.mp4 may be different paths. A manifest created on one computer can also contain absolute paths that do not exist on the machine running FFmpeg.
Check the process's working directory, especially when a scheduled job launches the command. A command that works in an interactive terminal may run from a different directory when started by a service or cron-like scheduler. Use paths that resolve in that context, and confirm the account running FFmpeg can read every file. Do not assume that because the first episode opens, every later path is valid.
If the next file opens but playback errors or jumps at the boundary, compare the streams rather than simply appending more files. Differences in codec, stream count, time base, sample rate or timestamps may matter to concat. Check whether an episode has a shorter or longer duration than its metadata claims. A local test that plays through the boundary is more informative than just checking that each filename exists.
You can also test a short copy of the intended sequence before sending it to YouTube. Keep the same manifest, working directory and relevant input options, but direct the output to a local file or preview where appropriate. That helps distinguish input and transition problems from ingest problems. Do not expose your real stream key in a shared test command or log.
Creators using OBS rather than FFmpeg face a similar distinction between a playlist and a looping setting. The practical steps differ, but configuring OBS to restart a media playlist is a useful comparison if you are considering changing tools rather than fixing the FFmpeg input.
Compare FFmpeg output with YouTube stream health
Input completion and output health are separate questions. A local file can finish normally while the YouTube broadcast also has an ingest issue; conversely, FFmpeg may continue sending packets while YouTube reports that the feed is unhealthy. Compare timestamps: note when FFmpeg's last output or error occurred and when Live Control Room showed its health message. Matching times help narrow the path, but the dashboard message and encoder log still need to be read on their own terms.
YouTube's live error guidance describes problems involving codecs, bitrates, audio and video stream counts, channel count, frame rate and keyframe frequency. Check the specific warning shown for your stream instead of guessing from a generic recipe. Its encoder settings guidance recommends RTMPS and a two-second keyframe frequency; confirm the current requirements and settings applicable to your channel and ingest mode before changing output options.
FFmpeg's protocol reconnect settings are not a substitute for looping a local episode. The reconnect family concerns network input behaviour, while reconnect_at_eof treats EOF as an error for reconnect purposes and is described for live or endless streams. A local file or finite concat input reaching its last packet is an input-completion case; an RTMP or RTMPS output failure is an output connection case. Read the FFmpeg protocol documentation and the actual log before adding reconnect flags.
If FFmpeg remains active, look for output-side errors around the same time as YouTube's health warning. If FFmpeg exits after the finite input is exhausted and YouTube has no corresponding ingest error, work on the input sequence and loop placement first. If YouTube flags an audio, video or timing mismatch while FFmpeg continues, check the output configuration against the current Studio guidance. A general guide to a continuous FFmpeg playlist, such as streaming Kannada songs continuously with FFmpeg, can provide context, but it cannot confirm that your particular command is correct.
For a creator who would rather not keep a local FFmpeg process and computer running, StreamNeo removes that specific operating burden by taking an uploaded video and running it as a YouTube live stream while the computer is off. That does not diagnose an existing FFmpeg command, and it is YouTube-only; check that a managed workflow fits your intended playlist and channel before switching.
Once you have confirmed the input sequence, the loop position and a clean local transition, you can decide whether to keep operating the command yourself or use a managed workflow.
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
Why does FFmpeg stop after one podcast episode?
A likely cause is that FFmpeg was given one finite file, or a finite ordered list, and reached its end. That is only a hypothesis until you check the command, final log lines and exit status; missing files, output errors or external process termination can produce a similar symptom.
Where should -stream_loop -1 go?
Put it before the -i for the input that should repeat. For several episodes, make the intended ordered sequence a concat input, then put the loop option before that input's -i.
Does the concat demuxer automatically loop episodes?
No. It reads the manifest's files in order and finishes at the end of that sequence unless the input is looped. The files also need compatible stream structures, and you should test the timestamps and transition before broadcasting.
Could YouTube Live be stopping FFmpeg?
A stopped public player does not show whether the FFmpeg process exited or remains active. Check FFmpeg's logs and exit status alongside timestamped Live Control Room health messages; an ingest warning is distinct from FFmpeg reaching the end of a local input.