A 24/7 cartoon stream on Ubuntu can be built by looping an authorised media file with FFmpeg and letting systemd supervise the publishing process. The exact command depends on your Ubuntu release, FFmpeg build, media streams and destination requirements, so treat the examples below as patterns to adapt and validate, not tested recipes.
Looping, sending media at live speed, and publishing to a platform are separate jobs. A service manager can restart a process that exits, but it cannot prove that viewers receive a valid stream or keep a failed host powered on.
Confirm the host and destination requirements
Start by deciding where the stream will go and checking that the machine is suitable for a long-running encode or remux. The destination matters first: obtain its current ingest instructions, including the endpoint, stream key handling, accepted container, codecs, resolution, frame rate and any account or channel conditions. These requirements can change and are not interchangeable between platforms. This article uses RTMP and YouTube as examples, but a command that works for one ingest endpoint may be rejected by another.
If your destination is YouTube, consult its current live encoder settings before choosing output settings. Use the endpoint and key supplied by YouTube for the specific broadcast; do not infer either from an old command or an unrelated tutorial. Keep the key private. A key exposed in a public unit file, shell history, screenshot or log can let someone else publish to your channel.
Check the Ubuntu release and available system resources before configuring the stream. The machine needs a stable network path, enough disk space for the source file and logs, and enough compute capacity for the chosen video processing. Copying compatible streams may use less compute than decoding and re-encoding, but compatibility has to be established against both the file and the destination. No single CPU, bandwidth or bitrate figure applies to all cartoons and encodes, so measure the actual workload rather than relying on a generic estimate.
For a local server, check that the system can remain powered and connected, and consider what happens after a reboot. For a rented host, check its operating limits and whether continuous media distribution is permitted under its terms. If your purpose is simply to keep a prerecorded channel online without maintaining a Linux machine, compare that operational model with a managed approach in options for running 24/7 streams. The right choice depends on whether you need control over the host and command line or prefer not to maintain them.
Put authorised media somewhere stable
Store the source file on a path that will remain available after reboot and that the service account can read. A path such as /srv/cartoon/cartoon.mp4 is illustrative, not a required layout. Avoid relying on a removable drive that may disconnect, a user’s temporary download directory, or a mounted network location that is not ready when the service starts.
Before copying anything into the stream directory, establish that you are entitled to use it in a continuous live broadcast for the relevant audience and territory. The fact that you own a disc, have a downloaded file, or can play a cartoon on your computer does not establish permission to rebroadcast it. Rights can depend on the work, the licence, the territory, the platform and the way the stream is used. Obtain the necessary permission from the rights holder or another appropriate source, and check the platform’s current policies. Neither FFmpeg nor systemd can determine whether the media is authorised.
For a file you are entitled to use, give the service only the access it needs. A dedicated, non-login service account can read the media and its secret configuration without broad write access to the whole host. Keep a working copy and preserve the original. If you replace the source, test the replacement separately: a changed audio track, variable frame rate or unusual pixel format can alter what FFmpeg must do.
This article focuses on one file repeating. A changing programme schedule or playlist is a different problem: transitions, file ordering and recovery from a missing item need their own validation. If you are planning a sequence rather than one continuous cartoon, compare the scheduling concerns in this guide to automating playlist changes with a Bash script and a repeating YouTube Live playlist. Do not assume a multi-file playlist will have seamless transitions merely because each file plays on its own.
Check the FFmpeg build and the media
Different Ubuntu releases and installation sources can provide different FFmpeg versions and enabled codecs. First record what is installed:
ffmpeg -version
ffmpeg -buildconf
Then inspect the source rather than guessing its streams:
ffprobe -hide_banner -show_streams -show_format /srv/cartoon/cartoon.mp4
Confirm which video and audio streams exist, their codecs, dimensions, frame rate and duration. Check for subtitles, multiple audio tracks or unusual stream layouts too. The sample command later maps the first video stream and an optional first audio stream; that may not be the right choice if the file has no audio, has multiple languages, or puts its desired track elsewhere. A file that has no audio can sometimes be sent without an audio stream, but the destination’s current rules still decide whether that is accepted.
Check that the installed FFmpeg has the encoder and muxer you intend to use. For example, an FFmpeg build may not include libx264, or the destination may not accept the proposed output combination. ffmpeg -encoders and ffmpeg -muxers can help you inspect local capabilities. Do not treat a command copied from a different distribution or build as proof that a particular encoder is present.
Choose between copying and re-encoding only after comparing the source against ingest requirements. Stream copy avoids a video re-encode, but cannot change incompatible codecs, dimensions or frame rates. Re-encoding can make the output conform more closely, at the cost of additional processing and a new opportunity for quality loss or resource pressure. For a visual source, inspect an excerpt with the intended settings before making it the unattended output. The FFmpeg documentation describes its options and muxers; use the documentation matching the installed build where possible.
Build a repeat-playback command
FFmpeg’s -stream_loop -1 requests indefinite looping of an input file. -re reads file input at a rate intended to simulate live input; it is not a general fix for a slow or unstable network. FFmpeg documents a file-to-RTMP pattern using -re, and the protocol documentation explains protocol-related options. Keep input options before the corresponding -i, as in this schematic:
ffmpeg -re -stream_loop -1 -i /srv/cartoon/cartoon.mp4 \\
-map 0:v:0 -map 0:a? \\
-c:v libx264 -c:a aac \\
-f flv "$RTMP_URL/$STREAM_KEY"
The example assumes an RTMP-style destination and a build with the named encoders. It does not establish that the endpoint accepts H.264, AAC or FLV, that those maps match your file, or that the resulting encode fits the host. Replace the output settings only after consulting the destination’s current specifications. FFmpeg’s documentation includes an RTMP example, but the destination’s own ingest rules remain authoritative.
Do not paste a real key into the command while experimenting in a shared terminal. In a shell, command history may preserve it. For systemd, one practical pattern is to keep sensitive values in a root-readable environment file and refer to variables in the unit’s command. The exact mechanism depends on the host’s security model. Restrict permissions on any file containing a key, and avoid printing expanded commands or secrets into logs. Confirm that the service account can access the required configuration without granting access to other credentials.
Test the command in a controlled window with a non-sensitive key or a destination’s supported test workflow, where available. Watch FFmpeg’s output and inspect the result at the platform, not only in a local player. A successful process start proves only that FFmpeg began; a successful connection message does not prove that a viewer receives the right picture and sound. Check a loop boundary as well, because discontinuities or a broken source near the end may only become apparent after the file repeats.
If the source is a set of cartoons rather than one file, do not simply append filenames to the one-file pattern. Playlist handling, gaps, differing dimensions and audio layouts need a deliberate design. The related 24/7 Marathi stream with FFmpeg offers another use case to compare, but its commands should not be treated as universally compatible either.
Run FFmpeg under systemd
A systemd service lets the operating system track FFmpeg as a long-running process rather than relying on a terminal session staying open. Put a unit file in the appropriate systemd location for your host, with an ExecStart that runs FFmpeg directly. Avoid starting it through an unnecessary shell wrapper: direct execution makes the supervised process clearer and simplifies stop and restart behaviour.
A minimal unit pattern might look like this, with paths, account and environment file changed for the machine:
[Unit]
Description=Cartoon live stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
Group=streamer
EnvironmentFile=/etc/cartoon-stream.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/cartoon/cartoon.mp4 -map 0:v:0 -map 0:a? -c:v libx264 -c:a aac -f flv ${RTMP_URL}/${STREAM_KEY}
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This is a starting shape, not a portable drop-in. Verify that FFmpeg is at the given path, that the service user and group exist, that the environment file is readable only by appropriate users, and that the unit’s variable expansion behaves as intended on your systemd version. In particular, test how the configured secret values reach FFmpeg without exposing them in process inspection or logs. Network-online ordering does not guarantee that a remote ingest endpoint is reachable or that DNS, routing and authentication are healthy.
Ubuntu’s systemd.service manual recommends Restart=on-failure for long-running services. This makes systemd attempt recovery after certain failures, but not after a normal stop requested through systemd. Restart attempts are subject to start-rate limits, so a process that exits repeatedly may eventually stop being restarted until the condition is addressed or the limit is reset. RestartSec= adds a pause before another attempt; choose a delay suited to the endpoint and investigate repeated failures instead of masking them with aggressive retries.
Before enabling a unit, use the verification tools available on that Ubuntu release and review systemd’s output for syntax or execution errors. Reload systemd after changing unit files, then start the service and check its state. A reboot test is useful only after you have confirmed that the service starts safely and does not publish an unintended test feed. Ensure media storage and any secret file are available before the service starts; dependencies and mount ordering vary by setup.
Choose the recovery layer for the failure
There are several distinct things that can go wrong, and one restart setting does not cover them all. A source file that is unreadable is not fixed by reconnecting. A brief output network interruption is not the same as FFmpeg exiting. A dead host cannot be restarted by a service manager running on that host. A destination outage may reject new connections even while the local machine and process are healthy.
FFmpeg offers recovery mechanisms with different scopes. Protocol reconnect options documented for supported input protocols concern those inputs; do not assume they restore an RTMP output. The FIFO muxer documentation describes an output-recovery pattern, including attempts to recover from temporary output failures while FFmpeg continues processing. It is a separate option to evaluate, not a substitute for process supervision. Read the FIFO and protocol sections in FFmpeg’s complete documentation and confirm support in your installed build before adapting any example.
| Failure or choice | What may help | What it does not establish |
|---|---|---|
| FFmpeg process exits after an error | systemd Restart=on-failure can start a new process |
No gap-free recovery, and repeated starts can hit rate limits |
| Temporary output failure while FFmpeg remains alive | An appropriate FIFO output recovery pattern may retry | It cannot guarantee the endpoint accepts the next publishing session |
| Input protocol interruption | Relevant protocol options may apply to supported inputs | Input reconnect options do not automatically repair a separate output connection |
| Host loses power or becomes unreachable | Host-level power, network and provider recovery procedures | systemd cannot supervise a machine that is not running |
| Destination rejects or interrupts ingest | Check platform status, key, endpoint and current ingest requirements | A locally active process does not prove a healthy viewer stream |
Use the least complicated recovery design that covers the failure you actually expect, then test it deliberately where safe. If both FFmpeg recovery and systemd restarts are configured, understand which layer handles a failure and how logs distinguish the cases. A restart usually creates a new publishing attempt and may interrupt viewers; it does not promise no gap, no repeated content or platform availability.
Validate logs and the viewer output
After starting the unit, inspect its state and recent logs:
systemctl status cartoon-stream.service
journalctl -u cartoon-stream.service
Use the actual unit name in place of the example. FFmpeg’s own messages can show whether it opened the file, found the expected streams, connected and encountered errors. Treat logs as clues, not as the final health check. A service can be active while output is frozen, silent, incorrectly mapped or rejected downstream.
Verify the broadcast at the destination using its preview, dashboard or a separate viewer. Confirm picture, audio, orientation, intended channel and loop behaviour. If the platform offers stream health information, review it alongside the local logs. Do not leave a public test stream running while troubleshooting rights, credentials or encoding. A key change or endpoint change should be followed by a new validation pass.
Monitor practical constraints over time: disk growth, CPU load, memory, network stability, and log volume. If you re-encode, compare actual resource use with the capacity available on that host. If you use a filesystem mount, check whether it remains present after reboot. If you rotate or replace a file, confirm the service can still read it and decide whether a restart is needed to pick up the new content.
You should also make a controlled failure test: stop the process in a planned way, confirm that a requested stop behaves as intended, and separately observe how a failure is logged and restarted. Avoid simulating a failure on a public channel without warning or a safe maintenance window. Record what happened and how long the destination took to show the feed again; do not treat one successful recovery as a guarantee of future uninterrupted service.
Decide whether to maintain Ubuntu yourself
A self-managed Ubuntu stream is useful when you need to choose the exact FFmpeg build, control the host and inspect systemd behaviour. The trade-off is that you own updates, secrets, filesystem readiness, monitoring and diagnosis when a stream drops overnight. A shell command that worked during setup still depends on the machine, media and destination remaining in the expected state.
If the recurring burden is keeping a local or rented computer awake and bringing the broadcast back after a process failure, StreamNeo removes that particular task by letting you upload a video and run the YouTube broadcast without leaving your own computer switched on. It does not change the need to use authorised content or check YouTube’s current requirements. It is YouTube-only, so it is not a fit if your destination is another platform or your workflow requires a custom Ubuntu process.
Choose based on what you need to operate, not on an uptime promise. If you prefer direct control, keep the FFmpeg and systemd configuration small, documented and tested against your own channel. If you prefer not to administer that machine, account for the limits of a managed workflow before moving an existing schedule or key.
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 -stream_loop -1 guarantee a seamless cartoon loop?
No. It requests repeated input playback, but it does not guarantee a clean transition, uninterrupted output or a healthy destination session. Inspect the source around its end and beginning, then verify the loop at the platform.
Will systemd restart FFmpeg if YouTube disconnects?
Only if FFmpeg exits in a way that systemd treats as a failure; a process that remains alive may not trigger a service restart. Output recovery and process restart are different mechanisms, and neither guarantees that a new ingest session will be accepted.
Can I use cartoons that I own on DVD or as downloaded files?
Owning a copy does not by itself establish permission for a continuous public broadcast. Confirm the rights that apply to the works, intended use and territory with the relevant rights holder, and check the platform’s current policies before publishing.
How do I know the stream is actually working?
Check the systemd state and journal, then inspect the destination’s stream preview or a separate viewer for picture and sound. A running FFmpeg process is not enough; continue monitoring logs and host resources for errors or repeated reconnects.