To stream a folder of MP4 videos to YouTube Live from a Vultr server, install FFmpeg, put the files in the order you want in a concat-demuxer list, then send the resulting feed to the RTMPS ingest URL and stream key shown in YouTube Live Control Room. Whether you can pass the files through unchanged depends on their actual video and audio streams; there is no universal command that works for every folder.
The workflow below is for a sequential playlist, not a promise of seamless transitions or an endlessly repeating loop. You will check the media first, choose stream copy or re-encoding accordingly, and test the real sequence in YouTube’s preview before relying on it unattended.
Prepare the Vultr server and install FFmpeg
Start with a Linux server on Vultr that has the videos stored locally or mounted somewhere the account running FFmpeg can read. You also need outbound network access to the YouTube ingest destination. Confirm disk space, file permissions and network capacity for the intended broadcast before configuring the encoder. The research reviewed for this guide does not establish a current Vultr instance size, egress price or bandwidth allowance, so check the current plan terms against your stream’s bitrate and duration rather than relying on an unverified recommendation.
Install FFmpeg using the current package instructions for your server’s distribution and release. Package names, supported releases and repository choices change. Vultr has published an FFmpeg installation guide using Ubuntu 20.04 as its example and listing other distributions, but those examples are dated; treat that guide as background, not as current installation instructions. See Vultr’s FFmpeg guide and check the current documentation for the operating system you have installed.
After installation, verify that the executable is available with ffmpeg -version. This only confirms that FFmpeg starts; it does not show that the required encoders or demuxers are enabled, nor that the server can encode your media at the chosen settings. For a stream-copy workflow, basic FFmpeg support for the input and output formats is still necessary. For a transcode, make sure the build includes the encoder you intend to use, such as libx264 for H.264 video.
Keep the videos in a dedicated directory, for example /srv/videos, and use a predictable naming scheme such as 01-intro.mp4, 02-main.mp4 and 03-outro.mp4. Confirm that the account that will run FFmpeg can read the directory and each file. A process that works in your login session may fail under a service account if the paths or permissions differ.
This is a server-side version of the broader prerecorded workflow described in how to stream prerecorded videos to YouTube 24/7 from a cloud service. The important distinction here is that you are explicitly building a list of files and invoking FFmpeg on Vultr yourself. You remain responsible for the operating system, process supervision and checking the broadcast.
Create a concat list in the desired file order
FFmpeg’s concat demuxer reads a text file containing the inputs in playback order and presents them as one concatenated input. Create a plain-text playlist, for example /srv/videos/playlist.txt, with one file entry per video:
file '/srv/videos/01-intro.mp4'
file '/srv/videos/02-main.mp4'
file '/srv/videos/03-outro.mp4'
The order of these lines is the order FFmpeg reads the files. Use absolute paths where practical so the command does not depend on the working directory. A line for every video makes it easier to review what will air than relying on a wildcard whose ordering may differ from your expectation. Check that each path exists and is readable by the same account that will launch the stream.
The list is not a shell script. It does not need a command prefix, and it should not include the stream key or ingest destination. Filenames with apostrophes or unusual characters need careful escaping in concat-list syntax. The simplest operational choice is to use straightforward names without those characters, rather than troubleshooting a quoting error just before broadcast. Consult the FFmpeg concat demuxer documentation for the exact file-list syntax and limitations.
A playlist ending with 03-outro.mp4 is a one-pass sequence. It does not automatically mean “repeat the folder forever”. If you want a continuous channel, decide explicitly how the sequence should repeat and test that behaviour with your FFmpeg version and actual files. Repetition and transitions should not be inferred from the mere existence of a concat list. If your goal is a continuous music stream with audio carried across video changes, the separate problem is covered in how to keep audio playing between videos on a continuous YouTube stream.
Check whether the files can be stream-copied
Stream copy, written -c copy, passes compressed audio and video packets onward without decoding and re-encoding them. That can reduce CPU load and avoid another generation of encoding loss. It is appropriate only when the inputs can be concatenated and their streams are suitable for the output. MP4 is a container name, not a guarantee that every file inside it uses the same codecs, resolution, frame rate, audio layout or stream parameters.
Inspect representative files, and ideally every file when the folder has been assembled from different sources. FFprobe, distributed with FFmpeg, can report the streams and their properties. For example, run ffprobe -hide_banner -i '/srv/videos/01-intro.mp4' and compare the video codec, dimensions, frame rate and pixel format, along with the audio codec, sample rate and channel layout, across the playlist. Treat the output as diagnostic information, not proof that the concat will play cleanly: the actual test is to run the sequence and inspect what FFmpeg and YouTube report.
If every clip has matching, suitable streams and you do not need to resize, change frame rate or apply filters, a copy-based command may be worth testing. The output muxer and YouTube ingest still need to accept those streams. If a file differs, the sequence may fail, show a discontinuity, or produce output that is not accepted as intended. FFmpeg’s documentation explains that stream copy omits decoding and encoding, but it can be unsuitable when the output needs different stream information or processing.
A quick local test before going live can reveal obvious issues. Try reading or joining the playlist to a local output, then check the resulting duration and playback near each file boundary. Do not assume that a successful first clip proves later clips match. Look for missing audio, unexpected black frames, abrupt changes in level, and warnings about stream parameters. For live operation, send a private or unlisted test event first if appropriate to your channel, and check the preview and health indications in Live Control Room.
| Choice | When it may fit | Main trade-off |
|---|---|---|
Stream copy (-c copy) |
Input streams are compatible, and you want to preserve them without filters or output changes | Low encoding work, but it cannot repair differing codecs or parameters |
| Re-encode | Files differ, or you need consistent resolution, frame rate, codec or filtering | More CPU use and another lossy encode may affect quality |
| Stop and standardise files first | You want predictable inputs and can prepare media before the broadcast | Requires a separate preparation step, but simplifies the live command |
The table is a decision aid, not a compatibility guarantee. If you are not sure what a particular file contains, inspect it instead of guessing from its .mp4 extension.
Encode to YouTube-compatible settings when needed
When stream copy is not suitable, decode and encode the concatenated input to a consistent output. An illustrative starting shape is below. It is not a tested command for your files or a universal setting; adjust the output to the source, the event’s settings in YouTube Live Control Room and YouTube’s current encoder guidance.
ffmpeg -re -f concat -safe 0 -i /srv/videos/playlist.txt \
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \
-pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -ar 44100 \
-f flv 'rtmps://INGEST_URL/STREAM_KEY'
The example shows the overall pattern: read the ordered playlist in real time, encode H.264 video and AAC audio, and mux for the live destination. The placeholder at the end is deliberately not a working address or key. Replace it only with the exact values YouTube supplies for your event, using safer handling than pasting a secret into a saved command. The example’s bitrate and keyframe settings are illustrative values, not a recommendation for every resolution or frame rate.
YouTube’s current encoder settings and bitrate guidance recommends constant bitrate, supports up to 60 frames per second, and recommends a two-second keyframe interval that should not exceed four seconds. Its H.264 guidance lists 10 Mbps for 1080p at 30 fps and 12 Mbps for 1080p at 60 fps. These are YouTube recommendations, not a promise that a particular Vultr plan can sustain the bitrate or that your source will look right at that output. Match resolution and frame rate to what your material can support, then check network capacity and test with representative motion and audio.
Transcoding consumes CPU in a way stream copy does not. If the chosen preset and output settings cannot keep pace with real time on your instance, the feed may fall behind or drop frames. Conversely, lowering the output bitrate too far can reduce picture quality. Watch FFmpeg’s progress output during a test and check YouTube’s preview and stream health. If the source is already suitable, a transcode may add work without solving a real problem; if files differ, a consistent encode can make the output more predictable.
Use YouTube’s exact RTMPS ingest destination
Create or open the live event in YouTube Studio and copy the encoder URL and stream key from Live Control Room. YouTube’s encoder documentation describes these as the destination details your encoder uses. Do not compose the URL from memory or substitute an address from an old tutorial: use the exact RTMPS URL shown for the event and its matching key.
RTMPS is RTMP carried over TLS/SSL, which encrypts the connection between encoder and ingest. YouTube recommends it and provides an RTMPS URL in Live Control Room when you select that protocol; the interface may show RTMP by default. Read the current YouTube RTMPS guidance and confirm that the URL you copied begins with the RTMPS scheme. RTMP and RTMPS are not interchangeable spellings: choosing the encrypted protocol means using the corresponding destination YouTube presents.
The command’s -f flv selects the output format commonly used for this RTMP-family ingest workflow. It does not make an incompatible input compatible, and it does not verify that the address or key is correct. A connection error may result from a mistyped or mismatched destination, network access, or an issue with the event. Change one thing at a time and compare the command’s diagnostic output with the current Live Control Room details.
Do not confuse successful connection with a ready public broadcast. YouTube can show an incoming feed preview before you make a scheduled event live. Follow the on-screen flow: start the encoder feed, wait for the preview and health indicators, then select “Go live” when the event is ready. That gives you an opportunity to catch a wrong file order or missing audio before viewers see it.
Protect the stream key and test the sequence
Treat the stream key as a password. Anyone who obtains it may be able to send a feed to the associated event or channel. Never put a real key directly in a command that you will save, share, screenshot or paste into documentation. Commands may remain in shell history, terminal recordings or process listings; scripts and logs can persist longer than expected. The example above uses placeholders for that reason.
A safer operational pattern is to keep secret material out of the playlist and source control, restrict access to any configuration file containing it, and avoid printing it in diagnostics. YouTube’s interface provides the key; retrieve it only when needed, and consider resetting it in Live Control Room if you believe it has been exposed. After a reset, update the encoder’s configuration and test again. The stream-key recovery guide covers a related issue: keeping track of the correct key when encoder settings change.
Before the first scheduled run, test the full playlist from the same account and environment that will run the live command. Verify that all listed paths are readable, the clips play in order, audio continues as expected, and the feed reaches YouTube. Watch the preview and health messages through at least one file boundary; then check later boundaries if files vary. A test of a short sample is useful for syntax but cannot establish that every transition in a longer folder is sound.
For a recurring channel, decide how the process starts, how you will notice a stopped feed, and how you will restart or end it. A shell session closing, a server reboot, exhausted disk space or a changed key can interrupt a broadcast. FFmpeg can send the feed, but the command alone does not provide an operating plan. If you are comparing ways to run a channel rather than maintaining a server process yourself, how to choose a YouTube streaming service for an Indian music channel discusses the broader decision. StreamNeo can remove the need to keep this FFmpeg process and your own computer running by turning an uploaded video into a YouTube live stream, but it is YouTube-only and does not replace checking that your content and event are ready.
A scheduled event should be ended from Live Control Room and the feed stopped as directed there. YouTube says streams under twelve hours are automatically archived; that is a platform behaviour, not a substitute for verifying the event’s status and archive afterwards. Check the current official instructions, particularly if the broadcast is longer or its archive matters to you.
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 FFmpeg play every MP4 in a folder in order?
Yes, the concat demuxer can read an explicitly ordered file list, but playback depends on the inputs and output being compatible. Check the streams and test the complete sequence; the MP4 extension by itself does not establish that the files can be joined by stream copy.
Can I use -c copy for the whole playlist?
Only if the compressed streams are suitable for concatenation and the intended output. It avoids decoding and re-encoding, but it cannot resize, filter or make differing codecs and parameters consistent. If the files do not match or the output needs changes, test a transcode instead.
Should I use RTMP or RTMPS?
Use the RTMPS destination YouTube displays for the event when selecting that protocol. RTMPS encrypts the connection; copying the exact URL from Live Control Room avoids relying on an address from an old example.
How do I keep the folder playing continuously?
A concat list defines an ordered sequence, not automatically an endless loop. Decide what should happen when the final file ends, and test the repeat behaviour you configure with your actual FFmpeg build and files before treating the channel as continuous.