To stream a 24/7 YouTube playlist with separate video and audio files from a VPS, run FFmpeg with the video and audio as distinct inputs, map one stream of each type into a single output, and send that output to YouTube over RTMPS. The files must be checked for compatibility, and the transitions must be tested before you leave the process unattended.
The important part is not a universal command: there is no safe one-size-fits-all command for arbitrary media. Build compatible playlists or normalise them first, decide how their durations should align, then use the current ingest address and stream key shown for your YouTube broadcast.
How separate playlists become one live output
A playlist of video files and a playlist of audio files are not automatically one programme just because FFmpeg can open both. Think of them as two independent inputs. Your output needs a video stream selected from the video input and an audio stream selected from the audio input. FFmpeg’s stream mapping makes that choice explicit; the output muxer packages the selected streams together for delivery.
There are two distinct jobs here. First, each playlist must produce a continuous input, whether by concatenating compatible files, by filtering and encoding mismatched files, or by arranging a deliberate schedule. Second, the combined output must continue long enough for the intended broadcast. A process that ends when one input reaches its end is not a 24/7 channel, even if the other playlist still has material.
Decide whether your audio and video are meant to be paired or merely run alongside one another. A devotional channel might pair a particular bhajan recording with a matching visual sequence. A lofi station might run a long audio rotation beneath a separate collection of slowly changing scenes. Those are different schedules, and they need different handling when one side runs out or loops.
If both inputs loop independently, each reaches its next cycle according to its own total duration. A video rotation lasting longer than the audio rotation will not restart at the same moment as the audio. If each visual item must accompany a particular track, construct a paired order and verify that the durations match closely enough for the transition you want. Do not assume that unrelated lists stay synchronised.
For a broader look at why a broadcast can stop when its media list ends, see why a 24/7 study stream can stop at the end of a playlist. The same distinction matters here: playlist order is a content decision, while looping and process recovery are playback decisions.
Prepare the video and audio inputs
Start with an inventory, not a command copied from someone else. Record the file names and intended order for each side. Inspect representative files, and any files that seem different, for container, video and audio codecs, dimensions, frame rate, sample rate, channel layout and duration. FFmpeg’s documentation describes the tool and its options; the right inspection method depends on the build installed on your VPS.
Keep the two playlists in separate, clearly named lists. Use full paths where possible, especially when FFmpeg will run from a service directory rather than your interactive shell. Check for missing files, spelling differences, unreadable permissions and accidental duplicates. A list that works while you are in one directory can fail after a scheduled service starts elsewhere.
The video list and audio list need not contain the same number of entries, but you must decide what a mismatch means. If the programme uses one long audio bed and repeated video, document when the video repeats and when the audio is expected to end. If every track has a corresponding visual, make a paired schedule or a single ordered set of matching pairs. A loose pair of independently looping lists can drift in and out of alignment.
Make a short test copy of the sequence using the actual opening, middle and boundary files. Include a file with a different codec or frame rate if one exists. Watch and listen through the boundary between items; opening each file on its own is not enough to establish that the transition works. This catches changes in resolution, a black frame, an audio gap, an unexpected level jump or an abrupt switch in scene.
Storage is part of preparation. The VPS must be able to read the source files for the duration of the broadcast, and the account must have room for any converted copies and logs you retain. Do not infer a VPS size from the title of a tutorial: whether FFmpeg copies streams or transcodes them changes the processing load, while resolution, bitrate, storage and provider limits also matter.
Use the concat demuxer for compatible files
FFmpeg offers more than one way to join media. Its concat demuxer can read a list of files as a single input without re-encoding, but that convenience is conditional. The files need compatible stream characteristics and suitable timestamps; the fact that they share a filename extension, or play separately, does not establish compatibility. FFmpeg’s FAQ on concatenation explains the distinction between the concat demuxer and other concatenation approaches.
For compatible video files, create a text list in the order they should play. The demuxer’s list format uses file entries; paths need to be valid from the process’s working directory, and unusual path characters require care. Build a second list for audio if those files are also compatible with one another. The video and audio lists remain separate inputs to the later mapping step.
Do not treat a successful start as proof that the whole list is safe to leave running. The first file may decode while a later one fails, or a boundary may reveal a time-base or timestamp issue. Exercise the complete playlist, including its last-to-first transition if it is meant to repeat. If the duration reported for a concatenated input is wrong or the output stalls at a boundary, inspect the files and list rather than assuming YouTube caused it.
The demuxer is useful when avoiding an extra encoding pass is important and the source material already agrees. It does not make mismatched material consistent. When the files vary in ways that matter to a single output, use an encoding and filter workflow instead; that is more work and consumes more VPS resources, but gives you a defined output format.
Normalise inputs that do not match
Normalisation means choosing an output shape and converting the inputs to meet it. Decide the intended video dimensions and frame rate, video codec and pixel format, audio codec, sample rate and channel layout. There is no universal correct set for every channel: use settings appropriate to your source, audience and current YouTube requirements, and check YouTube’s official guidance before settling on a profile.
With FFmpeg, the concat filter is the documented route when streams must be re-encoded as part of joining. A filter workflow can scale or pad video to a common frame, set a consistent frame rate, and resample audio to a common rate and channel layout. It also gives you a place to address timestamps and levels. The exact filter graph depends on the input streams and desired output, so it should be derived from inspection rather than pasted as an assumed-tested recipe.
Normalising each file to a common intermediate format before assembling the playlists can make later playback easier to reason about. It also creates additional files and takes time and storage. Alternatively, filter and encode as the broadcast is produced; that avoids an intermediate library but places the encoding workload on the VPS during the live process. Test performance with the actual media, because there is no general VPS sizing number that applies to both stream-copy and transcoding workflows.
Pay particular attention to audio loudness and transitions. A stream can be technically valid yet uncomfortable if one track is much louder than the next. Listening to the source files alone may not reveal an abrupt difference when played in sequence. Apply a consistent loudness approach only after deciding what level you want, then listen to the result on ordinary speakers or headphones. Avoid assuming a filter will repair clipped or poor-quality source audio.
Normalisation can also alter the visual character of a file. Scaling can add borders or crop content depending on the filter choices; frame-rate conversion can duplicate or omit frames. Review representative material and transitions at the intended output size. If you need a useful troubleshooting reference while checking media on a VPS, see how to fix FFmpeg failing to open video files on a VPS.
Map one video stream and one audio stream
Once each playlist behaves as an input, the combined output requires explicit stream selection. In schematic terms, FFmpeg opens the video playlist input and the audio playlist input, maps the video stream from the first and the audio stream from the second, then sends the selected streams to an output. The input numbers and stream indices depend on how your invocation is arranged, so treat this as a workflow description rather than a ready-to-run command.
Mapping is valuable because it avoids relying on automatic stream selection. A video file may contain an audio track you do not want, or a container may expose additional streams. Explicitly choosing the intended streams helps prevent the output from using incidental source audio instead of the separate audio playlist. Check FFmpeg’s console output to confirm that the mapped streams are the ones you meant to send.
You must also choose whether streams are copied or encoded for output. Stream copy avoids encoding, but only works when the selected streams and their container/output requirements are compatible. Encoding lets you establish consistent output settings, but increases processing demand and can introduce quality changes. FFmpeg documents support for RTMP variants and output via the FLV muxer in its protocol documentation; your installed build and media still determine viable options.
Do not build a long-running process around a test that only checks whether a file opens. Confirm that the combined output contains both audio and video, that audio is present when the video changes, and that neither side ends earlier than intended. If the audio and video playlists have unequal total durations, choose an explicit policy: loop one independently, stop and restart both as a pair, or prepare a schedule with matched boundaries.
For a channel that needs predictable recurring content, consider the schedule as well as the stream command. A list of files can be technically sound and still produce the wrong show if a late-night item appears at the wrong time. This guide to recurring YouTube video scheduling for Indian time zones may help frame that separate planning question.
Send RTMPS to YouTube and test transitions
For a straightforward FFmpeg-to-YouTube workflow, use RTMPS. YouTube describes RTMPS as RTMP secured with TLS/SSL and documents its connection on port 443 in YouTube Help. Retrieve the active ingestion address and stream key from the current Live Control Room setup, or use the documented LiveStreams API fields. Do not copy an old example URL as though it were your account’s current destination.
Keep the stream key private. It is a credential that allows someone to publish to your broadcast configuration. Do not put it in a public script repository, paste it into a screenshot, or include it in an article or support message. If your deployment needs the key when a process restarts, use an access-controlled method suited to your VPS and take care that logs do not expose it.
FFmpeg’s RTMP documentation gives the general shape of sending an output with the FLV muxer, and includes RTMPS among supported protocol variants. This does not make every FFmpeg build, input or option combination interchangeable. Confirm that your installed build supports the required protocol and that the output settings fit the streams you selected. Use the current endpoint supplied by YouTube, with your own key, rather than a literal credential or unverified URL from an example.
Before a long broadcast, start a private or otherwise appropriate test in the YouTube Live Control Room and inspect the preview. Confirm that YouTube receives both audio and video, and listen through transitions from one audio file to the next. Watch video boundaries as well: look for a black interval, frozen frame, unintended crop or a change that breaks the channel’s visual style. A short preview is useful, but the full sequence should also be checked if its later files differ from the first ones.
Test the loop boundary, not only transitions inside the list. Verify that the last item reaches the first as intended and that the output does not terminate when a source reaches its end. If the audio list and video list loop on different schedules, observe the point at which their cycles diverge. Adjust the schedule if the result is not what viewers should hear and see.
RTMPS is a practical starting point for this workflow. HLS is not just another interchangeable destination flag: YouTube’s HLS setup guidance describes a segment-based path and requires muxed audio and video, with generally higher latency than RTMP-based ingestion. Consider it when your use case or media requirements call for HLS, and follow its distinct setup requirements rather than translating an RTMPS command by guesswork.
Keep the VPS process recoverable
A VPS removes the need to keep your own desktop switched on, but the process still needs operational care. Monitor FFmpeg’s output and the YouTube preview, keep enough disk space for media and logs, and decide what should happen if the network connection, process or VPS fails. A running process is not the same as an observed broadcast.
Use a process supervisor or equivalent service management appropriate to your operating system so you can define how the process starts and what happens after it exits. Test a restart deliberately before relying on it. Make sure the restarted process can read the playlist files, obtain the credential without exposing it, and return to the intended point in the programme. A basic restart from the beginning may be acceptable for a loop, but could be wrong for a time-sensitive schedule.
FFmpeg documents an RTMP FIFO muxer example that can attempt recovery after temporary failures. Treat that as a documented mechanism to evaluate, not a promise that YouTube delivery will remain uninterrupted. Recovery behaviour depends on the failure and the surrounding process. Plan to check the broadcast after a restart and to understand whether the player resumes, reconnects or requires a fresh action in your Live Control Room.
Keep a simple runbook with the exact media lists, output profile, current credential location, service start and stop procedure, and a way to check recent logs. Do not keep the secret itself in the runbook. Note which file is expected to play at a given time so you can tell whether a recovery resumed correctly or restarted the wrong portion of the schedule.
If you would rather avoid maintaining a VPS process and separate file inputs yourself, StreamNeo can remove that specific operational burden by taking an uploaded video and running it as a 24/7 YouTube live stream without your computer left on. It is YouTube-only, so it is not a fit if you need to publish the same workflow to another platform or need the control of an FFmpeg setup on your own VPS.
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 use any video files and audio files in separate concat lists?
No. The concat demuxer is intended for compatible streams, and a shared file extension does not establish compatibility. Inspect the codecs, timing and other stream properties; if they do not match suitably, use a filter and encoding workflow or normalise the files first.
Will separate audio and video playlists stay in sync when they loop?
Not necessarily. If they have different total durations and loop independently, they reach their next cycles at different times. Pair items deliberately, match durations where needed, or decide which input should continue or restart when the other reaches its boundary.
Where do I find the RTMPS address and stream key?
Get the current ingestion details from YouTube Live Control Room or the relevant LiveStreams API information for your broadcast. Keep the key private and avoid copying an old static example as your endpoint; account and broadcast details can differ.
Does a VPS and FFmpeg command guarantee a 24/7 broadcast?
No. A process can fail, a connection can drop, and a media boundary can expose a problem that did not appear in a short test. Supervise the process, test recovery, and check the YouTube preview rather than treating any command or recovery option as a guarantee.