To play a sequence of local media files from an Ubuntu VPS, put their paths in an FFmpeg concat-demuxer playlist, then pass that playlist as an input with -i. To send the result live, use the ingest URL, stream-key arrangement, protocol, and encoding settings documented by your chosen destination; there is no single command that fits every service.
The playlist describes what FFmpeg reads. The output URL describes where it sends the stream. Those are separate parts of the command, and getting the order right matters: input options belong with the playlist input, while stream selection, encoding and output-format options belong with the live output.
Check FFmpeg and prepare the media files on Ubuntu
Start by confirming which FFmpeg is available on the VPS and which features that build includes. Ubuntu packages vary by release, and the online FFmpeg manual may describe a newer revision than the one installed. Run ffmpeg -version and ffmpeg -protocols to see the version and listed protocols. You can also use ffmpeg -codecs to review codec support. A listed protocol or codec is useful evidence, but it does not confirm that your destination accepts a particular output profile.
Keep the media files and playlist somewhere the account running FFmpeg can read. For example, if you are logged in as ubuntu, a directory such as /home/ubuntu/videos is easier to reason about than a path buried in another account’s home directory. Check names and permissions before building the playlist. A file that works from your desktop may not exist at the same path on the VPS.
Inspect representative files rather than assuming a folder contains uniform media. ffmpeg -i /home/ubuntu/videos/clip-01.mp4 prints information about detected streams; ffprobe can provide a more focused inspection if it is installed. Compare the video and audio streams, codecs, dimensions, frame rates and time bases where relevant. This helps you decide whether the files are suitable for streamcopy or whether they need encoding to a common format.
A playlist does not make mismatched files identical. FFmpeg’s concat demuxer has documented behaviour for some differences, but inputs with different stream layouts or parameters can still produce errors or output the destination cannot accept. Test a representative transition between files before relying on a long sequence. For a YouTube-specific discussion of matching output settings to a particular kind of playlist, see the 720p60 gaming highlights bitrate guide; do not treat its settings as a profile for a different destination or content type.
Create a concat-demuxer playlist
The concat demuxer reads a text file with a header and one file directive for each item. Create a file such as /home/ubuntu/playlist.ffconcat:
ffconcat version 1.0
file '/home/ubuntu/videos/clip-01.mp4'
file '/home/ubuntu/videos/clip-02.mp4'
Use one entry per file, in the order you want the items to play. The paths must resolve on the VPS and be readable by the user who runs FFmpeg. The header must be the first line for the demuxer to recognise this format. If a filename contains spaces, quote it as shown; for unusual characters, consult the concat-demuxer documentation rather than guessing at escaping rules.
By default, the concat demuxer’s safe option is enabled. Its safety check rejects certain paths and directives, including some absolute paths. The example above uses absolute paths for clarity, so the command later includes -safe 0 to permit them. That setting relaxes the check: use it only with a playlist you trust and have reviewed. A playlist that accepts arbitrary entries is not a file to download blindly and run.
If you prefer not to disable safe mode, arrange the playlist and media using path forms permitted by the default check, then omit -safe 0. The exact path rules are documented by FFmpeg. The practical choice is not about making a stream more stable; it is about whether the playlist’s entries meet the demuxer’s safety requirements.
The concat demuxer is not the same thing as an M3U8 playlist. It is a local input format for FFmpeg that describes files on the machine. If your source is instead a segmented network playlist, the input and its handling differ. The M3U8 guide explains that distinction.
Understand FFmpeg input and output option order
A useful mental model is: global or input-side settings, input, output-side settings, output. FFmpeg options generally apply to the next input or output, so their position affects what they configure. The -i flag introduces an input; the final URL or path is an output. The FFmpeg command-line documentation describes this option model, stream selection and streamcopy.
For a playlist being sent in real time, the general shape is:
ffmpeg -re -f concat -safe 0 -i /home/ubuntu/playlist.ffconcat \
[stream selection and encoding options for your destination] \
-f [destination-compatible-output-format] '[documented-ingest-address]'
This is a template, not a ready-to-run universal command. Replace each bracketed item from the chosen platform’s instructions and your media inspection. The -f concat input-format option precedes -i because it tells FFmpeg how to read the playlist. -re asks FFmpeg to read the input at its native rate, which is useful when pushing a prerecorded file sequence as a live stream rather than sending it as fast as possible.
Options after the input generally configure the output that follows. That is where stream mapping, encoding choices, and the output muxer format belong. Do not move an option just because a sample command elsewhere places it differently: check what input or output it is intended to affect. FFmpeg’s Ubuntu protocol manual includes a real-time RTSP example that illustrates a protocol-specific output pattern, but it is not a stream-key recipe for an unspecified service.
The output format flag is also not interchangeable with the ingest URL. -f selects a muxer, while the URL tells FFmpeg where to send the resulting data. Which muxer and transport are appropriate depends on the destination’s current instructions and the protocol supported by your build. FFmpeg documents RTMP and RTMPS, but those protocol names do not establish how a particular platform expects a key to be placed.
Get the ingest URL and stream key from the destination
Before writing the output portion, identify the service or platform that will receive the stream. Find its current official live-streaming instructions and record the ingest protocol, server address, stream-key format, accepted video and audio codecs, and any published encoding recommendations. The title does not name a destination, so it would be misleading to fill in a YouTube, Twitch or other service URL by assumption.
The URL and key may be supplied separately in a platform workflow, or the platform may document a particular way to combine them for an encoder. Follow that exact arrangement. Do not assume that a key always goes after a slash, after a query string, or in a separate field: the receiving service’s documented format controls. If your chosen destination is YouTube, its official live encoder setup guidance is the place to check the current instructions for encoder setup and stream credentials.
Treat the key as a password. Use a placeholder in notes and examples, do not paste the real value into a public post, screenshot, shared ticket or shell command that others can inspect, and rotate it through the destination’s own account tools if it is exposed. Shell history can retain command text, so consider how you will enter and protect credentials on your VPS before launching a process. These are general precautions, not a claim about a specific platform’s key interface.
A destination may offer a primary and backup ingest address, or it may prescribe a different protocol or configuration. Use only the address and failover procedure it documents. If you change an ingest server later, verify the complete URL and key arrangement again rather than changing just one fragment; this checklist for a YouTube server change is relevant when that is your destination.
Build the output command with destination-specific settings
Once you have checked the files and destination documentation, replace the template placeholders. The command below shows the structure, not a guaranteed profile:
ffmpeg -re -f concat -safe 0 -i /home/ubuntu/playlist.ffconcat \
-map 0:v:0 -map 0:a:0? \
[destination-specific codec, bitrate, size and audio options] \
-f [documented-muxer] '[documented-ingest-URL-and-key-format]'
The example uses explicit mapping to select the first video stream and, if present, the first audio stream. The ? makes the audio mapping optional, so a video-only item does not fail solely because it lacks audio. This is a starting point, not a guarantee that all playlist items have matching streams. If some files have multiple audio tracks, no video, or a different layout, inspect them and choose mappings that fit the whole sequence.
There are two broad choices for handling media. With -c copy, FFmpeg passes encoded packets through without decoding and re-encoding. This can be efficient and avoids another lossy encode, but it only works when the input streams are compatible with the selected output format and destination. It cannot apply filters, resize the picture or change a codec. It may also fail if the output muxer needs stream information that the source does not provide.
When files differ, or you need to resize, filter, or convert the audio or video, choose destination-compatible encoders and explicit settings instead of streamcopy. Do not borrow a bitrate, resolution or codec simply because it appears in another streaming guide. The destination’s current documentation and the actual input material determine the choices. FFmpeg’s manual explains -map and -c copy; the platform documentation must supply the receiver-specific requirements.
If you are not certain which path is suitable, make a short local test output first or test with an unlisted/private destination workflow where supported. Look for errors about incompatible streams, missing codecs, or muxing. A successful local encode still does not prove the remote service will accept the stream: the connection, URL, key and destination profile need their own test.
Test playback and connection before relying on the stream
Start with the playlist, not the live service. Run FFmpeg against a short sample or a copy of the playlist and check that it opens every file in the intended order. Watch the output for missing-file errors, timestamp warnings and stream-selection messages. If the process stops at the second item, verify that path and its permissions before changing encoding options.
Next, check the connection using the destination’s supported test or preview workflow. Keep the stream private or unlisted if the platform provides a way to do so and that suits your purpose. Confirm that the destination sees both picture and sound, that the sequence advances at the expected points, and that the selected stream appears in the platform’s diagnostics. A successful FFmpeg connection message alone is not the same as a confirmed, viewable broadcast.
If the image appears but sound does not, inspect the input’s audio streams and make the mapping explicit. If FFmpeg reports a protocol or connection failure, check the installed build’s protocol list, the exact documented ingest address, network policy on the VPS, and the key arrangement. If the platform receives the stream but rejects or flags its encoding, compare the actual output with its current requirements instead of cycling through arbitrary values.
For a long-running channel, a successful short test is only one check. It does not guarantee an uninterrupted broadcast: the VPS process can stop, network conditions can change, media can be malformed, and the destination can alter its requirements. Decide how you will observe errors and restart the process, and test the recovery steps separately. If the pain is having to keep a terminal session or your own computer available to run a prerecorded loop, StreamNeo removes that specific manual runtime task by letting you upload a file and run the YouTube broadcast without leaving your computer on; it does not change the need to check the destination’s current rules.
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 one FFmpeg command for any streaming platform?
No. The general pattern of reading an input and writing to an output is shared, but the ingest address, key placement, protocol, muxer, codecs and encoding recommendations depend on the destination. Use the service’s current official instructions to fill in the output part.
Should I use -safe 0 with my playlist?
Only if the playlist contains paths that the default safe check rejects and you trust every entry. Disabling safe mode permits unsafe paths and names, so review the playlist rather than using the flag automatically. You can instead organise paths to comply with the default rules.
Is -c copy the best way to stream the files?
It is suitable only when the files’ encoded streams are compatible with one another, the output format and the destination. Streamcopy avoids re-encoding but cannot filter or convert media, and it can fail when the muxer cannot use the source stream information. Inspect the inputs and test the sequence before choosing it.
Does a successful test mean the stream will stay live?
No. A test confirms only that the tested files and connection worked at that time. It does not promise continued operation, so plan how you will detect a stopped process or failed connection and verify the destination’s current guidance before a later change.