To run two distinct prerecorded loops on one Linode, use two independent FFmpeg processes. Each process should read its own file and publish to the YouTube Live event and stream key intended for that loop.
This is a reasoned architecture based on YouTube’s encoder workflow and documented VPS looping approaches, not a hands-on test of this exact two-process configuration. Treat the processes independently for supervision and health checks, while remembering that both still depend on the same server and network connection.
Choose two independent loop streams
Start by deciding whether you really need two separate live events. If you have a bhajan loop for one audience and a study ambience loop for another, each with its own video and destination, two independent outputs are a good fit. One process handles one input and one event; the other handles its own input and event.
That is different from sending one programme to two destinations. A single feed redistributed to two endpoints has one source and a relay or multi-output arrangement; it is not two distinct loops. If you need to rotate a folder of clips within one broadcast rather than run two separate channels of content, a playlist design may fit better. See the guide to looping a folder of videos into one YouTube Live stream.
The two-process layout makes it easier to change or restart one loop without intentionally changing the other process. It does not promise isolation from shared failures: a Linode reboot, exhausted network capacity, account-level issue or YouTube-side interruption can affect both. Independent processes reduce one kind of coupling, not every kind.
It is also worth checking that your channel is able to create and run the intended live events. YouTube’s live streaming setup guidance describes the setup workflow; check the current official instructions and your account’s Live Control Room before configuring the server. A technically correct encoder cannot resolve a channel eligibility or event configuration issue.
Prepare separate inputs and YouTube events
Prepare one input file for each loop and label them so you cannot confuse them during setup. For example, aarti.mp4 might be the devotional loop and study-ambience.mp4 the second programme. Keep the files in separate, clearly named paths or directories, and confirm that each plays correctly with its audio intact before making it a live input.
The two events should also be easy to distinguish in YouTube Studio. Create or select an event for each broadcast, and note which title, scheduled details and stream credentials belong together. The event destination is not determined by the filename: it is the URL and key configured in the encoder. A copy-and-paste mistake can send the right picture to the wrong event, so match each event, file and process explicitly in a small checklist.
Treat each stream key as a credential. Store it where only the required account and operator can access it, avoid posting it in screenshots or public logs, and do not reuse a key simply because it is convenient. YouTube’s encoder setup instructions explain that the encoder uses a server URL and stream key. Follow the current Live Control Room instructions for the events you create.
If a channel cannot start an event as expected, investigate the event and account state before repeatedly restarting FFmpeg. Our guide on finding a YouTube stream that does not appear on the channel covers one kind of event visibility confusion. Keep the distinction clear: a process can be publishing successfully while the event, privacy, or channel configuration still needs attention.
Check your source files for practical compatibility as well. A container extension alone does not tell you whether the contained video and audio streams are suitable for the output you plan to send. Stream copy can avoid re-encoding when the input streams and container already suit the intended output, but it is not a universal fix for every media file. If your source is a MOV file, the MOV and MP4 streaming comparison can help frame what to check; test the actual file rather than assuming its extension settles compatibility.
Configure one FFmpeg process per input
Think of each FFmpeg command or service definition as a separate, complete job. Process A reads the first file, loops it, applies the chosen output behaviour and sends it to event A. Process B does the same for the second file and event B. Keep their configuration distinct rather than trying to make a single command perform both jobs invisibly.
For a file that is suitable for stream copy, an FFmpeg loop commonly uses -re to read at a real-time rate and -stream_loop -1 to repeat input indefinitely. A simplified pattern is:
ffmpeg -re -stream_loop -1 -i /path/to/aarti.mp4 [output options] [YouTube destination]
The second process uses its own input path and output options. This is a pattern, not a paste-ready command: the right options depend on the file’s codecs, audio, container, desired resolution and YouTube’s current ingest guidance. The example should not be taken to mean every MP4 can safely be copied without conversion, or that every input will loop seamlessly at the file boundary.
If a file requires conversion, specify and test the conversion settings rather than assuming the server can transcode it indefinitely. Re-encoding video uses more CPU than passing through a compatible encoded stream, and two simultaneous conversions compete for the same instance resources. The chosen output settings need to suit each source and the capacity you have measured. YouTube publishes encoder options and recommendations, but those recommendations do not certify a particular Linode size for your workload.
YouTube currently lists RTMP and RTMPS ingest and recommends RTMPS for encrypted delivery to its servers. Its settings guidance recommends constant bitrate and a two-second keyframe interval, with the interval not exceeding four seconds. The official encoder settings and bitrate page is the source to recheck when choosing codecs, resolution, frame rate, audio and bitrate; the guidance can change.
For each input, preview the beginning, a representative middle section and the loop transition. A file that plays locally may still reveal an audio gap, black frame, unexpected aspect ratio or codec issue in the live output. Do not debug both streams at once if you can first test each configuration separately with its matching event and credentials.
Give each process its own destination and key
The most important configuration boundary is the output destination. Process A must use the server URL and stream key associated with event A; process B must use the URL and key for event B. Do not point both commands at the same event if your intent is two separate live programmes. The two inputs and the two event credentials should form a one-to-one mapping.
Keep secrets out of command histories and logs where possible. A process manager configuration may itself expose values to users with access to the machine, so limit account permissions and file access accordingly. If a key is disclosed, use YouTube Studio’s current controls to replace or manage it rather than assuming that hiding a terminal window has revoked it.
Use explicit names for service units, process labels, log files and alerts: for example, loop-aarti and loop-study. Names should help you answer quickly which input and event are associated with a failing process. When changing one stream, verify that you are editing its own unit and key rather than a copied configuration for the other.
A clean mapping also improves recovery. If the devotional event reports a problem, you can check the devotional process and event without treating the other programme as the same feed. This is especially useful when the loops have different bitrates, content schedules or audio needs. Still, a shared network or host issue can appear in both health checks, so compare their symptoms rather than assuming every simultaneous alert has an independent cause.
Supervise and health-check streams independently
A process that was started once is not a 24/7 operating plan. Arrange a supervisor or equivalent mechanism to notice when each FFmpeg process exits and to restart it according to a deliberate policy. Give each process its own restart status and logs. Test what happens after a process exits and after a network interruption before depending on unattended operation.
Separate supervision matters because one FFmpeg process can fail while the other continues, but only if the configuration and monitoring let you see that distinction. A single wrapper that reports only “the stream host is running” may conceal that one child process has stopped. Check each process, each event’s Live Control Room health, and the actual picture and sound from a viewer’s perspective.
Health checks should look beyond whether a process exists. Confirm that it is producing output, that YouTube is receiving the expected event, and that the stream health is acceptable. YouTube recommends testing before the broadcast and monitoring stream health during it. For a 24/7 loop, do a representative test of each feed and periodically review both, including their loop transitions and audio. YouTube’s status view and a process status provide different evidence; neither by itself proves everything is working as viewers see it.
Arrange alerts that identify the affected process and event, and decide who will respond at night or during a holiday. A restart loop that repeats without telling you can hide a bad key, unavailable file or repeated ingest rejection. The useful signal is not merely that a restart happened, but whether the stream returned and stayed healthy.
For a single radio loop, the same operational issue is discussed in how to recover a YouTube stream when FFmpeg exits. Apply the principle separately to both processes: test failure and recovery for each, and avoid assuming that the recovery behaviour of one configuration proves the other is correct. The two processes remain on one host, so plan separately for host-level maintenance and outages as well.
Estimate combined server and transfer load
The server must send both outputs at the same time. Add their outbound bitrates for a first estimate, then account for audio and protocol overhead. YouTube’s current H.264 recommendations include 8 Mbps for 720p30 and 14 Mbps for 1080p30; two feeds configured at those respective settings would therefore need roughly 16 Mbps or 28 Mbps of combined video bitrate before overhead. Those are YouTube recommendations, not guaranteed requirements or a promise that your source and connection will sustain them.
| Example output choices | Approximate combined video bitrate | What to remember |
|---|---|---|
| Two H.264 feeds at 720p30, 8 Mbps each | 16 Mbps | Add audio and delivery overhead |
| Two H.264 feeds at 1080p30, 14 Mbps each | 28 Mbps | Check network and transfer capacity, not just CPU |
| One 720p30 and one 1080p30 H.264 feed | 22 Mbps | The outputs need not use identical settings |
The calculation is simple addition, not a capacity test. YouTube also lists lower recommended values for AV1/H.265 at these resolutions, but codec choice must match what your encoder can reliably produce and what the source supports. Check the current YouTube bitrate table rather than treating the examples here as timeless settings.
For monthly transfer planning, a useful approximation is combined Mbps × 0.45 × hours streamed, which gives decimal GB before allowance for audio, protocol overhead, restarts and other account traffic. For instance, use your actual combined bitrate and intended streaming hours in that calculation, then compare the estimate with the current transfer allowance and billing terms for the Linode plan you are considering. This is a planning calculation, not a plan quote. Do not rely on historical community posts for today’s allowances or charges.
CPU and memory needs depend on what the processes do. Two compatible stream-copy jobs are likely to require less processing than two video transcodes, but the exact load depends on source format, output settings and instance. Linode’s NGINX RTMP guide offers general streaming guidance, including advice for relaying or converting; it is not a benchmark for two independent FFmpeg loop processes on a current plan.
Before treating a size as sufficient, run both representative streams together for a sustained period. Observe CPU, memory, network use and dropped frames, and verify the results in YouTube Studio. Check what happens at the busiest expected point, not only while starting one feed. If either stream needs transcoding, test that exact configuration. Increase capacity, reduce output demands or choose a different operating approach if the measurements show inadequate headroom.
Use an RTMP relay only for redistribution
A relay solves a different problem. If you have one incoming live feed that must be forwarded to several destinations, an RTMP relay can accept that source and push copies onward. Linode’s guide describes that kind of arrangement. It can be useful when the sending location should upload one source rather than separately upload to each destination, though the relay still has to send an output to every endpoint.
For two different prerecorded loops going to two different YouTube events, direct FFmpeg processes are usually the clearer architecture: each process already has its own file and destination. A relay does not make two distinct inputs magically simpler, and adding one introduces another service and point to monitor. If you need redistribution later, reassess the relay’s resource and bandwidth needs, especially if it will convert formats as well as forward them.
Do not confuse a relay with backup. A relay can help with distribution topology, but it does not by itself provide a second independent source, host or YouTube event. The same is true of two processes on one Linode: process-level supervision is useful, but the server remains shared. Choose the least complicated arrangement that meets the actual source and destination requirements.
Choose an operating model you can maintain
Running FFmpeg yourself gives you control over file placement, output settings and the server’s process behaviour, but you also own updates, credentials, restart policy, health checks and transfer planning. If you are comfortable maintaining a Linux host and responding to alerts, that control may be worthwhile. If not, a desktop tool such as OBS may be easier where a graphical session and hands-on controls matter, though it brings its own always-on computer and session considerations.
A managed loop workflow shifts server operations elsewhere but makes storage, service availability and fit with your required number and quality of streams vendor questions. StreamNeo turns an uploaded video into a YouTube live stream, which removes the need to keep a personal computer running FFmpeg and notice a stopped process overnight; check that its current terms and supported outputs match your plan before relying on it. It is YouTube-only, so it is not a solution for a requirement to publish to another platform.
Compare choices against the same practical questions: how many distinct feeds you need, whether inputs need conversion, the output resolutions and bitrates, how you will be alerted, who can respond, what transfer limits apply, and how much maintenance you are prepared to do. A lower-complexity approach can be the better choice if nobody will be available to look after a VPS. None of these approaches removes the need to check the event and stream health.
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 one server run two FFmpeg streams to YouTube?
Yes, the design is two concurrent FFmpeg processes, each with its own input and event credentials. Whether a particular Linode can sustain them depends on encoding work, outbound bitrate and transfer capacity, so test both together and monitor them.
Do both loop streams need separate YouTube keys?
Each process should use the stream URL and key associated with its intended YouTube event. Keep the mapping clear and treat the keys as credentials; follow the current Live Control Room instructions for creating or selecting each event.
Will one stream keep running if the other FFmpeg process fails?
Separate supervision can let one process fail and restart without deliberately stopping the other, but this is not a guarantee against shared server or network failures. Check each process and each event independently, and test how your own supervisor responds to an exit or interruption.
Should I use an RTMP relay for two different loop videos?
Usually not: two distinct inputs and two destinations are more directly represented by two independent outputs. A relay is more relevant when one incoming feed needs to be redistributed to multiple destinations.