To run a 24/7 YouTube story stream with FFmpeg, put your video files in the order you want in a concat playlist, then loop that playlist as an input and send it to YouTube Live. The playlist does not sort files for you, and looping the input does not guarantee a healthy broadcast if the host, network, encoder or ingest fails.
For reliable playback, check that clips are compatible before trying stream copy, pace file input in real time, and test the complete path in YouTube Live Control Room. If your files differ in codecs, dimensions, frame rates or audio layout, normalise them or use a filter-based concat workflow that re-encodes rather than assuming they can be joined unchanged.
Enable YouTube Live and get the ingest details
First check that the channel can stream live. YouTube says first-time activation may take up to 24 hours, so enable the feature and verify the channel well before planning a launch. The YouTube Live streaming restrictions checklist can help you find the relevant status in Studio; the current status shown for your channel is what matters.
In YouTube Studio, create or schedule the live stream and open Live Control Room. Copy the server URL and stream key shown in the stream settings. If you select encrypted ingest, use the RTMPS URL provided there. YouTube describes RTMPS as RTMP over TLS/SSL; its live encoder setup instructions explain where to find the connection details and how to configure an encoder.
Treat the key like a password. Do not put a real key in a public command, a shared screenshot, a script repository or a tutorial. In a shell command, use a placeholder while drafting and substitute the key privately when you launch. If you accidentally expose it, replace it in YouTube Studio before using the stream again.
The server address and key are tied to the live configuration you are using. Avoid reusing old copied details without checking the current event. Start the FFmpeg process only after the stream is configured, and confirm in Live Control Room that YouTube receives the signal and produces a preview before you consider the setup ready.
Prepare a playlist in the order viewers should see
The FFmpeg concat demuxer reads the files in the sequence written in its playlist. It does not inspect names and sort them alphabetically or chronologically. If the intended story is introduction, chapter two, then closing scene, write those three entries in exactly that order.
Create a plain text file named stories.ffconcat in the directory where you will run FFmpeg:
ffconcat version 1.0
file 'story-01.mp4'
file 'story-02.mp4'
file 'story-03.mp4'
The first line is an optional format signature, but if you use it for automatic recognition it must be the exact first line, without a byte-order mark. Relative paths make a playlist easier to move along with its media files and normally work with FFmpeg's safe-path checks. Use quoted paths for spaces or escape special characters according to FFmpeg's concat syntax. Check spelling, capitalisation and directory locations before launch; a missing file can interrupt the input.
Absolute paths or other unsafe path forms may be rejected under the default safe-path setting. The command examples later show -safe 0 for cases where absolute paths are needed. Only use that override with a playlist you trust and have created yourself, since it relaxes path restrictions. Prefer relative paths when they fit your folder layout.
Review the playlist as a sequence, not just as a collection. Add a short descriptive note in your own production checklist about the intended order, and verify it against the actual entries after edits. A playlist can be valid yet narratively wrong: FFmpeg will faithfully play the order you supplied, not the order you meant.
Check compatibility before using stream copy
The concat demuxer joins packets from the listed inputs and adjusts timestamps so each file follows the previous one. FFmpeg's concat demuxer documentation says that the files need the same streams, codecs and time bases. If they do not, packet concatenation may fail or produce playback problems. This is why a folder full of MP4 files is not, by itself, evidence that they can be copied together without re-encoding.
Inspect every clip before choosing a no-re-encode workflow. Compare the video and audio streams: codec, dimensions, frame rate, time base and audio layout are among the properties that can differ. A 1080p H.264 clip with stereo AAC is not automatically compatible with a 720p clip with a different frame rate or audio arrangement. Even when the file extensions match, the encoded streams can differ.
The demuxer uses file durations when it adjusts timestamps. Unequal video and audio stream lengths can therefore leave gaps or create visible or audible artefacts at transitions. Incorrect or estimated durations can also affect the result. FFmpeg allows a duration directive to supply a known duration for a file, but only use it when you have an accurate value; an invented duration can make timing worse rather than better.
If all the packet streams are compatible with one another and with the output path, -c copy avoids decoding and encoding the media again. That can reduce the processing load, but it leaves no opportunity to correct incompatible frame sizes, codecs or audio layouts. If the preview shows timestamp, codec, resolution or audio trouble, do not keep retrying the same copy command and hope it settles. Normalise the clips to a shared format first, or use a filter-based concat-and-encode workflow. FFmpeg's concat filter is generally the more suitable route when clips need re-encoding.
For a playlist of devotional stories, for example, you might have recordings from different phones. One clip may use a different frame rate or audio sample rate from the others. You can prepare a consistent set of outputs before going live, then test transitions at the points where the original files meet. The guide to building a 24/7 Indian music channel covers broader channel planning; here, the practical point is that a clean playlist still needs compatible media.
Loop the input and pace it in real time
FFmpeg's -stream_loop -1 option tells it to loop the input indefinitely. Put the option before the -i that refers to the concat playlist, so it applies to that input. For file-based input, -re asks FFmpeg to read at the media's native rate rather than consuming the entire file sequence as quickly as the machine can process it.
A basic input shape is:
ffmpeg -re -stream_loop -1 -f concat -i stories.ffconcat ...
The ellipsis is only a reminder that output options and the destination still need to be supplied; it is not a runnable command. Add -safe 0 only if your trusted playlist needs paths that the default safe-path setting rejects. It is usually better to keep media and playlist in a known directory and use relative paths.
The two options do different work. -stream_loop -1 makes FFmpeg revisit the input after reaching its end; -re controls the read pace. Without real-time pacing, FFmpeg may read a file input faster than its playback duration, which is not appropriate for an ordinary live feed. Neither option watches the network or repairs an encoder process that has stopped.
An infinite input loop is not an infinite healthy broadcast. A computer may sleep or restart, a disk may fill, an internet connection may drop, FFmpeg may exit on an error, or YouTube may stop receiving usable media. The loop only describes input behaviour while the process is running and able to read its source. Plan monitoring and recovery separately.
Choose encoding or compatible stream copy
A general encoded-output template looks like this:
ffmpeg -re -stream_loop -1 -f concat -i stories.ffconcat \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-b:v VIDEO_BITRATE -maxrate VIDEO_BITRATE -bufsize VIDEO_BUFFER \
-g KEYFRAME_INTERVAL_FRAMES -keyint_min KEYFRAME_INTERVAL_FRAMES \
-sc_threshold 0 -c:a aac -b:a 128k -ar 44100 \
-f flv 'rtmps://YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
This is a template, not a tested command. Replace the placeholders with values suited to the selected resolution, frame rate and available upload capacity, and use the actual RTMPS address and key from Live Control Room. The example encodes video as H.264 and audio as AAC. Your FFmpeg build must include the requested encoder and protocol support.
YouTube's current encoder settings guidance recommends CBR, a two-second keyframe interval and settings appropriate to the chosen resolution and frame rate. It lists different H.264 bitrate recommendations for 720p and 1080p, with higher settings for 60 fps than 30 fps. Use the current values on YouTube's page rather than copying a bitrate from an unrelated tutorial. A setting that is reasonable for one upload connection may be too demanding for another.
If every input's packet streams are compatible with the concat demuxer and the output, a copy template is shorter:
ffmpeg -re -stream_loop -1 -f concat -i stories.ffconcat \
-c copy -f flv 'rtmps://YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
Here, -c copy passes the encoded packets through instead of decoding and encoding them. It can save CPU, but it cannot make unlike inputs alike. A stream-copy command is worth trying only after inspection shows the files satisfy the compatibility requirements and a test confirms that timestamps, audio and video arrive correctly. For mixed-source stories, normalising once before the broadcast is often easier to diagnose than discovering transitions are broken during the live stream.
Encoding gives you more control over a common output format but uses CPU capacity. If the machine cannot encode at the chosen settings in real time, output may lag or become unstable. Copying reduces that work but is constrained by the source material. Compare the cost of preparing standardised files with the cost of keeping enough encoding capacity available for a continuous session.
Send the output to YouTube over RTMPS where supported
In the output URL, the stream key is typically included after the ingest URL. Keep the full value private. If you have a command history or a shared automation file, consider how access to that location is controlled; anyone who can read a saved key may be able to send a feed to the associated stream.
YouTube's Live API documentation describes RTMPS ingestion and shows that some encoders expect the stream URL and stream name to be combined. Follow the format that YouTube supplies for the chosen stream and the format FFmpeg expects. Do not append or remove path components by guesswork. The RTMPS endpoint from your current settings is more authoritative than an old command found in a forum post.
The -f flv option in the templates selects the output container used for this RTMP-style delivery. It does not convert unsupported source codecs into supported ones. That is the job of the encoding options, or of preparing compatible media before using stream copy. If the destination rejects the feed or the preview reports a format issue, check the output codecs and container before changing unrelated settings.
Monitor the host, connection, encoder and ingest
A 24/7 channel needs more than a command that starts successfully. The host must stay awake and available, the files must remain readable, the connection must have upload headroom, and FFmpeg must continue producing output. YouTube must also receive and accept the signal. A failure in any one of those places can interrupt the stream while the playlist itself remains correct.
Before the public launch, run a representative test that includes the same kind of movement and audio as the planned channel. Watch the YouTube preview and stream-health messages in Live Control Room. Check the opening, a transition between files, and a point near the end of the playlist before confirming that it loops. YouTube recommends monitoring the preview and stream health rather than assuming a successful FFmpeg start means the audience is receiving a usable picture and sound.
Keep FFmpeg logs and decide who or what will notice an exit. A process supervisor can be configured to restart a failed process, but restart behaviour should be tested deliberately: repeated failures can create a cycle of restarts without restoring a healthy feed. Add practical checks for disk space, file availability and network connectivity, and make sure alerts reach someone who can act on them. These are operational choices, not a guarantee supplied by the concat loop.
A locally hosted stream depends on the local machine and broadband connection being available through the night. A cloud-hosted arrangement can remove the need to leave your own computer running, but it does not remove the need to test the files, ingest and recovery plan. If FFmpeg maintenance, power cuts or a home connection are the particular burden, StreamNeo removes the need to keep a personal computer running by turning an uploaded video into a YouTube live stream, while still leaving you responsible for preparing suitable content and checking the channel.
Also decide how you will keep a copy of the stories. A continuous live broadcast is not the same as a guaranteed full-length archive. YouTube's setup guidance says streams under 12 hours are automatically archived; do not assume a continuous broadcast longer than that will appear as one complete VOD. Check the current YouTube live streaming setup guidance and retain source files or make separate recordings if you need your own copy. For recovery after a dropped session, the guide to preserving a live session after reconnect is relevant to the archive side, but it does not replace a local retention plan.
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 FFmpeg sort files in a concat playlist?
No. The concat demuxer follows the order of the file entries in the playlist. Write the desired story order explicitly and review it before launch.
Can I use -c copy with any MP4 files?
No. MP4 is a container, not proof that the clips contain matching streams. Inspect codec, stream layout, time base and other relevant properties; normalise or re-encode files that do not fit the concat demuxer's requirements.
Does -stream_loop -1 keep a YouTube stream healthy forever?
It repeats the input while FFmpeg remains able to run and read it. It does not prevent a host, network, encoder or YouTube ingest failure, so a continuous channel still needs monitoring and a tested recovery plan.
Will YouTube archive the entire 24/7 broadcast?
Do not assume so. YouTube's published setup guidance describes automatic archiving for streams under 12 hours, which is not a promise that a longer continuous broadcast will be preserved as a complete video. Keep your own source files or recordings if you need reliable retention.